لماذا يتفوق سحب الـ allowance على الضمان ومفاتيح الجلسة
20 أبريل 2026 — على كل منتج اشتراكات بالكريبتو أن يحل المشكلة نفسها: كيف يأذن الدافع بمدفوعات مستقبلية دون التخلي عن الحفظ؟ هناك ثلاث إجابات واقعية. اخترنا سحب الـ allowance، ويشرح هذا المقال السبب.
النماذج الثلاثة
1. سحب الـ allowance (approve في ERC-20 + delegate في SPL)
يوقّع الدافع approve(spender, cap) مرة واحدة على عقد الرمز. لاحقًا، يستدعي الـ spender (أي SubscriptionHub لدينا أو برنامج سولانا) الدالة transferFrom (EVM) أو يحوّل بصلاحية التفويض (SOL) عند استحقاق فترة. يحتفظ الدافع بالحفظ؛ ويمكن للـ spender سحب ما يصل إلى cap طوال عمر الاشتراك.
الإلغاء: يوقّع الدافع approve(spender, 0) أو Revoke. ومن تلك اللحظة لا يمكن أن ينجح أي سحب.
هذا ما يستخدمه الخصم التلقائي أصلًا اليوم. تنقل المرحلة 2 الـ spender من محفظة ساخنة تتحكم بها المنصة إلى عقد على السلسلة، لكن جهة الدافع لا تتغير.
2. إيداع ضمان (escrow)
يودع الدافع أموال N فترة في عقد ضمان خاص بكل اشتراك. يُفرج العقد عن الأموال للتاجر وفق الجدول. ويمكن للدافع سحب الرصيد غير المستخدم في أي وقت (ناقص الفترات المدفوعة).
3. محفظة ذكية بمفاتيح جلسة
يستخدم الدافع محفظة ذكية ERC-4337 ويمنح مفتاح جلسة محدود النطاق لعقد الاشتراك. لا يستطيع مفتاح الجلسة إلا فعل ما يسمح به نطاقه (مثل «تحويل ما يصل إلى X من USDC كل 30 يومًا إلى هذا العنوان»). ويلغي الدافع الإذن بحذف مفتاح الجلسة.
التقييم
قيّمنا النماذج الثلاثة على خمسة محاور:
| المحور | سحب الـ allowance | الضمان | مفاتيح الجلسة |
|---|---|---|---|
| الحفظ أثناء الاشتراك النشط | الدافع | عقد الضمان | الدافع (عبر المحفظة الذكية) |
| خطوات الإعداد للدافع | توقيع واحد | إيداع واحد (مع غاز) | تسجيل واحد في محفظة 4337 |
| توافق محفظة الدافع | كل المحافظ | كل المحافظ | محافظ 4337 فقط |
| الأموال المقفلة / رأس المال العامل | لا شيء | N شهر مقفلة | لا شيء |
| تجربة الإلغاء | إلغاء الـ approve | سحب + إلغاء | حذف مفتاح الجلسة |
| مخاطر الـ keeper | أي مستدعٍ | أي مستدعٍ | أي مستدعٍ |
| التعقيد من جهة التاجر | أدنى حد | محاسبة الإفراج | إعداد bundler في 4337 |
| يعمل مع MetaMask / Phantom | نعم | نعم | ليس بشكل أصيل |
| يعمل مع Ledger / محافظ الأجهزة | نعم | نعم | جزئيًا |
| الوضوح التنظيمي | عالٍ | أقل (له رائحة الضمان) | عالٍ |
لماذا ليس الضمان
للضمان أجمل عرض تسويقي («أموال الدافع مقفلة في عقد، لا لدى شركة») لكنه يملك أسوأ تجربة فعلية:
- لا يحب الدافعون قفل أموال N شهر. اشتراك بقيمة 20 دولارًا شهريًا مع ضمان لمدة 12 شهرًا يعني 240 دولارًا مقفلة. وهذا سقف لمعدل التحويل.
- تصبح السحوبات معقدة: يجب على العقد تتبّع الفترات المدفوعة وغير المدفوعة، ومعالجة الاستردادات الجزئية، ومنع التاجر من الوصول إلى الأموال المستقبلية.
- «ضمان يحتفظ بأموال العملاء» له رائحة تنظيمية في عدة ولايات قضائية لا يملكها «allowance لعقد ذكي».
لماذا ليست مفاتيح الجلسة
مفاتيح الجلسة على محافظ 4337 الذكية أنيقة. لكنها تتطلب أن تكون محفظة الدافع محفظة ذكية. ما زال معظم الدافعين في 2026 يستخدمون حسابات EOA (MetaMask وRabby ومحافظ الأجهزة وموقّعي Safe)، ويستخدم دافعو سولانا محافظ keypair على نمط Phantom. فرض التسجيل في 4337 من أجل اشتراك يقتل معدل التحويل.
هناك مسار تصبح فيه 4337 المحفظة الافتراضية للدافع وتصبح مفاتيح الجلسة أمرًا بسيطًا. لم نصل إلى هناك بعد.
لماذا يفوز سحب الـ allowance اليوم
- لا تغيير في محفظة الدافع. تعمل أي محفظة تستطيع توقيع
approveفي ERC-20، أي كلها. - لا أموال مقفلة. يحتفظ الدافع بالحفظ؛ ويحدث السحب في الوقت المناسب تمامًا.
- الإلغاء عالمي.
approve(0)أوRevokeمكوّن تعرضه واجهة كل محفظة أصلًا. - الـ keeper سلعة متاحة.
SubscriptionHub.charge(id)عامة ودون إذن. يمكن لـ NestJS أو Chainlink أو Gelato أو AVS في EigenLayer (راجع المرحلة 6) استدعاؤها جميعًا. - الرواية التنظيمية أبسط. لا تحتفظ المنصة أبدًا بالأموال أثناء انتقالها.
القيود المعروفة وكيف نحد منها
سحب الـ allowance ليس مثاليًا. العيوب بصراحة:
1. الموافقات غير المحدودة
كثيرًا ما تقترح المحافظ قيم approve غير محدودة افتراضيًا. والعقود الخبيثة ذات الـ allowances غير المحدودة تفرغ المحافظ. حلّنا: تطلب الواجهة صراحةً موافقة محدودة (مثل 12 × monthly_amount لاشتراك سنوي)، وتعرض المبلغ بالدولار، وتقدّم نص «ألغِ في أي وقت». ويفرض العقد cap بشكل منفصل عن allowance في ERC-20.
2. الإلغاء بين الدورات
يمكن للدافع الإلغاء في منتصف الاشتراك فيفشل الخصم التالي. هو نمط الفشل نفسه لبطاقة محفوظة أُلغيت. يُعالج عبر الـ webhook + البريد الحاليين: subscription-insufficient-allowance.hbs وsubscription-past-due.hbs.
3. allowance قديم بعد تغيير السعر
إذا رفع التاجر السعر في منتصف الاشتراك، فقد يصبح cap القديم أصغر من اللازم. يُعالج ذلك بثابت cap الذي يُفشل charge() (revert)، وبواجهة التاجر التي تطلب موافقة جديدة.
4. خصم مزدوج بسبب إعادة التنظيم
يمكن لبوت يستغل إعادة تنظيم الكتل أن يكرر charge(). يُعالج ذلك عبر lastChargedAt الرتيب في SubscriptionHub.
ما الذي يتغير للدافعين اليوم
لا شيء. يطلب تدفق الخصم التلقائي الحالي أصلًا approve(spender, amount) وSPL Approve؛ الخطوات نفسها. تنقل المرحلة 2 الـ spender إلى عنوان عقد غير احتجازي. وتعرض محفظتك شاشة الأذونات نفسها.
ما الذي يتغير للتجار
لا شيء في شكل استجابة API. يشير الحقل approval_spender_address في كائن auto_charge الخاص بالاشتراك ببساطة إلى عقد SubscriptionHub بدلًا من محفظة OrcaRail الساخنة. وتُرسل الـ webhooks في اللحظات نفسها.
الملخص
| الاعتبار | الفائز |
|---|---|
| تجربة تسجيل الدافع | سحب الـ allowance |
| رأس المال العامل | سحب الـ allowance / مفاتيح الجلسة |
| توافق المحافظ | سحب الـ allowance |
| الوضوح التنظيمي | سحب الـ allowance / مفاتيح الجلسة |
| مرونة الـ keeper | الثلاثة |
| بساطة العقد | سحب الـ allowance |
يفوز سحب الـ allowance بوضوح في توافق المحافظ ورأس المال العامل، ويتعادل أو يفوز في كل المحاور الأخرى. ولهذا بُنيت اشتراكات OrcaRail عليه.
ذو صلة: المرحلة 2: اشتراكات بسحب الـ allowance · توثيق الخصم التلقائي · نموذج الأمان