كوينبيس تدفع x402 نحو الحياد، وStripe تواصل المراهنة على الجانبين خارج MPP

الكاتب: Charlie، مسؤول OSL في الأمريكتين، شريك Venture @ Generative Ventures. عمل سابقًا كنائب الرئيس في شركة كريبتو يونيكورن Strike (شارك في مشروع قانون بيتكوين في السلفادور، وكان مسؤولًا عن أعمال شبكة بيتكوين لايتنينغ في أمريكا اللاتينية ومدفوعات العملات المستقرة)، محللًا للسياسات الاقتصادية الكلية والنقدية لدى صندوقٍ بمستوى تريليون Franklin Templeton، وعضوًا مبكرًا في عملاق المدفوعات Adyen.

تتناول المقالة آراء الكاتب الشخصية ولا تمثل مواقف الشركات المعنية.

الأصدقاء الذين يهتمون مؤخرًا بـ agentic commerce يزدادون باستمرار، لكن مختلف البروتوكولات واللاعبين جعلوا الجميع تدريجيًا غير قادرين على فهم الصورة.

وخاصةً الأسبوع الماضي، كان الجميع مشغولًا بفهم MPP الخاص بـ Stripe / Tempo، وفجأة انضمت Stripe إلى x402 Foundation الخاصة بصديقها Coinbase.

والآن حتى Cloudflare يدعم الطقمين. كما أن Google موجودة في هذا المشهد، لكنها لديها AP2 و UCP أيضًا.

وصلت كذلك Visa وMastercard، لكن من الواضح أنها ليست هنا لتقديم دعم للعملات المستقرة.

Linux Foundation عرّفت بشكل علني x402 كـ “مأوى” محايد يحكمه القطاع عبر إدارة مشتركة، في حين أن Cloudflare حددت صراحةً أنها وضعت x402 وMPP معًا داخل Agents SDK الخاص بها، كما أن Stripe كتبت علنًا أنها تدعم في الوقت نفسه MPP وx402.

إذن: من ينافس من، ومن يكمّل من؟

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

الأمر أشبه بما هو شائع في البنية التحتية للإنترنت—طبقات مختلفة تطول في الوقت نفسه، وشركات مختلفة تراهن في طبقات مختلفة، وفي النهاية يعمل كل شيء أولًا عبر قابلية التشغيل البيني.

إن قصة الاستراتيجية الحقيقية هي: من يعرّف طبقة التحكم الافتراضية للوصول المدفوع إلى paid machine access على agentic web؛ والأهم أن اللاعبِين الرئيسيين يراهنون بوضوح على multi-home، لأن الجميع ما زال يتكهن بأن الاختناق الحقيقي في المستقبل سيقع في الترخيص أم التوزيع أم التسوية.

1. لماذا تركت Coinbase الأمر وقررت أن تُدار مؤسسة x402 عبر Linux؟

إذا كانت x402 مجرد بروتوكول لـ Coinbase، فمن الصعب جدًا أن تصبح خيارًا افتراضيًا للقطاع.

هذه ليست عبارة “صحيح سياسيًا”، بل منطق معياري واقعي للتوحيد.

تعبير Linux Foundation هذه المرة واضح: إنها تؤكد على حياد مقدمي الخدمة، وحوكمة المجتمع، وبنيةٍ تحتية مشتركة، وليس على “شركة ما أطلقت ميزة جديدة في منتج”.

والأهم: صفحة x402 Foundation الآن تكتب أن المشروع في مرحلة التطوير المبكر، وأن آليات الحوكمة ومجلس الإدارة ما زالت قيد البناء.

بعبارة أخرى، هذه الخطوة ليست إعلانًا عن أن “المنتج نضج”، بل إعلان عن “سنمنح هذا البروتوكول بيتًا محايدًا”.

والكلام غير المعلن وراء ذلك بسيط.

