خارطة طريق OrcaRail نحو نموذج غير احتجازي
20 أبريل 2026 — ننشر اليوم خارطة الطريق الكاملة لنقل OrcaRail من نموذج الكنس (sweep) الاحتجازي الحالي (ننشئ عنوان إيداع لكل رابط دفع، ثم نكنس الأموال ونقسّمها) إلى نموذج غير احتجازي قائم على العقود الذكية (تصل الأموال إلى عقد خاص بكل رابط يقسّمها ويسوّيها بشكل ذري، وتسحب الاشتراكات من allowance يتحكم به الدافع).
هذا المقال هو الفهرس. لكل مرحلة مقال تفصيلي وصفحة توثيق حيّة، لتتمكن من الربط مباشرةً بالجزء الذي يهمك.
لماذا نفعل ذلك
التدفق الحالي يعمل، لكنه يعاني من مشكلة هيكلية بسيطة: بين الإيداع والتسوية، تحتفظ OrcaRail بالأموال. يبقى هذا صحيحًا رغم أننا لا نحتفظ أبدًا بالأرصدة التشغيلية للتجار؛ فاللحظة العابرة بين «أرسل الدافع» و«استلم التاجر» احتجازية. إزالة هذه اللحظة مكسب للأمان والامتثال والموثوقية.
بشكل ملموس، يبدو المسار القديم هكذا:
والهدف هو:
لا تمر الأموال أبدًا عبر محفظة نتحكم بها. يحدث التقسيم على السلسلة. وتسحب الاشتراكات من allowance يمكن للدافع إلغاؤه في أي وقت.
ما الذي يتغير، في صفحة واحدة
| المجال | قبل | بعد |
|---|---|---|
| عناوين روابط الدفع | EOA مشتق من HD أو smart account من Alchemy لكل رابط | CREATE2 حتمي على EVM؛ وPDA على سولانا، دون أي مفاتيح تخزنها OrcaRail |
| التسوية | معاملة كنس بعد الرصد | تقسيم ذري داخل العقد المستقبِل في معاملة الدفع نفسها |
| الاشتراكات | سحب احتجازي من محفظة يموّلها التاجر | يوقّع الدافع approve من ERC-20 أو delegate من SPL؛ ويستدعي الـ keeper الدالة charge(id) |
| Keeper | مُجدوِل واحد في NestJS | NestJS أساسي + Chainlink Automation أو Gelato احتياطي (+ EigenLayer اختياري) |
| عبر الشبكات | جسر Relay ينفّذه الـ keeper | مسار Relay نفسه، لكن كاستدعاء على السلسلة من مستقبِل غير احتجازي |
| بيتكوين | محفظة ساخنة مع xpub محفوظ على الخادم | توقيع متعدد taproot اثنان من اثنين لكل رابط (التاجر + المنصة) مع استردادات موقّعة مسبقًا |
خارطة الطريق
كل مرحلة مستقلة وقابلة للإطلاق. تزيل المراحل الأولى الحفظ عن الأحجام الأكبر (مدفوعات واشتراكات EVM)، وتتناول المراحل اللاحقة الشبكات الأصعب واللامركزية الاختيارية.
- المرحلة 0: تصميم منظومة دفع غير احتجازية — تجميد مواصفات الرسوم والتقسيم، واختيار الشبكات، وجهة التدقيق، وتوقيع النشر المتعدد، ومصفوفة قرار نموذج الاشتراك.
- المرحلة 1: روابط دفع قائمة على العقود في EVM —
PaymentLinkFactory+PaymentLinkReceiver+FeeSplitter، وعناوين حتمية، ومفهرس أحداث. - المرحلة 2: اشتراكات بسحب الـ allowance —
SubscriptionHub، وتدفق جديد للدافع، وkeeper يحل محل معالج الخصم التلقائي الاحتجازي. - المرحلة 3: التوسع إلى شبكات EVM متعددة وتكرار الـ keepers — Ethereum وArbitrum وOptimism وPolygon + احتياطي Chainlink/Gelato.
- المرحلة 4: سولانا غير احتجازية مع PDAs من Anchor — برامج Anchor باسم
payment_linkوsubscription، وخصم تلقائي عبر delegate من SPL. - المرحلة 5: بيتكوين، taproot اثنان من اثنين ونطاق صريح — حفظ مخفَّض، واستردادات موقّعة مسبقًا، وLightning BOLT12 كعمل مستقبلي.
- المرحلة 6: مُجدوِل لامركزي وEigenLayer — متى يفيد الـ AVS ومتى لا يفيد.
- المرحلة 7: إيقاف بنية الحفظ — حذف
hd_wallet_seed، وإزالة مسارات الكنس، وتحديث شروط الخدمة.
يشرح مقال مرافق، لماذا يتفوق سحب الـ allowance على الضمان (escrow) ومفاتيح الجلسة، كيف اخترنا نموذج الاشتراك.
ماذا يعني ذلك عمليًا
للتجار: بعد المرحلة 1 لا يتغير شيء في API؛ تعمل روابط الدفع والـ webhooks كما هي. تنتقل قواعد السحب من «التسوية بعد الكنس» إلى «الإرسال عند الدفع». تحصل على مسار أسرع وأرخص وأكثر قابلية للتدقيق دون تغيير الكود. تضيف المرحلة 2 نقطة نهاية عامة جديدة ليسجّل الدافعون approve الخاص بهم على السلسلة، بما يطابق التدفق الموثق في الخصم التلقائي.
للدافعين: تبقى المدفوعات الفردية كما هي تمامًا. تضيف الاشتراكات توقيعًا إضافيًا واحدًا عند الإعداد (approve على السلسلة) ومسار «إلغاء» أوضح: ألغِ على السلسلة وستتوقف OrcaRail عن المحاولة. لا تغادر أموالك محفظتك حتى يسحبها العقد، ولا تستقر أبدًا في محفظة نتحكم بها.
للمطورين المتكاملين: يبقى شكل API مستقرًا. الحقول الجديدة (عناوين العقود، شبكة النشر، بيانات الـ allowance الوصفية) إضافية فقط، وخلف feature flag لكل شبكة. تواصل التكاملات الحالية العمل خلال دورة التجديد الحالية وتنتقل عند الاختيار.
ما الذي يبقى احتجازيًا (حاليًا)
بيتكوين. سنخفّض الحفظ بشكل ملموس في المرحلة 5 بنقل كل رابط إلى توقيع متعدد taproot اثنان من اثنين مع موقّع من جهة التاجر، إضافةً إلى PSBT استرداد موقّعة مسبقًا. لكن الطبقة الأولى من بيتكوين لا تملك اليوم القدرة التعبيرية للعقود اللازمة لإلغاء الحفظ كليًا. تبقى اشتراكات BTC خارج النطاق حتى تجهز المدفوعات المتكررة عبر Lightning BOLT12.
الجدول الزمني والحالة
تُتابَع الخطة الكاملة في /docs/non-custodial/roadmap، ولكل مرحلة صفحة حالة:
- مخطط لها: 0 — 7
- قيد التنفيذ: لا شيء بعد
- أُطلقت: لا شيء بعد
سننشر مقال تحديث مؤرخًا في كل مرة تُطلق فيها مرحلة.
اقرأ توثيق البنية
للنسخة المرجعية من كل ذلك (مخططات البنية، وواجهة العقود، ودليل الترحيل، ونموذج الأمان) ابدأ من /docs/non-custodial/overview.