> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# العملات الرقمية للبنوك المركزية CBDC: من مشروع عابر إلى اليوم
- URL: https://arabroot.io/articles/العملات-الرقمية-للبنوك-المركزية-cbdc-من-مشروع-عابر-الى-اليوم/
- Published: 2026-10-28T06:11:35.000Z
- Updated: 2026-10-28T13:45:36.000Z
- Description: ما هي العملة الرقمية للبنك المركزي، وما الذي جربه مشروع عابر بين المملكة والإمارات، وما الذي قاله البنك المركزي السعودي رسمياً.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, البلوكتشين والعملات الرقمية, الاستضافة الذاتية

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

والعملة الرقمية للبنك المركزي Central Bank Digital Currency، واختصاراً CBDC، موضوع يكثر فيه الخلط، فالبعض يظنها عملة مشفرة يصدرها البنك المركزي، والبعض يظنها مجرد تطبيق دفع، والبعض يربطها حتماً بالبلوكتشين. لذلك سوف نبدأ من أنواع المال نفسها، ثم ننتقل إلى مشروع «عابر» الذي نفذه البنك المركزي السعودي ومصرف الإمارات المركزي، ثم إلى المشاريع الدولية مثل mBridge، ثم نبني نموذجاً مصغراً لعملتين رقميتين من بنكين مركزيين افتراضيين ونسوي بينهما دفعة عبر الحدود في معاملة واحدة، ثم نناقش قرارات التصميم التي تواجه أي بنك مركزي. والمقال تعليمي تقني، وكل ما يخص الموقف الرسمي في المملكة مأخوذ من صفحات البنك المركزي السعودي نفسه، ولا نتوقع فيه أي قرار لم يعلن.

وسوف نناقش في هذا المقال ما يلي:

- أنواع المال: نقد البنك المركزي، وأموال البنوك التجارية، والعملات المستقرة، والعملات المشفرة، وأين تقف العملة الرقمية للبنك المركزي بينها.
- العملة الرقمية للأفراد Retail وللبنوك Wholesale، ولماذا تهتم البنوك المركزية بها.
- مشروع عابر Aber بين المملكة والإمارات: ما الذي جرب، وكيف صمم، وما الذي تعلمه البنكان.
- من عابر إلى mBridge، وموقف البنك المركزي السعودي المعلن.
- تجربة: عملتان رقميتان افتراضيتان وتسوية دفع مقابل دفع PvP في معاملة واحدة، مع ساق تفشل وحساب مجمد.
- قرارات التصميم في العملة للأفراد: الخصوصية، والعمل دون اتصال، وحدود الاحتفاظ، والبرمجة، والتقنية.
- التجارب التي سبقت عابر، والأمن والصمود، والعلاقة مع العملات المستقرة.
- ما الذي يعنيه كل ذلك لشركة مدفوعات، وقائمة استعداد.

## أين تقف العملة الرقمية للبنك المركزي بين أنواع المال؟

عندما تنظر إلى رصيدك في تطبيق البنك، فأنت لا تنظر إلى مال يملكه البنك المركزي، وإنما إلى التزام على البنك التجاري تجاهك: البنك مدين لك بهذا المبلغ، وقد شرحنا كيف يحفظ البنك هذه الالتزامات في [مقال النظام المصرفي الأساسي](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B8%D8%A7%D9%85-%D8%A7%D9%84%D9%85%D8%B5%D8%B1%D9%81%D9%8A-%D8%A7%D9%84%D8%A7%D8%B3%D8%A7%D8%B3%D9%8A-core-banking-%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-%D8%A7%D9%84%D8%A8%D9%86%D9%83-%D9%85%D9%86-%D8%A7%D9%84%D8%AF%D8%A7%D8%AE%D9%84/). أما الالتزام المباشر على البنك المركزي فيأخذ اليوم شكلين فقط: النقد الورقي الذي يستطيع أي شخص أن يحمله، والاحتياطيات Reserves التي تحفظها البنوك التجارية في حساباتها لدى البنك المركزي، والتي لا يملكها إلا البنوك، ومنها تسوى المدفوعات بين البنوك كما شرحنا في [مقال المقاصة والتسوية](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%86%D8%AA%D9%82%D9%84-%D8%A7%D9%84%D8%A7%D9%85%D9%88%D8%A7%D9%84-%D8%A8%D9%8A%D9%86-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-%D8%A7%D9%84%D9%85%D9%82%D8%A7%D8%B5%D8%A9-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9/).

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