إذا كان x402 دائمًا يحمل وجه “ميزة منتج Coinbase” (مثل Base الحالية)، فحتى لو كانت شركات السحابة وشركات الدفع وتنظيمات البطاقات واللاعبون من نوع المنصات على استعداد تقنيًا للتكامل، فمن المؤكد أنهم سيترددون سياسيًا.

لا يريد أحد أن يسلّم طبقة paid access المستقبلية إلى منصة واحدة. وضعها تحت Linux Foundation ليس لأن Coinbase لا تريد السيطرة، بل لأن Coinbase تريد—بالعكس—أن يتم اعتماد x402 على نطاق واسع، ولذلك يجب أولًا إزالة عبء أنها “بروتوكول تابع لـ Coinbase”.

هذه النقطة مهمة فعلًا، لأن كثيرين يرون مثل هذه التحركات من المؤسسات غالبًا على أنها مجرد PR أو موقف “منحاز مفتوح المصدر”.

لكن في حرب البروتوكولات، الحوكمة هي جزء من المنتج.

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

على العكس، إذا تمكن x402 مستقبلًا فعلا أن يصبح نوعًا من baseline للوصول المدفوع متوافقًا مع HTTP-native، فمن المحتمل ألا يكون ذلك لأن كوده هو الأجمل، بل لأنّه—في وقت أبكر—خفّض التكاليف السياسية مقارنةً بالبدائل.

بمعنى آخر: الحوكمة هنا ليست دورًا ثانويًا؛ الحوكمة نفسها هي محرك النمو.

2. ماذا يفعل Stripe بالضبط عبر المناورة يمينًا ويسارًا؟

أكثر لاعب يستحق الملاحظة هذه المرة هو Stripe، لأن تحركات Stripe هي الأكثر قدرة على إرباك الناس.

من جهة، أطلقت Stripe بشكلٍ لافت في 18 مارس MPP، وقدمتها كمعيار مفتوح لدفع الآلات.

ومن جهة أخرى، هي founding contributor في x402 Foundation، ويدعم توثيقها أيضًا مدفوعات الآلات عبر x402.

توثيق Cloudflare أكثر مباشرةً، بل ويذكر صراحةً أن: إن عملية الدفع الأساسية لـ MPP المتعلقة بـ x402 قابلة للتوافق مع الخلف backward-compatible، ويمكن لعميل MPP استهلاك خدمات x402 الحالية مباشرةً.

إذا نظرنا فقط ضمن إطار “تنافس البروتوكولات”، يبدو الأمر كما لو أن Stripe تتلاعب يمينًا ويسارًا.

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

لأن الشيء الذي تحاول Stripe حمايته حقًا، قد لا يكون مجرد 402 handshake ذاته.

الذي تحاول حمايته فعلًا هو تلك الطبقات فوق الـ handshake: credentials، وcompliance، وrisk، وreporting، وtax، وrefunds، وmerchant integration.

Stripe لا تبدو كأنها تؤمن بشكلٍ حقيقي ببروتوكول واحد بعينه؛ بل تبدو كأنها تضمن أن Stripe ستظل طبقة التجريد الافتراضية لمدفوعات agent بغض النظر عن أي handshake قياسي سيفوز في النهاية.

دعم x402، حتى لا تكون خارج النظام البيئي المفتوح؛ دفع MPP، حتى تشارك في تعريف الدلالات الأساسية؛ ثم دفع ACP وShared Payment Tokens إلى الأعلى، حتى تحافظ على طبقة القيمة الأكثر ثِقلًا المتعلقة بسير العمل وأوراق/مستندات الدفع.

لذلك فإن أكثر ما يبدو “غريبًا” في Stripe هذه المرة هو—بالتحديد—الأكثر صدقًا.

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

3. هذه في الحقيقة قصة بنية تحتية لـ B2B

أصبحت أظن أكثر فأكثر أن كثيرًا من وسائل الإعلام قد حوّلت تركيز هذه القضية عن موضعه.

عندما يُذكر agent payments، فإن أول ما يتبادر غالبًا إلى الذهن هو التجزئة: أن يساعدك الذكاء الاصطناعي في شراء تذاكر الطيران، وحجز الفنادق، ووضع الطلب، والقيام بالـ checkout.

