منشورتي السابقة تناولت لماذا لا ترغب البنوك في مشاركة دفتر أستاذ واحد مع منافسيها. بعد أن انتهيت من الكتابة، ظهر لدي سؤال: بما أن كل جهة تتمسك بدفترها الخاص، فكيف تتم المعاملات بين بنكين مختلفين؟ يتم تسجيل الأموال والأصول في دفترين لا يتواصلان ولا يمكنهما تبادل البيانات؛ يبدو الأمر وكأنه غير قابل للتطبيق. تهدف هذه المقالة إلى توضيح العملية التفصيلية وراء ذلك.
رابط المقال السابق موجود هنا: (لماذا لا ترغب البنوك في مشاركة دفتر أستاذ واحد مع منافسيها)
حدّد السيناريو مسبقًا، وإلا فسيبدو الشرح عامًا جدًا.
لنفترض أن هناك بنكين في نفس الاختصاص القضائي. البنك (A) يريد الدفع، ويستخدم مدفوعاته المرقمنة/المُرمّزة التي يصدرها هو. البنك (B) يريد تسليم أصل مُرمّز. الطرفان لا يرغبان في منح معلومات العملاء والأرصدة والمنطق التشغيلي للطرف الآخر، ولا يرغبان أيضًا في تسليم ذلك لأي جهة ثالثة للتخزين/الوساطة. هذه هي الحالة الأكثر نموذجية لصفقة «السند مقابل المال»، أي ما يسميه القطاع DvP.
النهج التقليدي إما أن يبحث عن وسيط ليقوم بالتمرير في المنتصف، أو أن يسجل الطرفان كلٌ حسابه ثم يقومان بالمطابقة. في الحالة الأولى يتم إدخال طرف ثالث موثوق ومخاطر الطرف المقابل، وفي الحالة الثانية تظهر نافذة قد تحدث فيها الحالة التي يكون فيها أحد الطرفين قد قدّم، بينما الآخر لم يقدم بعد.
ما الذي تقوم به كل طبقة على حدة؟
طريقة Sovereign هي تفكيك هذه المسألة إلى ثلاث طبقات، مع اختلاف مسؤوليات كل طبقة عن الأخرى.
في الأسفل يوجد دفتر حسابات الجهة المؤسسية نفسها. يتم تشغيله داخل سحابة الجهة المؤسسية أو في مركز بياناتها المحلي؛ والمشغل الوحيد هو المؤسسة. هوية العميل، والأرصدة، وتفاصيل المعاملات، والمنطق الخاص بالأعمال كلها تبقى في هذه الطبقة ولا تخرج منها. يتم إصدار الودائع المُرقمنة (tokenized) الخاصة بـ A على دفتر حساباته، ويتم إصدار الأصول المُرقمنة لـ B على دفتر حساباته، ولا يرى أي طرف ما لدى الآخر.
الطبقة الوسطى هي شبكة Rayls الخاصة. تتصل مؤسسات المشاركة داخل نفس الاختصاص بهذه الطبقة. تحدث التسويات بين المؤسسات هنا، ولا يغادر كل دفتر إلا المعلومات الضرورية المُشفّرة والبراهين. والجهة الرسمية تعطي مثالًا هو الإثباتات المُعرّفة بلا معرفة (Zero-Knowledge Proof). أي أنه لا يحتاج البنك B إلى معرفة من هم عملاء البنك A، أو كم تبقى من الرصيد على الحساب، لكي يؤكد أن عملية الدفع هذه قد اكتملت.
في الأعلى توجد سلسلة Rayls العامة. تتيح هذه الطبقة للمؤسسات الاتصال حسب الحاجة بالسيولة العامة. هذه الطبقة اختيارية؛ فعملية التسوية التي تقع فقط بين مؤسستين داخل نفس الاختصاص لا تحتاج إلى المرور عبر السلسلة العامة.
على ماذا تقوم مسألة الذرّية فعلًا؟
معنى التسوية الذرّية بسيط جدًا: الأموال والأصول إما أن تتحرك معًا، أو لا تتحرك معًا؛ ولا توجد حالة وسيطة يكون فيها وصول طرف ولم يصل الطرف الآخر بعد.
الجوهر ليس في دمج دفترَي حساب في دفتر واحد، بل في ربط عمليتين معًا بحيث تتمان في تسوية واحدة، وفي نفس كتلة التأكيد. إذا فشلت أي جهة، فستفشل الصفقة كاملة، ولن يبقى في دفاتر كل طرف حالة نصف منجزة.
وهذا هو السبب في أن النوع النهائيية النهائية يعد مهمًا جدًا في سيناريوهات المؤسسات. فإذا كانت سلسلة ما توفر فقط نهائية احتمالية، فإنه قبل اعتبار التسوية آمنة بما يكفي، يتعين على المؤسسات إبقاء هذا التعرض ورأس المال معلّقين على الحسابات. وهذا يشكل مخاطرة وكذلك تكلفة رأس مال مُقيّد. في العرض الرسمي لـ Rayls عند تقديم Sovereign، تم تحديد النهائيّة الاحتمالية بوضوح باعتبارها مشكلة في المنصات الحالية. تعني النهائيّة الحتمية أن التسوية بمجرد اكتمالها تكون مكتملة فعلًا، ويمكن فورًا تحرير الأموال وما يرتبط بها من ضوابط للمخاطر.
هناك تفصيلة يمكن أن يُخطئ كثيرون في فهمها أو قلبها.
على الشبكة الخاصة وPrivacy Node، لا تُفرض رسوم gas على هذا النوع من المعاملات.
هذه النقطة تستحق أن تُقال على حدة، لأن كثيرين يفترضون ضمنيًا أن إجراء معاملات على بلوك تشين يعني بالضرورة استخدام رموزها لدفع رسوم المعاملات. في بنية Rayls، لا يتعين على المؤسسات دفع gas مقابل كل معاملة عند تنفيذ الأنشطة ضمن دفتر الحسابات الخاص بها وعلى الشبكة الخاصة. الذي يحتاج إلى gas هو سلسلة Rayls العامة، ورمز gas في السلسلة العامة هو USDr وليس RLS.
فصل هاتين النقطتين عن بعضهما ضروري لفهم التكلفة الفعلية التي تتحملها المؤسسات ضمن هذه المنظومة بشكل دقيق.
ما النتيجة الفعلية؟
يمكن تلخيص أثره على الأعمال في ثلاث نقاط محددة جدًا.
لم تعد التسوية تتطلب طرفًا موثوقًا بالتمركز في الوسط. لا تقوم أي من البنكين بتسليم دفتر حسابها إلى الآخر، ولا ترى أي منهما بيانات عملاء الطرف الآخر، لكن يمكن إتمام هذه الصفقة بشكل ذري.
الجهة الرقابية ستحصل على ما تحتاجه. وفقًا لقولهم الرسمي، فإن الامتثال وإتاحة الوصول للرقابة مُدمجان في طبقة البروتوكول الأساسية، وليس كفحص يُضاف لاحقًا. وهذا يعني أن القابلية للتدقيق لا تعتمد على التزام المؤسسات بتقديم التقارير بإرادتها، بل إن البنية المعمارية نفسها تدعم عرض المعلومات ضمن نطاق التفويض.
تحسين كفاءة رأس المال. تضمن النهائيّة الحتمية أن اكتمال التسوية يعني التحرير الفوري، دون الحاجة إلى حجز أموال إضافية وضبط التعرض للمخاطر انتظارًا لتأكيدات احتمالية.
إلى أي مدى وصلت عمليًا؟
هذه البنية ليست تصميمًا على الورق، لكن درجة نضجها تختلف بشدة بين الحالات المختلفة؛ لذا فإن مزجها ومشاهدتها معًا قد يؤدي إلى المبالغة في تقدير الأمور.
ما هو مطبَّق بالفعل في بيئة الإنتاج هو عملة مستقرة بالدولار USDXP أصدرتها XP على Sovereign. ولدى الجهة الرسمية عبارة أخرى يمكن الاستشهاد بها: يقوم العملاء من المؤسسات في البرازيل بمعالجة عشرات الآلاف من الأصول المُمَوْلَة (tokenized) على Privacy Nodes التي تم تشغيلها بالفعل كل شهر؛ والمنصة الأساسية دخلت الإنتاج منذ يونيو 2024، وقد تم نشرها لدى أكثر من 30 مؤسسة مالية.
في مرحلة التجريب، يوجد Drex الصادر عن البنك المركزي البرازيلي، حيث قامت 16 بنكًا كبيرًا في البرازيل بنشر كلٌ منها نسخة خاصة به، مستخدمين عملة البنك المركزي الرقمية لتسوية السندات الحكومية والأصول الأخرى. أما صياغة القول هنا فهي pilot (تجريبي).
الذي تم اختباره هو Kinexys التابع لـ JPMorgan في Project EPIC، حيث تم استخدام Sovereign كطبقة للخصوصية والهوية. الاختبار لا يعني الانتقال إلى الإنتاج.
ما تم الالتزام به لكن لم يُسلَّم بعد، هو تمويل دين خاص بقيمة 1 مليار دولار ناتج عن خطة AmFi، وكذلك أصول طاقة وسلع أساسية تصل إلى 100 مليار دولار كحد أقصى تعهدت بها Nimofast. هذان الرقمان يمثلان حجم الالتزام، وليسا أصولًا تم إصدارها فعليًا عبر Sovereign.
بعد فصل هذه الأربعة فئات، انظر إلى القائمة مرة أخرى؛ تكمن قوة إقناعها في أن نوع المؤسسات يكون شاملًا: من البنوك المركزية إلى البنوك التجارية، وصولًا إلى جهات إصدار الأصول، وليس في جمع مبالغ الالتزام.
خلاصة بجملة واحدة
كل جهة تدير دفتر حسابها الخاص، والعمل معًا في إبرام الصفقات لا يتعارض. النقطة الأساسية هي وضع عملية التسوية في تلك الطبقة الوسطى، بحيث يقتصر ما يغادر كل دفتر على البراهين فقط، لا على البيانات.
للاطلاع على الشرح الكامل الرسمي لـ Sovereign، يمكنك زيارة صفحة المنتجات في موقع Rayls: rayls.com/products/sovereign
مصدر الرجوع: مدونة Rayls الرسمية (Introducing Rayls Sovereign: the onchain gateway for institutions) (Peter Bidewell، 25 أغسطس 2026)؛ توثيق سلسلة Rayls العامة: https://www.rayls.com/blog/introducing-rayls-sovereign-the-onchain-gateway-for-institutions