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

المؤلف: تشارلي ليو، شريك لدى Generative Ventures

أصبح عدد الأصدقاء الذين يراقبون ما يُسمّى 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.

إذن: من ينافس من؟ ومن يتداخل مع من؟

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

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

القصة الاستراتيجية الحقيقية هي: من الذي سيُعرّف طبقة التحكم الافتراضية للوصول المدفوع على الويب الوكيل (agentic web)؟ والأهم أن اللاعبين الرئيسيين واضح أنهم يتبعون نهج التعدد (multi-home)، لأن الجميع ما يزال يراهن على أين ستقع بالفعل عنق الزجاجة الحقيقي في المستقبل—على مستوى التفويض أم التوزيع أم التسوية.

أولًا: لماذا تخلّت Coinbase عن x402 وأعطتها إلى Linux?

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

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

صياغة Linux Foundation هنا واضحة جدًا؛ فهي تؤكد أن ما يهم هو حياد مزوّدي الخدمة، وحوكمة المجتمع، والبنية التحتية المشتركة، وليس “شركة ما أطلقت ميزة جديدة في منتج”.

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

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

والكلام المستتر وراء ذلك بسيط جدًا.

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

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

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

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

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

وبالعكس، إذا كانت x402 في المستقبل فعلًا تستطيع أن تصبح خط أساس (baseline) للوصول المدفوع على HTTP native، فربما لا يكون ذلك لأن كودها الأكثر جمالًا، بل لأنها أزال تكاليفه السياسية مبكرًا أكثر من غيره.

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

ثانيًا: ماذا يفعل التنافس/التكامل الجانبي لـ Stripe؟

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

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

ومن جهة أخرى، هي أيضًا مساهم مؤسس في x402 Foundation، ووثائقها الخاصة تدعم مدفوعات x402 للآلات.

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

إذا نظرنا فقط من إطار “تنافس البروتوكولات”، فإن Stripe تبدو كأنها تمارس تنافسًا جانبيًا (左右互搏).

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

لأن ما تحاول Stripe الحفاظ عليه ربما ليس مجرد “بروتوكول مصافحة 402” نفسه.

بل ما تريد حمايته هو تلك الطبقات فوق المصافحة: credentials، وcompliance، وrisk، وreporting، وtax، وrefunds، وmerchant integration.

Stripe تبدو ليست “مؤمنة” بمقياس بروتوكول واحد بعينه، بل كأنها تضمن أنه مهما فاز معيار المصافحة النهائي، فإن Stripe ستظل طبقة التجريد الافتراضية لمدفوعات الوكلاء (agent payments).

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

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

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

ثالثًا: هذه في الحقيقة قصة بنية تحتية B2B

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

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

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

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

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

والتغير خلف هذا الأمر كبير بالفعل.

في الماضي، عندما تريد API ما أن تُحصّل رسومًا، كان غالبًا يتعين المرور بسلسلة كاملة من الخطوات “الودية مع البشر”: فتح حساب، ربط billing، إصدار API key، وضع حدود، تسوية/مطابقة الحسابات (对账)، ثم معالجة صلاحيات الدفع.

هذا مزعج للناس، فكيف بالأمر بالنسبة لوكلاء (agents)؟ إنه أكثر انزعاجًا.

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

الخادم يعيد 402، ويخبرك كم تساوي قيمة هذا الطلب؛ ثم يدفع العميل المال، وبعد ذلك يكرر الطلب نفسه باستخدام بيانات إثبات الدفع.

هذا النموذج، إذا نظرت إليه من زاوية البرمجيات B2B وإتاحة الآلة-إلى-آلة، سيكون أكثر سلاسة بكثير مما لو نظرنا إليه من زاوية التجزئة.

وكلما اتجهنا أكثر نحو B2B، ازدادت ميزة x402 وضاقت فجواتها حتى وإن كانت موجودة.

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

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

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

وبالنسبة لموجة agent payments الحالية تحديدًا، فهذا السيناريو غالبًا ليس سلة التسوق، بل الوصول المدفوع بين متزايد من البرامج—بين البرامج، وبين الوكلاء، وبين سير العمل.

رابعًا: التحقق من تطور الصناعة يدعم حكم interoperability الذي ذكرته سابقًا

في مقالي السابق، كانت أهم فرضية لدي هي interoperability.

في ذلك الوقت، بدت هذه الفرضية وكأنها تحمل بعض الطابع القائل “ينبغي أن يكون الأمر هكذا من الناحية المعمارية”.

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

Cloudflare لم تختر جانبًا، بل تدعم x402 وMPP معًا بشكل مباشر، كما أنها نفّذت بوضوح تعيينات (compatibility mapping) للتوافق.

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

Visa وMastercard أيضًا لم تُظهر استراتيجية “all in one winner”؛ بل من جهة تنضم إلى x402، ومن جهة أخرى تزيد الاستثمار في agent token، والتحقق من الهوية، والتحقق من التعليمات، وإشارات النزاع (dispute signals).

مراهنة العمالقة متعددة الأطراف هي قرار عقلاني، وليست نفاقًا تجاريًا.

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

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

**AP2 ** أقرب إلى سلطة الإنفاق والتحقق من النوايا الموثوقة، حيث تحل مشكلة “هل يملك هذا الوكيل أهلية إنفاق هذا المبلغ فعليًا”.

**UCP وACP ** هما أكثر شبيهًا بطبقة سير العمل (workflow)، حيث يتعاملان مع اكتشاف الخدمة (discovery)، وcheckout، وعلاقات التاجر، وتمرير بيانات الاعتماد، وهي قضايا في مستوى أعلى.