لكن إذا نظرت إلى المشاهد التي تم بالفعل نشرها بشكل علني الآن، وتبدأ فعلًا أن تحمل “رائحة بنية تحتية”، فالأول الذي ينطلق ليس checkout للتجزئة، بل B2B paid access الأكثر مللًا—والمعقولية الواقعية—مثل: API مدفوع، بيانات مدفوعة، أدوات مدفوعة، جلسات متصفح مدفوعة، وagent workflow مدفوع.

Cloudflare تدعم علنًا حاليًا فرض الرسوم على HTTP content وAPI وMCP tools باستخدام x402 وMPP.

أقوى مسار لاعتماد x402 هو على paid APIs وtools من developer-to-developer، لأن “لا حساب + دفع لكل طلب” هنا ليس مجرد شعار، بل تنفيذ عملي قابل للتطبيق.

والتغيير الذي خلف ذلك كبير فعلًا.

في الماضي، عندما يكون API قابلًا للتحصيل، كان عليك عادةً المرور عبر سلسلة كاملة من إجراءات “ملائمة للبشر”: فتح حساب، ربط billing، إصدار API key، تعيين حدود، التسوية/المطابقة، ثم معالجة صلاحيات الدفع.

هذا مزعج للناس، فكيف بالـ agent؟ إنه أكثر انزعاجًا.

ما يجعل x402 جذابًا للغاية ليس لأنه أكثر crypto أو لأنه أكثر ذكاء اصطناعي، بل لأنه يحاول إعادة إدخال “الوصول المدفوع” إلى داخل HTTP نفسه، بحيث تحدث السيطرة على الدخول والتفاوض على الدفع تمامًا مثل request-response المعتادة.

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

إذا نظرت إلى هذا النموذج من زاوية B2B والـ machine-to-machine access، فسيبدو أكثر انسيابية بكثير مما هو عليه من زاوية التجزئة.

ومع التقدم أكثر نحو B2B، تصبح مزايا x402 أكثر وضوحًا، وتقل أيضًا حدّته في نقاط النقص إلى حد لا يهدد.

لأن في consumer commerce، هناك مشكلات صعبة جدًا مثل: refunds، والchargebacks، وmerchant-of-record، وconsumer protection، وتحديد المسؤولية. لكن في B2B API واستدعاءات الأدوات، تتضاءل أهمية هذه القضايا بشكل ملحوظ.

في المقابل، الحاجة الفعلية هي: “بدون حساب، الدفع لكل استدعاء، والحصول على النتيجة ثم الانصراف”.

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

وبالنسبة لموجة agent payments اليوم، فمن المحتمل جدًا ألا يكون ذلك checkout للتسوق، بل وصول مدفوع بين متزايد من البرامج، وبين agents، وبين workflows.

4. تطور الصناعة تحقق حكمتي السابقة حول interoperability

أكثر حكمتي جوهرًا في مقالي السابق كانت interoperability.

حينها بدا هذا الحكم وكأنه يحمل بعض النكهة من “منطقي هندسيًا”.

لكن الآن، يبدو أكثر فأكثر كأنه قيد واقع، لأن السوق المفتوح بدأ باستخدام “التصويت بالأقدام”.

Cloudflare لم تختَر جانبًا واحدًا؛ بل تدعم x402 وMPP معًا بشكل مباشر، وتوفر أيضًا خرائط توافقيّة واضحة.

Google تشارك في x402، وفي الوقت نفسه تواصل دفع AP2 وUCP إلى الأمام.

Visa وMastercard أيضًا لم تعبّر عن استراتيجيتها عبر وضع “all in on winner”؛ بل تضاف إلى x402 من جهة، وتواصل تعزيز agent token، والتحقق من الهوية، والتحقق من التعليمات، وإشارات dispute من جهة أخرى.

رهانات الشركات الكبرى المتعددة هي قرارات عقلانية وليست نفاقًا تجاريًا.

