المرحلة 0: تصميم منظومة دفع غير احتجازية

20 أبريل 2026 — قبل أن نكتب سطرًا واحدًا من Solidity، نجمّد المواصفات. المرحلة 0 هي مرحلة التصميم والاعتماد في خارطة الطريق غير الاحتجازية: ما الذي ينتقل إلى السلسلة وما الذي لا ينتقل، وأي شبكة تُطلق أولًا، ومن يدقق العقود، ومن يحتفظ بمفاتيح النشر.

باختصار

• جُمّد تقسيم الرسوم على أربع حصص: التاجر، والمنصة، والإحالة/الشريك، ورسوم الجسر. كل ما في الموزّع على السلسلة قابل للتعبير بنقاط الأساس؛ دون تصحيحات خارج السلسلة.
• Base هي شبكة إطلاق المرحلة 1. رخيصة وسريعة، وموجودة أصلًا في قائمة شبكات خدمة المحافظ، وتدعم USDC الأصلي.
• تعتمد الاشتراكات approve + السحب في ERC-20 (EVM) وdelegate في SPL (سولانا). رُفضت تصاميم الضمان (escrow) ومفاتيح الجلسة؛ راجع مصفوفة القرار أدناه.
• تُنشر العقود عبر توقيع متعدد Safe ثلاثة من خمسة (EVM) وتوقيع متعدد Squads ثلاثة من خمسة (سولانا). المستقبِلات لكل رابط غير قابلة للتغيير. والمصانع وSubscriptionHub خلف proxy صغير مع قفل زمني 48 ساعة.

ما الذي تغيّره هذه المرحلة

لا شيء في بيئة الإنتاج. المرحلة 0 عبارة عن مواصفة مكتوبة، وثلاثة عروض تدقيق، ومراسم لمفاتيح النشر، وبضعة ADRs مدمجة.

مواصفة تقسيم الرسوم (مجمّدة)

اليوم، تجمع SmartAccountWalletService.drainSmartAccountWallet في api/src/withdrawals/services/smart-account-wallet.service.ts التحويلات في UserOperation بثلاثة مستلمين: التاجر (toAddress)، ومحفظة الدعم (supportWalletAddress)، ومحفظة العمولة. ونسخة العقد تعكس ذلك تمامًا:

struct Split {
    address merchant;   // main receiver
    address platform;   // support / platform fee
    address referral;   // commission / affiliate (optional, zero = skip)
    address bridgeFee;  // Relay bridge fee carrier (optional, zero = skip)
    uint16 platformBps;
    uint16 referralBps;
    uint16 bridgeFeeBps;
}

كل ما يفعله الـ keeper اليوم بلغة TypeScript قابل للحساب من هذه الـ struct ومبلغ الدفعة. وكل ما لا يستطيع الـ keeper الحالي التعبير عنه (مثل الضرائب الديناميكية أو المبالغ المحتجزة على مستوى التاجر) خارج نطاق المرحلة 1؛ ونضيفه في مرحلة لاحقة عند الحاجة.

اختيار الشبكة

شبكة إطلاق المرحلة 1 هي Base:

• موجودة أصلًا في خريطة chainId لدينا (8453 → base، 84532 → baseSepolia) في api/src/payments/wallet.service.ts.
• الغاز رخيص بما يكفي لتكون تكلفة نشر PaymentLinkReceiver + التقسيم عند أول دفعة بضعة سنتات لكل معاملة.
• سياسة الـ paymaster من Alchemy تدعمها أصلًا، ما يمنحنا مخرجًا إذا أردنا رعاية غاز الـ keeper في SubscriptionHub.charge().
• USDC أصلي (غير منقول عبر جسر)، وهذا مهم لـ allowances الاشتراكات.

تأتي Ethereum mainnet وArbitrum وOptimism وPolygon في المرحلة 3. أما سولانا فبرنامج منفصل يُتابع في المرحلة 4.

نموذج الاشتراك: مصفوفة القرار

قيّمنا ثلاثة تصاميم. واحد فقط يناسبنا.

النموذج	الحفظ	تجربة الدافع	توافق المحافظ	متطلبات الـ keeper	الحكم
approve + السحب في ERC-20 (المختار)	لا يوجد	approve لمرة واحدة	MetaMask وPhantom وLedger وSafe — أصلي	أي مستدعٍ؛ الـ keeper اختياري	نطلق هذا
إيداع ضمان (escrow)	لا يوجد	إيداع N شهر	جميع المحافظ	أي مستدعٍ	تجربة أسوأ؛ أموال مقفلة
محفظة ذكية + مفاتيح جلسة	لا يوجد	التسجيل في 4337	محافظ 4337 فقط	موقّع مفاتيح الجلسة	توافق ضيق جدًا