أن تدعم شركات كثيرة في الوقت نفسه x402 وMPP وAP2 وUCP ليس لأن لديها لخبطة ولا تستطيع فهم الأمور؛ بل لأنالهيكل الذي سينتهي به الفوز في النهاية غالبًا ما يكون عبـارة عن بنية متعددة الطبقات تتطلب بروتوكولات متعددة لتكوين كل شيء.

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

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

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

ففي عالم التجزئة، قد يتم امتصاص النهاية في النهاية بواسطة عدد قليل من المنصات الكبيرة وعدد قليل من أنظمة سير العمل الكبيرة؛ لكن عالم B2B ليس كذلك.

الشركات أصلًا تعيش في واقع متعدد السحب (multi-cloud)، متعدد طرق الدفع، أنظمة سير عمل متعددة، وأنظمة أذونات متعددة للهويات.

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

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

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

خامسًا: ليست مجرد منافسة بروتوكولات، بل منافسة stack بعد الفصل إلى طبقات

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

أعمق طبقة هي paid access handshake.

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

x402 وMPP يضربون أساسًا هنا. MPP تحاول جعل 402 أكثر اندماجًا مع دلالات auth في HTTP بشكل رسمي؛ بينما x402 أشبه بتحويل 402 إلى منصة (platformization)، عبر header مخصص، وfacilitator، وتجريد التسوية على السلسلة، وتكاملات مع النظام البيئي، لتجعله يعمل أولًا.

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

الطبقة التالية هي authority to spend، أي “من الذي فوّض هذه الأموال؟”

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

المبالغ التي يدفعها الآلي (machine) ليست هي الصعوبة؛ الصعوبة الحقيقية هي أن الآلة يمكن تفويضها بشكل موثوق للدفع.

AP2 مهم لأنه لا يحل مشكلة “كيفية الدفع” فقط، بل يواجه أمور mandates، وverifiable credentials، وauthenticity، وaccountability.

Visa وMastercard زادت مؤخرًا التركيز على agent token، والتحقق من التعليمات، وpasskeys، وإشارات النزاع (dispute signals)، وهذه كلها في جوهرها ضمن هذه الطبقة.

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

أي discovery، وcheckout، وعلاقة التاجر، ومشاركة الاعتمادات (credential sharing)، وتكامل سطح AI—وهي أشياء أقرب إلى “من يتحكم بتدفق حركة البيانات (traffic) وترتيب/تنسيق المعاملات”.

UCP وACP ينافسان هنا.

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

لأنه إذا أصبح المزيد من برامج المؤسسات تُنسّق وتستدعي وتشتري وتدفع عبر agent، فإن من يمتلك لغة سير العمل لن يكون فقط يتحكم في عملية دفع واحدة، بل يتحكم في سير العمل بأكمله.

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

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

ولهذا السبب، المراهنة متعددة الرؤوس ليست ترددًا بل قرار عقلاني.

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

إذا كنا مجرد نعرف أن “تعدد البروتوكولات موجود”، فهذا لا يكفي لفهم العمق.

الخطر الأكبر في x402 ليس بالضرورة الرقابة (regulation)، بل قد يكون اقتصاديات تقسيم verify–settle إلى خطوتين، أي time-of-check/time-of-use.

ببساطة: إذا لم تكن عملية التحقق من الدفع والآلية النهائية للتسوية شيئًا واحدًا، ففي بيئات الإنترنت الحقيقية مثل كثافة التزامن العالية، وإعادة المحاولة (retries)، وطبقات الوكلاء، وطبقات الكاش (caching)، سيظهر نافذة “ادفع مرة واحدة، واحصل على وصول عدة مرات”.

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

لماذا تعد هذه النقطة مهمة جدًا لقراء B2B تحديدًا؟

لأن أكثر ما تخاف منه B2B ليس أن عروض demo جميلة لا يمكن تنفيذها، بل أن الحالات الحدّية (edge cases) كثيرة جدًا ثم تتسرب المشاكل عند الانتقال إلى الإنتاج.

Monetization عبر API تبدو من ناحية سطحية كأنها بضعة سنتات لكل طلب؛ لكن إذا كان منتجك يتقاضى رسومًا حسب الاستدعاء أو حسب النتيجة أو حسب سير العمل، فإن “ادفع مرة واحصل على مرة واحدة” مقابل “ادفع مرة واحصل على عدة مرات” لا يعود تفصيلًا في المنتج، بل خط حياة/موت.

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

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

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

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

x402 أيضًا كذلك.

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

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

وهذا مهم جدًا بالنسبة لـ B2B.

لأن العملاء في المؤسسات لن يدفعوا أو يغيّروا كامل بنية أنظمتهم لمجرد بروتوكول جديد، بل ما هم مستعدون للدفع مقابله هو من يستطيع مساعدتهم في تنظيف وإدارة كل هذه المهام المزعجة في بيئة متعددة البروتوكولات: orchestration، وpolicy، وrisk، وcompliance، وaudit، وsettlement، وحدود الصلاحيات.

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

وهذا هو السبب أيضًا الذي يجعلني أعتقد أنه عند النظر إلى x402 اليوم، لا ينبغي أن تراقب فقط Coinbase أو Cloudflare أو Stripe من هو أقرب إلى “البطل”.

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

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

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

ثامنًا: الخاتمة

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

إنها اعتراف علني بأن جيل مدفوعات الوكلاء (agent payments) من أول يوم لن يكون عالمًا من بروتوكول واحد فقط.

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

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

دعم Cloudflare لكلا النظامين معًا لأن ذلك الأقرب إلى حركة المرور الواقعية.

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

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

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

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

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

ومن هذا المنظور، فإن x402 Foundation ليست نهاية قصة هذه المعركة.

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