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

مؤلف: تشارلي، رئيس قسم OSL في الأمريكتين، شريك استثماري في Generative Ventures. نائب الرئيس السابق في شركة العملات المشفرة العملاقة Strike (التي شاركت في قانون البيتكوين في السلفادور وكانت مسؤولة عن شبكة البرق للبيتكوين في أمريكا اللاتينية وأعمال دفع العملات المستقرة)، ومحلل الاقتصاد الكلي والعملات في صندوق فرانكلين تمبلتون الذي تبلغ قيمته تريليون دولار، وعضو مبكر في شركة المدفوعات العالمية العملاقة Adyen.

يعكس هذا المقال وجهات نظر الكاتب الشخصية ولا يمثل مواقف الشركات ذات الصلة.

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

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

علاوة على ذلك، يدعم Cloudflare الآن كلا النظامين. تشارك جوجل أيضًا، لكن لديها بروتوكول AP2 وبروتوكول UCP الخاص بها.

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

تُعرّف مؤسسة لينكس علنًا x402 على أنها "معسكر أساسي" محايد ومُدار بشكل مشترك من قبل الصناعة، في حين أدرجت Cloudflare صراحةً كلاً من x402 وMPP في حزمة تطوير البرامج الخاصة بها، كما صرحت Stripe علنًا أنها تدعم كلاً من MPP وx402.

من يتنافس مع من، ومن يتداخل مع من؟

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

يشبه هذا الوضع حالة شائعة في البنية التحتية للإنترنت - حيث تتطور طبقات مختلفة في وقت واحد، وتراهن شركات مختلفة على طبقات مختلفة، وفي النهاية، سيؤدي التوافق التشغيلي إلى تشغيل كل شيء.

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

1. لماذا قامت شركة Coinbase بتسليم مؤسسة x402 إلى نظام Linux؟

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

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

بيان مؤسسة لينكس هذه المرة واضح للغاية؛ فهو يؤكد على حيادية مزودي الخدمة، وحوكمة المجتمع، والبنية التحتية المشتركة، بدلاً من "أصدرت شركة معينة ميزة منتج جديدة".

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

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

والنتيجة الضمنية بسيطة للغاية.

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

لا أحد يريد تسليم طبقة الوصول المدفوع المستقبلية إلى منصة واحدة. إن وضعها تحت مظلة مؤسسة لينكس ليس لأن Coinbase لا تريد التحكم بها؛ بل على العكس من ذلك، لأنها تريد أن يتم اعتماد x402 على نطاق واسع، ولذلك يجب عليها أولاً إزالة عبء "هذا بروتوكول Coinbase".

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

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

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

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

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

2. ما الذي تفعله استراتيجية Stripe المزدوجة حقاً؟

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

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

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

إن وثائق Cloudflare أكثر وضوحًا، حيث تنص صراحة على أن MPP متوافق مع عملية الدفع الأساسية لـ x402، ويمكن لعملاء MPP استهلاك خدمات x402 الحالية بشكل مباشر.

إذا نظرنا إلى الأمر من منظور "منافسة البروتوكولات" فقط، يبدو أن Stripe تنخرط في استراتيجية مزدوجة.

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

لأن ما تريد Stripe حمايته حقًا ليس مجرد عملية المصافحة 402 نفسها.

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

لا يبدو أن Stripe مؤمن حقيقي بأي بروتوكول واحد؛ بل يبدو أنها تضمن أنه بغض النظر عن معيار المصافحة الذي يسود في النهاية، تظل Stripe طبقة التجريد الافتراضية لمدفوعات الوكلاء.

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

وبالتالي، فإن أكثر جوانب Stripe "غرابة" هذه المرة هو في الواقع أكثر جوانبها صدقاً.

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

3. هذه في الواقع قصة تتعلق بالبنية التحتية بين الشركات (B2B).

أشعر بشكل متزايد بأن العديد من وسائل الإعلام قد ركزت بشكل خاطئ على هذه المسألة.

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

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

تدعم Cloudflare الآن بشكل علني فرض رسوم على محتوى HTTP وواجهات برمجة التطبيقات وأدوات MCP باستخدام x402 وMPP.

يكمن أقوى مسار لاعتماد x402 في واجهات برمجة التطبيقات والأدوات المدفوعة من مطور إلى مطور، لأن "عدم وجود حساب + الدفع لكل طلب" هنا ليس مجرد حيلة، بل هو واقع تشغيلي حقيقي.

