موافقات التوكنات والـ Allowance والـ Permit: ما الذي توقّعه فعلاً

موافقة التوكن (approval) إذنٌ على السلسلة مخزَّن داخل عقد توكن ERC-20 — يُسمّى allowance — يسجّل أن عقداً محدداً واحداً يجوز له إنفاق ما يصل إلى مقدار محدد من توكناتك، في أي لحظة لاحقة، دون أن يسألك مجدداً. تنشأ هذه الموافقة بمعاملة approve()، وتبقى حيّة بعد انتهاء التفاعل الذي منحتها لأجله: قد يختفي الموقع ويبقى الـ allowance. ويستبدل Permit (EIP-2612) تلك المعاملة المنفصلة بتوقيع خارج السلسلة تقدّمه الـ dApp مع إجرائها، بينما يوسّع Permit2 النموذج نفسه — المحدود بمهلة وبمقدار — ليشمل توكنات لم تنفّذ EIP-2612 قط؛ ما يعني أن التوقيع صار قادراً على تسليم سلطة إنفاق، فباتت طلبات التوقيع تستحق التدقيق الذي كانت تناله الموافقات. أما الدفاع فغير مبهر: وافق على مقادير محددة بدل غير المحدودة، وألغِ الـ allowances التي لم تعد تستخدمها. وفي محفظة غير وصائية بالكامل مثل WATS — حيث يحتفظ المستخدم بالمفاتيح ولا تحتفظ WATS بمفتاح أبداً — لا تحدث أي موافقة ولا توقيع Permit ولا إلغاء إلا بتوقيع مفتاحك أنت، ولأن رسوم الشبكة تُحتسب برمز واحد هو ATS، لا تتأجل معاملة التنظيف يوماً بسبب نفاد رمز الغاز الأصلي لتلك السلسلة.

لماذا تطلب تطبيقات dApp الموافقة أصلاً

لتوكنات ERC-20 خاصية تشكّل نصف تجربة استخدام Web3: لا يستطيع العقد الذكي ببساطة أخذ التوكنات من عنوانك، حتى عندما تريد ذلك. منصة DEX التي تبدّل USDC الخاص بك تحتاج أولاً إلى إذنك الصريح. لهذا تتكون تفاعلات كثيرة من خطوتين — معاملة approve أولاً، ثم المبادلة أو الإيداع الفعلي. الموافقة ليست إجراءً شكلياً؛ إنها تفويض إنفاق دائم، يعيش أطول من المعاملة التي منحته لأجلها.

ما الذي يمنحه approve() فعلاً

عندما توقّع موافقة، يسجّل عقد التوكن allowance: يمكن للعنوان X (عقد الـ dApp) إنفاق ما يصل إلى N من توكناتك، وقتما يشاء، حتى تُستهلك الـ allowance أو تُخفَّض أو تُلغى. خاصيتان مهمتان هنا. الأولى: الـ allowance يقيم داخل عقد التوكن ويُمنح للعقد الذي وافقت عليه، لا للموقع الذي زرته — قد تختفي الواجهة ويبقى الإذن. الثانية: لا شيء في الـ allowance يتطلب مشاركتك لحظة الإنفاق — فبمجرد منحها، يستطيع العقد المعتمد سحب التوكنات في أي معاملة لاحقة دون توقيع آخر منك. هذا بالضبط ما يجعل الموافقات مفيدة — وهذا بالضبط ما يجعلها سطح هجوم.

الموافقات غير المحدودة: مريحة، وخطر دائم

لأن كل موافقة تكلّف غازاً، تطلب dApps كثيرة allowance غير محدودة عملياً كي لا تضطر للموافقة مجدداً أبداً. الراحة حقيقية، وكذلك الصفقة: allowance غير محدودة لعقدٍ ما تعني أن كامل رصيدك من ذلك التوكن يعتمد إلى الأبد على أمان ذلك العقد. إذا استُغل العقد بعد سنوات — أو كان خبيثاً منذ البداية — فلن يحتاج المهاجم إلى مفتاحك ولا توقيعك؛ يكفيه الـ allowance الذي منحته. كثير من أكبر حوادث إفراغ المحافظ لم تكن سرقة مفاتيح، بل صرف موافقات قديمة.

Permit وPermit2: موافقات بالتوقيع

التحسين الحديث هو Permit (EIP-2612): بدلاً من معاملة approve على السلسلة، توقّع رسالة خارج السلسلة تقدّمها الـ dApp مع إجرائها — معاملة واحدة بدل اثنتين، بلا غاز موافقة منفصل، ويمكن تحديد الإذن بمهلة زمنية. أما Permit2 فيعمّم الفكرة على التوكنات التي لم تنفّذ EIP-2612 قط، عاملاً كمركز موافقات مشترك: تمنح موافقة واحدة عادية على السلسلة لعقد Permit2 نفسه، ثم يُصرَّح لكل dApp بعد ذلك بتوقيع يحمل مقداره ومهلته الخاصة. ويستحق هذا التنازل دقةً في الوصف — Permit2 لا يلغي الموافقات، بل يجمّعها في مكان واحد، ومن ثم فإن الـ allowance الدائم الذي منحته لـ Permit2 هو نفسه موافقة عليك متابعتها. هذه تحسينات حقيقية، لكن انتبه لما تغيّره: التوقيعات تؤدي الآن العمل الذي كانت تؤديه المعاملات. موقع تصيّد يجعلك توقّع رسالة Permit الخاطئة يحقق النتيجة نفسها التي تحققها موافقة خبيثة — لذا فإن قراءة ما توقّعه أهم من أي وقت مضى، لا أقل.

