إفصاح: تنشر OrcaRail هذه المدونة وهي إحدى البوابات المدرجة. كل رقم يخص المنافسين مأخوذ من صفحة الأسعار أو التوثيق الخاص بكل مزوّد، وتم التحقق منه في 13 أكتوبر 2026، مع رابط للمصدر. الأسعار تتغير، لذا تحقّق مع المزوّد قبل أن تقرر.

مقارنة سريعة​

رسوم الشبكة (الغاز) إضافية في كل البوابات، ومن يدفعها يعتمد على المزوّد وإعداداتك.

كيف تختار بوابة الدفع بالعملات الرقمية؟​

• تبيع اشتراكات؟ اختر بين بوابات ترسل فاتورة في كل دورة يدفعها العميل يدويًا، وبوابات تخصم تلقائيًا بناءً على موافقة يوقّعها العميل مرة واحدة. الخصم التلقائي يقلّل فقدان العملاء. على السلسلة، يعمل ذلك عبر allowance لرمز ERC-20 على شبكات EVM أو تفويض رمز SPL على Solana. لماذا اخترنا السحب عبر allowance.
• الرسوم حسب حجم مبيعاتك. النسبة الثابتة سهلة الحساب. أما الرسوم الثابتة لكل فاتورة، مثل 0.25$ لدى BitPay، فتثقل المدفوعات الصغيرة.
• الحفظ والتسوية. بعض البوابات تحتفظ بأموالك وتدفع لك بعملة ورقية. وأخرى ترسل العملات المستقرة مباشرةً إلى محفظة تتحكم بها أنت.
• العملات المستقرة والشبكات. تأكد من أن الرموز التي يملكها عملاؤك (USDC و USDT) مقبولة على الشبكات التي يستخدمونها.
• الاختبار. تتيح لك بيئة Sandbox على الشبكات التجريبية تجربة التدفق كاملًا، بما في ذلك Webhooks والتجديدات، دون أموال حقيقية.

OrcaRail​

OrcaRail واجهة برمجية موجهة للمطورين لـ صفحات الدفع والاشتراكات بالعملات المستقرة على شبكات EVM و Solana.

• الرسوم: 0.5% لكل معاملة مكتملة على المنصة المستضافة، وأول 1,000 معاملة مجانية. لا رسوم لـ OrcaRail عند الاستضافة الذاتية. راجع الأسعار.
• الدفع المتكرر: طريقتان للتحصيل. رابط دفع لكل دورة، أو خصم تلقائي على السلسلة يسحب كل تجديد من allowance لرمز ERC-20 (EVM) أو تفويض SPL (Solana). راجع الاشتراكات.
• الحفظ: غير حاضنة افتراضيًا. تُسوّى المدفوعات إلى عناوين سحب تتحكم بها أنت.
• أدوات المطورين: REST API، و Webhooks موقّعة، و SDK لـ Node و PHP، وحزمة Laravel Cashier، وإضافة WooCommerce، وخادم MCP لوكلاء البرمجة بالذكاء الاصطناعي.
• الاختبار: مؤسسات Sandbox مجانية على الشبكات التجريبية مع مفاتيح ak_test_.

Coinbase Commerce​

Coinbase Commerce هي صفحة الدفع للتجار من Coinbase.

• الرسوم: 1% لكل معاملة، حسب صفحة Commerce.
• الدفع المتكرر: لا توثّق Coinbase Commerce ميزة اشتراكات مدمجة.
• ملاحظة: أعلنت Coinbase أنها ستدمج Commerce في Coinbase Business. تحقّق مما إذا كان التسجيل متاحًا في بلدك.

BitPay​

BitPay من أقدم معالجات الدفع بالعملات الرقمية، وتسوّي المدفوعات إلى حساب بنكي أو بعملة رقمية.

• الرسوم: متدرجة حسب الحجم الشهري. 2% + 0.25$ لكل فاتورة مدفوعة تحت 500 ألف دولار شهريًا، و1.5% + 0.25$ حتى مليون دولار، و1% + 0.25$ فوق ذلك. راجع دعم BitPay.
• الدفع المتكرر: قائم على الفواتير. يدفع العميل كل فاتورة بنفسه.

NOWPayments​

NOWPayments تدعم قائمة طويلة من العملات الرقمية.

• الرسوم: تبدأ من 0.5% للمدفوعات بدون تحويل عملة، و1% للمدفوعات مع التحويل. راجع الأسعار.
• الدفع المتكرر: Recurring Payments API ترسل فواتير أو طلبات دفع في كل فترة فوترة.

CoinGate​

CoinGate معالج مستضاف مقره الاتحاد الأوروبي.

• الرسوم: 1% لكل معاملة في باقة Standard، دون رسوم شهرية. أسعار Enterprise مخصصة. راجع الأسعار.
• الدفع المتكرر: منتج Billing يرسل «فواتير لمرة واحدة أو مجدولة».

CoinPayments​

CoinPayments تدعم عملات ورموزًا كثيرة.

• الرسوم: 3% لكل دفعة إضافةً إلى رسوم الشبكة، حسب صفحة الرسوم. تذكر الصفحة أيضًا باقة مجانية، لكنها تنطبق فقط على الإيداع في المحافظ الشخصية، لا على مدفوعات التجار.
• الدفع المتكرر: غير موثّق في صفحة الرسوم.

Cryptomus​

Cryptomus تقدّم المدفوعات والتحويلات والصرف في حساب واحد.

• الرسوم: تدفع الحسابات الجديدة 2% لكل معاملة. وحسب نوع النشاط وحجم التداول وطريقة التكامل، قد تنخفض النسبة إلى 0.4%. راجع رسوم الدفع.
• الدفع المتكرر: متاح كخدمة مدفوعات متكررة.

مدفوعات Stripe بالعملات المستقرة​

Stripe تقبل العملات المستقرة وتسوّيها في رصيدك على Stripe بالعملة الورقية المحلية.

• الرسوم: 1.5% من مبلغ المعاملة بالدولار. راجع توثيق Stripe.
• الرموز: USDC على Tempo و Ethereum و Solana و Polygon و Base. وتُقبل USDP و USDG على بعض الشبكات، في الولايات المتحدة فقط.
• الدفع المتكرر: نعم، عبر اشتراكات Stripe Billing.
• القيود: يجب أن تكون الشركة في بلد مدعوم. الولايات المتحدة متاحة للجميع، والاتحاد الأوروبي وهونغ كونغ والمكسيك وسويسرا في معاينة خاصة. يمكن للعملاء دفع حتى 10,000$ لكل معاملة، ولا تدعم مدفوعات العملات المستقرة الاعتراضات (disputes).

MoonPay Commerce (سابقًا Helio)​

MoonPay Commerce هو منتج Helio السابق الذي نشأ في منظومة Solana.

• الرسوم: 1% أو 2% لكل معاملة حسب الباقة وفئة المخاطر. التبديل (swap) بتكلفة إضافية 0.25% والتحويل التلقائي إلى عملة ورقية (off-ramp) بـ 0.5%. راجع الأسعار.
• الدفع المتكرر: الاشتراكات مدعومة.

BTCPay Server​

BTCPay Server برنامج مجاني ومفتوح المصدر للاستضافة الذاتية، يركّز على Bitcoin و Lightning.

• الرسوم: لا رسوم معالجة. تدفع تكلفة الاستضافة وتدير الخادم بنفسك.
• الدفع المتكرر: ليس ميزة أساسية.
• الحفظ: غير حاضن بالكامل. تذهب المدفوعات إلى محفظتك الخاصة.

الخلاصة​

• أقل رسوم معلنة على منصة مستضافة: OrcaRail (0.5%، أول 1,000 معاملة مجانًا) و NOWPayments (من 0.5% بدون تحويل). تصل Cryptomus إلى 0.4% بعد التفاوض فقط.
• مجاني وباستضافة ذاتية: BTCPay Server لـ Bitcoin، أو OrcaRail باستضافة ذاتية للعملات المستقرة على EVM و Solana.
• اشتراكات تلقائية على السلسلة دون فاتورة لكل دورة: الخصم التلقائي في OrcaRail. تدعم Stripe Billing أيضًا الاشتراكات بالعملات المستقرة، برسوم 1.5% وتسوية بعملة ورقية.
• التسوية إلى بنك بعملة ورقية: Stripe أو BitPay.

لتجربة OrcaRail، افتح Sandbox مجانية واتبع دليل البدء.

لا تحتاج إلى أي رموز إطلاقًا إن كنت تريد رؤية التدفق فقط: انقر على محاكاة الدفع في صفحة دفع الـ sandbox، أو استدعِ POST /payment_intents/:id/simulate. راجع محاكاة المدفوعات.

ما الذي تحتاجه​

• الرمز الذي تدفع به: USDC على شبكات EVM وسولانا، أو BTC على بيتكوين.
• الغاز للمعاملة: ETH على شبكات EVM أو SOL على سولانا. وتدفع بيتكوين رسومها بـ BTC.

استخدم محفظة الدافع التي ستربطها في صفحة دفع OrcaRail.

USDC لكل الشبكات: صنبور Circle​

يرسل صنبور USDC من Circle عملة USDC تجريبية مجانية على كل شبكة EVM تجريبية أدناه وعلى Solana Devnet. اختر الشبكة، والصق عنوان محفظتك، واطلب الرموز.

شبكات EVM التجريبية​

يسرد توثيق الشبكات أيضًا صنابير: Arbitrum وBase.

Solana Devnet​

Bitcoin testnet4​

تستخدم OrcaRail شبكة testnet4 من بيتكوين (المستكشف: mempool.space testnet4). استخدم محفظة تدعم عناوين testnet4.

نصائح​

• تحدّ الصنابير عدد الطلبات، غالبًا بطلب واحد لكل عنوان يوميًا. اطلب مبكرًا.
• تطلب بعض صنابير الغاز تسجيل الدخول أو امتلاك رصيد صغير على الشبكة الرئيسية.
• تعرض الـ sandbox الخاصة بك بالضبط الشبكات التجريبية المفعّلة. راجع الشبكات التجريبية والصنابير للقواعد: لا يمكن للمؤسسات الحية استخدام الشبكات التجريبية، ولا يمكن للـ sandbox استخدام الشبكات الرئيسية.

ما الذي أصبح مفتوح المصدر​

هذه الحِزم عامة على GitHub ومرخّصة بموجب MIT:

ثبّتها من npm أو Composer كالمعتاد؛ ومصدر الحقيقة لكل حزمة هو مستودعها المذكور أعلاه.

استخدم، أبلغ، ساهم​

استخدم الحِزم في تطبيقاتك. وجّه الوكلاء والأشخاص إلى المستودعات وإلى docs.orcarail.com لواجهات API والأمثلة.

أبلغ عن الأخطاء وطلبات الميزات في GitHub Issues للحزمة التي تهمك:

• issues لـ Node SDK
• issues لـ PHP SDK
• issues لـ Laravel Cashier
• issues لـ MCP
• issues لإضافة WooCommerce
• issues لتطبيق العرض التوضيحي

ساهم متى استطعت: انسخ المستودع (fork)، وافتح طلب سحب، وأبقِ التغييرات مركّزة. نرحب بشكل خاص بإصلاحات التوثيق والاختبارات وتحسينات SDK الصغيرة. وإن لم تكن متأكدًا من مكان شيء ما، فافتح issue أولًا.

لماذا يهم ذلك​

الحِزم والإضافات المفتوحة تعني أنه يمكنك فحص كيفية تواصل OrcaRail مع منظومتك، وسد الثغرات دون انتظار مزوّد مغلق، ومشاركة التحسينات مع كل من يدمج البنية نفسها.

تبقى OrcaRail المستضافة واجهة المنتج للمدفوعات ولوحات التحكم والبنية التحتية للإنتاج. يتعلق هذا الإعلان بـ حِزم المطورين التي تتكامل معها، وليس ادعاءً بأن المنصة كلها مفتوحة المصدر.

الملخص​

شكرًا لبنائك على OrcaRail. إن أطلقت شيئًا مفيدًا، فافتح PR، أو issue إن احتجت إلى مساعدة.

تطبيق OrcaRail · التوثيق · GitHub

هذا المقال هو الفهرس. لكل مرحلة مقال تفصيلي وصفحة توثيق حيّة، لتتمكن من الربط مباشرةً بالجزء الذي يهمك.

لماذا نفعل ذلك​

التدفق الحالي يعمل، لكنه يعاني من مشكلة هيكلية بسيطة: بين الإيداع والتسوية، تحتفظ OrcaRail بالأموال. يبقى هذا صحيحًا رغم أننا لا نحتفظ أبدًا بالأرصدة التشغيلية للتجار؛ فاللحظة العابرة بين «أرسل الدافع» و«استلم التاجر» احتجازية. إزالة هذه اللحظة مكسب للأمان والامتثال والموثوقية.

بشكل ملموس، يبدو المسار القديم هكذا:

والهدف هو:

لا تمر الأموال أبدًا عبر محفظة نتحكم بها. يحدث التقسيم على السلسلة. وتسحب الاشتراكات من allowance يمكن للدافع إلغاؤه في أي وقت.

ما الذي يتغير، في صفحة واحدة​

خارطة الطريق​