approve + السحب هو الوحيد الذي يعمل مع المحافظ التي يستخدمها الدافعون أصلًا (MetaMask وPhantom ومحافظ الأجهزة وSafe). وهو أيضًا التصميم الذي ننشره في الخصم التلقائي، الذي يوثّق approve(spender, amount) والتفويض في SPL. تستبدل المرحلة 2 جهة السحب بعقد ذكي وتترك جهة الدافع دون تغيير.

الحجة المفصلة موجودة في لماذا يتفوق سحب الـ allowance على الضمان ومفاتيح الجلسة.

حفظ مفاتيح النشر

• EVM: Safe (سابقًا Gnosis Safe) على Base مع عتبة ثلاثة من خمسة. الموقّعون: مؤسسان، ومسؤول عمليات، ومستشار، ونسخة احتياطية باردة. كل موقّع يستخدم محفظة أجهزة؛ لا مفاتيح على أي خادم.
• سولانا: توقيع متعدد Squads بالإعداد نفسه ثلاثة من خمسة والموقّعين أنفسهم.
• التدوير: يُدوَّر كل موقّع سنويًا أو عند المغادرة؛ وكل تدوير هو معاملة Safe/Squads.
• لا يمكن لأي keeper ساخن النشر. حساب EOA الخاص بالـ keeper في NestJS (المستخدم لاستدعاء charge() في المرحلة 2) لا يملك صلاحية نشر ولا صلاحية ترقية ولا عنوان رسوم.

سياسة الترقية

• PaymentLinkReceiver لكل رابط: غير قابل للتغيير. لا ترقية. هذا مكسب ثقة للدافعين؛ فالكود الذي يدفعون إليه لا يمكن أن يتغير لاحقًا.
• PaymentLinkFactory: proxy صغير من نوع UUPS يملكه التوقيع المتعدد، مع قفل زمني 48 ساعة على upgradeTo. لا يمكن للترقيات تغيير المستقبِلات المنشورة مسبقًا.
• SubscriptionHub: النمط نفسه. دلالة charge() وcancel() مستقرة بين الإصدارات؛ وإذا احتجنا يومًا إلى تغيير غير متوافق، ننشر SubscriptionHubV2 وننقل البيانات بدلًا من الترقية.
• دلالة الاسترداد والنزاعات: refund(txId) على السلسلة، يمكن أن يستدعيه موقّع التاجر (عبر مفتاح API الخاص به ← EOA الخاص بالـ keeper) أو التوقيع المتعدد للنشر. لا يمكن للدافع استرداد المبلغ بنفسه (كما في المنتج الحالي).

استراتيجية جهات التدقيق

سنختار قائمة قصيرة من ثلاث شركات ونجري تدقيقًا أساسيًا + مراجعة تنافسية:

• المرشحون الأساسيون (EVM): Spearbit وTrail of Bits وZellic.
• المرشحون الثانويون (سولانا): OtterSec وNeodyme.
• النطاق: PaymentLinkFactory وPaymentLinkReceiver وFeeSplitter وSubscriptionHub. برامج Anchor لها تدقيقها الخاص في المرحلة 4.
• الميزانية: التدقيق شرط مسبق صارم للإطلاق على Base mainnet. لا إطلاق على الشبكة الرئيسية قبل تقرير إصلاح كل الملاحظات.
• الإفصاح العام: تُضاف تقارير التدقيق إلى المستودع ويُربط إليها من /docs/non-custodial/security-model.

المخاطر ووسائل الحد منها

• توسع نطاق المواصفات. الحل: كل ما لا يمكن التعبير عنه كتقسيم بنقاط الأساس يُؤجَّل إلى مرحلة لاحقة. لا تتوقف المرحلة 1 على الضرائب الديناميكية أو الاستثناءات لكل تاجر.
• توفر موقّعي التوقيع المتعدد. الحل: ثلاثة من خمسة، لا اثنان من ثلاثة، كي يمكن غياب أي موقّعَين دون تجميد عمليات النشر.
• توقيت التدقيق. الحل: بدء المحادثات مع الجهات الآن؛ ونشر العقود على الشبكة التجريبية أثناء التدقيق؛ والنشر على الشبكة الرئيسية مشروط.
• حالة رسوم منسية. الحل: إعادة إنتاج كل مسار حالي في drainSmartAccountWallet (أصلي + ERC-20، مع/بدون دعم، مع/بدون عمولة) كاختبار invariant في Foundry قبل التدقيق.

قائمة الحالة

• اعتماد struct تقسيم الرسوم ووسمها
• اختيار Base كشبكة إطلاق المرحلة 1
• اختيار قائمة قصيرة من ثلاث جهات تدقيق
• إنشاء واختبار توقيعات النشر المتعددة Safe (Base) وSquads (سولانا)
• دمج ADR حول سياسة الترقية والقفل الزمني
• دمج ADR حول قرار نموذج الاشتراك
• توثيق دلالة الاسترداد / النزاعات

ما التالي

تنفّذ المرحلة 1 المواصفات: روابط دفع قائمة على العقود في EVM.

---

التوثيق المرجعي: حالة المرحلة 0 · نموذج الأمان · البنية