لماذا يحدث ذلك؟ لأن هذه البروتوكولات أصلاً ليست في نفس الطبقة.

على الأقل حتى الآن، x402 وMPP أقرب إلى طبقة paid HTTP handshake، وتعالج مسألة “كيف نجعل الطلب يحمل معه قدرة الدفع إلى الخلف”.

AP2 أقرب إلى التفويض بالإنفاق (authority to spend)، وتعالج مسألة “هل لدى هذا agent أهلية موثوقة للصرف لهذه الأموال”.

UCP وACP أقرب إلى طبقة workflow، لمعالجة مشاكل أعلى مثل discovery وcheckout وعلاقة التاجر ونقل بيانات الاعتماد.

عندما تدعم شركات متعددة في الوقت نفسه x402 وMPP وAP2 وUCP، فهذا ليس لأنهم لا يعرفون ما يريدون، بل لأن المعمارية التي سيتم الفوز بها في النهاية قد تكون عبر عبور طبقات متعددة، بل وقد تحتاج إلى بروتوكولات متعددة تتكون معًا.

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

والآن السوق يتحقق من هذا الحكم بنشاط.

وبشكل أعمق: هذا الحكم مهم أيضًا بالنسبة لـ B2B مقابل التجزئة.

لأن عالم التجزئة قد ينتهي فعلًا إلى أن يبتلع بعض المنصات الكبرى وبعض الـ workflows الكبرى؛ لكن عالم B2B ليس كذلك.

الشركات تعيش أصلًا في واقع تعدد السحابة وتعدد طرق الدفع وتعدد أنظمة الـ workflow وتعدد أنظمة الهوية وصلاحياتها.

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

العميل في B2B يدفع غالبًا ليس مقابل “بروتوكول وحيد صحيح”، بل مقابل “القدرة على أن تعمل الأنظمة الحالية في بيئة متعددة البروتوكولات”.

وهذا المنطق يجعل interoperability في بيئة المؤسسات أكثر صلابة مما هي عليه في بيئة consumer.

5. ليست منافسة بروتوكولات فقط، بل منافسة stack بعد تقسيم الطبقات

بمجرد أن تفهم الأمر على أنه تقسيم stack طبقي، ستنسجم فورًا كثير من الظواهر التي كانت تبدو عشوائية.

أدنى طبقة هي paid access handshake.

هذه الطبقة تهتم بـ: كيف يعبر طلب HTTP عن “هنا يلزم دفع رسوم”، وكيف تُعاد ورقة/مستندات الدفع إلى العميل بعد الدفع.

x402 وMPP يتنافسان أساسًا هنا. MPP يحاول نقل 402 إلى semantics أكثر رسمية لهويات HTTP auth؛ بينما x402 يبدو أكثر كونه “يمنطق” 402 عبر جعلها منصة، من خلال headers مخصصة، وfacilitator، وتجريدات التسوية على السلسلة، وتكاملات النظام البيئي، لكي تعمل أولًا.

هذا مسار “الدلالات الموحدة” مقابل مسار “التوزيع على منصة”.

الطبقة التالية هي التفويض بالإنفاق (authority to spend)، أي “من الذي فوّض صرف هذه الأموال”.

هذه الطبقة هي المفتاح الحقيقي الذي لم يدركه كثيرون بعد تمامًا.

الآلات يمكنها الدفع، وهذا ليس صعبًا جدًا؛ لكن أن تكون الآلات مفوضة للدفع بشكل موثوق—هذا هو الصعب.

AP2 مهم لأنه لا يعالج فقط “كيف يتم الدفع”، بل يعالج أيضًا mandates، وverifiable credentials، وauthenticity، وaccountability.

Visa وMastercard عززتا مؤخرًا مثل agent token، وinstruction validation، وpasskeys، وdispute signals؛ وجوهر هذه الأشياء هو أيضًا هنا.

والطبقة التي تليها هي workflow وdistribution.

