إنتقل إلى المحتوى الرئيسي

المرحلة 2: اشتراكات EVM (السحب من الـ allowance)

الحالة: مخطط لها.

SubscriptionHub مع charge(id) عامة. يوقّع الدافع approve(spender, cap) مرة واحدة؛ ويفرض المركز التوقيت والحد الأقصى والـ allowance والرصيد. يحل الـ keeper محل معالج الخصم التلقائي الاحتجازي.

النطاق​

  • تنفيذ SubscriptionHub وتدقيقه.
  • يوجّه تطبيق الدفع approve إلى عنوان المركز.
  • تقبل API ‏approve-auto-charge قيم allowance يكون فيها المركز هو الجهة المخوّلة.
  • يرحّل المشتركون الحاليون اختياريًا عند التجديد.

الكود المتأثر​

  • api/src/scheduler/processors/subscription-auto-charge.processor.ts: السحب عبر SubscriptionHub.charge بدلًا من smart account احتجازي.
  • تطبيق pay: تتغير قيمة إعداد الجهة المخوّلة إلى عنوان المركز.
  • لوحة التحكم: شريط ترحيل للاشتراكات القائمة.
  • جديد: مُفهرِس مخصص للاشتراكات (يعيد استخدام بنية المرحلة 1).

الأثر على التشغيل / تجربة المستخدم​

  • يرى الدافع أن الجهة المخوّلة عقد بدلًا من محفظة ساخنة. خطوة approve الواحدة على السلسلة دون تغيير.
  • الإلغاء عبر واجهة المحفظة (approve(0) أو ما يكافئه)، كما يوثّق الخصم التلقائي.
  • تُطلق webhooks التاجر في اللحظات نفسها وبالأشكال نفسها.
  • واجهة جديدة: زر «الانتقال إلى غير الاحتجازي» في صفحة تفاصيل الاشتراك.

القيود الحالية​

  • يجب أن تكون الـ allowance كافية؛ وتفشل عمليات الخصم ذات الـ allowance غير الكافية بـ ChargeSkipped(InsufficientAllowance).
  • تتطلب تغييرات الحد الأقصى أن يعيد الدافع الموافقة.
  • معرّف الاشتراك من نوع bytes32؛ ويظهر كحقل إضافي في كائن الاشتراك.

منشور المدونة المرتبط​

المرحلة 2: اشتراكات السحب من الـ allowance

قائمة التحقق من الحالة​

  • تنفيذ SubscriptionHub بكل الثوابت
  • اختبارات fuzz والثوابت (الحد الأقصى والـ allowance والـ reorg وحالات التخطي)
  • دمج التدقيق التكميلي الخاص بالمركز
  • تجهيز EOA للـ keeper لكل سلسلة ومراقبته
  • نقل تطبيق الدفع هدف approve إلى المركز
  • تحديث نقطة النهاية approve-auto-charge
  • تفعيل شريط لوحة التحكم
  • ترحيل مجموعة canary واستقرارها لمدة 14 يومًا