نظرة عامة على عدم الاحتجاز
تنتقل OrcaRail من نموذج احتجازي قائم على التجميع (محفظة HD على الخادم لكل رابط دفع، تُجمَّع أموالها وتُقسَّم بعد رصدها) إلى نموذج عقود غير احتجازي (تصل الأموال إلى عقد ذكي خاص بكل رابط يقسّمها ذريًا، وتسحب الاشتراكات من allowance يتحكم فيه الدافع). هذا القسم هو المرجع الأساسي لهذا الانتقال.
الإعلان السردي موجود في /blog/non-custodial-roadmap. هذه الصفحة هي نقطة الدخول الثابتة؛ وتشير منشورات المراحل وصفحات التوثيق إليها.
من يتأثر بذلك
- التجار: لا تتغير واجهة API لديك. تحتفظ روابط الدفع والـ webhooks وكائنات الاشتراك بشكلها. ما يتغير في الخلفية هو مكان وجود الأموال أثناء انتقالها.
- الدافعون: المدفوعات لمرة واحدة متطابقة. تحتفظ الاشتراكات بعملية
approveواحدة على السلسلة (EVM) أو بتفويض SPL (Solana)، لكن الجهة المخوّلة بالإنفاق تصبح عقدًا ذكيًا قابلًا للتدقيق بدلًا من محفظة ساخنة لـ OrcaRail. - المطوّرون المدمِجون: حقول إضافية فقط (عناوين العقود وبيانات الـ allowance الوصفية). لا يُزال أي شيء قائم دون فترة إهمال.
بيان المشكلة
في النظام الحالي، يحصل كل رابط دفع على EOA مشتق من HD أو على smart account من Alchemy. تصل الإيداعات إليه، ثم يجمعها keeper في api/src/withdrawals/ وينفّذ التقسيم بين التاجر والمنصة والإحالة. يحتفظ الـ keeper بمواد المفاتيح (عبارة mnemonic مشفّرة في hd_wallet_seed) وبالأموال قيد الانتقال.
نافذة الاحتجاز هذه هي المشكلة. إزالتها مكسب أمني، وتبسيط للامتثال، ومكسب تشغيلي (لا مزيد من رسوم غاز التجميع، ولا مفتاح تشفير mnemonic يجب حمايته).
الحالة المستهدفة
- EVM: يحسب
PaymentLinkFactoryعنوان CREATE2 لكل رابط؛ وتقبل نسخPaymentLinkReceiverالأموال وتقسّمها ذريًا عبرFeeSplitter. تعمل الاشتراكات علىSubscriptionHubباستخدامapproveفي ERC-20. - Solana: يملك برنامج Anchor
payment_linkحساب PDA لكل رابط؛ ويسحب برنامجsubscriptionعبر صلاحية تفويض SPL. - Bitcoin: توقيع متعدد taproot من نوع 2 من 2 لكل رابط مع موقّع من التاجر ومعاملات PSBT للاسترداد موقّعة مسبقًا. المدفوعات المتكررة بـ BTC خارج النطاق حتى ينضج Lightning BOLT12.
- Keeper: نقاط دخول
charge()عامة؛ NestJS أساسي، وChainlink Automation أو Gelato احتياطي؛ وAVS اختياري على EigenLayer إن احتجنا إليه يومًا.
راجع البنية للمخطط الكامل.
مسار القراءة
- ابدأ بـ البنية للصورة على مستوى النظام.
- اقرأ نموذج الأمان لافتراضات الثقة وحفظ المفاتيح.
- اطّلع على مرجع العقود للدوال وواجهات ABI.
- اقرأ دليل الترحيل إذا كانت لديك روابط أو اشتراكات قائمة.
- استخدم استراتيجية الـ keeper لفهم كيفية تنفيذ عمليات الخصم وأهداف SLO.
- راجع اعتبارات Bitcoin للنطاق الصريح لـ BTC.
- اقرأ تقييم EigenLayer لموقفنا من الـ keepers اللامركزية.
- تابع خارطة الطريق لحالة كل مرحلة.
حالة المراحل (ملخص)
القائمة الكاملة للمراحل وحالاتها في خارطة الطريق. فهرس سريع:
- المرحلة 0: التصميم واستراتيجية التدقيق
- المرحلة 1: عقود روابط الدفع على EVM
- المرحلة 2: اشتراكات EVM (السحب من الـ allowance)
- المرحلة 3: التوسع متعدد EVM وتكرار الـ keepers
- المرحلة 4: Solana (برامج Anchor)
- المرحلة 5: Bitcoin (احتجاز مُقلَّص)
- المرحلة 6: keepers لامركزية (EigenLayer)
- المرحلة 7: إيقاف البنية الاحتجازية
وثائق ذات صلة
- الاشتراكات: الخصم التلقائي: مسار approve/revoke من جهة الدافع (متوافق مع الجهة المخوّلة غير الاحتجازية الجديدة).
- السحوبات: الاستراتيجية: كيف تعمل مسارات التسوية لكل عائلة سلاسل.
- المرجع: تعدد السلاسل: الشبكات المدعومة وتغطية الرموز.