سطح الهجوم: أدوات الإفراغ والـ allowances الراكدة

إساءة استخدام الموافقات تأتي بنكهتين. نشطة: مواقع drainer تنتحل صفة dApps حقيقية وتطلب موافقات (أو توقيعات Permit) متنكرة في هيئة إجراءات بريئة مثل «المطالبة» أو «التحقق من المحفظة». وخاملة: allowances منحتها قبل سنوات لعقود مشروعة تظل نائمة حتى يُخترق العقد أو مفاتيح إدارته أو مسار ترقيته. كلاهما سبب لمعاملة تدفق الاتصال-والموافقة بوصفه اللحظة الحرجة أمنياً في Web3 — نغطي الطريقة الآمنة في كيفية توصيل محفظتك بتطبيق dApp.

نظافة موافقات تعمل فعلاً

ثلاث عادات تغطي معظم الخطر. وافق على مقادير محددة عندما تسمح الـ dApp بذلك، خصوصاً للأرصدة الكبيرة — الموافقة الإضافية لاحقاً تأمين رخيص. راجع وألغِ الـ allowances دورياً عبر أداة فحص موافقات موثوقة، معاملاً كل ما لم تعد تستخدمه كوزن ميت يجب إزالته — والإلغاء نفسه معاملة على السلسلة تعيد الـ allowance إلى الصفر، أي أنه يكلّف غازاً ويحتاج توقيعك مثل أي معاملة أخرى. واحتفظ بالحيازات الجادة في عنوان لا يوقّع الموافقات إطلاقاً، منفصل عن محفظة dApp النشطة. عادات أكثر تعمقاً في أفضل ممارسات أمان المحافظ.

أين تقع WATS من هذا

الموافقات توقيعات، والتوقيعات أرض المحفظة. WATS غير وصائية بالكامل — أنت تحتفظ بمفاتيحك، وWATS لا تحتفظ بمفتاح أبداً — لذا فإن كل موافقة وتوقيع Permit وإلغاء لا يحدث إلا حين يوقّعه مفتاحك أنت، من امتداد Chrome أو تطبيق الجوال أو الـ Hot Wallet، عبر Ethereum وArbitrum وOptimism وBase وPolygon وBNB Chain وSolana وTON. وهذا يرسم أيضاً الحد الصادق لما تستطيع أي محفظة فعله نيابةً عنك: تستطيع المحفظة أن تعرض عليك الطلب، لكن وحدك من يقرر أن المُنفِق والمقدار هما ما قصدته فعلاً.

وجانب الرسوم يزيل العذر الشائع الآخر لترك الـ allowances القديمة في مكانها. في WATS يُحتسب كل إجراء، بما فيه معاملات الموافقة والإلغاء، برمز واحد هو ATS بدلاً من رمز الغاز الأصلي لكل سلسلة — عبر paymaster بمعيار ERC-4337 على EVM ودافع رسوم/مرحّل مكافئ على Solana وTON. وهذا ليس خصماً: تأخذ الشبكة مستحقها كاملاً، والتكلفة الأساسية لا تتغير؛ ما يتغير هو الرمز الذي يدفع. ويُحرق ما يُجمع من ATS من معروض 100 مليون نحو أرضية 30 مليوناً، ولأن ATS هو OFT من LayerZero، يغطي رصيد واحد كل السلاسل المدعومة. وWATS هي المحفظة الأولى والوحيدة التي تجمع رسوم الرمز الواحد عبر ERC-4337 وOFT مع هذا الحرق — التفاصيل على صفحة رسوم ATS.

الخلاصة العملية لهذا المقال روتين قصير: فضّل الموافقات محددة المقدار، واقرأ ما يفوّضه توقيع Permit فعلاً قبل أن توقّعه، وافتح مرة كل ربع سنة أداة فحص موافقات ونظّف المُنفِقين الذين لم تعد تستخدمهم. والخطوة الملموسة أن تشغّل هذا الروتين من محفظة لا تقف يوماً بينك وبين مفتاحك: في Hot Wallet من WATS أو امتداد Chrome أو تطبيق الجوال، لا توجد أي موافقة ولا أي إلغاء إلا لأن مفتاحك أنت وقّعه — وWATS لا تحتفظ بمفتاح أبداً — ويُدفع الإلغاء بـ ATS بدلاً من أي رمز غاز أصلي تصادف أن تطلبه تلك السلسلة.