![خمس بطاقات: نقد البنك المركزي والتزامه على البنك المركزي ويشمل النقد الورقي والاحتياطيات، وأموال البنوك التجارية والتزامها على البنك التجاري وهي رصيد حسابك، والعملة الرقمية للبنك المركزي والتزامها على البنك المركزي بصيغة رقمية بنوعين للأفراد أو للبنوك، والعملات المستقرة والتزامها على الشركة المصدرة أو الآلية وخطرها فقدان الربط، والعملات المشفرة ولا التزام فيها على أحد، وتحتها تصحيح للبس الشائع أن العملة الرقمية للبنك المركزي ليست عملة مشفرة يصدرها البنك المركزي](https://arabroot.io/content/images/2026/10/cbdc-01-money.webp)

السؤال الذي يفرق بين أنواع المال: على من يقع الالتزام

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

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

وقد يتساءل البعض: إذا كانت لا تختلف في القيمة، فلماذا تهتم بها البنوك المركزية أصلاً؟ ويذكر بنك التسويات الدولية في ورقته عن [نتائج مسح 2024 عن العملات الرقمية للبنوك المركزية والأصول المشفرة](https://www.bis.org/publ/bppdf/bispap159.htm?ref=arabroot.io)، المنشورة في أغسطس 2025، أن 91% من البنوك المركزية التي شملها المسح، أي 85 من 93، كانت تستكشف عملة رقمية للأفراد أو للبنوك أو كليهما، وأن العمل على العملة للبنوك أكثر تقدماً، وأن كثيراً منها يريد أن يحافظ على دور مال البنك المركزي مع تراجع استخدام النقد وتحول الأصول إلى رموز، وأن أكثر من بنك من كل ثلاثة سرع عمله بسبب تطورات العملات المستقرة والأصول المشفرة. أي أن الدافع ليس التقنية في ذاتها، وإنما أن يبقى للمال الرسمي مكان في عالم تتحول فيه المدفوعات إلى أشكال رقمية يصدرها غير البنك المركزي.

## مشروع عابر Aber: تجربة سعودية إماراتية

أقرب تجربة إلينا هي مشروع «عابر»، والاسم كلمة عربية اختيرت لأنها تعني من يعبر الحدود. وبحسب [التقرير النهائي للمشروع](https://www.centralbank.ae/media/cbshgsmf/aber-report-2020-en.pdf?ref=arabroot.io) المنشور على موقع مصرف الإمارات المركزي، أعلن البنك المركزي السعودي ومصرف الإمارات المركزي المبادرة في يناير 2019، وكان هدفها أن يختبرا هل يمكن لعملة رقمية واحدة يصدرها البنكان معاً Dual-issued أن تكون وحدة تسوية بين البنوك التجارية داخل كل بلد وبين البلدين. ثم أعلن البنكان النتائج في [بيان مشترك على موقع البنك المركزي السعودي](https://www.sama.gov.sa/en-US/MediaCenter/News/pages/news-630.aspx?ref=arabroot.io)، وذكر البيان أن العملة الرقمية للبنوك في المشروع أصدرها البنكان المركزيان واستخدمها هما والبنوك المشاركة فقط، كوحدة تسوية للمعاملات المحلية وعبر الحدود بين البنوك التجارية في البلدين، وأن النتائج كانت متسقة مع تجارب مشابهة أجرتها بنوك مركزية أخرى، وأظهرت أن تقنية السجلات الموزعة يمكن أن تمكن البنوك المركزية من تطوير أنظمة المدفوعات محلياً وعبر الحدود.

وغطى المشروع ثلاث حالات استخدام بحسب التقرير: مدفوعات بين البنكين المركزيين على سجل مشترك، ومدفوعات محلية بين البنوك التجارية، ومدفوعات عبر الحدود بين البنوك التجارية في البلدين. وشارك فيه ستة بنوك تجارية، ثلاثة من كل بلد، وكان من المبادئ التي اتفق عليها المشاركون أن تكون البنوك التجارية مشاركة فعلاً تشغل عقدها بنفسها على الشبكة، لا مستخدمة لنظام يشغله غيرها. ويذكر التقرير أن المشروع استخدم Hyperledger Fabric بإصدار الدعم الطويل 1.4، وأن القناة الواحدة حققت قرابة 15 معاملة في الثانية، وأن الأداء زاد خطياً تقريباً مع عدد القنوات حتى تجاوز 100 معاملة في الثانية في شبكة البنوك الستة باستخدام تسع قنوات من أصل خمس عشرة قناة ثنائية ممكنة، مع زمن استجابة متوسط قرابة 3 ثوان. والصورة التالية تلخص المشروع:

![ملخص مشروع عابر: ثلاث حالات استخدام هي مدفوعات بين البنكين المركزيين ومدفوعات محلية بين البنوك التجارية ومدفوعات عبر الحدود، وتحتها أربع بطاقات: من 2019 إلى 2020 بإعلان في يناير 2019 وتقرير نهائي في نوفمبر 2020، وبنكان مركزيان وستة بنوك تجارية كل منها يشغل عقدته، وHyperledger Fabric 1.4 LTS، وأداء قرابة 15 معاملة في الثانية لكل قناة وأكثر من 100 بتسع قنوات وزمن قرابة 3 ثوان](https://arabroot.io/content/images/2026/10/cbdc-02-aber.webp)

عابر جرب عملة رقمية واحدة يصدرها بنكان مركزيان، تستخدمها البنوك فقط

### ما الذي سبق عابر؟ تجارب البنوك المركزية الأولى

لم يبدأ عابر من الصفر، فالفصل الذي يستعرض التجارب السابقة في تقريره النهائي يحكي قصة مفيدة لمن يريد أن يفهم كيف تطورت الفكرة. ففي كندا جرب بنك كندا في المرحلة الأولى من مشروع Jasper إيصالات رقمية يصدرها البنك المركزي مقابل نقد مودع، على منصة Ethereum وبإجماع إثبات العمل، ونجحت الوظائف في بيئة غير إنتاجية، ولكن التقرير ينقل أن هناك قلقاً من الكفاءة وفجوات، ثم انتقلت المرحلة الثانية إلى منصة Corda المصرح بها التي تستخدم «عقدة توثيق» Notary بدلاً من إثبات العمل، وأضافت آلية توفير السيولة Liquidity Saving Mechanism التي تجمع المدفوعات المنتظرة وتسويها بالصافي. وفي سنغافورة بدأت سلطة النقد في أواخر 2016 مشروع Ubin مع مؤسسات مالية ومزودي تقنية، وجربت في مراحله ثلاث منصات معاً، Corda وHyperledger Fabric وQuorum، وهي نسخة خاصة من Ethereum، وينقل تقرير عابر أن حل Corda كان فيه قيود في الخصوصية، وأن حلي Fabric وCorda اعتمدا على بعض الخدمات المركزية لضمان الصحة.

وفي أوروبا واليابان جرب البنك المركزي الأوروبي وبنك اليابان في مشروع Stella على مراحل: الأولى سألت هل يستطيع سجل موزع أن يشغل آلية توفير السيولة في أنظمة التسوية الإجمالية الآنية RTGS، وكانت الخلاصة كما ينقلها التقرير أن بعض الخصائص الوظيفية يمكن تحقيقها، ولكن التقنية لم تكن ناضجة بعد لتشغيل أنظمة بحجم RTGS بسبب قيود في الأداء والتوسع، والثانية جربت تسليم الأوراق المالية مقابل الدفع Delivery versus Payment على ثلاث منصات، والثالثة جربت المدفوعات عبر الحدود بين سجلات مختلفة. وفي جنوب أفريقيا بدأ البنك المركزي في أواخر 2017 مشروع Khokha مع سبعة بنوك لمحاكاة نظام تسوية بين البنوك على سجل موزع. ومن هذه التجارب كلها جاء عابر بفكرة جديدة: عملة واحدة يصدرها بنكان من بلدين، بدلاً من عملة لكل بنك مركزي وجسر بينهما.

### دورة حياة الوحدة الرقمية في عابر

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

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

## من عابر إلى mBridge، وما قاله البنك المركزي السعودي

الخطوة التالية في العالم كانت مشروع mBridge، الذي تصفه [صفحته في بنك التسويات الدولية](https://www.bis.org/project/mbridge?ref=arabroot.io) بأنه منصة لعملات رقمية متعددة لبنوك مركزية، مبنية على تقنية السجلات الموزعة، تشترك فيها البنوك المركزية والبنوك التجارية لمدفوعات عبر الحدود أسرع وأقل تكلفة، على سلسلة جديدة تسمى mBridge Ledger، وأن أعضاءه المؤسسين سلطة النقد في هونغ كونغ وبنك تايلاند ومعهد العملة الرقمية في البنك المركزي الصيني ومصرف الإمارات المركزي، وأن كل عضو شغل عقدة تحقق. وفي 5 يونيو 2024 أعلن بنك التسويات الدولية في [بيان صحفي](https://www.bis.org/press/p240605.htm?ref=arabroot.io) أن المشروع وصل إلى مرحلة المنتج الأدنى القابل للتطبيق Minimum Viable Product، وأن البنك المركزي السعودي ينضم إليه عضواً كاملاً. ثم تذكر صفحة المشروع أن بنك التسويات الدولية أعلن في أكتوبر 2024 أنه يسلم المشروع إلى الشركاء.

أما داخل المملكة، فقد نشر البنك المركزي السعودي خبراً بعنوان [«Saudi Central Bank Continues CBDC Experimentations»](https://www.sama.gov.sa/en-US/MediaCenter/News/pages/news-812.aspx?ref=arabroot.io) يقول فيه إنه يعمل على مرحلة من مشروع يركز على حالات استخدام محلية لعملة رقمية للبنوك، بالتعاون مع البنوك المحلية وشركات التقنية المالية، وإنه يسعى في هذه المرحلة إلى استكشاف الأثر الاقتصادي وجاهزية السوق وتطبيقات الدفع السريعة الممكنة، ومراجعة الاعتبارات السياساتية والقانونية والتنظيمية قبل الانتقال إلى المراحل التالية. ويؤكد البيان صراحة أنه لم يتخذ أي قرار بشأن إصدار عملة رقمية للبنك المركزي في المملكة، وأنه يواصل التركيز على استكشاف فوائدها ومخاطرها المحتملة.

⚠️

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

## تجربة: عملتان رقميتان وتسوية دفع مقابل دفع

الفكرة التقنية التي تجمع عابر وmBridge هي أن تكون عملتان أو أكثر على سجل واحد يشترك فيه المشاركون، فتسوى الدفعة عبر الحدود في معاملة واحدة بدلاً من سلسلة بنوك مراسلة. وحتى نرى هذه الفكرة بالكود، نبني نموذجاً مصغراً على آلة EVM بأداة Foundry: عقداً لعملة رقمية للبنوك يصدرها بنك مركزي افتراضي، ونسخة ثانية منه لبنك مركزي افتراضي آخر، وعقداً يسوي الساقين معاً. وهذا نموذج تعليمي لا يمثل تصميم عابر ولا mBridge ولا أي عملة حقيقية، فعابر استخدم Hyperledger Fabric كما ذكرنا، والرمزان wA وwB في التجربة اسمان افتراضيان. احفظ العقد الأول باسم `src/WholesaleCBDC.sol`:

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

// A toy wholesale CBDC: only the issuing central bank mints and burns, only banks it admits can hold it,
// and the central bank can freeze an account. For learning only.
contract WholesaleCBDC {
    string public symbol;
    address public immutable centralBank;
    mapping(address => bool) public admitted;
    mapping(address => bool) public frozen;
    mapping(address => uint256) public balanceOf;
    mapping(address => mapping(address => uint256)) public allowance;
    uint256 public totalSupply;

    event Issued(address indexed bank, uint256 amount);
    event Redeemed(address indexed bank, uint256 amount);
    event Transfer(address indexed from, address indexed to, uint256 amount);

    modifier onlyCB() { require(msg.sender == centralBank, "only the central bank"); _; }

    constructor(string memory s) { symbol = s; centralBank = msg.sender; admitted[msg.sender] = true; }

    function admit(address bank) external onlyCB { admitted[bank] = true; }
    function setFrozen(address bank, bool f) external onlyCB { frozen[bank] = f; }

    // the bank moves reserves at the central bank into tokens (issue) or back (redeem)
    function issue(address bank, uint256 amt) external onlyCB { require(admitted[bank], "not admitted"); balanceOf[bank] += amt; totalSupply += amt; emit Issued(bank, amt); }
    function redeem(address bank, uint256 amt) external onlyCB { balanceOf[bank] -= amt; totalSupply -= amt; emit Redeemed(bank, amt); }

    function approve(address spender, uint256 amt) external returns (bool) { allowance[msg.sender][spender] = amt; return true; }
    function transfer(address to, uint256 amt) external returns (bool) { _move(msg.sender, to, amt); return true; }
    function transferFrom(address from, address to, uint256 amt) external returns (bool) {
        allowance[from][msg.sender] -= amt; _move(from, to, amt); return true;
    }
    function _move(address from, address to, uint256 amt) internal {
        require(admitted[from] && admitted[to], "holder not admitted");
        require(!frozen[from] && !frozen[to], "account frozen");
        require(balanceOf[from] >= amt, "insufficient balance");
        balanceOf[from] -= amt; balanceOf[to] += amt; emit Transfer(from, to, amt);
    }
}
```

في الكود أعلاه لاحظ التالي:

- المصدر الوحيد هو البنك المركزي الذي نشر العقد، والدالة `issue` تمثل الخطوة التي يحول فيها البنك التجاري احتياطيه إلى وحدات رقمية، و`redeem` عكسها، كما في دورة حياة عابر.
- الشبكة مصرح بها: لا يستطيع أي عنوان أن يحمل الوحدات إلا إذا أدخله البنك المركزي بالدالة `admit`، وهذا الفرق الجوهري عن رموز الشبكات العامة التي يحملها أي عنوان.
- البنك المركزي يستطيع أن يجمد حساباً بالدالة `setFrozen`، وهذه أداة رقابية حقيقية في أي نظام رسمي، ووضعناها لنرى أثرها على التسوية.

ثم عقد التسوية في الملف `src/PvP.sol`:

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import {WholesaleCBDC} from "./WholesaleCBDC.sol";

// Payment versus payment: both legs of a cross-currency payment settle in the same transaction, or none does.
contract PvP {
    function settle(WholesaleCBDC x, address payerX, uint256 amtX, WholesaleCBDC y, address payerY, uint256 amtY) external {
        require(msg.sender == payerX || msg.sender == payerY, "not a party");
        x.transferFrom(payerX, payerY, amtX);   // leg 1: currency X from bank 1 to bank 2
        y.transferFrom(payerY, payerX, amtY);   // leg 2: currency Y from bank 2 to bank 1
    }
}
```

العقد ينفذ الساقين بالترتيب في نفس المعاملة: wA من البنك الأول إلى الثاني، ثم wB من الثاني إلى الأول. وإذا فشلت أي ساق لأي سبب تلغى المعاملة كلها، بما فيها الساق الأولى التي نجحت، لأن المعاملة على هذه الآلة وحدة واحدة كاملة أو لا شيء. وهذا ما يسمى الدفع مقابل الدفع Payment versus Payment، واختصاراً PvP، ويذكر تقرير عابر نفسه أن السجل الذي يحمل عدة عملات رقمية يمكن أن يعطي هذه القدرة ويقلل خطر التسوية الذي تحاول أنظمة مثل CLS حله لعدد محدود من العملات. وأخيراً ملف الاختبار `test/Cbdc.t.sol`، الذي يبني بنكين مركزيين وبنكين تجاريين ويجرب أربعة سيناريوهات:

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import {Test, console2} from "forge-std/Test.sol";
import {WholesaleCBDC} from "../src/WholesaleCBDC.sol";
import {PvP} from "../src/PvP.sol";

contract CbdcLab is Test {
    address cbA = address(0xA0); address cbB = address(0xB0);   // two central banks
    address bankA = address(0xA1); address bankB = address(0xB1); // a commercial bank in each country
    address outsider = address(0xEE);
    WholesaleCBDC wA; WholesaleCBDC wB; PvP pvp;

    function setUp() public {
        vm.prank(cbA); wA = new WholesaleCBDC("wA");
        vm.prank(cbB); wB = new WholesaleCBDC("wB");
        pvp = new PvP();
        // each central bank admits both commercial banks and the PvP contract, then issues to its own bank
        vm.startPrank(cbA); wA.admit(bankA); wA.admit(bankB); wA.admit(address(pvp)); wA.issue(bankA, 1_000_000); vm.stopPrank();
        vm.startPrank(cbB); wB.admit(bankA); wB.admit(bankB); wB.admit(address(pvp)); wB.issue(bankB, 1_000_000); vm.stopPrank();
        vm.prank(bankA); wA.approve(address(pvp), type(uint256).max);
        vm.prank(bankB); wB.approve(address(pvp), type(uint256).max);
    }

    function show(string memory when) internal view {
        console2.log(when);
        console2.log("  bankA: wA", wA.balanceOf(bankA), "wB", wB.balanceOf(bankA));
        console2.log("  bankB: wA", wA.balanceOf(bankB), "wB", wB.balanceOf(bankB));
    }

    function test_1_pvp() public {
        show("before PvP");
        vm.prank(bankA); pvp.settle(wA, bankA, 100_000, wB, bankB, 98_000);   // agreed rate 0.98
        show("after one atomic PvP");
    }

    function test_2_legFails() public {
        vm.prank(bankA);
        vm.expectRevert(bytes("insufficient balance"));
        pvp.settle(wA, bankA, 100_000, wB, bankB, 2_000_000);                 // bankB cannot pay leg 2
        show("after failed PvP (leg 1 rolled back too)");
    }

    function test_3_permissioned() public {
        vm.prank(bankA);
        vm.expectRevert(bytes("holder not admitted"));
        wA.transfer(outsider, 10);
        console2.log("transfer to a non-admitted address: reverted");
        vm.prank(outsider);
        vm.expectRevert(bytes("only the central bank"));
        wA.issue(outsider, 1_000_000);
        console2.log("issue by someone other than the central bank: reverted");
    }

    function test_4_freeze() public {
        vm.prank(cbB); wB.setFrozen(bankB, true);
        vm.prank(bankA);
        vm.expectRevert(bytes("account frozen"));
        pvp.settle(wA, bankA, 100_000, wB, bankB, 98_000);
        console2.log("PvP with a frozen account: reverted, total wA supply", wA.totalSupply());
    }
}
```

```bash
docker run --rm --name lab-cbdc-forge -v "$PWD:/src" ghcr.io/foundry-rs/foundry:v1.8.6 \
  "cp -r /src /tmp/cbdc && cd /tmp/cbdc && forge install foundry-rs/forge-std --no-git >/dev/null 2>&1; forge test -vv"
```

والجزء المهم من المخرج سوف يكون كما يلي:

```text
Ran 4 tests for test/Cbdc.t.sol:CbdcLab
[PASS] test_1_pvp() (gas: 245047)
Logs:
  before PvP
    bankA: wA 1000000 wB 0
    bankB: wA 0 wB 1000000
  after one atomic PvP
    bankA: wA 900000 wB 98000
    bankB: wA 100000 wB 902000

[PASS] test_2_legFails() (gas: 165347)
Logs:
  after failed PvP (leg 1 rolled back too)
    bankA: wA 1000000 wB 0
    bankB: wA 0 wB 1000000

[PASS] test_3_permissioned() (gas: 82008)
Logs:
  transfer to a non-admitted address: reverted
  issue by someone other than the central bank: reverted

[PASS] test_4_freeze() (gas: 167767)
Logs:
  PvP with a frozen account: reverted, total wA supply 1000000
```

في المخرج أعلاه لاحظ التالي:

- في السيناريو الأول تبادل البنكان 100,000 من wA مقابل 98,000 من wB بسعر متفق عليه في معاملة واحدة، فلم توجد لحظة دفع فيها أحدهما ولم يستلم، وهذا ما لا يضمنه التحويل التقليدي عبر الحدود.
- في السيناريو الثاني طلبت التسوية من bankB أن يدفع 2,000,000 وهو يملك مليوناً فقط، ففشلت الساق الثانية، والأرصدة بعدها هي نفس أرصدة البداية بالضبط، أي أن الساق الأولى ألغيت تلقائياً، ولم يحتج أحد أن يطالب الآخر بإرجاع شيء.
- في السيناريو الثالث رفض العقد تحويلاً إلى عنوان لم يدخله البنك المركزي، ورفض إصداراً من غير البنك المركزي، أي أن قواعد من يحمل ومن يصدر جزء من الكود نفسه.
- في السيناريو الرابع جمد البنك المركزي B حساب bankB، فرفضت التسوية كلها، والإجمالي المصدر من wA بقي كما هو، وهذا يبين القوة والخطر معاً: أداة رقابية فعالة في يد البنك المركزي، تحتاج حوكمة واضحة لمن يستخدمها ومتى.

![ثلاث بطاقات: تسوية ناجحة 100,000 من wA مقابل 98,000 من wB تصبح فيها أرصدة bankA 900000 و98000 وbankB 100000 و902000، وساق ثانية لا تكفي فتلغى المعاملة كلها وتعود الأرصدة كما كانت، وحساب مجمد فترفض التسوية، وتحتها شرح خطر التسوية وأن التسوية الذرية تزيله تقنياً مع أن من يملك السجل يملك أدوات مثل التجميد](https://arabroot.io/content/images/2026/10/cbdc-03-pvp.webp)

على سجل واحد تسوى الساقان معاً أو لا تسوى أي منهما

### ما الذي تعلمناه من التجربة كمهندسين؟

التجربة صغيرة، ولكنها تكشف قرارات تصميم يواجهها أي نظام حقيقي من هذا النوع. أولاً، الذرية Atomicity ليست ميزة إضافية، وإنما أساس التسوية الآمنة، وقد حصلنا عليها مجاناً لأن الساقين على نفس السجل وفي نفس المعاملة، أما إذا كانت العملتان على سجلين مختلفين فتحتاج آلية أعقد مثل الأقفال بالهاش والوقت التي رأيناها في مقال شبكة Lightning، وهي نفس الفكرة التي يذكرها تقرير عابر عند مناقشة ربط الشبكات المختلفة. ثانياً، كل قرار رقابي مثل التجميد أو قبول مشارك يجب أن يترك أثراً قابلاً للتدقيق، فالعقد في تجربتنا يصدر أحداثاً للإصدار والاسترداد والتحويل، ولكنه لا يصدر حدثاً عند التجميد، وهذا نقص يجب أن يصلح في أي نظام حقيقي، لأن الجهة الرقابية والمشاركين يحتاجون أن يعرفوا من جمد ماذا ومتى، كما شرحنا في [مقال سجل التدقيق](https://arabroot.io/articles/%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82-audit-trail-%D9%85%D9%86-%D9%81%D8%B9%D9%84-%D9%85%D8%A7%D8%B0%D8%A7-%D9%88%D9%85%D8%AA%D9%89/). ثالثاً، صلاحيات البنك المركزي في الكود هي نفسها صلاحيات من يملك مفتاحه، وهذا يعيدنا إلى قسم الأمن. رابعاً، قاعدة من يحمل العملة، أي الدالة `admit`، هي ما يجعل الشبكة مصرحاً بها، وهذا يتوافق مع ما وصفه بيان عابر من أن العملة استخدمها البنكان والبنوك المشاركة فقط.

وحتى لا نبالغ في ما تثبته التجربة: هي تعمل على عقدة Ethereum محلية واحدة، فلا يوجد فيها أي إجماع بين بنوك مستقلة، ولا خصوصية، فكل رصيد يراه كل من يقرأ السجل، بينما تحتاج أنظمة التسوية الحقيقية أن يرى كل بنك أرصدته ومعاملاته فقط، ولهذا اختار عابر منصة Fabric بقنواتها الخاصة بين كل بنكين، وسوف نرى القنوات في مقال الشبكات الخاصة للمؤسسات. ولا يوجد في التجربة ربط بنظام التسوية الحالي، ولا آلية لتوفير السيولة، ولا أي ضمانات قانونية. فالتجربة تثبت فكرة واحدة فقط، هي الذرية على سجل مشترك، وكل ما عداها قرارات تصميم كبيرة.

## لماذا تهتم البنوك المركزية بالتحويل عبر الحدود تحديداً؟

التحويل عبر الحدود اليوم يمر غالباً بسلسلة من البنوك المراسلة، كما شرحنا في [مقال التحويلات الدولية](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A7%D8%AA-%D8%A7%D9%84%D8%AF%D9%88%D9%84%D9%8A%D8%A9-swift-%D9%88%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-%D8%A7%D9%84%D9%85%D8%B1%D8%A7%D8%B3%D9%84%D8%A9-%D9%88%D9%83%D9%85-%D9%8A%D8%B3%D8%AA%D8%BA%D8%B1%D9%82-%D8%A7%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84/): بنك المرسل لا يملك حساباً عند بنك المستلم، فيمر المال عبر بنك أو أكثر يملك كل منهما حساباً عند الآخر، وكل بنك في السلسلة يضيف وقتاً ورسوماً، وكل ساق تسوى في نظام بلدها في ساعات عمله. والسجل المشترك يقترح بديلاً مختلفاً جذرياً: العملتان على نفس السجل، والبنكان مشاركان فيه مباشرة، فتسوى الدفعة في معاملة واحدة كما رأينا في التجربة، دون حسابات متبادلة بين المراسلين ودون انتظار. والصورة التالية تقارن الطريقتين:

![مقارنة: في الأعلى الطريقة الحالية حيث يمر التحويل من بنك المرسل إلى بنك مراسل أول ثم ثان ثم بنك المستلم، وكل بنك يحفظ حسابات Nostro وVostro ويضيف وقتاً ورسوماً، وفي الأسفل سجل واحد يشغله البنوك المركزية والبنوك المشاركة يتصل به بنك المرسل وبنك المستلم مباشرة فتسوى الساقان معاً، وتحتهما ما يتحسن من وقت ووسطاء وما يبقى صعباً من اختلاف الأنظمة والسياسات والحوكمة](https://arabroot.io/content/images/2026/10/cbdc-04-crossborder.webp)

من سلسلة مراسلين إلى سجل مشترك، والمشكلة الصعبة تنتقل من التقنية إلى الحوكمة

ولكن لاحظ ما يبقى صعباً حتى لو عملت التقنية تماماً: من يحكم السجل المشترك، ومن يقرر قبول مشارك جديد، وقانون أي بلد يطبق عند الخلاف، وكيف ترتبط المنصة بأنظمة التسوية الحالية في كل بلد، وكيف تتعامل مع اختلاف السياسات النقدية التي ذكرها تقرير عابر نفسه. وهذه الأسئلة هي ما يجعل هذه المشاريع تأخذ سنوات بعد أن تنجح تقنياً، وهي أيضاً ما يجعل السؤال الذي طرحناه في [مقال البلوكتشين للمبتدئين](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D9%84%D9%88%D9%83%D8%AA%D8%B4%D9%8A%D9%86-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-%D9%88%D9%85%D8%AA%D9%89-%D9%84%D8%A7-%D8%AA%D8%AD%D8%AA%D8%A7%D8%AC%D9%87/#when-not) حاضراً هنا: السجل الموزع منطقي عندما توجد أطراف مستقلة لا تقبل أن يملك أحدها السجل، وبنوك مركزية لدول مختلفة مثال واضح على ذلك.

### كيف قد تبدو الدفعة من داخل تطبيق؟

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

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

## الأمن والصمود: ما الذي يجب أن يحمى؟

في كل المقالات السابقة كان أكبر خطر هو المفتاح الخاص، وهنا يصبح هذا الخطر في أعلى مستوياته: المفتاح الذي يملك صلاحية الإصدار، أي الدالة `issue` في تجربتنا، يستطيع أن ينشئ مالاً رسمياً. لذلك أي نظام حقيقي لا يضع هذه الصلاحية في مفتاح واحد، وإنما يوزعها على توقيعات متعددة وأجهزة أمن عتاد HSM وإجراءات موافقة، كما شرحنا في [مقال وحدات أمن العتاد](https://arabroot.io/articles/%D9%88%D8%AD%D8%AF%D8%A7%D8%AA-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B9%D8%AA%D8%A7%D8%AF-hsm-%D9%88%D8%A7%D9%84%D8%B1%D9%82%D9%85-%D8%A7%D9%84%D8%B3%D8%B1%D9%8A-pin-%D9%88%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%85%D9%81%D8%A7%D8%AA%D9%8A%D8%AD/). وفي التجربة رأينا أن أي عنوان غير البنك المركزي يحاول الإصدار يرفض، وهذا يحمي من المهاجم الخارجي، ولكنه لا يحمي من سرقة مفتاح البنك المركزي نفسه، وهذا ما تحميه الإجراءات وليس الكود.

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

## العملة للأفراد: قرارات التصميم

العملة للبنوك قرار تقني ومؤسسي محدود نسبياً، أما العملة للأفراد فتمس كل مواطن وكل تاجر وكل بنك، لذلك هي التي تأخذ أطول نقاش. وأفضل مثال على حجم هذا النقاش اليورو الرقمي، فبحسب [صفحة البنك المركزي الأوروبي](https://www.ecb.europa.eu/euro/digital%5Feuro/html/index.en.html?ref=arabroot.io) قرر مجلس المحافظين في أكتوبر 2025 الانتقال إلى المرحلة التالية من المشروع، ويحضر النظام لتجربة في 2027، ويهدف إلى أن يكون جاهزاً لإصدار أول محتمل في 2029 بشرط أن يعتمد التشريع الأوروبي اللازم خلال 2026، والصفحة نفسها تذكر أنه لم يتخذ قرار بالإصدار بعد. وهذه هي القرارات التي يواجهها أي بنك مركزي يفكر في عملة للأفراد:

![جدول قرارات التصميم: من يتعامل مع المستخدم البنك المركزي أو الوسطاء، والخصوصية بين رؤية كل شيء وبيانات مجزأة، والعمل دون اتصال بأجهزة آمنة، وحد الاحتفاظ لكل فرد وخطر انتقال الودائع في الأزمات، والبرمجة ومن يقرر القواعد، والتقنية بين سجل موزع وقاعدة بيانات مركزية، مع أمثلة من اليورو الرقمي وعابر](https://arabroot.io/content/images/2026/10/cbdc-05-design.webp)

التقنية تأتي بعد هذه الأسئلة، وكل إجابة لها ثمن

- **من يتعامل مع المستخدم؟** البنك المركزي لا يريد عادة أن يفتح حسابات لملايين الأفراد ويخدمهم، لذلك تتجه أغلب التصاميم إلى نموذج من طبقتين: البنك المركزي يصدر، والبنوك وشركات الدفع توزع وتخدم العملاء، وهذا مهم جداً لشركة المدفوعات في قصتنا، لأنه يعني أن الوسطاء يبقى لهم دور، ولكن بقواعد جديدة.
- **الخصوصية**: النقد الورقي لا يترك أثراً، والدفع الرقمي يترك بيانات، والتوازن بين مكافحة غسل الأموال وحق الخصوصية قرار سياسي قبل أن يكون تقنياً. وتقول صفحة اليورو الرقمي إن البنك المركزي الأوروبي والنظام لن يستطيعا تحديد المستخدمين أو رؤية ما يشترونه من بيانات الدفع التي تصلهم.
- **العمل دون اتصال**: النقد يعمل دون شبكة، والعملة الرقمية تحتاج أجهزة آمنة لتعمل دون اتصال، وهنا تعود مشكلة الإنفاق المزدوج التي بدأنا بها المسار كله في مقال تاريخ العملات الرقمية، لأن الجهاز غير المتصل لا يستطيع أن يسأل أحداً هل صرفت هذه الوحدة من قبل. وصفحة اليورو الرقمي تذكر أن الدفع سيكون ممكناً متصلاً ودون اتصال بالهاتف أو البطاقة.
- **حد الاحتفاظ**: إذا استطاع الناس أن ينقلوا كل ودائعهم من البنوك إلى عملة البنك المركزي بنقرة، فقد تتحول أزمة ثقة صغيرة في بنك إلى سحب سريع جداً، لذلك تناقش أغلب المشاريع حداً أقصى لما يحمله الفرد.
- **البرمجة**: المال القابل للبرمجة، أي أن تكون قواعد الاستخدام جزءاً من الوحدة نفسها، يختلف عن المدفوعات القابلة للبرمجة، أي أن تبني تطبيقات فوق مال عادي. والتجميد في تجربتنا مثال بسيط على القدرة التي تأتي مع البرمجة، ومعها سؤال من يقرر القواعد.
- **التقنية**: لا يوجد ما يلزم أن تكون العملة على سجل موزع، فبنك مركزي واحد يصدر عملته لأفراد بلده هو حالة «جهة واحدة يقبلها الجميع» في اختبارنا من خمسة أسئلة، وقاعدة بيانات مركزية قوية قد تكون أنسب، والسجل الموزع يصبح منطقياً أكثر عندما تتعدد الأطراف المستقلة كما في التحويل عبر الحدود.

## العملة الرقمية الرسمية والعملات المستقرة

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

## ماذا يعني هذا لشركة مدفوعات؟

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

وفي المقابل هناك أشياء لا يجب أن تفعلها الشركة: أن تبني منتجاً على افتراض عملة لم تعلن، أو أن تسوق لعملائها «ريالاً رقمياً» من إنتاجها، فالعملة الرسمية يصدرها البنك المركزي وحده، وأي رمز تصدره شركة بقيمة الريال هو شيء آخر تماماً، أقرب إلى العملة المستقرة أو النقود الإلكترونية التي تحتاج ترخيصاً، وقد رأينا في مقال تاريخ العملات الرقمية تحذير الجهات الرسمية في المملكة من العملات الافتراضية.

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

## أسئلة المجلس، وما نستطيع أن نقوله عنها

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

## أخطاء شائعة

- **«العملة الرقمية للبنك المركزي عملة مشفرة رسمية»**: هي التزام على البنك المركزي بقيمة العملة الوطنية، ولا تتقلب قيمتها، وقد لا تستخدم أي بلوكتشين.
- **«التجربة تعني قرار إصدار»**: عابر والمرحلة المحلية التي أعلنها البنك المركزي السعودي تجارب، والبيان الرسمي يقول إنه لا يوجد قرار.
- **الخلط بين العملة للبنوك والعملة للأفراد**: أغلب ما جرب في المنطقة للبنوك فقط، ولا يمسه الفرد مباشرة.
- **«السجل الموزع يحل مشاكل التحويل عبر الحدود»**: يحل مشكلة التسوية التقنية، أما الحوكمة والأنظمة والسياسات النقدية فتبقى، كما يذكر تقرير عابر.
- **نقل أرقام التجارب كأنها مواصفات**: أرقام الأداء في عابر قيست على شبكة تجريبية بستة بنوك وإصدار محدد من Fabric في 2019، ولا تصلح لتقدير أداء أي نظام قادم، فالتصميم والتقنية والحجم كلها مختلفة، وأي تقدير يحتاج قياساً جديداً على التصميم الفعلي.
- **تجاهل قدرة التجميد والبرمجة**: أي نظام رسمي يملك أدوات رقابة، والسؤال الحقيقي هو الحوكمة التي تحكم استخدامها.

## قائمة استعداد لشركة مدفوعات

| البند              | ما الذي تفعله الآن                                                                                |
| ------------------ | ------------------------------------------------------------------------------------------------- |
| المتابعة الرسمية   | متابعة أخبار البنك المركزي السعودي وأوراقه، وتسجيل الاهتمام بأي تجربة يعلن عنها للشركات           |
| الفهم التقني       | فريق يفهم السجلات الموزعة والرموز وإدارة المفاتيح والتسوية الذرية، بتجارب داخلية على شبكات اختبار |
| التكامل            | بنية مدفوعات بطبقة مستقلة لوسائل الدفع، حتى تضاف وسيلة جديدة دون إعادة بناء النظام                |
| الامتثال           | فصل واضح بين ما هو مال رسمي وما هو منتج للشركة في أي واجهة أو تسويق                               |
| البيانات والخصوصية | فهم متطلبات نظام حماية البيانات الشخصية، لأن أي عملة رقمية للأفراد سوف تطرح أسئلة الخصوصية أولاً  |
| التوقعات           | لا توجد خطة عمل مبنية على تاريخ إصدار غير معلن                                                    |

## إزالة التجربة

```bash
docker image rm ghcr.io/foundry-rs/foundry:v1.8.6
```

## تدريب عملي

1. أضف إلى `WholesaleCBDC.sol` حداً أقصى لما يحمله أي عنوان، واكتب اختباراً يبين أن التسوية ترفض إذا تجاوز المستلم الحد.
2. عدل `PvP.sol` ليقبل التسوية فقط إذا وافق الطرفان مسبقاً على نفس الشروط، بدالة يسجل بها كل طرف موافقته، ثم ينفذها أي منهما.
3. اكتب اختباراً ينفذ عشر تسويات متتالية، واحسب الغاز لكل تسوية، وقارنه بما ذكره تقرير عابر عن الأداء.

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- العملة الرقمية للبنك المركزي التزام مباشر على البنك المركزي بصيغة رقمية، للأفراد أو للبنوك، وليست عملة مشفرة ولا تتقلب قيمتها.
- 91% من البنوك المركزية في مسح بنك التسويات الدولية لعام 2024 تستكشفها، والعمل على العملة للبنوك أكثر تقدماً.
- مشروع عابر بين البنك المركزي السعودي ومصرف الإمارات المركزي جرب عملة رقمية واحدة يصدرها بنكان على Hyperledger Fabric مع ستة بنوك تجارية، ونجح تقنياً، وترك أسئلة نقدية وتنظيمية.
- البنك المركزي السعودي انضم إلى mBridge في 2024، وأعلن مرحلة تجارب محلية للعملة للبنوك، وقال صراحة إنه لم يتخذ قراراً بالإصدار.
- التسوية الذرية على سجل مشترك تزيل خطر الساق المفقودة كما رأينا في التجربة، والتجميد يبين أن الحوكمة جزء من التصميم.
- العملة للأفراد تحتاج قرارات في الوسطاء والخصوصية والعمل دون اتصال وحدود الاحتفاظ والبرمجة قبل أي قرار تقني.

[![](https://arabroot.io/content/images/2026/10/cross-border-payments-cover-cover.webp)دليلالتحويلات الدولية: SWIFT والبنوك المراسلةنتبع حوالة دولية عبر سلسلة البنوك المراسلة في نموذج بافتراضات مكتوبة، ونقرأ رسائل MT103 وpacs.008 ومثال تتبع gpi من Swift.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A7%D8%AA-%D8%A7%D9%84%D8%AF%D9%88%D9%84%D9%8A%D8%A9-swift-%D9%88%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-%D8%A7%D9%84%D9%85%D8%B1%D8%A7%D8%B3%D9%84%D8%A9-%D9%88%D9%83%D9%85-%D9%8A%D8%B3%D8%AA%D8%BA%D8%B1%D9%82-%D8%A7%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84/)[![](https://arabroot.io/content/images/2026/10/payments-clearing-cover-cover.webp)دليلكيف تنتقل الأموال بين البنوك؟ المقاصة Clearing والتسويةماذا يحدث بين ضغطة «ادفع» ووصول المال: الدفع والمقاصة والتسوية الإجمالية والصافية، مع محاكاة يوم من التسويات بين ستة بنوك.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%86%D8%AA%D9%82%D9%84-%D8%A7%D9%84%D8%A7%D9%85%D9%88%D8%A7%D9%84-%D8%A8%D9%8A%D9%86-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-%D8%A7%D9%84%D9%85%D9%82%D8%A7%D8%B5%D8%A9-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9/)[![](https://arabroot.io/content/images/2026/10/core-banking-cover-cover.webp)دليلالنظام المصرفي الأساسي Core Banking: البنك من الداخلما الذي يحفظه النظام المصرفي الأساسي وكيف تمر فيه الحركة، ولماذا يعمل بتاريخ عمل ودورة ليلية، مع مختبر لاستحقاق العائد على ألف حساب.](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B8%D8%A7%D9%85-%D8%A7%D9%84%D9%85%D8%B5%D8%B1%D9%81%D9%8A-%D8%A7%D9%84%D8%A7%D8%B3%D8%A7%D8%B3%D9%8A-core-banking-%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-%D8%A7%D9%84%D8%A8%D9%86%D9%83-%D9%85%D9%86-%D8%A7%D9%84%D8%AF%D8%A7%D8%AE%D9%84/)[![](https://arabroot.io/content/images/2026/10/saudi-payments-cover-cover.webp)دليلمنظومة المدفوعات في السعودية: سريع وSARIE ومدى وسدادالأنظمة الوطنية للمدفوعات في المملكة كما تصفها مصادر البنك المركزي، وما يعنيه كل نظام للمطور، مع تحليل تقارير نقاط البيع الأسبوعية.](https://arabroot.io/articles/%D9%85%D9%86%D8%B8%D9%88%D9%85%D8%A9-%D8%A7%D9%84%D9%85%D8%AF%D9%81%D9%88%D8%B9%D8%A7%D8%AA-%D9%81%D9%8A-%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9-%D8%B3%D8%B1%D9%8A%D8%B9-%D9%88-sarie-%D9%88-%D9%85%D8%AF%D9%89-%D9%88-%D8%B3%D8%AF%D8%A7%D8%AF/)[![](https://arabroot.io/content/images/2026/10/crypto-history-cover-cover.webp)دليلتاريخ العملات الرقمية: من Cypherpunks إلى Bitcoinكيف حاول المهندسون صنع نقد رقمي أربعين سنة، ولماذا تعثرت المحاولات قبل Bitcoin، وما الذي جمعه Bitcoin منها.](https://arabroot.io/articles/%D8%AA%D8%A7%D8%B1%D9%8A%D8%AE-%D8%A7%D9%84%D8%B9%D9%85%D9%84%D8%A7%D8%AA-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A%D8%A9-%D9%85%D9%86-cypherpunks-%D8%A7%D9%84%D9%89-bitcoin/)[![](https://arabroot.io/content/images/2026/10/enterprise-blockchain-cover-cover.webp)دليلشبكة بلوكتشين خاصة للمؤسسات: Besu أم Fabric؟كيف تبني شبكة خاصة من أربع شركات بإجماع QBFT، وماذا يحدث عندما يتوقف أعضاؤها، ومتى تختار Fabric أو قاعدة بيانات.](https://arabroot.io/articles/%D8%B4%D8%A8%D9%83%D8%A9-%D8%A8%D9%84%D9%88%D9%83%D8%AA%D8%B4%D9%8A%D9%86-%D8%AE%D8%A7%D8%B5%D8%A9-%D9%84%D9%84%D9%85%D8%A4%D8%B3%D8%B3%D8%A7%D8%AA-besu-%D8%A7%D9%85-fabric/)

## سجل التحديثات

- أكتوبر 2026: كتابة المقال، واختبار التجارب على Docker Engine 29.8.0 مع Foundry v1.8.6 وSolc 0.8.30 وforge-std v1.17.0.