أي discovery وcheckout وعلاقة التاجر ومشاركة بيانات الاعتماد وتكاملات AI surface، وهي الأقرب إلى “من يتحكم في تدفق حركة المرور وترتيب المعاملات”.

UCP وACP تبدوان كأنهما تتنازعان على هذه الطبقة.

بالنسبة لـ B2B، قد لا تكون هذه الطبقة ساخنة جدًا على المدى القصير، لكن على المدى الطويل قد تكون قيمتها عالية جدًا.

لأن إذا تنسق وكلاء (agents) ويستدعيون ويشترون ويدفعون مستقبلًا متزايدًا من برامج المؤسسات، فمن يملك لغة الـ workflow لن يتحكم فقط في عملية دفع واحدة، بل سيتحكم في كامل سير العمل.

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

المسار الأكثر واقعية هو أن كل طبقة تنمو أولًا بمفردها، ثم تلتئم عبر interoperability ببطء.

وهذا بالضبط سبب أن الرهان المتعدد ليس ترددًا، بل هو قرار عقلاني.

6. المخاطر الحقيقية لـ x402 ليست بالضرورة التنظيم، بل اقتصاديات الانقسام تحت التوازي

إذا كنا نكتفي بإدراك “وجود بروتوكولات متعددة بالتوازي”، فهذا ليس كافيًا لفهم عمق المشكلة.

الخطر الأكبر في x402 قد لا يكون أولًا التنظيم، بل اقتصاديات verify–settle المقسمة إلى خطوتين وما ينتج عنه من time-of-check/time-of-use.

ببساطة: إذا كان التحقق من الدفع والتسوية النهائية ليسا الشيء نفسه، ففي بيئات الإنترنت الحقيقية مثل التوازي العالي، وإعادة المحاولة، وطبقات الوكلاء، وطبقات الكاش، ستظهر “نافذة” إمكانية: pay once, access multiple times.

بيئة x402 تقوم حاليًا بسد الثغرات، مثل settlement cache، وidempotency extension، وpayment identifier، لكن حقيقة أنها تضطر لسد الفجوات تعني أن المشكلة ليست نظرية فقط.

لماذا هذا مهم جدًا لقراء B2B؟

لأن عالم B2B يخاف أكثر شيء من: ليس من أن demo يبدو جميلًا ولا يمكن إنجازه، بل من وجود edge cases كثيرة، ثم يبدأ التسرب فور دخولها إلى الإنتاج.

في monetization الخاصة بـ API، تبدو الفكرة على السطح أن كل طلب يدفع بضعة سنتات؛ لكن إذا كان منتجك محاسَبًا على أساس الاستدعاءات أو النتائج أو الـ workflow، فـ “ادفع مرة واحصل على مرة” أو “ادفع مرة واحصل على عدة مرات” لا يعد تفاصيل منتج، بل يصبح خط حياة أو موت.

لذلك إذا تمكن x402 مستقبلًا فعلا من العمل في B2B، فشرط مهم ليس مجرد narrative، بل أن تُنفذ تلك آليات default-safe بطريقة “بلا تفكير”، وإلا فلن ترتاح الشركات في إدخال تدفقها الحقيقي.

7. البروتوكول قد يكون مجانيًا، لكن بوابات التحصيل لن تختفي

هناك نقطة أخرى أعتقد أنها تستحق أن تُقال بوضوح في هذه المقالة.

كثير من البروتوكولات المفتوحة في النهاية تنتهي إلى مكان مألوف: البروتوكول نفسه يصبح أرخص وأكثر مجانية، بل مجانيًا، لكن بوابات التحصيل الحقيقية تنمو بجواره.

x402 ليس استثناءً.

المعيار نفسه بالطبع يشدد على الانفتاح والحياد و0 fees مدمجة في المعيار، لكن هذا لا يعني أن قيمة الالتقاط value capture ستختفي.

إذا نجح x402، فمن غير المرجح أن تبقى القيمة أساسًا داخل البروتوكول؛ بل ستنتقل إلى الطبقات المجاورة مثل facilitator، والمحافظ وkey management، وdiscovery، وpolicy engine، وtrust wrapper.