التغييرات الكامنة وراء ذلك مهمة للغاية.

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

بالنسبة للبشر، هذا الأمر مزعج للغاية بالفعل؛ أما بالنسبة للوكلاء، فهو أكثر إحراجاً.

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

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

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

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

لأن عمليات رد الأموال، وعمليات رد المبالغ المدفوعة، والتاجر المسجل، وحماية المستهلك، وتحديد المسؤولية كلها قضايا صعبة في التجارة الاستهلاكية؛ ولكن في واجهات برمجة التطبيقات B2B واستدعاءات الأدوات، تتضاءل أهمية هذه القضايا بشكل كبير.

وعلى النقيض من ذلك، فإن "لا حاجة لحساب، والدفع مقابل كل مكالمة، والحصول على النتائج والرحيل" هو مطلب حقيقي.

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

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

4. يؤكد تطور الصناعة صحة حكمي السابق بشأن قابلية التشغيل البيني

كان الحكم الأساسي في مقالتي الأخيرة هو قابلية التشغيل البيني.

في ذلك الوقت، بدا هذا الحكم أشبه بـ "ينبغي هيكلته بهذه الطريقة".

والآن، بات الأمر يشبه بشكل متزايد قيداً واقعياً، حيث أن السوق المفتوحة تعبّر عن رأيها بالفعل من خلال انسحابها.

لم تنحز شركة Cloudflare إلى جانب واحد، بل تدعم بشكل مباشر كلاً من x402 وMPP مع إجراء عمليات ربط التوافق بشكل واضح.

تشارك جوجل في x402 مع مواصلة تطوير AP2 و UCP.

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

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

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

على الأقل حتى الآن، فإن x402 و MPP أقرب إلى طبقة المصافحة HTTP المدفوعة، مما يعالج مسألة "كيفية ضمان عودة الطلبات مع إمكانية الدفع".

يُعد AP2 أقرب إلى التفويض والنية الموثوقة، حيث يعالج مسألة "هل يحق لهذا الوكيل إنفاق هذه الأموال؟"

تعتبر UCP و ACP أشبه بطبقة سير العمل، حيث تتعامل مع الاكتشاف والدفع وعلاقات التجار ونقل بيانات الاعتماد - وهي قضايا أقرب إلى "من يتحكم في حركة المرور وتنسيق المعاملات".

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

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

وبالنظر إلى الوضع الحالي، نجد أن السوق يؤكد هذا الحكم بشكل فعال.

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

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

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

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

إن ما يرغب عملاء B2B حقًا في دفعه ليس في كثير من الأحيان "البروتوكول الصحيح الوحيد"، بل القدرة على جعل الأنظمة الحالية تعمل في بيئة متعددة البروتوكولات.

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

5. هذا ليس مجرد تنافس على البروتوكولات، بل تنافس على طبقات البنية التحتية.

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

في الطبقة السفلية توجد عملية المصافحة الخاصة بالوصول المدفوع.

تتعلق هذه الطبقة بكيفية تعبير طلبات HTTP عن "الدفع مطلوب هنا"، وكيف يعيد العميل بيانات اعتماد الدفع بعد الدفع.

يتنافس كل من x402 و MPP بشكل أساسي هنا. يحاول بروتوكول MPP إضفاء الطابع الرسمي على 402 في دلالات مصادقة HTTP أكثر رسمية؛ بينما يركز x402 بشكل أكبر على جعل 402 منصة، باستخدام رؤوس مخصصة، وميسرين، وتجريدات تسوية على السلسلة، وتكامل النظام البيئي لتشغيله أولاً.

أحدهما أشبه بمسار دلالي معياري، بينما يشبه الآخر مسار توزيع المنصة.

المستوى التالي هو سلطة الإنفاق، وهو "من سمح بدفع هذه الأموال".

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

إن قيام الآلات بدفع الأموال ليس بالأمر الصعب؛ التحدي الحقيقي هو ضمان إمكانية الوثوق بالآلات ومنحها الإذن بإنفاق الأموال.

تكتسب AP2 أهمية خاصة لأنها لا تتناول فقط "كيفية الدفع"، بل تتناول أيضاً المتطلبات، والمؤهلات القابلة للتحقق، والمصداقية، والمساءلة.

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