كل مرحلة مستقلة وقابلة للإطلاق. تزيل المراحل الأولى الحفظ عن الأحجام الأكبر (مدفوعات واشتراكات 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.

تطبيق OrcaRail · التوثيق · التوثيق غير الاحتجازي

هذه الورقة توسّع خارطة الطريق غير الاحتجازية ونقاش البروتوكول، ولا تحل محلهما. تزيل خارطة الطريق غير الاحتجازية (المسار N، المراحل 0-7) الحفظ. وتضيف هذه الورقة مسارًا موازيًا P يجعل الباقي لامركزيًا: المفهرسات، والواجهات الأمامية، والمعايير، والـ keepers، والحوكمة.

الملخص​

بروتوكول OrcaRail مجموعة من المكوّنات الأساسية على السلسلة (مصانع روابط الدفع ومستقبِلاتها، ومراكز اشتراك بسحب الـ allowance، وموزّعات الرسوم، وبرامج Anchor على سولانا، وواصفات توقيع متعدد taproot على بيتكوين)، إلى جانب مواصفات عامة للمفهرسات والـ keepers والواجهات الأمامية وحِزم SDK التي تعمل فوق هذه المكوّنات. يحقق البروتوكول أربعة ثوابت: غير احتجازي (لا يحتفظ أي طرف بالأموال أثناء انتقالها)، ومتواصل (تستمر التسوية المشروعة دون OrcaRail)، ومحايد بشكل موثوق (لا يستطيع أي طرف منفرد حجب معاملة مدفوعة سليمة البنية)، ومتوافق مع Web2 (يحتفظ التجار بمفاتيح API والـ webhooks ولوحات التحكم). يجري الإطلاق على مسارين متوازيين: المسار N يزيل الحفظ في سبع مراحل؛ والمسار P يجعل الفهرسة والواجهات الأمامية والمعايير وتوجيه التسوية لامركزية في خمس مراحل. لا يوجد أي رمز عند الإطلاق ولا يُخطَّط لأي رمز ضمن هذه الورقة؛ ورمز الحوكمة المستقبلي محجوز صراحةً كخيار لما بعد اللامركزية، وإن طُرح يومًا فسيصدر بورقة بيضاء خاصة به.

1. مقدمة: لماذا بروتوكول وليس مجرد منتج​

تُقدَّم OrcaRail اليوم كمنتج مدفوعات مستضاف، مع خيارات استضافة ذاتية في الطريق. هذا منتج، لا بروتوكول. المنتجات يمكن تحسينها؛ أما البروتوكولات فيمكن الوثوق بها في غياب صانعها.

تُخرج خارطة الطريق غير الاحتجازية الحفظ من المسار. هذا ضروري لكنه غير كافٍ. فحتى دون حفظ، قد تتعطل بنية الدفع إذا توقفت الشركة المشغّلة عن دفع فواتير AWS، أو فُرضت عليها عقوبات، أو ببساطة غيّرت توجهها. يجب أن يستمر البروتوكول في العمل عند حدوث ذلك.

استعرض نقاش البروتوكول خمس بنى. وكانت الخلاصة: أطلق مسار «البراغماتي»، وحافظ على ضغط «المتشدد» عليه، واعتمد الـ intents لتجربة الدافع، واكتب المعايير على طول الطريق، وأبقِ السلسلة الخاصة مستقبلًا اختياريًا. هذه الورقة هي تلك الخلاصة مكتوبة كالتزامات.

2. أهداف التصميم​

يُصاغ كل هدف بتعريف دقيق وقابل للاختبار. يجب أن يكون لسؤال «هل يحقق التصميم ذلك؟» جواب بنعم أو لا.

1. غير احتجازي — في أي لحظة أثناء الدفع أو خصم الاشتراك، لا تحتفظ أي محفظة أو حساب تتحكم به OrcaRail أو معالج التاجر أو أي وسيط بأموال الدافع. الاختبار: هل يمكن لجهة تنظيمية تجميد الأموال أثناء انتقالها بمخاطبة OrcaRail وحدها؟ لا.
2. متواصل — إذا توقفت خوادم OrcaRail إلى أجل غير مسمى، تستمر تسوية خصم الاشتراك المستحق المشروع على السلسلة، ويظل بإمكان الدافع إكمال دفعة فردية. الاختبار: بعد انقطاع OrcaRail لمدة 30 يومًا، هل فات أي اشتراك مضبوط بشكل صحيح خصمًا؟ لا.
3. محايد بشكل موثوق — القواعد على السلسلة عامة، وغير قابلة للتغيير لكل رابط، وتُطبَّق بالتساوي. لا تستطيع OrcaRail حجب الخدمة انتقائيًا في طبقة التسوية (بل في واجهتها الأمامية فقط). الاختبار: هل يمكن لتاجر غير مرغوب فيه أن يتلقى المدفوعات عبر واجهة أمامية لطرف ثالث؟ نعم.
4. متوافق مع Web2 — يحتفظ التجار بالسهولة التي اعتادوها (نقاط نهاية REST، وwebhooks، ومفاتيح API، ولوحات التحكم، والبريد الإلكتروني). التحول إلى بروتوكول لا يتطلب من التاجر تشغيل أدوات Ethereum لقبول دفعة. الاختبار: هل يستطيع تاجر غير متمرس في الكريبتو إتمام التكامل في أقل من ساعة؟ نعم.
5. ند للند حقيقي — يُعرَّف بدقة في القسم التالي.

أي تصميم يخفق في أي هدف يُعدّ ناقصًا.

3. ماذا يعني «ند للند حقيقي» هنا​

مصطلح «ند للند» (P2P) محمّل بمعانٍ كثيرة. في هذا البروتوكول له ثلاث طبقات ملموسة.

• P2P في التسوية — يوقّع الدافع؛ وتتدفق الأموال من الدافع إلى عقد على السلسلة (EVM) أو PDA مملوك للبرنامج (سولانا) أو توقيع متعدد اثنان من اثنين (بيتكوين)، ثم إلى التاجر ومستلمي الرسوم بشكل ذري. لا توجد أي محفظة لـ OrcaRail في المسار. يضمن المسار N ذلك.
• P2P في الاكتشاف — يمكن استخلاص رابط الدفع أو الاشتراك بالكامل من بياناته على السلسلة و(اختياريًا) من بيانات وصفية مثبّتة على IPFS. يمكن لأي محفظة أو واجهة أمامية أو معالج طرف ثالث عرضه وإكماله. لوحة التحكم المستضافة لـ OrcaRail هي إحدى تطبيقات طبقة العرض، وليست السجل.
• P2P في الاستمرارية — SubscriptionHub.charge(id) وتعليمة charge في Anchor عامة. يمكن لأي EOA أو solver استدعاؤها. مُجدوِل OrcaRail مشارك واحد بين عدة مشاركين (Chainlink، وGelato، ومشغّلين من التجار، ومشغّلين من الـ solvers).

ما لا يعنيه «ند للند حقيقي» هنا: لسنا Lightning؛ ولسنا طبقة قنوات مباشرة من محفظة إلى محفظة؛ ولا نستبدل تطبيق دفع بـ DHT. OrcaRail بروتوكول على السلسلة بتجربة استخدام خارج السلسلة. خاصية P2P تأتي من استحالة تدخّل وسيط في التسوية أو الاكتشاف أو الاستمرارية، لا من تجنب البنية على السلسلة.

4. بنية النظام​

على أعلى مستوى، يتكون البروتوكول من خمس طبقات.

طبقة التسوية غير قابلة للتغيير لكل رابط على EVM وسولانا، ومشتقة من الواصفات لكل رابط على بيتكوين. أما الطبقات الأربع الأخرى فقابلة للاستبدال. من يريد المخطط التقني الكامل فليتوجه إلى /docs/non-custodial/architecture.

5. مكوّنات التسوية الأساسية​

المرجع الكامل: /docs/non-custodial/contract-reference. ملخص:

• EVM — PaymentLinkFactory (عناوين حتمية عبر CREATE2)، وPaymentLinkReceiver (نسخة مصغّرة EIP-1167، غير قابلة للتغيير لكل رابط)، وFeeSplitter (تقسيم ذري بنقاط الأساس)، وSubscriptionHub (سحب الـ allowance مع lastChargedAt رتيب).
• سولانا — برنامج Anchor باسم payment_link (PDA لكل رابط، وتقسيم عبر CPI) وبرنامج Anchor باسم subscription (صلاحية delegate من SPL، بدلالة charge مطابقة لمركز EVM).
• بيتكوين — توقيع متعدد taproot اثنان من اثنين لكل رابط (موقّع التاجر + موقّع المنصة من HSM/MPC) مع PSBT استرداد موقّعة مسبقًا. لا مدفوعات BTC متكررة حتى تنضج المدفوعات المتكررة في Lightning BOLT12.

صُمم كل مكوّن بحيث يشير linkId أو subscriptionId نفسه دائمًا إلى العنوان الحتمي نفسه على الشبكة نفسها إلى الأبد: دون تدوير للعناوين، ودون إعادة إصدار، ودون ربط محفوظ على خادم.

6. العمليات عبر الشبكات كـ intents​

البروتوكول الذي يتعامل مع العمليات عبر الشبكات على أنها «الخادم الخلفي لدينا يستدعي Relay» ما زال منتجًا. أما البروتوكول فيتعامل معها على أنها intent من الدافع:

• يوقّع الدافع: «ادفع للتاجر X مبلغ 50 دولارًا بـ USDC، من أي من محافظي على أي شبكة مدعومة، خلال ساعة واحدة، برسوم لا تتجاوز Y».
• تتنافس شبكات الـ solvers القائمة (Across وRelay وdeBridge وعلى نمط CoW) على تنفيذ الـ intent. ويحصل الـ solvers على مكافأة مضمّنة في الـ intent.
• للمسارات الطويلة غير المربحة اقتصاديًا (مبالغ صغيرة، شبكات غير شائعة) تشغّل OrcaRail solver احتياطيًا بسعر التكلفة لضمان تسوية هذه المسارات أيضًا. الاحتياطي عام، ويمكن لأي شخص آخر تشغيل واحد.

توقيع الدافع محدود بالمبلغ والمستلم والمهلة والحد الأقصى للرسوم. في أسوأ الأحوال يكون الـ solver الخبيث بطيئًا؛ ولا يستطيع تحويل الأموال إلى وجهة أخرى. هذه هي خلاصة «المؤمن بالـ intents» من نقاش البروتوكول، مكتوبة كالتزام.

7. المعايير والتشغيل البيني​

مكوّنات روابط الدفع والاشتراكات في OrcaRail بنية عامة. ولا تتضاعف قيمتها إلا إذا طبّقتها معالجات ومحافظ ومفهرسات أخرى بشكل أصيل.

الالتزامات:

• صياغة مسودة EIP لروابط الدفع غير الاحتجازية باستخدام PaymentLinkFactory وPaymentLinkReceiver كواجهة مرجعية. والاشتراك في كتابتها مع فريق معالج أو محفظة آخر على الأقل لتجنب نمط «EIP من مزوّد واحد».
• صياغة مسودة EIP لاشتراكات سحب الـ allowance باستخدام SubscriptionHub كمرجع. lastChargedAt الرتيب ومجموعة أسباب ChargeSkipped(reason) أهداف للتوحيد القياسي.
• نشر مقابل لسولانا عبر IDL من Anchor ومواصفة مكتوبة، لتتمكن أي محفظة أو مفهرس على سولانا من عرض رابط دفع من الأساس.
• نشر مخطط الـ subgraph المرجعي ليكون أي مفهرس (The Graph أو Goldsky أو Envio أو مستضاف ذاتيًا) متوافقًا مباشرةً.

كتابة الـ EIP لا تقلّص ميزتنا التنافسية. كما جادلنا في النقاش، تكمن الميزة في التكاملات والامتثال واتفاقيات مستوى الخدمة وثقة التجار، ولا شيء من ذلك يُنسخ بـ EIP.

8. الحوكمة​

للحوكمة أفقان.

اليوم وعلى المدى القريب​

• EVM: توقيع متعدد Safe ثلاثة من خمسة على كل شبكة منشورة. موقّعون بمحافظ أجهزة. تدوير سنوي. قفل زمني (timelock) لمدة 48 ساعة على ترقيات الـ proxy. نسخ PaymentLinkReceiver لكل رابط غير قابلة للتغيير.
• سولانا: توقيع متعدد Squads ثلاثة من خمسة بمجموعة الموقّعين نفسها وسياسة التدوير نفسها.
• نطاق الترقية: المصانع والمراكز خلف proxies من نوع UUPS؛ ولا تتأثر المستقبِلات لكل رابط وسجلات كل اشتراك بالترقيات.
• قابلية التدقيق العام: يُنفَّذ كل نشر وترقية كمراسم توقيع متعدد مُعلنة مع تسجيل المعاملات الموقّعة.

هذه هي الحوكمة الموصوفة في /docs/non-custodial/security-model.

ما بعد اللامركزية​

مع الوقت، لا تبقى مجموعة الموقّعين مقتصرة على موظفي OrcaRail، بل تصبح مجلسًا عامًا يضم متكاملين وشركات تدقيق ومشغّلي keepers ومساهمين مستقلين. تنتقل صلاحية الترقية إلى المجلس. عندها تصبح الحوكمة على السلسلة خيارًا فعليًا، لكن كآلية حوكمة فقط، لا كأداة مضاربة.

عتبة «ما بعد اللامركزية» صريحة: ثلاث واجهات أمامية مستقلة على الأقل في بيئة الإنتاج تستضيف البنية، وثلاثة keepers مستقلين على الأقل ينفّذون الخصومات، ومعالج واحد على الأقل من غير OrcaRail يطلق تكاملات. وحتى يتحقق ذلك فعليًا، لا يكون البروتوكول لامركزيًا بعد، بغض النظر عن آلية الحوكمة القائمة فوقه.

9. رمز حوكمة مستقبلي (حجز صريح)​

هذا القسم قصير ودقيق عن قصد.

• لا رمز عند الإطلاق. لا بيع مسبق. لا تخصيصات. لا نقاط. لا مطالبات بأثر رجعي.
• رمز الحوكمة المستقبلي محجوز كخيار، لا كالتزام. لا يصبح مناسبًا إلا بعد بلوغ عتبة ما بعد اللامركزية في القسم 8 ووجود قاعدة نشطة من المتكاملين والـ keepers والواجهات الأمامية تستفيد من حقوق رسمية لإبداء الرأي.
• إن طرحنا رمزًا يومًا ما، فسيصدر بورقة بيضاء خاصة به، مع شفافية كاملة بشأن التوزيع وفترات القفل والمعروض ونطاق الحوكمة. وستُناقَش ورقة الرمز علنًا قبل الإصدار.
• سيكون الرمز للحوكمة أولًا، لا للمضاربة. آليات منطقية: تصويت لإبداء الرأي في الترقيات، وضبط المعاملات ضمن حدود آمنة، وسمعة مشغّلي الـ keepers. آليات غير منطقية: خصومات على الرسوم مرتبطة بالحيازة، والدفع مقابل الدفع، وزراعة العوائد (yield farming).
• لن ندّعي أن البروتوكول لامركزي لمجرد وجود رمز. تُقاس اللامركزية بما ورد في القسم 8. الرمز أداة يمكنها إضفاء الطابع الرسمي على لامركزية متحققة بالفعل؛ ولا يمكنها صنعها.

هذا الحجز مدوَّن في الورقة البيضاء للبروتوكول، أي هذه الوثيقة، وليس في أي مكان آخر. وأي تغيير مستقبلي في هذا الموقف هو تغيير في هذه الورقة، يُنشر علنًا، وليس إعلانًا أحادي الجانب.

10. الاقتصاد والرسوم: كيف يستدام البروتوكول دون رمز​

نموذج إيرادات البروتوكول هو نموذج المنتج نفسه، لكنه مُرمَّز على السلسلة.

• يقع تقسيم الرسوم في إعداد نقاط الأساس لـ FeeSplitter لكل دفعة. وهي الحصص نفسها التي تصفها صفحة السحوبات اليوم: التاجر، والمنصة (حصة OrcaRail المستضافة)، والإحالة/الشريك، ورسوم الجسر.
• تُموَّل الخدمات المستضافة من OrcaRail (لوحة التحكم، والبريد الإلكتروني، وغاز الـ paymaster، ودعم العملاء) من حصة OrcaRail في التقسيم.
• يمكن للمستضيفين البدلاء (المعالجات من أطراف ثالثة، والمشغّلين بالاستضافة الذاتية، والواجهات المثبتة على IPFS) العمل بتقسيم صفري لحصة المنصة، أو ضبط مستلم رسوم خاص بهم. لا يفضّل البروتوكول رسوم OrcaRail على رسوم أي طرف آخر.
• لا إصدار رموز، ولا دعم، ولا عوائد staking. التكاليف نقدية والإيرادات نقدية. الطريقة الوحيدة ليصبح البروتوكول أرخص هي أن يرخص الغاز أو أن يقبل مستضيفٌ هامشًا أقل، لا إصدار رموز لتغطية تكاليف التشغيل.

11. نموذج الأمان​

البيان الكامل: /docs/non-custodial/security-model. الموقف الأساسي:

• المستقبِلات لكل رابط وسجلات كل اشتراك غير قابلة للتغيير.
• لا تُرقّى المصانع والمراكز إلا عبر توقيع متعدد + قفل زمني.
• الـ keepers حسابات EOA تدفع الغاز فقط ولا تملك أي صلاحية لنقل الأموال.
• يستخدم توقيع BTC خدمة HSM أو MPC من جهة المنصة، إضافةً إلى مفتاح التاجر؛ ولا يملك أي خادم صلاحية إنفاق أحادية.

إضافة خاصة بالتحول إلى بروتوكول: يجب على مستضيفي الواجهات الأمامية المستقلين التحقق من عناوين العقود مقابل سجل على السلسلة (أو بيان إصدار موقّع) قبل عرض رابط الدفع. الواجهة المستنسخة الخبيثة التي توجّه المدفوعات إلى عقد مشابه هي أرجح وسيلة تصيّد عندما يضم النظام عدة مستضيفين. السجل المرجعي موجود على السلسلة، وتدفق التحقق موثّق كجزء من P2.

12. خارطة الطريق: مساران متوازيان​

يجري إطلاق البروتوكول على مسارين في الوقت نفسه.

المسار N هو خارطة الطريق القائمة دون تغيير. ويحوّل المسار P التزامات M1-M5 من مقال النقاش إلى مراحل رسمية. يستهدف المساران الحالة النهائية نفسها: بنية تستمر في العمل إذا ابتعدت OrcaRail.

لا يعيق المسار P المسار N أبدًا، ولا يعيق المسار N المسار P أبدًا. يمكن لأي منهما إطلاق مرحلة قبل الآخر.

13. مراحل المسار P​

خمس مراحل، كل منها امتداد طبيعي لأحد التزامات M في مقال النقاش.

P1 — subgraph عام ومفهرس مفتوح​

النطاق: subgraph مرجعي (The Graph أو Envio أو ما يعادلهما) يفهرس كل أحداث Paid وSubscriptionCreated وCharged وChargeSkipped وCanceled وRefunded من PaymentLinkReceiver وSubscriptionHub عبر كل الشبكات المنشورة. المخطط منشور. وتعليمات الاستضافة الذاتية منشورة ليتمكن أي شخص من تشغيل الفهرس نفسه.

قائمة الحالة

• بيان الـ subgraph + الـ mappings لشبكات EVM المفعّلة في المرحلة 1 والمرحلة 3
• مقابل على سولانا (webhooks من Helius أو بث Triton) بأشكال الأحداث نفسها
• مخطط موثّق بإصدارات مستقرة
• إثبات تشغيل مفهرس خارجي للمخطط نفسه على أحداث حية

P2 — واجهات أمامية لامركزية (IPFS / ENS)​

النطاق: تثبيت تطبيق الدفع ولوحة تحكم التاجر في OrcaRail على IPFS بحِزم إصدار معنونة بالمحتوى. والوصول إليها عبر ENS (pay.orcarail.eth وapp.orcarail.eth). بناء قابل لإعادة الإنتاج ليتحقق أي قارئ من مطابقة الحزمة للمصدر. على النسخة الخبيثة أن تنتحل عناوين العقود وسجل ENS معًا، لا اسم المضيف فقط.

قائمة الحالة

• بناء تطبيق الدفع قابل لإعادة الإنتاج
• بناء لوحة التحكم قابل لإعادة الإنتاج
• سجلات ENS تشير إلى معرّفات CID على IPFS
• مراسم توقيع الإصدارات من التوقيع المتعدد Safe
• سجل على السلسلة لعناوين العقود تتحقق منه الواجهات قبل العرض

P3 — المعايير (مسودة EIP)​

النطاق: صياغة وتقديم EIP لروابط الدفع غير الاحتجازية وEIP مرافق لاشتراكات سحب الـ allowance. والاشتراك في الكتابة مع فريق معالج أو محفظة آخر على الأقل. التطبيق المرجعي هو عقود OrcaRail. وتُنشر مواصفة سولانا المقابلة إلى جانب الـ EIPs.

قائمة الحالة

• تأكيد الشريك في الكتابة
• مسودة EIP روابط الدفع في مرحلة سلسلة النقاش
• مسودة EIP الاشتراكات في مرحلة سلسلة النقاش
• نشر مواصفة سولانا إلى جانب IDLs من Anchor
• دمج ملاحظات محرري EIP حتى مرحلة Last Call

P4 — SDK للدافع قائمة على الـ intents​

النطاق: واجهة SDK (orcarail.pay(intent)) تقبل intent موقّعًا من الدافع وتوجّهه عبر شبكات الـ solvers القائمة (Across وRelay وdeBridge)، مع solver احتياطي تشغّله OrcaRail للمسارات الطويلة. ويُوحَّد مخطط الـ intent بالتزامن مع P3.

قائمة الحالة

• إنهاء مخطط الـ intent
• محوّل SDK لشبكتي solvers على الأقل
• نشر الـ solver الاحتياطي وقياسه
• دعم تجربة الدافع في تطبيق الدفع للـ intent نفسه + العمليات عبر الشبكات
• نشر المواصفة كجزء من مرجع Node SDK

P5 — حزمة الاستضافة الذاتية / التطبيق المرجعي​

النطاق: ملف Docker Compose (وHelm chart) يتيح لأي شخص تشغيل معالج متوافق مع OrcaRail من البداية إلى النهاية انطلاقًا من العقود العامة. يتضمن الـ subgraph والـ keeper والمفهرس ولوحة تحكم اختيارية ومواصفة OpenAPI لواجهة API الخاصة بالمعالج يمكن للآخرين الالتزام بها.

قائمة الحالة

• Docker Compose يعمل على شبكة حية ويخدم تاجرًا تجريبيًا
• مواصفة OpenAPI لواجهة API الخاصة بالمعالج
• Helm chart لمشغّلي Kubernetes
• اختبار شامل يثبت أن المشغّل بالاستضافة الذاتية يعالج المدفوعات تمامًا مثل النسخة المستضافة
• توثيق في /docs/non-custodial/ (يُضاف في تغيير مستقبلي خاص بالتوثيق؛ خارج نطاق هذه الورقة)

14. P6 اختيارية: تقييم سلسلة خاصة​

تتبع P6 نمط تقييم EigenLayer. وهي ليست التزامًا، بل مراجعة ربع سنوية بمحفزات محددة.

التوصية الحالية: التأجيل.

المحفزات التي تستدعي فتح وثيقة تصميم لبناء المرحلة P6:

1. تجاوز حجم المدفوعات على شبكة واحدة عتبةً يصبح عندها الغاز بندًا جوهريًا في رسوم المنصة.
2. توفير سلسلة أدوات L2/L3 مرجعية لـ precompiles متخصصة لمنطق تقسيم المدفوعات بتكلفة شبه معدومة.
3. طلب التجار لزمن تسوية بأجزاء من السنت لا تستطيع الشبكة الرئيسية / L2 تلبيته باستمرار.
4. شريك rollup-as-a-service يتيح لـ OrcaRail الإطلاق بتسلسل مشترك من اليوم الأول.

إن تحققت المحفزات، فسيُفضَّل البناء على OP Stack مع تسلسل مشترك (Espresso، Astria) وجسر خروج موثوق إلى الشبكات المرجعية التي ندعمها بالفعل. وحتى حينها، يجب أن تكون المراحل N0-N7 وP1-P5 ناضجة بما يكفي لتكون السلسلة الخاصة تحسينًا لا اعتمادًا.

15. ما هي OrcaRail اليوم وما الذي ستصبح عليه​

مقارنة قبل وبعد على مستوى البنية.

تبقى الواجهة الموجّهة لـ Web2 مستقرة عن قصد. التجار الذين تكاملوا مع REST API في 2026 لن يتعطلوا في 2028.

16. نموذج التهديدات​

التهديدات التي نتعامل معها صراحةً، مع وسائل الحد منها:

• خلل في عقد ← عدة عمليات تدقيق لكل عقد؛ مستقبِلات غير قابلة للتغيير لكل رابط؛ ترقيات UUPS خلف قفل زمني 48 ساعة على المصانع والمراكز؛ برنامج مكافآت أخطاء عام.
• انقطاع الـ keeper ← تكرار الـ keepers في المرحلة 3 من المسار N (Chainlink/Gelato) + شبكة الـ solvers في P4 من المسار P + استدعاء charge() يدوي عام كاحتياطي.
• تصيّد عبر الواجهات الأمامية ← سجل العقود على السلسلة في P2 من المسار P + العنونة بالمحتوى عبر ENS + مراسم توقيع الإصدارات من التوقيع المتعدد Safe.
• الاستيلاء على الحوكمة ← تدوير موقّعي التوقيع المتعدد؛ عتبة ثلاثة من خمسة؛ مجلس ما بعد اللامركزية من مشغّلين مستقلين؛ مراسم علنية.
• إجراء تنظيمي ضد مستضيف واحد ← حزمة الاستضافة الذاتية في P5 من المسار P + عدة واجهات أمامية مستقلة ليحظى التجار ببنى بديلة.
• انحراف الـ subgraph أو المفهرس ← مخطط مرجعي + اختبارات قابلية إعادة الإنتاج؛ عدة مفهرسات مستقلة.
• ضعف عمق سوق الـ solvers ← solver احتياطي من OrcaRail بسعر التكلفة؛ دخول حر دون إذن للـ solvers الجدد.
• فقدان مفتاح BTC ← xpub احتياطي عند تسجيل التاجر؛ تبديل تلقائي لـ HSM؛ وPSBT الاسترداد الموقّعة مسبقًا تُبقي استرداد الدافع ممكنًا.
• إعادة تنظيم السلاسل (reorg) في EVM ← lastChargedAt رتيب في SubscriptionHub؛ ومقابله على سولانا last_charged_at.
• التشوّه الناتج عن الرمز ← لا رمز عند الإطلاق؛ حجز صريح؛ وأي رمز مستقبلي مشروط بعتبات المشغّلين المستقلين قبل أن يطالب بدور في الحوكمة.

17. أسئلة مفتوحة نعترف بها​

كتابة هذه الوثيقة لا تحل كل الأسئلة التي تطرحها.

• متى تبدأ «ما بعد اللامركزية» بالضبط؟ يحدد القسم 8 عتبة (ثلاث واجهات أمامية مستقلة، وثلاثة keepers مستقلين، ومعالج واحد من غير OrcaRail). وما إذا كانت هذه العتبة صحيحة نقاش مفتوح.
• من يدفع تكلفة الـ subgraph العام على نطاق واسع؟ لدى The Graph سوق؛ والاستضافة الذاتية مجانية لكنها ثقيلة تشغيليًا. لم تُحسم الجوانب الاقتصادية بعد.
• ما مسار الخروج لتاجر يختفي مستضيف واجهته الأمامية الأساسي؟ تجعل P5 الاستضافة الذاتية ممكنة، لكنها لا تجعلها تلقائية. تدفق «نقل متجري إلى مستضيف آخر» عمل مستقبلي.
• ما الذي تقرره الحوكمة فعليًا في بروتوكول بعقود غير قابلة للتغيير لكل رابط؟ ترقيات المصانع، وضبط معاملات المراكز (قوائم الرموز الموقوفة، والنشر على شبكات جديدة)، والقيم الافتراضية لتقسيم الرسوم لحركة OrcaRail المستضافة، وليس أكثر من ذلك بكثير. وما إذا كان هذا النطاق كافيًا لتبرير حوكمة على السلسلة جزء من حوار ما بعد اللامركزية.
• ماذا يحدث للبروتوكول إذا غيّرت شركة OrcaRail رأيها بشأن الحجز في القسم 9؟ أي تغيير هو تغيير منشور في هذه الورقة. لا تحوّل أحادي صامت.

18. الخاتمة: دعوة للبنّائين​

تُخرج خارطة الطريق غير الاحتجازية البنية من الحفظ. وتُخرج هذه الورقة البنية من يد OrcaRail. يجب إطلاق الاثنين ليكون لأيٍّ منهما معنى.

إذا كنت تبني محفظة أو لوحة تحكم أو مفهرسًا أو solver أو أداة امتثال أو معالجًا منافسًا، فالبروتوكول مصمم ليقبل مساهمتك دون طلب إذن. شارك في كتابة الـ EIP. شغّل الـ subgraph. ثبّت واجهتك الأمامية الخاصة. شغّل keeper أو solver. افتح issues على التطبيق المرجعي. كلما أنجز أشخاص لا يعملون في OrcaRail جزءًا أكبر من المسار P، استحق البروتوكول كلمة بروتوكول أكثر.

لن يلاحظ تجار Web2 الذين نعمل معهم اليوم أيًّا من هذا؛ فمفاتيح API والـ webhooks ولوحات التحكم لديهم تستمر في العمل. وهذا الاستقرار هو المقصود. نحن نغيّر أساس البنية، لا الواجهة التي تعامل معها التجار عند التسجيل.

المراجع

• خارطة طريق OrcaRail نحو نموذج غير احتجازي — المسار N
• نقاش البروتوكول: خمس رؤى لـ OrcaRail غير احتجازية بالكامل — أصل المسار P
• لماذا يتفوق سحب الـ allowance على الضمان ومفاتيح الجلسة — قرار نموذج الاشتراك
• البنية — البنية التقنية الكاملة
• مرجع العقود — ABIs والأحداث والعناوين
• نموذج الأمان — افتراضات الثقة وحفظ المفاتيح
• خارطة الطريق — حالة مراحل المسار N
• تقييم EigenLayer — النمط المعاد استخدامه في P6

باختصار​

• جُمّد تقسيم الرسوم على أربع حصص: التاجر، والمنصة، والإحالة/الشريك، ورسوم الجسر. كل ما في الموزّع على السلسلة قابل للتعبير بنقاط الأساس؛ دون تصحيحات خارج السلسلة.
• 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.

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

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

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 · نموذج الأمان · البنية

باختصار​

• تعيد PaymentLinkFactory.computeAddress(linkId) عنوان CREATE2 حتميًا. نعرض هذا العنوان على الدافع قبل نشر أي شيء.
• PaymentLinkReceiver نسخة مصغّرة EIP-1167. يقبل العملة الأصلية أو ERC-20، ويصدر Paid، ويستدعي FeeSplitter.split() في المعاملة نفسها.
• يتوقف api/src/payments/wallet.service.ts عن إنشاء محافظ HD لروابط EVM؛ ويستدعي دالة العرض في المصنع بدلًا من ذلك.
• يُتجاوز مسار الكنس (drainSmartAccountWallet وgetSmartAccountClientForDepositWallet) للروابط المنشأة تحت العلم useOnChainReceiver.

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

في جهة «بعد» لا يوجد أي صندوق نتحكم به يحتفظ بالأموال.

العقود الجديدة​

كلها ضمن حزمة جديدة contracts/evm/.

PaymentLinkFactory​

• computeAddress(bytes32 linkId) view returns (address) — عنوان CREATE2 حتمي مشتق من linkId (معرّف UUID الحالي لرابط الدفع بعد تجزئته إلى bytes32).
• deployAndPay(bytes32 linkId, Split split, address token, uint256 amount) — نشر كسول + دفع في معاملة واحدة. ينسخ المصنع تطبيق PaymentLinkReceiver، ويهيئه بالـ Split، ويمرر الأموال.
• isDeployed(bytes32 linkId) view returns (bool) — دالة مساعدة يستخدمها المفهرس والواجهة.
• قابل للترقية خلف proxy من نوع UUPS، يملكه التوقيع المتعدد للنشر (Safe ثلاثة من خمسة)، مع قفل زمني 48 ساعة على upgradeTo.

PaymentLinkReceiver (نسخة)​

• غير قابل للتغيير بعد التهيئة. يخزّن struct الـ Split وعنوان FeeSplitter.
• pay(address token, uint256 amount) — يتعامل مع العملة الأصلية وERC-20 في نقطة دخول واحدة. يستخدم SafeERC20 لتعمل الرموز غير القياسية (USDT). يصدر Paid(linkId, payer, token, amount).
• يستدعي FeeSplitter.split() ذريًا. إذا فشل التقسيم (revert) يفشل الدفع.
• دالة refund(bytes32 txId) صريحة لا يستدعيها إلا حساب EOA الخاص بـ keeper التاجر أو التوقيع المتعدد للنشر.

FeeSplitter​

• split(Split s, address token, uint256 amount) — يوزّع بنقاط الأساس. يذهب الـ wei المتبقي إلى التاجر (دون فقدان الفتات).
• يصدر Split(txId, merchant, platform, referral, bridgeFee) ليتطابق المفهرس مع حمولات webhook القديمة.

تغييرات API​

أكبر تغيير في الكود موجود في api/src/payments/wallet.service.ts. اليوم، تشتق getOrCreateAddressForPaymentLink من hd_wallet_seed، وتحسب عنوان Alchemy الافتراضي (counterfactual)، وتخزنه في wallet_address. بعد المرحلة 1، ولشبكات EVM التي يكون العلم مفعّلًا لها، تصبح الدالة:

async function getOrCreateAddressForPaymentLink(paymentLinkId, network) {
  if (isEvm(network) && featureFlags.useOnChainReceiver(network.chainId)) {
    const address = await factory.computeAddress(hashLinkId(paymentLinkId))
    return { address, walletAddressId: null, derivationPath: null }
  }
  // legacy path unchanged
}

لا اشتقاق HD. ولا أي بيانات سرية في قاعدة البيانات للروابط الجديدة.

تشترك خدمة جديدة، payments/indexer/evm-paid-event.service.ts، في أحداث Paid على كل شبكة مفعّلة عبر viem.watchContractEvent. عند التطابق:

1. تستخرج paymentLinkId من الحدث (مفهرس بصيغة bytes32).
2. تُدرج أو تحدّث صف PaymentTransaction بالشكل نفسه المستخدم اليوم.
3. تصدر الـ webhooks نفسها التي يصدرها مسار اكتمال الكنس اليوم (api/src/webhooks/webhooks.service.ts).

العلم useOnChainReceiver محدد لكل chain id. الرابط المنشأ أثناء إيقاف العلم يبقى على مسار الكنس القديم إلى الأبد؛ لا ننقل الروابط الجارية.

الإيقافات​

في هذه المرحلة نتجاوز دون أن نحذف:

• SmartAccountWalletService.drainSmartAccountWallet — لم يعد يُستدعى للشبكات المفعّل لها العلم.
• SmartAccountWalletService.getSmartAccountClientForDepositWallet — غير مطلوب عندما تأتي العناوين من المصنع.
• صفوف wallet_address — لا تُكتب لشبكات EVM المفعّل لها العلم.

يحدث الحذف الفعلي في المرحلة 7، بعد تسوية كل الروابط القديمة على الشبكة.

خطة الترحيل​

• الروابط الجديدة على Base: تحصل على عنوان CREATE2 يحسبه المصنع. تعرضه الواجهة كما هو الحال اليوم.
• الروابط المفتوحة الحالية على Base: تبقى على مسار الكنس القديم حتى تنتهي صلاحيتها أو تُسوّى. لا ترحيل إجباري.
• شبكات EVM الأخرى: على المسار القديم حتى تفعّل المرحلة 3 العلم لها.

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

• عرض عنوان CREATE2 قبل وجود أي كود. الحل: توثيق أن إمكانية الاسترداد تعتمد على ناشر المصنع. ووضع سقف maxLinkValue في المصنع خلال أول 30 يومًا.
• USDT ورموز ERC-20 غير القياسية الأخرى. الحل: SafeERC20 في كل من PaymentLinkReceiver وFeeSplitter؛ واختبارات fuzz في Foundry على نسخة (fork) من الشبكة الرئيسية مع USDT.
• الرموز التي تقتطع رسومًا عند التحويل. الحل: قائمة رموز مسموح بها؛ والرموز خارجها تعود إلى المسار القديم.
• تأخر مفهرس الشبكة. الحل: اشتراك مزدوج (Alchemy + RPC عام احتياطي)؛ ومهام مطابقة كل ساعة؛ وإدراج/تحديث idempotent.
• ملاحظة تدقيق أثناء التطوير. الحل: التدقيق شرط مسبق؛ لا نشر على الشبكة الرئيسية قبل تقرير إصلاح كل الملاحظات.

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

• إنشاء مشروع Foundry في contracts/evm/
• تنفيذ PaymentLinkFactory + PaymentLinkReceiver + FeeSplitter
• اختبارات fuzz + invariant لحسابات التقسيم (يحصل التاجر دائمًا على ≥ المتوقع ناقص الرسوم)
• نجاح اختبارات الـ fork لـ USDT / ERC-20 غير القياسية
• ربط العلم useOnChainReceiver في api/src/payments
• إطلاق المفهرس evm-paid-event.service.ts وإصداره للـ webhooks الحالية
• بدء التدقيق ودمج الإصلاحات
• النشر على Base mainnet من التوقيع المتعدد
• مجموعة تجار تجريبية (canary) مع تفعيل العلم

ما التالي​

مع انتقال تجار Base إلى المستقبِلات القائمة على العقود، تفعل المرحلة 2 الشيء نفسه للاشتراكات: اشتراكات بسحب الـ allowance.

التوثيق المرجعي: حالة المرحلة 1 · مرجع العقود · البنية

باختصار​

• يسجّل SubscriptionHub.createSubscription(...) الجدول على السلسلة.
• يوقّع الدافع approve(USDC, hub, cap) مرة واحدة في محفظته المعتادة. وهي الخطوة نفسها الموثقة لدينا أصلًا في الخصم التلقائي.
• يمكن لأي EOA استدعاء charge(id). يتولى المُجدوِل لدينا في NestJS ذلك افتراضيًا؛ وسيدعمه Chainlink/Gelato بدءًا من المرحلة 3.
• حماية من إعادة التنظيم (reorg) عبر lastChargedAt رتيب. لا خصم مزدوج.
• ينتقل المشتركون الحاليون اختياريًا عند التجديد.

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

اليوم، يستخدم api/src/scheduler/processors/subscription-auto-charge.processor.ts حسابًا ذكيًا تتحكم به OrcaRail للسحب من الدافع عبر الـ approve القائم. يعمل ذلك، لكن الحساب الذكي ملكنا؛ أي أن الثقة تمر عبرنا.

بعد المرحلة 2:

يبقى الـ allowance من الدافع إلى عقد، لكن العقد قابل للتدقيق وغير قابل للتغيير، ويمكن لأي طرف، لا نحن فقط، أن يكون الـ keeper.

العقود الجديدة​

SubscriptionHub​

نسخة واحدة لكل شبكة. واجهة مصغّرة:

function createSubscription(
    bytes32 id,
    address payer,
    IERC20 token,
    uint256 amount,
    uint64 interval,
    uint256 cap,
    Split calldata split
) external;

function charge(bytes32 id) external;        // any caller
function cancel(bytes32 id) external;        // payer only
function subscription(bytes32 id) view returns (Subscription memory);

event SubscriptionCreated(bytes32 indexed id, address indexed payer, ...);
event Charged(bytes32 indexed id, uint256 amount, uint64 nextChargeAt);
event ChargeSkipped(bytes32 indexed id, bytes32 reason);
event Canceled(bytes32 indexed id);

الثوابت التي تفرضها charge()​

• block.timestamp >= nextChargeAt — لا يمكن الخصم مبكرًا.
• block.timestamp > lastChargedAt — رتيب، فلا يمكن لإعادة التنظيم أن تسبب خصمًا مزدوجًا.
• amountCharged + amount <= cap — يفرض حد الموافقة إضافةً إلى allowance في ERC-20.
• token.allowance(payer, hub) >= amount — revert صريح مع InsufficientAllowance لنص webhook واضح.
• token.balanceOf(payer) >= amount — كذلك، مع InsufficientBalance.

يُعاد استخدام Split من المرحلة 1: FeeSplitter نفسه ودلالة نقاط الأساس نفسها.

تغييرات API​

التغيير الكبير أن api/src/scheduler/processors/subscription-auto-charge.processor.ts يتوقف عن السحب من حسابنا الذكي ويبدأ باستدعاء SubscriptionHub.charge(id) عبر EOA خاص بالـ keeper.

بشكل ملموس:

• حساب EOA الخاص بالـ keeper محفظة ساخنة لكل شبكة لا تحتوي إلا على الغاز. لا يملك أي صلاحية على أموال التاجر.
• إذا كانت للشبكة سياسة paymaster من Alchemy (راجع api/src/withdrawals/services/gas-strategy)، يستخدم الـ keeper المسار المدعوم؛ وإلا فيدفع من رصيد الغاز الخاص به.
• عند الـ revert، يحلل المعالج محدد الخطأ (selector) ويحدّث حالات SubscriptionAutoChargeEntity نفسها التي نستخدمها اليوم (past_due وinsufficient_balance وغيرها).
• تُرسل الـ webhooks ورسائل البريد من api/src/mail/mail-templates/subscription-*.hbs دون تغيير.

تحصل تجربة الدافع في pay على تعديلين بسيطين:

1. تشير خطوة approve() الآن بالـ spender إلى عنوان SubscriptionHub بدلًا من محفظتنا الساخنة. هذا تغيير في نص واحد وقيمة إعداد واحدة؛ والتدفق الذي يراه الدافع مطابق.
2. زر «إلغاء» يستدعي SubscriptionHub.cancel(id) ثم يطلب approve(hub, 0) على السلسلة للتنظيف الكامل. يبقى توثيق إلغاء الخصم التلقائي الحالي صحيحًا.

الإيقافات​

• مسار السحب الاحتجازي في subscription-auto-charge.processor.ts — مع العلم المفعّل، لا يعمل إلا فرع SubscriptionHub.charge.
• الحساب الذكي المملوك لـ OrcaRail بصفته approval_spender_address — تخزّن الاشتراكات الجديدة عنوان المركز بدلًا منه.
• يبقى الحقل approval_spender_address في استجابة API؛ لكنه يشير الآن إلى مكان جديد قابل للتدقيق.

خطة الترحيل​

لا يُنقل المشتركون الحاليون قسرًا أبدًا. نقدم مسارين:

1. عند التجديد: في الدورة التالية، يطلب شريط في لوحة التحكم من الدافع إعادة توقيع approve(hub, cap) على SubscriptionHub الجديد. نقرة واحدة. يمكن ترك الـ allowance القديم للمحفظة الساخنة القديمة أو إلغاؤه؛ لم يعد مهمًا.
2. بمبادرة المستخدم: زر «الانتقال إلى النموذج غير الاحتجازي» في صفحة تفاصيل الاشتراك يفعل الشيء نفسه فورًا.

الاشتراكات التي لا تنتقل أبدًا تبقى على المسار الاحتجازي حتى الإلغاء. ويُوقف هذا المسار في المرحلة 7 مع إشعار مسبق كافٍ.

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

• ارتباك الدافع عند الترحيل. الحل: يحاكي قالب البريد لغة subscription-auto-charge-approved.hbs الحالي؛ وشريط في لوحة التحكم؛ وسؤال شائع في /docs/non-custodial/migration-guide.
• انقطاع الـ keeper يفوّت خصمًا. الحل: charge() لا يتطلب إذنًا؛ يمكن لأي نسخة من Chainlink Automation أو Gelato أن تكون احتياطيًا؛ كما يمكن للتاجر استدعاء charge() يدويًا. الخطة الكاملة في المرحلة 3.
• خصم مزدوج بسبب إعادة التنظيم. الحل: ثابت lastChargedAt الرتيب؛ واختبار وحدة مع إعادة تنظيم على fork.
• إلغاء الدافع للتفويض بين الدورات. الحل: تصدر charge() الحدث ChargeSkipped(AllowanceRevoked)؛ ويُرسل قالب البريد الحالي subscription-insufficient-allowance.hbs؛ وينتقل الاشتراك إلى past_due.
• انحراف قائمة الرموز المسموح بها. الحل: لا يقبل المركز إلا الرموز التي تحقق SubscriptionHub.isAllowed(token)؛ والتغييرات تتطلب التوقيع المتعدد.

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

• تنفيذ SubscriptionHub مع كل الثوابت
• اختبارات fuzz لحالات السقف والـ allowance وإعادة التنظيم والتخطي
• إنجاز تدقيق إضافي يغطي SubscriptionHub
• تجهيز EOA للـ keeper لكل شبكة، مع مراقبة الغاز عبر Sentry + Datadog
• تحويل وجهة approve في تطبيق الدفع إلى SubscriptionHub
• تحديث نقطة النهاية approve-auto-charge لقبول allowances يكون فيها المركز هو الـ spender
• شريط في لوحة التحكم للاشتراكات الحالية
• ترحيل المجموعة التجريبية واستقرارها لمدة 14 يومًا

ما التالي​

التوسع إلى شبكات متعددة وkeeper ثانٍ: المرحلة 3.

التوثيق المرجعي: حالة المرحلة 2 · دليل الترحيل · مرجع العقود · لماذا سحب الـ allowance

باختصار​

• نشر PaymentLinkFactory وتطبيق PaymentLinkReceiver وFeeSplitter وSubscriptionHub على Ethereum mainnet وArbitrum وOptimism وPolygon.
• مخطط salt نفسه لـ CREATE2 في كل مكان؛ عنوان المصنع واحد على كل الشبكات (أنظف للتوثيق وللتكاملات ولـ computeAddress من جهة العميل).
• تسجيل Chainlink Automation (المفضّل) و/أو Gelato Web3 Functions كـ keeper ثانٍ يستدعي charge(ids[]) نفسها.
• نشر أهداف SLO: 99.5% من الخصومات خلال 10 دقائق من موعد الاستحقاق، بقياس فعلي.

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

تعدد الـ keepers التي تستدعي charge() العامة نفسها هو ضمان الاستمرارية. لا يملك أيٌّ منها حفظًا للأموال؛ ويمكن لأيٍّ منها إنقاذ خصم مستحق.

خطة النشر​

ترتيب النشر (شبكة واحدة أسبوعيًا، مع canary لكل شبكة):

1. Ethereum mainnet (chainId 1)
2. Arbitrum One (42161)
3. Optimism (10)
4. Polygon PoS (137)

تُنشر العناوين على كل شبكة في /docs/non-custodial/contract-reference. مفتاح النشر هو التوقيع المتعدد Safe ثلاثة من خمسة نفسه المحدد في المرحلة 0، ويُعاد نشره لكل شبكة من المراسم نفسها.

تشترك الشبكات الأربع في العلم نفسه useOnChainReceiver المحدد حسب chainId داخل api/src/payments/wallet.service.ts. يفعّله التجار شبكةً بعد شبكة؛ وتصبح القيمة الافتراضية مفعّلة بعد أسبوع canary نظيف.

استراتيجية الغاز لـ charge()​

تحتاج معاملات charge() الخاصة بالـ keeper إلى غاز. نعيد استخدام بنية الـ paymaster الحالية في api/src/withdrawals/services/gas-strategy:

• مع paymaster من Alchemy (Base وArbitrum وOptimism وPolygon): يستدعي الـ keeper الدالة SubscriptionHub.charge() كـ UserOperation برعاية السياسة. تكلفة غاز صفرية لحساب EOA الخاص بالـ keeper.
• Ethereum mainnet (دون paymaster): يدفع الـ keeper من رصيد الغاز الساخن الخاص به. تموّله محفظة المنصة يوميًا، ويُراقب بتنبيه Datadog عند انخفاض الرصيد.
• غاز مدعوم من التاجر (اختياري): يمكن للتجار تعيين gas_refund_address ويسحب الـ keeper التعويض منه، بما يطابق نمط الدعم/العمولة الحالي. خارج نطاق الإطلاق الأولي.

الـ keeper الثاني: Chainlink وGelato​

الـ keeper الثاني للتكرار، لا للاستبدال. يعمل إلى جانب مُجدوِل NestJS.

Chainlink Automation (المفضّل على EVM)​

• تسجيل Upkeep لكل SubscriptionHub.
• تعيد checkUpkeep() القيمة performData = abi.encode(ids[]) لكل id يحقق block.timestamp >= nextChargeAt (مقروءة من دالة عرض).
• تستدعي performUpkeep(performData) الدالة charge(ids) دفعة واحدة.
• يُموَّل بـ LINK من خزينة المنصة؛ ويُراقب الرصيد.

Gelato Web3 Functions (بديل)​

• تستطلع Web3 Function مكتوبة بـ JS المركز، وتجد المعرّفات المستحقة، وترسل معاملة charge(ids[]).
• يُدفع السعر لاحقًا من 1Balance في Gelato.

أيٌّ منهما كافٍ وحده؛ وسنختار بناءً على الخبرة التشغيلية خلال المرحلة 3. تشغيل الاثنين معًا لا بأس به؛ فـ charge() idempotent داخل الفترة بفضل lastChargedAt.

أهداف SLO والمراقبة​

أهداف SLO المنشورة:

تتصل المراقبة بإعداد Sentry الحالي الموثق في مهارة سير عمل Sentry في المستودع. التنبيهات:

• عدد revert لـ charge() في الساعة > العتبة ← PagerDuty
• الرصيد الأصلي لحساب الـ keeper أقل من N gwei × gasLimit × 100 ← PagerDuty
• upkeep في Chainlink/Gelato غير سليم ← تحذير
• تأخر مفهرس أحداث Paid أكثر من 5 دقائق ← تحذير

الإيقافات​

كما في المرحلتين 1 و2، لكن على شبكات أكثر. لا يُحذف شيء بعد؛ فالحذف ينتظر المرحلة 7.

خطة الترحيل​

• روابط الدفع الجديدة: تستخدم المستقبِلات القائمة على العقود على أي شبكة مفعّل لها العلم.
• الاشتراكات الجديدة: تستخدم SubscriptionHub على أي شبكة مفعّل لها العلم.
• العملاء الحاليون: ترحيل اختياري عند التجديد، كما في المرحلة 2.
• التسوية عبر الشبكات (Relay): الواجهة دون تغيير؛ يواصل الـ keeper استدعاء منفّذي Relay في api/src/withdrawals/services/bridge، لكن من EOA لا يملك أي حفظ.

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

• اختلاف العناوين بين الشبكات. الحل: ناشر CREATE2 حتمي (مثل 0x4e59b44847b379578588920cA78FbF26c0B4956C) مع تجزئة init-code مقفلة؛ تتشارك المصانع العنوان نفسه على الشبكات الأربع.
• حدود سياسة الـ paymaster لكل شبكة. الحل: مراقبة لكل شبكة وتنبيهات حصة السياسة عند 70% من الاستخدام.
• كثرة تغييرات تسجيل upkeep في Chainlink. الحل: upkeep واحد لكل شبكة؛ تُقرأ قائمة المعرّفات على السلسلة، فلا يتطلب تسجيل التجار تغيير إعدادات Chainlink.
• خصم مزدوج بين الـ keepers. الحل: lastChargedAt رتيب إضافةً إلى ChargeSkipped للتكرارات؛ وكلا الـ keepers idempotent بالتصميم.
• ارتفاعات مفاجئة في غاز الشبكة الرئيسية. الحل: ضبط حجم الدفعة لكل شبكة؛ وسقف لسعر الغاز يؤجَّل فوقه charge() كتلة واحدة.

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

• إتمام النشر على Ethereum وArbitrum وOptimism وPolygon
• نشر عناوين المصنع + المركز في مرجع العقود
• التحقق من سياسات الـ paymaster لكل شبكة
• تفعيل upkeep من Chainlink Automation على شبكتين على الأقل
• لوحة SLO في Datadog
• دليل تشغيل لانقطاع الـ keeper (charge() يدوي من CLI التاجر)
• إطلاق تجار canary لكل شبكة

ما التالي​

سولانا هي الشبكة الكبيرة الأخرى التي يجب أن نجعلها غير احتجازية: المرحلة 4.

التوثيق المرجعي: حالة المرحلة 3 · استراتيجية الـ keepers · مرجع العقود

باختصار​

• يملك برنامج payment_link حساب PDA لكل رابط دفع، مشتقًا من seeds = [b"pl", link_id]. لا keypair، ولا seed، ولا كنس.
• يستخدم برنامج subscription صلاحية delegate في SPL، وهي المكوّن نفسه الذي نعتمد عليه أصلًا في الخصم التلقائي، كـ allowance صريح يمنحه الدافع.
• يتم التقسيم عبر CPI إلى منطق fee_splitter نفسه الذي بنيناه على EVM، بعد تكييفه مع حسابات سولانا.
• تُتجاوز خدمة الكنس api/src/withdrawals/services/solana-withdrawal-transfer.service.ts للروابط المفعّل لها العلم، وتُحذف في المرحلة 7.

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

تستبدل جهة «بعد» الـ seed من نوع HD في api/src/payments/wallet.service.ts (الفرع m/44'/501'/i'/0') بحساب PDA حتمي بالكامل.

البرامج الجديدة​

حزمة جديدة contracts/solana/ (Anchor).

برنامج payment_link​

الحسابات لكل رابط:

#[account]
pub struct PaymentLink {
    pub link_id: [u8; 32],
    pub expected_mint: Pubkey,        // e.g. USDC on SOL
    pub expected_amount: u64,
    pub split: Split,
    pub created_at: i64,
    pub status: PaymentStatus,
}

التعليمات:

• initialize(link_id, expected_mint, expected_amount, split) — كسولة؛ يستدعيها الغلاف المشابه للمصنع عند أول إيداع.
• pay(link_id, amount) — تتحقق من الـ mint والمبلغ، وتحوّل عبر CPI إلى ATA الخاص بالـ PDA، ثم تقسّم عبر CPI بشكل ذري. تصدر PaymentReceived { link_id, payer, amount }.
• refund(link_id) — تتطلب التوقيع المتعدد، وتحاكي الاسترداد في EVM.

بذور الـ PDA: [b"pl", link_id]. لا يملك الـ PDA أي مفتاح خاص؛ بل يوقّع عبر invoke_signed.

برنامج subscription​

يستفيد من Approve / Revoke في SPL لتفويض الصلاحية. يوقّع الدافع spl_token::approve محددًا PDA البرنامج كمفوَّض بحد أقصى cap من الرموز. ثم:

pub fn charge(ctx: Context<Charge>, id: [u8; 32]) -> Result<()>

يمكن لأي طرف استدعاؤها، وتتحقق من:

• clock.unix_timestamp >= next_charge_at
• clock.unix_timestamp > last_charged_at // monotonic
• amount_charged + period_amount <= cap
• استمرار وجود صلاحية التفويض على ATA الخاص بالدافع

عند النجاح، يسحب spl_token::transfer_checked عبر CPI من ATA الدافع (بصفة المفوَّض) ثم يقسّم عبر CPI.

الأحداث: SubscriptionCreated وCharged وChargeSkipped وCanceled. بالأشكال نفسها التي ينتجها مفهرس EVM، لذا فإن api/src/webhooks لا يعتمد على الشبكة.

تغييرات API​

• يتوقف فرع سولانا في WalletService.generateAddressForNetwork عن اشتقاق keypairs ويعيد بدلًا من ذلك findProgramAddressSync(["pl", linkId], programId). لا يُكتب أي صف encryptedSeed لروابط سولانا الجديدة.
• تراقب خدمة مفهرس جديدة سجلات البرنامج (webhooks من Helius أو بث Triton) وتصدر أحداث الـ webhook الحالية.
• يضيف api/src/scheduler/processors/subscription-auto-charge.processor.ts فرعًا لـ SOL: يبني معاملة charge ويوقّعها بالـ keeper (مسار دون غاز عبر معاملة مدعومة، على غرار الـ paymaster في المرحلة 2).
• لا تُستدعى withdrawals/services/solana-withdrawal-transfer.service.ts للروابط المفعّل لها العلم.

الغاز على سولانا​

رسوم سولانا صغيرة (عادةً 5000 lamport لكل توقيع، أي 0.000005 SOL). يستخدم الـ keeper رصيد SOL ساخنًا بنمط التنبيه نفسه المستخدم في المرحلة 3. ولأن سولانا لا تملك paymaster على غرار Alchemy، تستخدم المعاملات المدعومة نمطًا بسيطًا للتوقيع المشترك: يوقّع الـ keeper بصفته دافع الرسوم، ولا يحتاج الدافع إلى أي SOL.

الإيقافات​

• اشتقاق HD لـ SOL (m/44'/501'/i'/0') للروابط الجديدة — لا يُستدعى عند تفعيل العلم.
• solana-withdrawal-transfer.service.ts — يُتجاوز للروابط المفعّل لها العلم.
• يبقى SolanaRelayBridgeExecutorService في api/src/withdrawals/services/bridge/solana-relay-bridge-executor.service.ts: فالنقل من SOL إلى EVM عندما يكون التاجر على EVM ما زال يستخدم Relay، لكن المشغّل ينتقل إلى البرنامج.

خطة الترحيل​

نموذج الاشتراك الاختياري نفسه في المرحلة 2:

• روابط الدفع الجديدة: معنونة عبر PDA.
• الاشتراكات الجديدة: قائمة على delegate في SPL.
• الاشتراكات النشطة الحالية: شريط + بريد إلكتروني عند التجديد التالي لإعادة التفويض للبرنامج الجديد.
• تستمر تسوية الإيداعات الجارية على العناوين القديمة عبر المسار القديم.

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

• إمكانية تجاوز الـ delegate في SPL. الحل: تعيد charge التحقق من delegated_amount قبل التحويل؛ وعند الفشل تصدر ChargeSkipped(DelegateRevoked) وتتبع قالب البريد نفسه المستخدم في حالة إلغاء الـ allowance على EVM.
• صلاحية ترقية Anchor. الحل: يملك توقيع متعدد Squads ثلاثة من خمسة صلاحية الترقية، مع قفل زمني. بما يطابق موقف Safe على EVM من المرحلة 0.
• SOL المغلّف مقابل SOL الأصلي. الحل: يدعم payment_link كليهما، مع expected_mint صريح لكل رابط لتجنب الالتباس.
• ارتفاعات رسوم الأولوية. الحل: حساب ديناميكي لرسوم الأولوية في الـ keeper؛ وإعادة محاولة احتياطية بأولوية أعلى بعد slot واحد.
• التدقيق. الحل: تدقيق البرنامجين من OtterSec أو Neodyme قبل النشر على الشبكة الرئيسية.

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

• إنشاء مساحة عمل Anchor في contracts/solana/
• برنامج payment_link بكل التعليمات + الاختبارات
• برنامج subscription بكل التعليمات + الاختبارات
• إطلاق مفهرس webhooks من Helius
• فرع SOL للـ keeper في subscription-auto-charge.processor.ts
• نشر تقرير التدقيق
• النشر على الشبكة الرئيسية من التوقيع المتعدد Squads
• مجموعة تجار تجريبية

ما التالي​

بيتكوين. أصعب شبكة لتحقيق عدم الاحتجاز، والشبكة التي يجب أن نكون فيها صريحين بشأن الحدود: المرحلة 5.

التوثيق المرجعي: حالة المرحلة 4 · مرجع العقود · البنية

باختصار​

• يصبح كل رابط دفع BTC توقيعًا متعددًا taproot اثنان من اثنين: موقّع واحد للتاجر وموقّع واحد للمنصة. لا تستطيع المنصة نقل الأموال منفردة.
• يحصل كل إيداع على PSBT استرداد موقّعة مسبقًا تُخزَّن خارج السلسلة، ليتمكن الدافع من استعادة أمواله إذا اختفى التاجر.
• تنتقل مفاتيح xpub الرئيسية من خادم API إلى خدمة HSM أو MPC (مثل Lit أو Turnkey). لا عبارات استرداد على القرص.
• المدفوعات المتكررة على BTC خارج النطاق حتى تصبح Lightning BOLT12 جاهزة للإنتاج. ويذكر الخصم التلقائي اليوم أصلًا أن BTC غير مدعومة للخصم التلقائي، ويبقى ذلك صحيحًا.

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

اليوم، يشتق BitcoinHotWalletService في api/src/withdrawals/services/bitcoin-hot-wallet.service.ts عنوان p2wpkh أحاديًا من عبارة استرداد محفوظة على الخادم ويكنسه عبر bitcoin-withdrawal-transfer.service.ts. هذا مفتاح واحد نتحكم به.

بعد المرحلة 5:

لا يستطيع أي طرف منفرد الإنفاق. ولا يحتفظ أي خادم بـ seed أحادي.

ما الذي سنطلقه​

1. taproot اثنان من اثنين لكل رابط​

• محفظة واصفات لكل رابط: wsh(multi(2, merchant_pubkey, platform_pubkey)) أو مقابل taproot (tr(NUMS, {pk(m), pk(p)}) مع MuSig2 لمخرج يبدو كتوقيع منفرد، وهو أفضل للخصوصية والرسوم).
• يوجد مفتاح التاجر في متصفح التاجر أو إضافة الهاتف. يطلب تدفق تسجيل التاجر xpub؛ وتُشتق مفاتيح كل رابط منه.
• يوجد مفتاح المنصة خلف خدمة HSM أو MPC. لا يرى خادم API المادة السرية أبدًا.

2. PSBT استرداد موقّعة مسبقًا​

عند رصد إيداع:

1. تجمع API معاملة PSBT تعيد الإيداع ناقص الغاز إلى عنوان الدافع (المسجَّل عند إنشاء رابط الدفع إذا كانت محفظة الدافع معروفة؛ وإلا تُطبق سياسة sendback).
2. يوقّع الموقّعان PSBT الاسترداد فورًا وتُخزَّن (مشفّرة) في قاعدة البيانات.
3. يمكن للتاجر بث الاسترداد في أي وقت بنقرة واحدة؛ دون الحاجة إلى توقيع إضافي.

هذا هو مقابل دالة refund() على السلسلة في BTC.

3. تدوير مفاتيح MPC​

• تُدوَّر مفاتيح xpub الرئيسية لمفاتيح المنصة سنويًا.
• تتبع كل المفاتيح المشتقة لكل رابط هذه التدويرات؛ وتستمر الروابط القديمة في العمل لأن توقيعها المتعدد موجود أصلًا على السلسلة بالمفتاح العام المحدد.
• يُسجَّل التدوير في سجل التدقيق نفسه الخاص بعمليات نشر التوقيع المتعدد من المرحلة 0.

ما الذي لن نطلقه​

• اشتراكات / خصم تلقائي على BTC. لا يوجد تصميم موثوق على الطبقة الأولى اليوم. يستثني توثيق الخصم التلقائي الحالي BTC أصلًا، ويبقى ذلك صحيحًا.
• تقسيم ذري على السلسلة لـ BTC. يحدث التقسيم في PSBT التسوية التي يوقّعها التاجر. يبقى التقسيم حتميًا ومرئيًا في المعاملة المبثوثة، لكن السكربت لا يفرضه.
• Fedimint أو statechains. بحث مثير للاهتمام؛ لكنه ليس ضمن هذه المرحلة.

Lightning كمسار مستقبلي​

للمدفوعات المتكررة بـ BTC خيار واقعي واحد: عروض BOLT12 في Lightning + امتداد recurrence. سيمنحنا ذلك حلًا لاشتراكات BTC يضاهي approve + السحب في ERC-20. نتابعه كمرحلة مستقبلية:

• يعتمد على تطبيقات ناضجة لـ recurrence في BOLT12 داخل LND وCLN.
• يعتمد على دعم محافظ Lightning (Phoenix وZeus وBlink) لـ recurrence في BOLT12.
• يتطلب أسطولًا من عُقد LN بسيولة كافية؛ ربما عبر شريك (Voltage أو Greenlight).

سننشر وثيقة تصميم مخصصة عندما تجهز الأدوات الأساسية. وحتى ذلك الحين، تبقى BTC للدفع لمرة واحدة.

الإيقافات​

• BitcoinHotWalletService — يحتفظ بواجهته، لكن مزوّد المفاتيح ينتقل إلى HSM/MPC. يتوقف إنشاء عنوان الإيداع الأحادي p2wpkh للروابط الجديدة.
• تبقى عناوين إيداع BTC القديمة قابلة للتسوية حتى انتهاء صلاحيتها عبر مسار الكنس القديم.

خطة الترحيل​

• روابط دفع BTC الجديدة: عناوين توقيع متعدد اثنان من اثنين. الواجهة دون تغيير؛ ويتحول تنسيق العنوان إلى taproot.
• روابط BTC المفتوحة الحالية: تبقى العناوين الأحادية القديمة نشطة حتى انتهاء صلاحيتها؛ لا نفرض الترحيل.
• التجار الذين لم يضبطوا موقّع BTC: يعودون حاليًا إلى توقيع متعدد للمنصة فقط، مع خطوة تسجيل إلزامية لإرفاق مفتاح التاجر خلال 30 يومًا. يحافظ ذلك على مسار الاسترداد ويتجنب تعطيل حجم BTC الحالي.

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

• فقدان التاجر لمفتاحه. الحل: يطلب تسجيل التاجر مفتاحَي xpub (أساسي + احتياطي)؛ والاحتياطي اختياري لكنه موصى به بشدة.
• انقطاع HSM الخاص بالمنصة. الحل: الـ HSM مكرر عبر مناطق متعددة؛ واسترداد طارئ للمفاتيح عبر مراسم توقيع متعدد موثقة في دليل التشغيل.
• اختراق مخزن PSBT الاسترداد. الحل: تُشفَّر PSBT الاسترداد أثناء التخزين بمفتاح KMS منفصل؛ كما أنها عديمة الفائدة دون إعادة توقيع التاجر لوجهة مختلفة (الوجهة ثابتة في PSBT الموقّعة مسبقًا).
• نضج MuSig2. الحل: يصدر الإصدار الأول باثنين من اثنين صريح wsh(multi(...))؛ ويأتي MuSig2 لاحقًا بعد تدقيق الأدوات على نطاق واسع.
• ارتفاعات سوق الرسوم. الحل: تتضمن PSBT التسوية خطاف CPFP يمكن للتاجر رفعه؛ ويراقب الـ keeper الـ mempool وينبّه التجار عندما يتجاوز غاز التسوية عتبة معينة.

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

• إنهاء قالب واصف taproot
• اختيار مزوّد HSM / MPC (Lit أم Turnkey أم HSM داخلي)
• تدفق تسجيل xpub التاجر في لوحة التحكم
• اشتقاق الواصفات لكل رابط وتخزينها
• إنشاء PSBT استرداد موقّعة مسبقًا + تخزين مشفّر
• واجهة التوقيع المشترك للتسوية (توقيع التاجر بنقرة واحدة)
• دليل تشغيل لتبديل الـ HSM وفقدان مفتاح التاجر
• مجموعة تجار تجريبية على BTC اثنان من اثنين

ما التالي​

لامركزية اختيارية للـ keeper عبر EigenLayer: المرحلة 6.

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

باختصار​

• EigenLayer هو إعادة تخزين + شهادات قابلة للمعاقبة من مشغّلي ETH. ليس شبكة، ولا منصة عقود، ولا حلًا للحفظ.
• موضعان يمكن أن يفيد فيهما OrcaRail: AVS للـ keepers من أجل charge() لامركزي، وAVS لشهادات الجسور من أجل التسوية عبر الشبكات.
• سنؤجّل البناء ما لم يطلب عميل أو متطلب امتثال استمرارية لامركزية تتجاوز ما يوفره Chainlink Automation + NestJS.
• إن بنينا واحدًا يومًا ما، فسنبدأ من قوالب Othentic / Eigen Foundation، لا من الصفر.

ما الذي يمنحك إياه EigenLayer فعلًا​

الـ AVS (Actively Validated Service) شبكة من المشغّلين تنفّذ عملية حسابية خارج السلسلة وتُنشر شهاداتها على السلسلة بأمان اقتصادي تشفيري من ETH المعاد تخزينه. يُعاقَب سوء السلوك (slashing).

ما الذي تحصل عليه:

• استمرارية لامركزية: تُنفَّذ المهمة حتى لو توقف أحد الأطراف (OrcaRail).
• صحة قابلة للمعاقبة: الشهادة الخاطئة تُفقد المشغّل حصته.
• أمان اقتصادي من ETH: ترث جزءًا من حصص مدققي Ethereum بدلًا من إطلاق رمز خاص بك.

ما الذي لا تحصل عليه:

• منصة عقود ذكية. ما زالت العقود تُنشر على Ethereum / L2.
• الحفظ. لا يحتفظ EigenLayer بـ USDC نيابةً عنك.
• دعم أصلي لسولانا أو بيتكوين. توجد جسور عبر الشبكات، لكنها تضيف تعقيدًا وثقة.
• مُجدوِل عام. ما زلت تحدد بنفسك المهمة خارج السلسلة والتحقق على السلسلة.

أين يمكن أن يفيد الـ AVS منصة OrcaRail​

1. AVS للـ keepers (charge() لامركزي)​

اليوم وحتى المرحلة 3، تبدو صورة الـ keepers هكذا:

• مُجدوِل NestJS (أساسي)
• Chainlink Automation أو Gelato (احتياطي)

يمنحنا ذلك تكرارًا ثنائيًا. أما AVS للـ keepers فسيمنحنا تكرارًا بعدد N مع استمرارية قابلة للمعاقبة: يشهد المشغّلون أن «هذه المعرّفات كانت مستحقة وقد استدعيت charge»، وتفويت خصم مستحق مخالفة قابلة للمعاقبة.

متى يستحق ذلك:

• عندما يكون لدينا عميل يمنع عقده أي اعتماد على طرف واحد في بنيتنا التحتية.
• عندما يطلبه الامتثال التنظيمي صراحةً (نادر اليوم).

متى لا يستحق ذلك:

• عندما تكون الموثوقية الإضافية مقارنةً بـ Chainlink ضئيلة وتكلفة الهندسة أشهرًا.

2. AVS لشهادات الجسور (بديل لـ Relay)​

تستخدم تسويتنا عبر الشبكات اليوم Relay (راجع api/src/withdrawals/services/bridge). Relay يتطلب الثقة. يمكن لـ AVS أن يشهد بأن «الأموال رُصدت على الشبكة X، أفرِج عنها على الشبكة Y» بأمان قابل للمعاقبة، بشكل مشابه لـ Hyperlane ISM مع EigenLayer أو Omni.

متى يستحق ذلك:

• عندما يفرض Relay شروطًا أو أداءً لا يمكننا قبوله.
• عندما تعالج المنصة حجمًا كافيًا عبر الشبكات لتصبح مخاطر الجسر جوهرية.

3. أوراكل الاحتيال / الامتثال​

«هل هذه المحفظة خاضعة للعقوبات؟» «هل سُلّمت البضاعة؟» — يمكن لفحوصات السياسات الموجودة حاليًا في مسار webhooks في NestJS أن تصبح شهادات AVS. استخدام محدود؛ ولا يفيد إلا إذا تحمّلت المنصة مسؤولية صريحة عن السياسات على السلسلة.

لماذا نؤجّل البناء​

• تكلفة Chainlink Automation + NestJS الهندسية تقارب الصفر. أما AVS للـ keepers فيستغرق أشهرًا.
• بناء AVS يعني تشغيل مشغّلين (أو تنسيق آخرين لذلك) وصيانة شروط المعاقبة. هذا عبء تشغيلي يضاهي إدارة أسطول عُقد بلوكتشين خاص بنا.
• لا يكون تحسين الأمان ذا معنى إلا بعد أن يتوفر لدينا تكرار ثنائي. وهو غير متوفر بعد (نحصل عليه في المرحلة 3). بالتالي: لا يصبح AVS للـ keepers مرشحًا إلا بعد استقرار المرحلة 3.
• حتى بنطاق متحفظ، سيكون للـ AVS اعتبارات حفظ خاصة به (ETH المعاد تخزينه، واقتصاديات تعويض المشغّلين).

سجل القرارات​

سنحتفظ بسجل قرارات عام في /docs/non-custodial/eigenlayer-evaluation يتضمن التوصية الحالية وأي محفزات قد تغيّرها. توصية اليوم: التأجيل.

المحفزات التي ستعيد فتح النقاش:

1. محادثة مبيعات تعطلت صراحةً بسبب مخاطر «keeper من طرف واحد».
2. إطار تنظيمي يعتبر الاستمرارية المدعومة بـ AVS ضابطًا مقبولًا.
3. تراجع ملموس في تسعير Chainlink Automation أو توفره على أكثر شبكاتنا استخدامًا.
4. شراكة يمكننا فيها إعادة استخدام AVS للـ keepers لدى طرف آخر بتكلفة تشغيل شبه معدومة.

إن بنيناه​

• البدء من قالب. تنشر Othentic وEigen Foundation قوالب لـ AVS شهادات المهام. لن نكتب منطق المعاقبة يدويًا.
• إبقاء نقطة الدخول على السلسلة دون تغيير. تبقى SubscriptionHub.charge(ids[]) عامة ودون إذن. ويصبح الـ AVS مجرد مستدعٍ إضافي إلى جانب NestJS وChainlink.
• عدم إدخال رموز جديدة أو آليات staking لحجمنا الخاص. يُدفع للمشغّلين بـ ETH من ميزانية غاز المنصة؛ ولا يوجد رمز لـ OrcaRail.
• تدقيقه. حتى الـ AVS القائم على قالب يحتاج إلى تدقيق.

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

• نشر صفحة سجل القرارات
• مراجعة ربع سنوية للمحفزات
• بيئة sandbox لإثبات المفهوم (لا للإنتاج) إذا تحقق أحد المحفزات

ما التالي​

تحذف المرحلة الأخيرة مسارات كود الحفظ التي استبدلتها المراحل 1 إلى 5: المرحلة 7.

التوثيق المرجعي: حالة المرحلة 6 · تقييم EigenLayer · استراتيجية الـ keepers

باختصار​

• حذف hd_wallet_seed وإعداد WALLET_ENCRYPTION_KEY ومنطق الاشتقاق للشبكات المفعّل لها العلم.
• حذف مسارات EVM/SOL في api/src/withdrawals/: SmartAccountWalletService.drainSmartAccountWallet وsolana-withdrawal-transfer.service.ts وملفات spec المرتبطة.
• إبقاء مسار BTC (مقلّصًا إلى نموذج اثنين من اثنين من المرحلة 5).
• تحديث شروط الخدمة وسياسة الخصوصية وضوابط SOC2 لتعكس نطاق حفظ أصغر بكثير.
• نشر تقرير ما بعد الحدث (postmortem) يلخص ما تعلمناه.

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

قبل هذه المرحلة، تحتوي قاعدة الكود على نسختين من كل شيء (مسار الكنس القديم ومسار العقود الجديد) خلف feature flags. بعد هذه المرحلة، يصبح المسار الجديد هو المسار الوحيد على EVM وسولانا.

ما الذي نحذفه​

قاعدة البيانات​

• جدول hd_wallet_seed وكيان TypeORM الخاص به في api/src/payments/infrastructure/persistence/relational/entities/hd-wallet-seed.entity.ts.
• يُحتفظ بالعمود wallet_address.derivationPath لعمليات البحث التاريخية لكنه يصبح قابلًا للقيم الفارغة؛ ولا تكتبه أي صفوف جديدة لـ EVM/SOL.
• يؤرشف ترحيل (migration) صفوف الـ seed المشفّرة في تخزين بارد لمدة سبع سنوات (احتفاظ تنظيمي)، ثم يحذف الجدول.

الكود​

في api/src/payments/wallet.service.ts:

• حذف encryptSeed وdecryptSeed وgetOrCreateHDWallet وgenerateAddressForNetwork (فرعا EVM + SOL) وgetNextAvailableIndex والاستيراد الديناميكي لـ @account-kit/wallet-client.
• تصبح getOrCreateAddressForPaymentLink غلافًا رقيقًا فوق factory.computeAddress لـ EVM وfindProgramAddressSync لسولانا.

في api/src/withdrawals/services/smart-account-wallet.service.ts:

• حذف drainSmartAccountWallet وtransferFromSmartAccount وbatchTransferFromSmartAccount وgetSmartAccountClientForDepositWallet وderivePrivateKey.
• تبقى الوحدة (فما زال لها استخدام صغير لأدوات مساعدة متعلقة بـ BTC ولقراءة الأرصدة).

عمليات حذف أخرى:

• api/src/withdrawals/services/solana-withdrawal-transfer.service.ts
• ملفات .spec.ts والـ fixtures المقابلة.
• الفرع الاحتجازي في subscription-auto-charge.processor.ts (يبقى فرع SubscriptionHub.charge).

الإعدادات​

• WALLET_ENCRYPTION_KEY — يُحذف من .env وأسرار النشر والتوثيق.
• أي مواد توقيع من Alchemy Account Kit في الإعدادات (تبقى مفاتيح API الخاصة بـ @account-kit/* إن كانت لا تزال مستخدمة للـ paymaster).

ما الذي يبقى​

• محفظة BTC الساخنة — مقلّصة إلى نموذج التوقيع المتعدد اثنان من اثنين من المرحلة 5. لا تبقى أي seeds من نوع HD لـ EVM/SOL.
• سياسة الـ paymaster من Alchemy — يستخدمها الـ keeper لرعاية charge() حيث ينطبق ذلك.
• منفّذو جسر Relay — ما زالوا ينسّقون التسوية عبر الشبكات؛ والمستدعون حسابات EOA للـ keepers، لا موقّعون احتجازيون.
• كل الـ webhooks ورسائل البريد والفوترة ولوحة التحكم والتحليلات — دون تغيير.

التحديثات القانونية وتحديثات الامتثال​

• شروط الخدمة: تصبح عبارة «لا تحتفظ OrcaRail بأموال EVM أو سولانا أثناء تسوية المدفوعات» بيانًا واقعيًا، لا نصًا طموحًا.
• سياسة الخصوصية: إزالة الإشارات إلى مواد الـ seed المخزنة.
• نطاق SOC2: تتقلص ضوابط الحفظ؛ وتُربط ملاحظات التدقيق بالنطاق الجديد الأصغر.
• الوضع كمحوّل أموال: مراجعة جديدة مع المستشار القانوني. تقليل نقاط التماس مع الحفظ يبسّط التحليل في عدة ولايات قضائية.

تقرير ما بعد الحدث​

سيلخص مقال مرافق ما تعلمناه عبر المراحل 0 إلى 7: ما الذي استغرق وقتًا أطول من المتوقع، وما الذي سار بسلاسة أكبر، وما التكلفة الهندسية الحقيقية لعدم الاحتجاز، وكيف تفاعل التجار. الإيقاع المتوقع: مقال واحد خلال 30 يومًا من إطلاق المرحلة 7.

الإيقافات (لا شيء جديد)​

هذه المرحلة هي الإيقاف نفسه. تصبح كل المسارات المرتبطة بالعلم useOnChainReceiver مفعّلة افتراضيًا؛ ويُحذف العلم.

خطة الترحيل​

عند تنفيذ المرحلة 7، تكون كل المدفوعات والاشتراكات الجديدة غير احتجازية منذ أكثر من 12 شهرًا. يتعلق الترحيل بالذيل الطويل من الروابط القديمة:

• روابط الدفع القديمة المفتوحة بعد انتهاء صلاحيتها ← تسوية أي فتات متبقٍ عبر سكربت لمرة واحدة، ثم التوقف.
• الاشتراكات القديمة التي لم تنتقل أبدًا ← إشعار بالبريد قبل 30 يومًا من الإيقاف، وعرض ترحيل بنقرة واحدة في لوحة التحكم، وتعليق الخصم التلقائي إن لم يتم الترحيل.
• الأرصدة المتبقية على عناوين الإيداع القديمة ← كنسها للمرة الأخيرة عبر مسار التفريغ القديم إلى عناوين سحب التاجر، ثم إيقاف المفاتيح.

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

• فتات متبقٍ على العناوين القديمة. الحل: تشغيل سكربت كنس نهائي قبل الإيقاف؛ ونشر أي فتات غير قابل للاسترداد في تقرير عام.
• مخاطر قانونية من الحذف المبكر. الحل: أرشفة صفوف الـ seed المشفّرة لمدة 7 سنوات (لا يمكن فك تشفيرها أبدًا دون مفتاح التشفير الذي يُتلف في مراسم)؛ ويظل بإمكان المدققين التحقق من الحالة التاريخية.
• اعتماد أحدهم على شكل API غير موثق. الحل: إشعار إيقاف عام قبل 90 يومًا؛ وإدخال في سجل تغييرات API؛ وتواصل موجّه مع كبار التجار.

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

• كل تجار EVM + SOL على التدفق غير الاحتجازي لمدة 90 يومًا على الأقل
• تصفير الاشتراكات القديمة المتبقية
• إتمام سكربت الكنس النهائي
• إتمام ترحيل hd_wallet_seed إلى الأرشيف البارد
• دمج عمليات حذف الكود
• تحديث شروط الخدمة + سياسة الخصوصية ونشرها
• نشر مقال تقرير ما بعد الحدث

نهاية خارطة الطريق​

بعد المرحلة 7، يصبح وضع الحفظ كالتالي:

• EVM وسولانا: غير احتجازي. لا تحتفظ OrcaRail بأي مواد seed.
• بيتكوين: حفظ مخفَّض عبر توقيع متعدد اثنان من اثنين مع موقّع من جهة التاجر.
• لحظة الانتقال: أُلغيت على EVM/SOL؛ وتقلّصت إلى مسار استرداد بتوقيع متعدد على BTC.

هذا ما وضعناه هدفًا في خارطة الطريق غير الاحتجازية.

التوثيق المرجعي: حالة المرحلة 7 · نموذج الأمان · خارطة الطريق

سأل عدد من القرّاء، وهم محقون: إذا كان الهدف أن نصبح بروتوكولًا، فلماذا نتوقف عند إزالة الحفظ؟ كيف ستبدو البنية لو اختفت OrcaRail غدًا واستمرت المدفوعات في التدفق؟

هذا المقال نقاش. خمسة مواقف تدافع عن خمس بنى مختلفة. ومحاور يختبر كل واحد منها. لا أحد يفوز فوزًا كاملًا، لكننا في النهاية نصبح أوضح بشأن المفاضلات التي نختارها فعلًا.

ماذا يعني «بروتوكول غير احتجازي بالكامل» بالضبط​

قبل بدء النقاش نحتاج إلى تعريف مشترك. يكون النظام بروتوكولًا غير احتجازي بالكامل إذا تحققت كل الشروط التالية:

1. الحفظ: لا يحتفظ أي طرف بأموال المستخدمين أثناء انتقالها، ولا حتى لكتلة واحدة.
2. الاستمرارية: لا يُشترط وجود أي طرف منفرد لحدوث دفعة أو خصم اشتراك مشروع.
3. مقاومة الرقابة: لا يستطيع أي طرف منفرد رفض معاملة سليمة البنية ومدفوعة.
4. التحكم في الترقيات / التغييرات: تتطلب الترقيات موافقة عدة أطراف، لا نشرًا من شركة واحدة.
5. الشفافية: القواعد التي يثق بها المستخدم مقروءة بالكامل على السلسلة أو تحت تجزئة قابلة للتحقق.

الخطة الحالية تحقق (1). وتحقق جزئيًا (3) و(4) و(5). ولا تحقق (2)؛ فما زال الـ keeper والـ API من OrcaRail مطلوبين لتشغيل المسار الطبيعي بشكل موثوق. يدور النقاش أدناه حول ما إذا كان علينا دفع المعايير الأربعة المتبقية حتى النهاية، وبأي تكلفة.

المواقف​

يدخل خمسة معماريين. لنستمع إليهم.

• البراغماتي — عقود ذكية + API من OrcaRail (خارطة الطريق الحالية).
• المتشدد — بروتوكول على السلسلة بالكامل + واجهة أمامية لامركزية («نموذج Uniswap»).
• السيادي — OrcaRail كطبقة ثالثة / سلسلة تطبيقات مع precompiles مخصصة للمدفوعات.
• المؤمن بالـ intents — يعبّر الدافعون عن intents؛ وتسوّيها شبكة solvers دون إذن.
• المدافع عن المعايير — EIP مفتوح لروابط الدفع والاشتراكات؛ يطبّقه أي أحد.

الجولة 1: البيانات الافتتاحية​

البراغماتي: «أطلِق شيئًا حقيقيًا، ثم اجعل الأجزاء المؤلمة لامركزية.»​

خارطة الطريق تزيل أصلًا المشكلة الصعبة (الحفظ). يمكن أن يكون الـ keeper أي طرف؛ فمُجدوِل NestJS لدينا مستدعٍ واحد بين عدة مستدعين، ويمكن تسجيل Chainlink وGelato غدًا. المفهرس عام: يمكن لأي شخص الاشتراك في أحداث Paid وCharged نفسها وإعادة بناء الحالة. «API الخاصة بـ OrcaRail» ليست طبقة التسوية، بل طبقة راحة فوق عقود عامة. التجار الذين يريدون المسار البروتوكولي الكامل يمكنهم أصلًا تجاوزنا واستدعاء المصنع مباشرةً.

الادعاء: نحن بروتوكول بنسبة 80%. الـ 20% المتبقية أدوات (محافظ، لوحات تحكم، بريد إلكتروني)، لا ثقة. ويجب أن تبقى الأدوات قابلة للتطوير المستمر.

المتشدد: «لا API. أحداث، عقود، subgraph. هذا كل شيء.»​

Uniswap موجود. 1inch موجود. يُصل إليهما عبر واجهات أمامية تستضيفها شركاتهما، لكن أيًّا من هذه الواجهات قد يختفي ويستمر البروتوكول في العمل. هذا هو معنى «البروتوكول».

بالنسبة لـ OrcaRail، يبدو ذلك هكذا:

• مصانع ومراكز وموزّعات على كل شبكات EVM/سولانا.
• subgraph مرجعي (أو مفهرس سولانا) يمكن لأي شخص الاستعلام منه.
• واجهة أمامية لامركزية مثبّتة على IPFS/Arweave، يُوصل إليها عبر ENS (orcarail.eth). لوحة تحكم التاجر وتطبيق الدفع حِزم ثابتة؛ وكل إصدار معنون بالمحتوى.
• لا REST API من OrcaRail في المسار الحرج. تستدعي الـ SDK الـ subgraph مباشرةً. وتُشتق الـ webhooks من الأحداث على السلسلة عبر مفهرسات كخدمة (Alchemy، QuickNode، أو مستضافة ذاتيًا).

الادعاء: أي شيء يحتاج إلى api.orcarail.com لكي تعمل الدفعة هو بروتوكول ناقص.

السيادي: «اجعل المدفوعات precompile على سلسلتنا الخاصة.»​

المدفوعات حساسة لزمن الاستجابة ومتكررة. ندفع الغاز نفسه للتقسيم نفسه في كل مرة. لماذا نستأجر أمان L1/L2 لحالة استخدام يمكن تخصيصها؟

لنطلق سلسلة OrcaRail كـ rollup على OP Stack (أو سلسلة تطبيقات Cosmos، أو سلسلة Arbitrum Orbit). عندها:

• تصبح دلالة روابط الدفع precompile، لا عقد Solidity من 80 سطرًا. تنخفض الرسوم من سنتات إلى ما يقارب الصفر.
• يُدمج منطق الـ keeper في إنتاج الكتل: يطلق الـ sequencer استدعاءات charge() كجزء من الكتلة، مع قابلية المعاقبة بأمان السلسلة نفسها.
• يستخدم الجسر إلى الشبكات «الحقيقية» (Ethereum، Arbitrum، سولانا) الجسر المرجعي الحالي + Relay؛ سلسلة OrcaRail طبقة تنسيق، لا طبقة قيمة.
• تصبح الاشتراكات مواطنًا من الدرجة الأولى؛ «الاشتراك» نوع معاملة، مثل «التحويل» في بيتكوين.

الادعاء: أرخص طريقة لجعل بروتوكول يعمل بموثوقية على نطاق واسع هي ألا يتقاسم مساحة الكتل مع عمليات سك NFT عشوائية.

المؤمن بالـ intents: «يعبّر الدافعون عن نيتهم. ويتنافس الـ solvers على التسوية.»​

يقول الدافع: «أريد أن أدفع للتاجر X مبلغ 50 دولارًا بـ USDC من أي من محافظي، خلال الساعة القادمة، مع تحسين الرسوم». هذا intent: موقّع، لكنه ليس معاملة بعد.

ترى شبكة solvers دون إذن (على نمط CoW أو SUAVE أو Anoma أو مرحّلات شبيهة بـ Across) الـ intent، وتجد أرخص مسار (بما في ذلك الجسور والعمليات عبر الشبكات، من أي رمز يملكه الدافع) وتسوّيه. ويحصل الـ solvers على مكافأة مضمّنة في الـ intent.

للاشتراكات: يوقّع الدافع intent متكررًا («اسحب 20 دولارًا شهريًا بـ USDC من محفظتي إلى PDA هذا التاجر، لمدة 12 شهرًا، قابلًا للإلغاء في أي وقت»). يتنافس الـ solvers على استدعاء charge() عند الاستحقاق، مقابل رسوم صغيرة. هذا ما يصبح عليه «AVS للـ keepers» في المرحلة 6 إن دققت النظر، لكن مع سوق حقيقية بدلًا من نظام معاقبة.

الادعاء: الـ keepers ليسوا مشكلة موثوقية فعلًا، بل مشكلة تصميم سوق. لنبنِ السوق.

المدافع عن المعايير: «اكتب EIP. الجميع يربح، ونحن منهم.»​

روابط الدفع والاشتراكات في OrcaRail مكوّن أساسي عام. تبني Shopify وCoinbase Commerce وغيرها من منظومات الدفع بالكريبتو المستضافة وعشرات الشركات الناشئة الشيء نفسه. يجب أن نكتب EIP لروابط الدفع غير الاحتجازية وEIP مرافقًا لاشتراكات سحب الـ allowance، مع تطبيق مرجعي.

عندها:

• يمكن لأي محفظة عرض رابط دفع بواجهة قياسية («أنت تدفع للتاجر X، 50 دولارًا، USDC، غير احتجازي»).
• يدعم أي مفهرس (The Graph أو Goldsky أو Envio) الأحداث القياسية مباشرةً.
• يمكن لأي معالج، بما في ذلك منافس مستقبلي لـ OrcaRail، استضافة البروتوكول نفسه.
• يصبح منتج OrcaRail أفضل تطبيق لمعيار مفتوح، لا منظومة مغلقة.

الادعاء: أكبر ميزة تنافسية في المدفوعات هي الثقة في المكوّن الأساسي، لا في منظومة شركة واحدة. لنجعل المكوّن الأساسي عامًا.

الجولة 2: المحاور يستجوب​

إلى البراغماتي: «كن صريحًا؛ إذا توقفت OrcaRail عن دفع فاتورة الـ paymaster، هل يستمر خصم اشتراك Alice؟»​

البراغماتي: في خارطة الطريق الحالية، بعد المرحلة 3، نعم؛ يواصل Chainlink Automation تنفيذ charge(). فاتورة الـ paymaster مخصصة لغاز الـ keeper، ويستخدم Chainlink عملة LINK للمهمة نفسها. لكن التجار الذين يحتاجون لوحة تحكم OrcaRail للمطابقة سيتأثرون: فرسائل البريد وإعادة المحاولات ورموز الأخطاء المقروءة كلها في API الخاصة بنا. تستمر العقود في العمل؛ أما المنتج فلا.

المحاور: هل «العقود تعمل لكن البشر لا يعرفون» استمرارية حقًا؟

البراغماتي: إنها استمرارية التسوية دون استمرارية تجربة الاستخدام. هذا تمييز حقيقي، ويجب أن نعترف به لا أن نخفيه. كما أن إصلاحه رخيص مع الوقت: ننشر قوالب البريد، ونفتح مصدر المفهرس، وندع غيرنا يستضيف لوحة التحكم. لا يلزمنا فعل كل ذلك في المرحلة 1.

إلى المتشدد: «لوحات التحكم على IPFS المثبّتة عبر ENS رائعة، إلى أن ترسل إلينا جهة تنظيمية خطابًا بشأن تاجر.»​

المتشدد: عندها تتوقف OrcaRail عن استضافة ذلك التاجر في لوحة تحكمها. ويستمر البروتوكول في خدمته عبر واجهة أمامية أخرى، أو واجهته الخاصة. هذه ميزة لا خلل؛ قارن بالتمويل التقليدي، حيث «جمّد المعالج حسابي» دراما متكررة لا علاج لها على مستوى البروتوكول.

المحاور: التجار الذين يطردهم معالج بطاقات يُطردون عادةً من شبكة Visa أيضًا. في المدفوعات، كثيرًا ما تكون البنية والمعالج الرقيب نفسه.

المتشدد: صحيح، وهذه بالضبط المشكلة التي يحلها البروتوكول. لا تستطيع Visa فرض رقابة على Ethereum. ولا تستطيع OrcaRail، ببنية بروتوكولية، فرض رقابة على التجار على مستوى البنية، بل على مستوى الواجهة الأمامية فقط. الواجهات قابلة للاستبدال؛ أما البنية فلا.

إلى السيادي: «كيف يسحب التجار إلى USDC على Ethereum إذا كانت التسوية على سلسلة OrcaRail؟»​

السيادي: بالطريقة نفسها التي يغادر بها أي أحد أي L2: عبر الجسر المرجعي. سندمج Relay بشكل أصيل لتكون مغادرة العملات المستقرة فورية. حجم السحب اليومي ضئيل مقارنةً بالحجم داخل السلسلة.

المحاور: أنت تطلب منا تشغيل سلسلة. كل سلسلة مهمة لها أنماط أعطال: توقف الـ sequencer، وتأخر نشر state root، والخروج عبر الجسور. وهذه الأعطال علنية وظاهرة. عنوان «توقف sequencer الخاص بـ OrcaRail لمدة 3 ساعات، وتوقفت المدفوعات عالميًا» أسوأ من «تعطلت API الخاصة بـ OrcaRail لمدة 3 ساعات».

السيادي: هو عنوان أسوأ فقط إلى أن تجعل الـ sequencer لامركزيًا. براهين الاحتيال في OP Stack والتسلسل المشترك (Espresso، Astria) تجعل هذا تدريجيًا أقل اعتمادًا على طرف واحد. أنت محق في أننا لن نبدأ من هناك. ومحق أيضًا في أنه لا ينبغي أن نشغّل سلسلة وحدنا؛ سنطلقها عبر شريك rollup-as-a-service مع مسار موثوق نحو التسلسل المشترك.

المحاور: هذه تبعيات كثيرة.

السيادي: نعم. والمقابل: نتوقف عن دفع الغاز إلى الأبد، ونتوقف عن التنافس على مساحة كتل الشبكة الرئيسية، ونتمكن من إطلاق مكوّنات مخصصة. إذا كان حجم المدفوعات كبيرًا بما يكفي لتبرير أي من ذلك، فهو مبرَّر. وإن لم يكن، فأنا مخطئ.

إلى المؤمن بالـ intents: «لأسواق الـ solvers مشكلة MEV. من يحمي الدافع من solver يقتطع لنفسه؟»​

المؤمن بالـ intents: يُوقَّع الـ intent بقيود صارمة. لا يمكن أن يتجاوز المبلغ المدفوع ما أذن به الدافع. ما يمكن أن يتغير هو المسار (أي جسر، وأي DEX إن لزم swap) والتوقيت. لا يستطيع الـ solver الخبيث تحويل الأموال إلى وجهة أخرى؛ وفي أسوأ الأحوال يكون بطيئًا. والمنافسة تقضي على ذلك.

المحاور: المنافسة تخفّض الرسوم على المسارات عالية الحجم. فماذا عن دفعة صغيرة بقيمة 5 دولارات من USDC إلى USDC عبر الشبكات لا يحصل أحد على ما يكفي لتسويتها؟

المؤمن بالـ intents: هذه فجوة حقيقية. والإجابة هي solvers احتياطيون: تشغّل OrcaRail واحدًا بسعر التكلفة. السوق تغطي الـ 95% العليا؛ ونحن نغطي الذيل الطويل. ومع الوقت، تسد الشبكات الأرخص والجسور الأفضل هذه الفجوة.

المحاور: إذن أنت أيضًا تشغّل keeper، لكنك تسميه solver.

المؤمن بالـ intents: keeper هو واحد من عدة، يتنافس على intent عام، ومعه احتياطي؛ نعم. هذا هو الفرق بين «الخادم الخلفي لـ OrcaRail هو الـ keeper» و«OrcaRail مشارك في سوق مفتوحة».

إلى المدافع عن المعايير: «الـ EIPs تستغرق سنوات. ماذا نفعل حتى ذلك الحين؟»​

المدافع عن المعايير: تطلق التطبيق المرجعي أولًا وفق خطتك الحالية. ثم تصوغ الـ EIP حول ما أطلقته، لا مسبقًا. هكذا كُتبت ERC-4337 وERC-721 وERC-20. خارطة الطريق الحالية متوافقة مع ذلك؛ يمكن أن تكون واجهة SubscriptionHub هي واجهة الـ ERC مع تعديلات طفيفة في الأسماء.

المحاور: هل هناك خطر في نشر «ميزتك التنافسية» كمعيار؟

المدافع عن المعايير: الميزة ليست العقد. الميزة هي التكاملات واتفاقيات مستوى الخدمة وعمل الامتثال ولوحات التحكم وقابلية توصيل البريد وثقة التجار. لا شيء من ذلك يستطيع منافس نسخه بقراءة EIP. فتح واجهة العقود ينقل المنافسة إلى المواضع التي نحن أقوياء فيها.

الجولة 3: أين يفوز كل موقف فعلًا​

بعد الاستجواب، يتفوق كل موقف في أبعاد محددة. بطاقة نتائج صريحة:

لا يوجد صف مهيمن. ولهذا السبب هذا نقاش وليس خطة إطلاق.

الجولة 4: خلاصة المحاور​

هكذا سأقرأ النقاش فعلًا، بصفتي الشخص الذي عليه أن يختار.

البراغماتي يفوز اليوم لأن المنتج يجب أن يستمر في الإطلاق، ولا نملك ترف التوقف 18 شهرًا لإعادة كتابة البنية. خارطة الطريق الحالية نسخة أفضل تمامًا من النسخة الاحتجازية التي نشغّلها اليوم، مع تحسينات تدريجية متوافقة.

المتشدد يفوز من حيث المبدأ ويلتقط قيدًا حقيقيًا: اليوم الذي تكون فيه API الخاصة بنا سبب عدم حصول تاجر على أمواله هو اليوم الذي نتوقف فيه عن كوننا بروتوكولًا. هذا هو الضغط الذي يجب أن يوجّه كل قرار هندسي في المراحل 1 إلى 7: انشر المفهرس، وانشر الـ subgraph، وثبّت لوحة التحكم على IPFS تحت ENS، ووثّق كيفية الاستضافة الذاتية. خارطة طريق البراغماتي تجعل ذلك ممكنًا، لكنها لا تفرضه. يجب أن نفرضه.

السيادي يفوز إذا برّر الحجم ذلك. تحت عتبة حجم معينة، يكون تشغيل سلسلة عبئًا. وفوقها، يصبح استئجار مساحة كتل Ethereum لتقسيم 3 دولارات على ستة أطراف في كل مرة أمرًا عبثيًا. سنعرف أننا تجاوزنا تلك العتبة عندما يكون الجزء الغالب من حجمنا مسارات من الدافع إلى التاجر على الشبكة نفسها، ويصبح تحسين الغاز وفرًا قابلًا للقياس في القوائم المالية. ليس بعد.

المؤمن بالـ intents يفوز في العمليات عبر الشبكات. المدفوعات بطبيعتها متعددة الأصول ومتعددة الشبكات. تدفق دافع قائم على الـ intents («ادفع للتاجر X، لا يهمني كيف») هو أفضل تجربة ممكنة لدافع كريبتو. يجب أن نعتمد الـ intents في طبقة SDK الدافع قبل اعتمادها في طبقة التسوية. هذا يجعل الـ solvers الحاليين (Across وdeBridge وRelay) ملائمين بشكل طبيعي دون الحاجة إلى بناء سوق جديدة.

المدافع عن المعايير يفوز حيثما يفوز المتشدد، بمخاطر أقل. كتابة EIP حول ما نطلقه في المرحلتين 1 و2 مجانية، ومفيدة للمنظومة، ولا تبطئنا. كما تمنحنا رواية موثوقة بأننا «نبني بنية، لا فخًا» للتجار الذين يقيّمون بنى الكريبتو لأول مرة.

الإجابة المدمجة​

الخلاصة المملة لكن الصحيحة: أطلِق مسار البراغماتي، وافرض ضغط المتشدد، واعتمد الـ intents لتجربة الدافع، واكتب EIP على الطريق، وأبقِ السيادي خيارًا للمرحلة 8 وما بعدها مشروطًا بالحجم.

بشكل ملموس، هذه هي الالتزامات التدريجية فوق خارطة الطريق الحالية:

• M1: subgraph عام من المرحلة 1. كل أحداث Paid وCharged في subgraph مرجعي يمكن لأي شخص الاستعلام منه. دون تعطيل الـ API.
• M2: تطبيق دفع مثبّت على IPFS من المرحلة 2. كل إصدار معنون بالمحتوى، وpay.orcarail.eth قابل للوصول عبر ENS.
• M3: حزمة استضافة ذاتية من المرحلة 3. Docker Compose + توثيق يتيحان لأي شخص تشغيل لوحة تحكم متوافقة مع OrcaRail من العقود نفسها.
• M4: SDK للـ intents من المرحلة 3. توجّه orcarail.pay(intent) على العميل المدفوعات عبر الشبكات من خلال شبكات الـ solvers القائمة (Across/Relay). مع solver احتياطي تشغّله OrcaRail للذيل الطويل.
• M5: مسودة EIP من المرحلة 2. المشاركة في كتابة EIP روابط الدفع مع معالج آخر أو فريق محفظة، على أساس SubscriptionHub لدينا.
• M6: تقييم ربع سنوي لخيار السيادي إلى جانب تقييم EigenLayer. المحفزات: حجم المدفوعات حسب الشبكة، وتكلفة الغاز لكل دفعة كنسبة من قيمتها، وطلب التجار على تسوية بأقل من سنت.

تنقل هذه الإضافات الخمس خارطة الطريق الحالية من «غير احتجازية» إلى «غير احتجازية، بشكل بروتوكولي، ومحايدة بشكل موثوق». ولا تبطئ المراحل 1 إلى 7. وتُتابَع كمسارات عمل حيّة ومستقلة.

وقد صيغت رسميًا كـ المسار P في الورقة البيضاء للبروتوكول، التي تحوّل M1-M5 إلى المراحل P1-P5 وتُبقي M6 (السلسلة الخاصة) كمرحلة P6 اختيارية.

ما لا نفعله صراحةً بعد​

• سلسلة خاصة. ليس خلال الـ 18 شهرًا القادمة. نعيد التقييم كل ربع سنة.
• رمز OrcaRail عند الإطلاق. لا رمز الآن. رمز الحوكمة المستقبلي محجوز كخيار لما بعد اللامركزية (راجع الورقة البيضاء للبروتوكول للموقف الكامل). لا بيع مسبق، ولا تخصيصات، ولا نقاط.
• مسار المتشدد على السلسلة بالكامل دون أي API. يحتاج المنتج إلى واجهات مقروءة للبشر، ويحتاج التجار إلى جهة يتصلون بها عند حدوث مشكلة. سنتيح الاستخدام دون API، لكننا لن نفرضه.
• شبكة solvers خاصة بنا. نستخدم الشبكات القائمة. قد نشغّل solver احتياطيًا بسعر التكلفة للمسارات الطويلة التي يتجاهلها الـ solvers الحاليون، لكننا لن نطلق شبكة منافسة جديدة.

أين نقف​

هذا المقال مرافق لـ خارطة الطريق غير الاحتجازية، لا بديل عنها. ما زالت خارطة الطريق تتابع المراحل 0-7. ويضيف هذا النقاش محورًا سادسًا، هو الشكل البروتوكولي، يجب تقييم كل مرحلة على أساسه.

إن كنت في هذا النقاش، فأرسل إلينا موقفك. سننشر الحجج المضادة القوية.

قراءات ذات صلة

• خارطة طريق OrcaRail نحو نموذج غير احتجازي — خارطة الطريق المرجعية
• لماذا يتفوق سحب الـ allowance على الضمان ومفاتيح الجلسة — نقاش نموذج الاشتراك، بالصيغة نفسها
• تقييم EigenLayer — سجل قرارات مرافق للـ keepers اللامركزية
• البنية — ما يبنيه مسار البراغماتي فعلًا

النماذج الثلاثة​

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 يومًا إلى هذا العنوان»). ويلغي الدافع الإذن بحذف مفتاح الجلسة.

التقييم​

قيّمنا النماذج الثلاثة على خمسة محاور:

لماذا ليس الضمان​

للضمان أجمل عرض تسويقي («أموال الدافع مقفلة في عقد، لا لدى شركة») لكنه يملك أسوأ تجربة فعلية:

• لا يحب الدافعون قفل أموال 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 بوضوح في توافق المحافظ ورأس المال العامل، ويتعادل أو يفوز في كل المحاور الأخرى. ولهذا بُنيت اشتراكات OrcaRail عليه.

ذو صلة: المرحلة 2: اشتراكات بسحب الـ allowance · توثيق الخصم التلقائي · نموذج الأمان

لماذا الاشتراكات في OrcaRail​

الاشتراكات مخصصة لمنصات SaaS والعضويات وعقود الأتعاب الدورية وأي منتج يُفوتر على فترة ثابتة (يوم، أسبوع، شهر، سنة)، مع فترات تجريبية وحدود للدورات وقواعد إلغاء اختيارية. تستخدم مصادقة المدفوعات نفسها المستخدمة في بقية المنصة، ويمكنك التفاعل مع أحداث دورة الحياة عبر webhooks الاشتراكات.

طريقتان للتحصيل: روابط الدفع أو الخصم التلقائي​

• send_payment_link (افتراضي): في كل دورة فوترة يحصل الدافع على رابط دفع (بالبريد الإلكتروني و/أو عبر التدفق المستضاف). يدفع عند فتح الرابط، وهي طريقة مألوفة في الدفع بالكريبتو ويسهل دمجها مع مسارات Relay واختيار المحفظة.
• auto_charge: يأذن الدافع مسبقًا لـ المحفظة الساخنة (hot wallet) الخاصة بـ OrcaRail بسحب مبلغ الفترة عند كل تجديد. بعد الإعداد، لا تتطلب التجديدات أن ينقر الدافع على رابط جديد كل مرة، طالما بقي الرصيد والتفويض صالحين.

أنشئ طريقة التحصيل واضبطها عبر POST /api/v1/subscriptions؛ واسرد الاشتراكات وحدّثها وأوقفها مؤقتًا وألغِها عبر إدارة الاشتراكات. الحقول الكاملة للطلب والأمثلة موجودة في تلك الأدلة.

الخصم التلقائي: كيف نتعامل معه​

1. ينشئ التاجر اشتراكًا مع collection_method: "auto_charge" والحقول المعتادة amount وinterval وtoken_id وnetwork_id وبيانات الاتصال بالدافع.
2. يفتح الدافع صفحة الاشتراك أو تجربة دفع الدورة الأولى. يرى النطاق الإجمالي للموافقة (مثل مجموع الرسوم القادمة التي تطلب منه تغطيتها) ويوقّع تفويضًا على السلسلة:
   • على شبكات EVM يكون ذلك approve(spender, amount) قياسيًا من ERC-20 مع محفظتنا الساخنة بصفتها spender.
   • على سولانا تكون الخطوة المقابلة تفويض رمز SPL (delegation) بمبلغ فترة واحدة على الأقل لمحفظتنا الساخنة على سولانا.
3. يستدعي الدافع نقطة النهاية العامة POST /api/v1/subscriptions/:id/approve-auto-charge مع تجزئة (hash) معاملة الـ allowance (أو التفويض) و**payer_wallet_address** و**payer_network_id** و**payer_token_id**. لا يلزم مفتاح API الخاص بالتاجر، فالدافع يثبت نيته بتوقيعه معاملة السلسلة.
4. تتحقق OrcaRail على السلسلة من أن الـ allowance أو التفويض يغطي دورة فوترة واحدة على الأقل للمحفظة الساخنة المتوقعة قبل وسم الخصم التلقائي بأنه معتمد. قبل كل سحب يمكننا إعادة التحقق من التفويض حتى لا تُخلط مشكلات RPC العابرة بإلغاء الـ allowance.
5. في كل دورة فوترة، تحاول عملية الفوترة تنفيذ السحب (في EVM تدفق من نوع transferFrom من الدافع إلى التسوية؛ وفي سولانا يُستخدم الرصيد المفوَّض). عند النجاح تتقدم الفترة؛ وعند الفشل المتكرر (مثل عدم كفاية الرصيد أو إلغاء الموافقة) قد ينتقل الاشتراك إلى past_due ويُبلَّغ الدافع. يمكنك الاستماع إلى webhooks مثل subscription.payment_link.payment_failed أو subscription.past_due كما هو موضح في الخصم التلقائي وwebhooks.

الإلغاء والبديل: إذا ألغى الدافع التفويض على السلسلة، تفشل عمليات السحب اللاحقة. ويمكنه أيضًا استدعاء POST .../revoke-auto-charge بعد الإلغاء لنسجّل الحالة ونحوّل التحصيل إلى send_payment_link، مع إرشادات بالبريد الإلكتروني لإدارة الاشتراك والدفع عبر الروابط مجددًا. التفاصيل في الخصم التلقائي وإدارة الاشتراكات.

الأمان والوضوح: تُستخدم في السحب المحفظة التي أكملت الموافقة فقط؛ ونعرض مجاميع وأعداد دورات واضحة ليعرف الدافعون ما الذي أذنوا به. في الخطط الطويلة جدًا أو المفتوحة، فكّر في وضع سقف للمبالغ المعتمدة وتجديد الموافقة دوريًا، أو البقاء على روابط الدفع؛ راجع الخصم التلقائي.

تعدد الشبكات: كيف يتكامل مع الاشتراكات​

• مرجع التاجر: يُنشأ كل اشتراك مع network_id و**token_id** يحددان كيفية تسعير الاشتراك وتسويته في API، أي الشبكة والأصل «الأساسيين» لتلك الخطة.
• سياق الدافع في الخصم التلقائي: يخزّن الخصم التلقائي payer_network_id و**payer_token_id**، وهما الشبكة والرمز اللذان ضبط عليهما الدافع الـ allowance أو التفويض فعليًا. قد يختلفان عن الحقول الأساسية للاشتراك عندما يموّل الدافع من شبكة أو أصل مدعوم آخر، بما يتسق مع طريقة تحديد عروض الأسعار وصفحة الدفع لمسارات جهة الدافع.
• تغطية متوافقة مع Relay: تبقى الشبكات والعملات المدعومة متوافقة مع Relay؛ وعندما يوسّع Relay الشبكات والرموز، تتبعه قائمتنا. لخّصنا هذا النموذج في الشبكات والعملات المدعومة: بتقنية Relay.
• وجهة العائدات: يضبط التجار عناوين السحب لكل نوع شبكة (ويمكنهم التجاوز لكل دفعة حيث يكون ذلك مدعومًا). للصورة الكاملة عن السحوبات متعددة الشبكات وتعدد العناوين لكل شبكة، راجع OrcaRail متعددة الشبكات: السحوبات والتوافق مع Relay.

الملخص​

تجمع الاشتراكات في OrcaRail بين موارد REST للاشتراكات وتفويض غير احتجازي من الدافع للخصم التلقائي ومدفوعات متعددة الشبكات، دون التخلي عن تجربة الدفع المستضافة وواجهات API التي تستخدمها أصلًا للمدفوعات الفردية.

تطبيق OrcaRail · التوثيق · Relay

من أين تأتي القائمة​

لا نحتفظ بقائمة منفصلة منسّقة يدويًا للشبكات والرموز المدعومة. بدلًا من ذلك:

• تُزامَن الشبكات من Chains API الخاصة بـ Relay (api.relay.link/chains للشبكة الرئيسية، إضافةً إلى الشبكات التجريبية). تبني عملية الـ seed لدينا سجلات الشبكات من بيانات Relay، بما في ذلك أنواع الشبكات EVM وبيتكوين وسولانا حيث يدعمها Relay.
• تُزامَن العملات والرموز من Currencies v2 API الخاصة بـ Relay (get-currencies-v2). تُدرج الرموز أو تُحدَّث لكل شبكة، فتحصل كل شبكة على المجموعة الصحيحة من الأصول القابلة للدفع والقابلة للنقل عبر الجسور.

عندما يضيف Relay شبكة أو عملة جديدة، تجلبها عملية الـ seed/التحديث لدينا. تحصل على توافق تلقائي مع تغطية Relay دون أي عمل تكامل إضافي من جانبك.

ماذا يعني «مدعوم»​

تتبع المدفوعات و(عند الحاجة) الجسور المسارات التي يدعمها Relay. يدعم Relay حاليًا أكثر من 69 شبكة بلوكتشين ضمن:

• شبكات EVM (Ethereum وBase وPolygon وArbitrum وOptimism وغيرها الكثير)
• بيتكوين
• سولانا (SVM)
• ترون

يمكن أن يكون دعم الرموز على كل شبكة "All" (الرموز التي تتوفر لها سيولة Solver أو DEX) أو "Limited" (فقط الرموز المدرجة مع supportsBridging: true). للاطلاع على المرجع الرسمي للمسارات ودعم الرموز، راجع توثيق Relay:

• Supported Tokens & Routes — كيفية التحقق من دعم مسار ما
• Contract Addresses — عناوين الـ solvers والعقود لكل شبكة

كيف ترى ما تدعمه OrcaRail​

استخدم واجهة API لدينا للحصول على المجموعة الحالية من الشبكات والرموز المتاحة في OrcaRail:

• الشبكات: GET /payments/networks — يسرد جميع الشبكات المدعومة (يمكنك التصفية بـ ?active=true).
• الرموز لكل شبكة: GET /payments/networks/:id/tokens — يسرد رموز شبكة معينة (استخدم id الشبكة من القائمة أعلاه).
• العملات الورقية/عملات العرض: GET /price/currencies — يسرد العملات الورقية المدعومة للتسعير وعروض الأسعار.

التفاصيل الكاملة في توثيق Payments API – سرد الشبكات / سرد الرموز وPrice API – سرد العملات.

الملخص​

الشبكات والعملات المدعومة في OrcaRail تعمل بتقنية Relay وتُحدَّث تلقائيًا: تكامل واحد، وشبكات كثيرة.

تطبيق OrcaRail · التوثيق · Relay

متعددة الشبكات، لكن ليس كل الشبكات (بعد)​

بُنيت OrcaRail اليوم للشبكات المتوافقة مع EVM. نحن لا ندعم بيتكوين أو سولانا (أو الرموز الأصلية على سولانا) كشبكات أساسية في تدفقات الدفع والسحب. هذا يُبقي نطاق التكامل مركّزًا وواجهات API متسقة بينما نتوسع.

إذا كانت بنيتك تعتمد على Ethereum أو Base أو Polygon أو Arbitrum أو Optimism أو غيرها من شبكات EVM من الطبقة الأولى أو الثانية، فلديك تكامل واحد ومجموعة توثيق واحدة. لا توجد تدفقات منفصلة لبيتكوين أو سولانا، حاليًا.

عدة عناوين سحب لكل نوع شبكة​

في السحوبات تظهر القيمة الحقيقية لتعدد الشبكات. يمكنك في OrcaRail ضبط عدة عناوين سحب لكل نوع شبكة.

• تحكم لكل شبكة: عيّن وجهة افتراضية مختلفة (أو مجموعة عناوين) لـ Ethereum وBase وPolygon وغيرها، لتصل الأموال إلى حيث تريد على كل شبكة.
• تجاوز لكل دفعة: عند إنشاء payment intent يمكنك تمرير withdrawal_address لتوجيه تلك الدفعة تحديدًا إلى بائع أو خزينة على الشبكة الصحيحة.
• دون عنق زجاجة واحد: أدِر الأسواق الإلكترونية أو منصات SaaS أو الهياكل متعددة الكيانات دون إجبار كل شيء على المرور عبر شبكة واحدة أو عنوان واحد.

إذن: تعدد الشبكات يعني شبكات متعددة وعدة وجهات سحب لكل شبكة، وكلها قابلة للضبط من لوحة التحكم وعبر API.

Relay يدعم بيتكوين وسولانا، ونحن كذلك (ضمن خارطة الطريق)​

يدعم Relay بيتكوين وسولانا (ورموزهما) ضمن تغطيته متعددة الشبكات. بُنيت OrcaRail لتتوافق مع نموذج Relay: رابط واحد، وشبكات كثيرة.

لا ندعم بيتكوين أو سولانا اليوم، لكن بنيتنا وخارطة طريقنا مصممتان بحيث عندما نضيفهما يبقى المنتج نفسه: واجهات API نفسها، ونموذج السحب نفسه (عدة عناوين لكل شبكة)، ولوحة التحكم نفسها. ونعني بـ«ونحن كذلك» أننا ملتزمون بالرؤية متعددة الشبكات نفسها التي يجسدها Relay، بما في ذلك بيتكوين وسولانا، وأننا نتوسع في هذا الاتجاه.

وحتى ذلك الحين، تحصل على تجربة مستقرة متعددة الشبكات تعتمد EVM أولًا، مع تحكم كامل في وجهة الأموال على كل شبكة مدعومة.

الملخص​

تعدد الشبكات في OrcaRail يعني: شبكات EVM كثيرة الآن، وعدة عناوين سحب لكل شبكة، ومسارًا نحو بيتكوين وسولانا بالتوازي مع Relay.

تطبيق OrcaRail · التوثيق · Relay

بُنيت OrcaRail بمساعدة الذكاء الاصطناعي وانطلاقًا من قناعة واحدة: يجب أن تكون مدفوعات الكريبتو مفتوحة وشفافة ومتاحة على جميع الشبكات. لفترة طويلة اضطر التجار والمطورون إلى الاختيار بين أدوات مفتوحة المصدر معقدة وغير مُصانة، أو بوابات دفع مغلقة ومكلفة تحبسك داخل منظومتها وتفرض رسومًا مرتفعة.

بنينا OrcaRail لكسر هذا النمط. OrcaRail منصة دفع متعددة الشبكات تربط منطق الأعمال في Web2 بالتسوية في Web3، إما مستضافة بتسعير بسيط قائم على النسبة المئوية وباقة مجانية سخية، أو باستضافة ذاتية لسيادة كاملة.

الفلسفة: منفعة عامة شفافة​

نؤمن بأن البنية المالية للإنترنت يجب أن تكون منفعة عامة. تكلّف OrcaRail المستضافة 0.5% من كل معاملة مكتملة، مع أول 1,000 معاملة مجانًا، حتى نتمكن من تشغيل بنية تحتية موثوقة مع البقاء في متناول المطورين. أما OrcaRail بالاستضافة الذاتية فهي مجانية من رسوم برمجيات OrcaRail: انشرها على أجهزتك وادفع فقط تكلفة بنيتك التحتية. حِزم SDK الرسمية وMCP والإضافات مرخّصة بموجب MIT.

يمكن أن تتضمن عروض الأسعار لكل دفعة بنودًا اختيارية تتحكم بها، مثل رسوم دعم قابلة للضبط (نسبة مئوية) وعمولة على مفاتيح API، إضافةً إلى رسوم الجسر عند التوجيه بين الرموز أو الشبكات. هذه البنود موثقة في أدلة الرسوم والحدود، وهي منفصلة عن سعر المنصة المستضافة.

بالبقاء مفتوحي المصدر وإتاحة تحسين المنتج للمجتمع، نهدف إلى بنية دفع غير احتجازية وعالية الأداء بمخاطر طرف مقابل أقل من البوابات المغلقة، شفافة من الأساس.

سواء استخدم المطورون OrcaRail المستضافة أو استضافوها ذاتيًا أو جمعوا بين الاثنين، يمكننا معًا مواجهة منظومات الدفع المغلقة المبهمة ذات الرسوم المرتفعة.

تجربة المطور: مفاهيم دفع مألوفة​

إذا كنت تعرف كيف تربط معالجات الدفع التقليدية في Web2، فأنت تعرف كيف تستخدم OrcaRail. صممنا البنية لتمنحك حالات متوقعة وتدفقات قابلة للتدقيق وwebhooks آمنة عند إعادة المحاولة.

• العملات المستقرة أولًا: سعّر منتجاتك بالعملات الورقية (USD/EUR) وسوِّ فورًا بـ USDC أو USDT. تخلّص من مخاطر التقلب لعملك وقدّم لعملائك تجربة دفع سلسة.
• صفحة دفع جاهزة: استخدم روابط الدفع المستضافة والأدوات القابلة للتضمين والواجهات المتوافقة مع WalletConnect لتقديم تجربة استخدام نظيفة.
• Webhooks وعدم التكرار (Idempotency): أبقِ قاعدة بياناتك متزامنة تمامًا مع ما يحدث على السلسلة. يرسل نظامنا أحداثًا موثوقة للحالات succeeded وprocessing وcanceled مع إعادة محاولة تلقائية.
• Node.js SDK وREST API: ابنِ مرة واحدة واتصل في كل مكان.

  npm install @orcarail/node
  

دعم أصيل لشبكات ورموز متعددة​

عالم Web3 مجزأ، لكن بوابة الدفع الخاصة بك لا ينبغي أن تكون كذلك. تحصل على تكامل واحد يعمل بسلاسة عبر الشبكات.

تدعم OrcaRail حاليًا الشبكات المتوافقة مع EVM مباشرةً. لكننا لن نتوقف هنا: جميع الشبكات التي يدعمها Relay في الطريق. تساعد تقنية التوجيه الذكي لدينا على اختيار الشبكة الأسرع أو الأقل رسومًا لكل دفعة تلقائيًا، حتى لا يترك عملاؤك سلة التسوق بسبب رسوم غاز باهظة.

سحوبات ديناميكية: مصممة لمنصات SaaS والأسواق الإلكترونية​

الأعمال الرقمية الحديثة معقدة. سواء كنت تدير منصة SaaS أو سوقًا متعدد البائعين أو تطبيقًا لاقتصاد صنّاع المحتوى، فإن توجيه الأموال يدويًا كابوس. تحل OrcaRail ذلك بشكل أصيل:

• توجيه لكل دفعة: مرّر withdrawal_address عند إنشاء payment intent. عندما يدفع العميل، تُوجَّه الأموال تلقائيًا مباشرةً إلى محفظة ذلك البائع.
• وجهة افتراضية: في الإعدادات الأبسط، احذف العنوان ودَع الأموال تُسوّى في العنوان الافتراضي لحسابك.
• تقسيم العمولات: تدير منصة؟ حدّد نسبة عمولة على مفاتيح API. تحصل على حصة منصتك من كل معاملة، تُحسب بوضوح في صفحة الدفع وتُرسل تلقائيًا إلى عنوان السحب الخاص بك.

ما التالي في خارطة الطريق؟​

هذا مجرد اليوم الأول. ومع نمونا، يزداد التزامنا بمنظومة مفتوحة عمقًا:

1. توسيع دعم الشبكات: إطلاق سريع لدعم الشبكات غير المتوافقة مع EVM عبر التكامل مع Relay.
2. الاستضافة الذاتية: انشر على بنيتك التحتية لتحقيق السيادة والخصوصية، دون أي رسوم برمجيات لكل معاملة منّا.
3. أدوات امتثال متقدمة: حقول بيانات وصفية اختيارية وتكاملات لسير عمل KYT/KYC بسلاسة.

جرّبها: اشعر بالفرق​

ندعوك لتكتشف كم يمكن أن تكون مدفوعات الكريبتو سهلة.

• 🚀 ابدأ البناء — أنشئ حسابًا، وولّد مفتاح API، وأنشئ أول رابط دفع في أقل من دقيقتين.
• 🎮 جرّب العرض التوضيحي المباشر — اختبر التدفق الكامل من إنشاء الـ intent حتى التأكيد عبر webhook.
• 📖 اقرأ التوثيق — استكشف مرجع API وأدلة SDK ونظرة عامة على البنية.

يجب أن يكون المستقبل مفتوحًا وشفافًا. لنبنِه معًا.

تطبيق OrcaRail · GitHub · X/Twitter