# التسوية ليست مسار العمل كله. **ملاحظة تصميم · 7 سبتمبر 2026** تخيل وكيلًا يستأجر خدمة لتنفيذ دفعة مالية. توجد دفعتان على الأقل: رسم استئجار الخدمة، والدفعة التي طُلب من الخدمة تنفيذها. إيصال الأولى ليس تلقائيًا دليلًا على نجاح الثانية. هذا التمييز نقطة بداية ملف الفحص المالي في Proof21. ليس ادعاء بأن البلوك تشين يحتاج طبقة أخرى لتخبره بوجود تحويل أصلي، بل القيمة المقترحة هي ربط الأدلة عبر مسار كامل متفق عليه. ## ثلاثة أسئلة مختلفة **ما المطلوب؟** تحدد التعليمات العملية والشبكة والأصل الدقيق والمستلم والمبلغ والقيود. وعلى النظام المحيط إثبات أصالتها والسلطة السارية؛ لا يجوز لتقرير P21 اختلاق أي منهما. **مقابل ماذا دُفع؟** تحدد الأدلة التجارية التفاعل مع الخدمة والدفع المستخدم لاستئجار المزود. امتداد عروض وإيصالات x402 الموقّعة مصدر لذلك، وتظل قواعد التحقق الخاصة به مطبقة. [1] **ما الذي نُفذ فعلًا؟** يجب تقييم المعاملة في سياق السلسلة الصحيح. لا يجوز تحويل معاملة فاشلة أو رمز ذي الاسم نفسه بعقد مختلف أو مستلم خاطئ أو نهائية غير كافية إلى نجاح صامت. قد تظهر المحفظة نفسها في عدة سجلات. لا يجعلها ذلك متكافئة ولا يثبت أنها تشير إلى العملية نفسها. ## التقرير المفيد محدد لا تقول نتيجة P21 المقترحة «هذا الوكيل آمن»، بل تحدد هل تدعم الأدلة المقدمة ادعاءً معينًا تحت ملف فحص مسمى. يجب أن يكشف التقرير الأدلة الأصلية والروابط المتوقعة وإصدار التقييم وافتراضات المصدر. يمكن لتوقيع أن يصادق على تقرير يتضمن فشلًا. مشاهدة RPC التي يقدمها مزود ليست مثل التحقق المستقل من السلسلة. يجب أن يبقى الإدخال المفقود غير محسوم بدل أن يملأه نموذج لغوي. تفيد هذه الفروق حتى إن لم يمس المسار Bitcoin. دعم Bitcoin/DMT قدرة أساسية لـ Proof21، وليس انحرافًا إجباريًا لكل مستدعٍ. ## البداية بجانب الضوابط القائمة يجب تشغيل أول تجربة في وضع الظل. تظل حدود المحفظة وقواعد التوقيع وضوابط التسوية قائمة. يصدر P21 نتيجة بجانبها، ويعيد مستلم مستقل الفحوص المدعومة. تنجح التجربة إذا كشفت اختلافًا مهمًا أو قللت جهد المطابقة أو أنتجت دليلًا يستخدمه الطرف المقابل. لا تنجح لمجرد توقيع كائن JSON جديد. تشمل الحالات المخطط لها شبكات خاطئة وأصولًا ومستلمين غير صحيحين وتعليمات معدلة وأدلة معاد استخدامها ومعاملات فاشلة ومشاهدات قديمة وبيانات غير متاحة. هذه متطلبات تنفيذ؛ لا يدّعي الموقع وجود مدقق منشور اجتازها بالفعل. ## مثال عملي على ربط البيانات لنفترض وجود تعليمة اصطناعية لتحويل 100 وحدة تجريبية إلى المورّد A. مع ست خانات عشرية، يكون المبلغ المتوقع هو سلسلة العدد الصحيح `100000000`. ويتقاضى مقدم الخدمة رسمًا منفصلًا مقابل خدمته. هذه قيم توضيحية للمحاسبة، وليست رمزًا حقيقيًا أو معاملة على شبكة أو عرض سعر. لنفترض الآن أن مقدم الخدمة يعيد إيصالًا صحيح التوقيع عن رسمه وسجل معاملة لتحويل 100 وحدة إلى المورّد B. قد يكون التفاعل مع الخدمة حقيقيًا بينما يفشل شرط الدفعة المطلوبة. وإذا سمّى السجل المورّد A لكنه وصف أصلًا مختلفًا له رمز العرض نفسه، يفشل الشرط أيضًا. التشابه في الأسماء المقروءة للبشر لا يحل محل الربط الدقيق. تعالج معرّفات السلاسل ومعرّفات الأصول جانبين مختلفين من مشكلة التسمية؛ وCAIP-2 وCAIP-19 مرجعان أصليان مفيدان، لا محركا تحقق. [2][3] ينبغي لملف الفحص المقترح أن يربط معرّف العملية، وبصمة التعليمة، والشبكة المتوقعة، والأصل المحدد، والمستلم، والمبلغ بوحدات صحيحة، ونتيجة التنفيذ، ونقطة الرصد، وإصدار السياسة. ويجب الاحتفاظ بالإيصال التجاري ودليل التنفيذ الأساسي كلٍّ على حدة. قد يساعد شرح الوكيل شخصًا على فهم عدم التطابق، لكنه لا يجوز أن يختلق معاملة مفقودة أو يصحح مستلمًا غير مأذون به بصمت. ## الفشل وغياب الأدلة يحتاجان إلى مسارين مختلفين إذا أظهر سجل مدعوم ومثبت بما يكفي أن المستلم خاطئ، فهذا يدعم نتيجة `FAIL`. أما تعذّر الحصول على السجل فيدعم عادةً `INDETERMINATE`، وليس استنتاج أن الدفع لم يحدث قط. لهذا الفرق أهمية تشغيلية: إعادة الدفع تلقائيًا بعد انتهاء المهلة قد تؤدي إلى دفعة مكررة. ينبغي لخدمة الفحص بيان حدود أدلتها، بينما يقرر متحكم منفصل ومخوّل ما إذا كان سينتظر أو يحقق أو يعيد المحاولة وفق سياسة التطبيق لمنع تكرار الأثر. حداثة الأدلة جزء من السؤال، وليست مجرد طابع زمني للزينة. لا يثبت سجل رُصد قبل الحدث المعني اكتماله لاحقًا. وبالمثل، قد تحتاج معاملة استوفت سياسة التأكيد عند نقطة رصد معينة إلى إعادة تقييم بعد اكتشاف إعادة تنظيم للسلسلة. احتفظ بعمليتي الرصد وأسبابهما؛ لا تستبدل النتيجة السابقة بعلامة خضراء غير مفسرة. ## ما الذي يجب أن يتمكن المستهلك المستقل من إعادة إنتاجه؟ يوفر الاختبار التجريبي المفيد للمستهلك التعليمة الأصلية، وإصدار ملف الفحص المختار، وبايتات الأدلة الدقيقة أو مراجع استرجاعها المصرح بها، ونتائج المنتج. يبدأ المستهلك بتحديد البايتات والجهة المصدرة التي يقيّمها، ثم يعيد المقارنات المدعومة، ثم يطبق قواعد القبول الخاصة به. يجب أن يكون الاختلاف حول القبول ممكنًا دون الادعاء بأن توقيع المنتج معطوب. ينبغي لحزمة الاختبار تغيير عنصر ربط واحد في كل مرة وتسجيل السبب المتوقع. ابدأ بحالة اصطناعية معلومة التطابق؛ غيّر المستلم، ثم الأصل، ثم الشبكة، ثم المبلغ. اختبر على نحو منفصل البيانات القديمة، والتنفيذ الفاشل، وإعادة استخدام العملية، وغياب مصدر الأدلة. وأدرج تقرير فشل صحيح التوقيع، لأن رفض كل تقرير سلبي يهزم غرض النظام. سجّل الفحوص التي نُفذت بالفعل وما لا يزال متطلبًا تصميميًا. قِس العمل الذي تم توفيره، لا عدد الإيصالات المنشأة فحسب. من المقاييس المفيدة قدرة مشغّل آخر على العثور على الأدلة المعنية وشرح عدم التطابق دون مطالبة الوكيل الأصلي بإعادة رواية ما جرى. لا تحتسب عينة اصطناعية إيرادًا من عميل أو دفعة حقيقية ناجحة. يوضح العرض غير المتصل القابل للتنزيل من Proof21 مجموعة محدودة من هذه الفروق، وليس المهايئ المالي الإنتاجي المقترح. ## الأسئلة الشائعة ### هل يثبت إيصال الخدمة الصحيح نجاح الدفعة المطلوبة؟ لا. قد يدعم التفاعل مع الخدمة وفق قواعد التوقيع والتحقق الخاصة به. أما الدفعة المطلوبة فهي ادعاء منفصل يحتاج إلى دليل تنفيذ مرتبط بالتعليمة. احتفظ بالأثرين بدل توسيع معنى إيصال واحد. ### هل يجب أن تؤدي النتيجة غير الحاسمة تلقائيًا إلى دفعة أخرى؟ لا. غياب الأدلة وفشل التنفيذ حالتان مختلفتان. أي إعادة محاولة تخص متحكمًا مأذونًا له صراحةً ومزوّدًا بضوابط منع الدفع المكرر، لا نموذجًا لغويًا يستنتج أن انتهاء المهلة يعني أن شيئًا لم يحدث. ### هل يحتاج كل فحص إلى Bitcoin أو إلى رمز جديد؟ لا. يمكن لتصميم الفحص المالي تقييم سير عمل مدعوم دون كتابة جديدة على Bitcoin. تؤدي الالتزامات الاختيارية وقدرات Bitcoin/DMT أدوارًا منفصلة. وP21 هنا اختصار لاسم المشروع، وليس رمز دفع متاحًا. ## مراجع أصلية إضافية - [2: CAIP-2 — مواصفة معرّف سلسلة الكتل](https://standards.chainagnostic.org/CAIPs/caip-2) - [3: CAIP-19 — مواصفة نوع الأصل ومعرّف الأصل](https://standards.chainagnostic.org/CAIPs/caip-19) ## عملات مستقرة تناسب كل تكامل يتطلب النطاق الأساسي الأول NAT الأصلي وUSDC على Base. ينطلق كل تكامل تجاري إضافي بقائمة سماح واضحة للأصل والشبكة والطريقة، بدلاً من افتراض استخدام جميع الأنظمة العملة نفسها. توضح وثائق المزودين التي روجعت في 9 سبتمبر 2026 أهداف التنفيذ التالية، ولا تثبت تشغيل P21 لها بالفعل. | التكامل | نطاق الدفع | حدود الطريقة | | --- | --- | --- | | Coinbase CDP / x402 | USDC على Base أولاً؛ الشبكات الأخرى بعد اختبار المحوّل | الحفاظ على المخطط المدعوم والشبكة والعقد المحددين | | Binance B402 / BNB Smart Chain | USDT وUSDC وUSD1 وU ضمن نطاق إطلاق B402 | يستخدم USDT/USDC طريقة Permit2؛ ويدعم USD1/U أيضاً EIP-3009 | | PayAI | USDC على Solana وشبكات EVM المعتمدة؛ غيره بعد فحص الإمكانات | إدراج شبكة لا يعني دعم جميع رموزها | | Virtuals ACP | رسوم خدمة USDC وفق دورة حياة المهمة | الحفاظ على معاني المهمة والتمويل والتسوية؛ ليس بديلاً عاماً لـ x402 | | MCP / A2A | لا تفرض البروتوكولات عملة دفع | النقل والاكتشاف لا يختاران الدفع أو يأذنان به | تستخدم أصول BSC الرئيسية المنشورة لدى Binance مقدار 18 منزلة عشرية، بما فيها عقدا USDC وUSDT. ويستخدم USDC على Base عقداً مختلفاً و6 منازل. لا تنقل افتراضات المنازل بين الشبكات ولا تخلط أصول الاختبار بالشبكة الرئيسية. لا تضف FDUSD أو غيره لمجرد ارتباطه بمنصة؛ تحقق من منتج الدفع المحدد. قبل الإعلان عن توفر طريقة، تقاطع قائمة سماح المالك مع إمكانات المزود المهيأ الحالية. ثبّت الشبكة والرمز والمنازل والطريقة والمستلم؛ تحقق من عناوين spender/signer المسموح بها واحفظ بيانات التفويض المطلوبة. لا يجوز أن يؤدي تحديث الإمكانات إلى توسيع القائمة بصمت. يتطلب B402 الإنتاجي إجراءات قبول المزود. تظل جميع مسارات P21 معطلة حتى اكتمال التنفيذ واختبارات التسوية والاعتماد. [Binance assets and methods](https://developers.binance.com/en/docs/products/onchainpay-x402/basics/9.supported-payment-methods) · [Binance integration](https://developers.binance.com/en/docs/products/onchainpay-x402/introduction) · [Coinbase facilitator](https://docs.cdp.coinbase.com/x402/seller/facilitator) · [PayAI assets](https://docs.payai.network/x402/reference) · [Virtuals ACP](https://os.virtuals.io/acp/concepts) · [NAT Ethereum listing](https://www.bitmart.com/en-US/support/articles/7923014477723/360001026214/49446319153179) · [NAT Solana record](https://solscan.io/token/FbKRaqBzupLry3V7QujpNghwrHgxutB4MY11M8aeyVa1) · [NAT BNB Chain contract](https://bscscan.com/token/0x600e3b55d5368c32a94f9372563318adb6a3f882) ## تحديث · الرفض الموقّع لا يعيد كتابة التسوية `REJECT` من الوكيل المستقبِل ليس حكماً على دفتر الأستاذ. يفصل Proof21 سلامة الأثر والتقييم الحتمي والتسوية وقرار المستهلك. قد تبقى المعاملة `CONFIRMED` بينما يوقع المستقبِل `REJECT` وفق سياسته. للمساءلة القابلة للإعادة، يلتزم المستقبِل بملخص/إصدار acceptance-policy قبل الفعل ثم يوقّع decision receipt. إذا أعطت السياسة الحتمية PASS من أدلة كاملة بينما القرار متناقض، يمكن لمقيّم مستقل حفظ التناقض؛ وإذا اعتمدت على مدخل خاص غير متاح فالنتيجة `UNRESOLVED`. ## قراءة إضافية - [تصميم الفحص المالي في P21](https://proof21.xyz/ar/docs/capabilities/check/) - [التحقق والتقييم والقبول](https://proof21.xyz/ar/docs/protocol/verification/) - [دليل تجارب الشركاء](https://proof21.xyz/ar/docs/partners/pilot/) - [1: عروض وإيصالات x402 الموقعة](https://docs.x402.org/extensions/offer-receipt)