وهذا مهم أكثر لـ B2B.

لأن عملاء المؤسسات لن يدفعوا ويعيدوا بناء كامل أنظمتهم على نطاق واسع فقط بسبب بروتوكول جديد؛ ما يدفعون مقابلها فعليًا هو: من يستطيع أن يساعدهم في تنظيف وتعقيدات orchestration، وpolicy، وrisk، وcompliance، وaudit، وsettlement، وحدود الصلاحيات داخل بيئة متعددة البروتوكولات.

بعبارة أخرى: سيصبح البروتوكول مثل لغة طبقة أساسية أكثر وأكثر؛ لكن تحويل هذه اللغات إلى قدرة “يمكن للمؤسسة أن تطمئن معها في تشغيلها فعليًا” في تلك الطبقة قد يصبح أسهل أن تتحول إلى منصة جديدة وبوابة تحصيل جديدة.

وهذا هو سبب اعتقادي أنه عند النظر إلى x402 اليوم، لا ينبغي أن تركز فقط على Coinbase وCloudflare وStripe من يُشبه أكثر “البطل” (المحور الرئيسي).

الأهم هو: من لديه فرصة أكبر للوقوف على تلك الطبقات المجاورة.

Cloudflare لديها موقع في الحافة وموضع لتوزيع حركة المرور، وStripe لديها موقع في بنية الدفع التحتية وعلاقات التجار، وVisa وMastercard لديهما موقع في credentials وشبكة الـ token وموضع الثقة لدى المستهلكين، وGoogle لديها موقع في workflow وdiscovery surface.

قد لا يحدث التقاط القيمة الحقيقية بالضرورة في “من يعرّف 402”، بل غالبًا في “من يدمج 402 داخل نظام المؤسسة الأكبر”.

8. الخاتمة

قضية x402 Foundation ليست إعلانًا بأن x402 قد فازت وتخطت كل بروتوكولات agentic commerce الأخرى.

هي اعتراف علني بأن هذه الجيل من agent payments لن يكون عالمًا للبروتوكول الواحد منذ اليوم الأول.

قيام Coinbase بتسليم x402 إلى Linux Foundation كان بهدف جعله أقرب إلى طبقة عامة محايدة أكثر، وليس منتجًا حصريًا.

عندما يدفع Stripe MPP وفي الوقت نفسه ينضم إلى x402، فهذا ليس ترددًا، بل لأنه يعرف أنه الآن لا ينبغي أن يراهن أحد على جانب واحد فقط.

كون Cloudflare يدعم الطقمين معًا، سببه أنها الأقرب إلى حركة المرور الحقيقية.

وأفعال Google وVisa وMastercard وAdyen أيضًا تبيّن الشيء نفسه: أولًا اجعل النظام يمكنه أن يتبادل العمل بين الأنظمة، ثم ناقش من سيحتل في النهاية أي طبقة.

وإذا نقلت المنظور بعيدًا عن التجزئة، يصبح هذا الحكم أكثر سلاسة.

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

التجزئة بالطبع أكبر، لكنها في كثير من الأحيان في B2B تكشف عن الاحتياجات الحقيقية أبكر، وتحدد شكل البنية التحتية النهائي أبكر أيضًا.

في مقالي السابق وضعت interoperability في المركز، وأعتقد أن جواب السوق في الوقت الحالي واضح جدًا بالفعل: نعم، بل أبكر مما كان يتصور في ذلك الوقت.

وبهذا المعنى، فإن x402 Foundation ليس نهاية هذه القصة.

إنها فقط تجعلنا نرى أبكر أن الموضوع الحقيقي لم يكن أبدًا “من سيفوز”، بل “هذا العالم محكوم أن يتصل ببعضه أولًا بشكل متبادل (mutually interoperable)، ومن يمكنه بعد الاتصال أن يسيطر على أغلى تلك الطبقة”.