الطبقة التالية هي سير العمل والتوزيع.

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

يبدو أن بروتوكولي UCP و ACP يتنافسان على هذه الطبقة.

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

لأنه إذا تم تنسيق المزيد والمزيد من برامج المؤسسات، واستدعاؤها، وشرائها، ودفع ثمنها من قبل الوكلاء في المستقبل، فإن من يتقن لغة سير العمل لن يدير دفعة واحدة فحسب، بل سيدير ​​سير العمل بأكمله.

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

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

ولهذا السبب، فإن المراهنة على عدة خيارات ليست تردداً بل عقلانية.

6. قد لا يكمن الخطر الحقيقي لـ x402 في التنظيم، بل في اقتصاديات التزامن.

إذا اقتصرنا على الاعتراف بـ "تعايش بروتوكولات متعددة"، فإن ذلك لا يزال غير كافٍ.

قد لا يكون الخطر الأكبر بالنسبة لـ x402 هو التنظيم في المقام الأول، بل هو اقتصاديات وقت التحقق/وقت الاستخدام الناتجة عن عملية التحقق والتسوية المكونة من خطوتين.

ببساطة، إذا لم يكن التحقق من الدفع والتسوية النهائية هما نفس الشيء، ففي بيئات الإنترنت الحقيقية التي تتميز بالتزامن العالي، وإعادة المحاولات، وطبقات الوكيل، وطبقات التخزين المؤقت، ستكون هناك فرصة لـ "ادفع مرة واحدة، واحصل على الوصول عدة مرات".

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

لماذا يُعد هذا الأمر جديرًا بالملاحظة بشكل خاص لقراء B2B؟

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

قد يبدو تحقيق الدخل من واجهة برمجة التطبيقات (API) ظاهريًا وكأنه دفع بضعة سنتات لكل طلب، وهو مبلغ زهيد للغاية؛ ولكن بمجرد أن يبدأ منتجك في فرض رسوم على كل مكالمة أو نتيجة أو سير عمل، فإن مسألة "ادفع مرة واحدة واحصل على واحد" أو "ادفع مرة واحدة واحصل على الكثير" لن تكون مجرد تفاصيل للمنتج، بل مسألة حياة أو موت.

لذا إذا كان بإمكان x402 أن يحقق نجاحًا في مجال الأعمال بين الشركات، فإن الشرط الأساسي المهم ليس السرد ولكن أن تكون هذه الآليات الآمنة افتراضيًا سهلة الاستخدام بشكل كافٍ؛ وإلا فلن تشعر المؤسسات بالأمان عند جلب حركة مرور حقيقية.

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

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

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

لا يختلف الأمر بالنسبة لـ x402.

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

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

وهذا الأمر مهم بشكل خاص بالنسبة للشركات التي تتعامل مع بعضها البعض.

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

بمعنى آخر، ستشبه البروتوكولات بشكل متزايد اللغات الأساسية، ولكن القدرة على ترجمة هذه اللغات إلى إمكانيات "جاهزة للمؤسسات" ستصبح بسهولة أكبر منصات جديدة وأكشاك تحصيل رسوم جديدة.

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

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

تتمتع شركة Cloudflare بمكانة في مجال الحوسبة الطرفية وتوزيع حركة المرور، وتتمتع شركة Stripe بمكانة في مجال البنية التحتية للدفع وعلاقات التجار، وتتمتع شركتا Visa وMastercard بمكانة في مجال بيانات الاعتماد ورموز الشبكة وثقة المستهلك، وتتمتع Google بمكانة في مجال سير العمل وواجهات الاكتشاف.

قد لا تكمن القيمة الحقيقية في "من حدد 402"، بل في "من قام بدمج 402 في أنظمة المؤسسات الأكبر".

8. خاتمة

مؤسسة x402 لا تعلن أن x402 قد فازت بالفعل في جميع بروتوكولات التجارة الوكيلة.

إنها اعتراف علني بأن هذا الجيل من مدفوعات الوكلاء لن يكون عالماً قائماً على بروتوكول واحد منذ اليوم الأول.

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

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

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

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

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

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

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

في مقالتي الأخيرة، وضعت قابلية التشغيل البيني في المركز، وأعتقد أن إجابة السوق واضحة تمامًا الآن: نعم، بل وأسرع مما كنت أعتقد في ذلك الوقت.

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

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