الجواب القصير
لا: مفتاح الوكيل الموافق عليه على Hyperliquid لا يستطيع السحب من حسابك، ولا يستطيع إرسال USDC أو رموزك إلى أي مكان، لأن المنصة ترفض له تلك الأفعال لما هو عليه لا للمبلغ. ويستطيع وضع الأوامر وإلغاءها، وقد استطاع شيئًا آخر بمالك: إيداع الحساب في خزينة على Hyperliquid.
وكل ما يلي قياس واحد على الشبكة الرئيسية، في 28 سبتمبر 2026، بمفتاح وكيل حقيقي موافق عليه على حساب اختبار. وصفحة محفظة الوكيل في هذا الموقع تحمل السجل نفسه.
كيف قيس
وافق حساب اختبار يحمل نحو 60 USDC على مفتاح وكيل جديد لساعة واحدة، كما يفعل Locker Vault في الإنتاج. ثم وقّع مفتاح الوكيل كل فعل يحرّك المال، كل واحد بمبلغ 1,000 USDC، أكبر بكثير من رصيد الحساب، فلم يكن شيء ليتحرك، ولم يكن المهم إلا سبب كل رفض.
ثم وقّع الحساب الطلبات نفسها. فحيث نال الوكيل جوابًا مختلفًا عن جواب الحساب، كان قد أُوقف لأنه وكيل. وحيث نال الاثنان الجواب نفسه، أُعيد الفعل بمبلغ صغير، نحو مقصد يبقى للحساب.
ماذا أجابت Hyperliquid
| فعل وقّعه مفتاح الوكيل | جواب Hyperliquid |
|---|---|
| وضع أمر ثم إلغاؤه | مقبول |
السحب (withdraw3) | مرفوض |
إرسال USDC أو رمز (usdSend وspotSend وsendAsset) | مرفوض |
النقل بين الفوري والعقود الدائمة (usdClassTransfer) | مرفوض |
الموافقة على وكيل ثان (approveAgent) | مرفوض |
الموافقة على رسم مُنشئ (approveBuilderFee) | مرفوض |
إيداع الحساب في خزينة (vaultTransfer) | مقبول |
كل رفض كان يُقرأ على النحو نفسه: Must deposit before performing actions، ويسمّي عنوان الوكيل نفسه. فقد طبّقت Hyperliquid الفعل على عنوان الوكيل، وهو لا يحمل شيئًا، بدل الحساب الذي وافق عليه. والطلبات نفسها موقَّعة بالحساب نفسه لاقت أخطاء رصيد، وهذا جواب آخر.
ولم يظهر وكيل ثان في قائمة الحساب بعد approveAgent المرفوض. ورُفضت كذلك الموافقة على رسم المُنشئ، وهذا يوافق الوثائق: فذلك الفعل يجب أن توقّعه محفظة المستخدم الرئيسية، لا محفظة وكيل.
حركة الأموال الواحدة التي وقّعها
vaultTransfer لا يُطبَّق على الموقِّع: فهو فعل على الطبقة الأولى، وقد ألحقته Hyperliquid بالحساب الذي وافق على المفتاح. ولمّا طلب 1,000 USDC نال الوكيل جواب نقص الأموال نفسه الذي ناله الحساب، فأُعيد الاختبار بـ 5 USDC نحو HLP، خزينة Hyperliquid نفسها، مقصد يبقى للحساب. ونجح: فهبط رصيد الحساب الفوري من 60.78 إلى 55.78 USDC، وقرأ رأس ماله في الخزينة 5.0.
مفتاح الوكيل المسروق لا يستطيع إخراج مالك، لكنه يستطيع نقله إلى خزينة يديرها غيرك، ومشغّلها يستطيع بعدها أن يخسره متداولًا مع نفسه. فجملة مفتاح الوكيل لا يستطيع إلا التداول خاطئة. وقد صحّحنا صفحاتنا التي قالتها، ولهذا فإن الحدّ الوحيد الذي يصمد حقًّا هو حساب لا يحمل إلا ما أنت مستعد لخسارته.
ما يضيفه الحارس
lpa لا يوقّع ذلك الفعل أبدًا. فحارسه يوقّع قائمة مغلقة من أفعال التداول: وضع الأوامر وتغييرها وإلغاؤها، وضبط رافعة سوق وهامشه، وضبط رمز الإحالة. وvaultTransfer ليس في القائمة، فلا ينتج عنه أي أمر منك أو من سكربت أو من مساعد ذكاء اصطناعي.
والإيداعات والسحوبات ونقل الهامش بين منصات dex توقّعها محفظتك: في Locker Vault، على الهاتف خارج الشبكة، في مراسم QR، أو طلبًا توافق عليه في إضافة متصفحك أو محفظة هاتفك. ويراجع الحارس أيضًا كل فتح على حدود هذا الحاسوب وعلى التفويض الذي وقّعته محفظتك، ولا يجيب إلا الطلبات التي تحمل الرمز الذي كتبه حين بدأ.
وهذا حدّ على lpa لا على المفتاح. فالسارق الذي يحمل ملف المفتاح المختوم وكلمة مرورك لا يحتاج lpa، ولا يوقفه أي ملف على حاسوبك.
الحدّ الذي يصمد فعلًا
ثلاثة أمور تصمد مهما جرى على الحاسوب: المنصة ترفض لذلك المفتاح كل سحب وكل إرسال، والموافقة تنتهي من نفسها، والحساب المستعمل للوكيل وحده لا يحمل إلا ما وضعته فيه. والأخير وحده هو الحدّ الذي لا يتوقف على برمجية.
ولإنهائه: lpa mandate revoke يوقف كل فتح في الحال ولا يحتاج محفظة؛ وlpa agent revoke يُحيل المفتاح عند المنصة، بمحفظتك؛ وlpa panic يوقف كل طيّار وكل نسخة ويخرج المفتاح من الذاكرة. ولا يغلق أي من الثلاثة مركزًا.