الدفع 3.0: سوق المدفوعات بوكيل الذكاء الاصطناعي

المؤلف: Ekko، Ryan Yoon المصدر: tiger-research الترجمة:善欧巴،金色财经

1. بدأ بناء بنية الدفع الأساسية لعصر الوكيل

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

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

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

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

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

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

2. الأعمال التجارية العامة للوكيل

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

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

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

• مستوى الاكتشاف: الوكيل يبحث عن المنتجات نيابة عن المستخدم على المنصة.

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

بعض اللاعبين الرائدين يركزون على مستوى واحد، بينما يسعى آخرون لاحتلال كلا المستويين.

شركة Alphabet Inc. (GOOG)

التقنية الأساسية

تسعى Google للسيطرة على مستويي الاكتشاف والدفع، ويعتمد ذلك على معايير UCP وAP2.

UCP (بروتوكول الأعمال العام) هو معيار يحدد كيفية تواصل الوكيل مع التجار.

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

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

أما AP2 (بروتوكول الدفع الوكيل) فهو معيار مرجعي يضمن “من منح إذن ماذا، وما هو الحد الأعلى للمبلغ المصرح به” خلال الانتقال من الاكتشاف إلى الدفع.

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

باختصار، إذا كانت UCP معيار الاكتشاف، فإن AP2 هو المعيار الذي يطبق المساءلة على المعاملات.

الأنشطة الأساسية

تتلقى Google حاليًا معظم إيراداتها من ركيزتين: الإعلانات والحوسبة السحابية. بحلول 2025، ستصل إيرادات الإعلانات إلى 262.7 مليار دولار، وإيرادات الحوسبة السحابية إلى 58 مليار دولار، مع أن كلاهما يشكل الجزء الأكبر من إجمالي الإيرادات الذي يقارب 400 مليار دولار.

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

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

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

• طرق الدفع: عملية الدفع بواسطة Agentic Checkout المبنية على AP2 تتطلب تأكيدًا واحدًا من المستخدم لإنهاء الدفع. يصبح Google Pay قناة الدفع، وتُحتسب رسوم على كل معاملة. المعاملات الوكيلة أسرع وأكثر تكرارًا من المعاملات اليدوية. تتراكم الرسوم الصغيرة لتوليد إيرادات ملحوظة.

• الحوسبة السحابية: احتمال، لكنه لم يتحول بعد إلى مصدر دخل. يحتاج التجار الذين يعالجون معاملات الوكيل إلى استدلالات الذكاء الاصطناعي، وتخزين البيانات، وتكامل API. إذا توجهت هذه الاحتياجات إلى Google Cloud، فستزداد إيرادات الحوسبة السحابية مع تطور نظام الوكيل.

الآفاق

ميزة Google تكمن في شبكتها الحالية.

قادت Google عصر الإنترنت، وبنت بنية تحتية دفع شبه كاملة، تشمل Google Pay وقاعدة تجار ضخمة. في عصر الذكاء الاصطناعي، تتصدر أيضًا منصة Gemini، مما يعكس حدة بصيرتها التكنولوجية. بالإضافة إلى ذلك، أنشأت Google قنوات تفاعل واسعة مع المستخدمين عبر Android ومتصفحات Chrome.

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

بالنسبة للتجار، فإن الانضمام إلى UCP وAP2 هو الطريق الأقل مقاومة للوصول إلى المشترين.

سبق أن فعلت Google ذلك. في 2008، أطلقت نظام Android كمصدر مفتوح. انضم المصنعون، وارتفع عدد المستخدمين، وبُنيت بنية Google التحتية، مثل متجر Play وGoogle Pay، على هذا الأساس. النتيجة: أصبحت Google أكبر مستفيد من سوق الهواتف المحمولة دون تصنيع أي هاتف بنفسها.

بمجرد أن تتشكل المعاملات الوكيلة بشكل حقيقي، من المرجح أن تتكرر تجربة Google. يتاجر المستخدمون والمشترون على بنية Google، وتحقق Google أرباحًا من كل مرحلة من المعاملات.

شركة Visa (V)

التقنية الأساسية

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

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

تشترك هذه المكونات في أن Visa لا تتدخل مباشرة في سباق البروتوكولات.

API الخاص بالوكيل هو تقنية خاصة بـ Visa، ويُفعّل عند استخدام بطاقة Visa. أما الاتصال بـ)Intelligent Commerce Connect) فهو استراتيجية تقبل بروتوكولات أخرى في آنٍ واحد.

) الأنشطة الأساسية

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

مصادر الدخل تظل كما هي.

أولاً، رسوم المعاملات. سواء ضغط المستخدم مباشرة على زر الدفع أو قام الوكيل بذلك، فإن الأمر واحد بالنسبة لـ Visa. طالما أن الدفع يتم عبر شبكة Visa، ستُفرض رسوم على البطاقة. هذا هو السبب وراء تصميم Visa لاتصال الحلول الذكية )Intelligent Commerce Connect###، الذي يدعم بروتوكولات دفع أخرى.

بغض النظر عن البروتوكول المستخدم، طالما أن الدفع يتم باستخدام بطاقة Visa، ستُفرض رسوم.

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

في النهاية، لا تسعى Visa للفوز في سباق البروتوكولات، وإنما تفرض رسومًا على جميع المشاركين (سواء فازوا أم خسروا). من جانب المشتري، تربط Visa تعاونها مع منصات الذكاء الاصطناعي مثل OpenAI وAnthropic وPerplexity. ومن جانب البائعين، تتعاون مع منصات التجارة الإلكترونية مثل Shopify ومزودي خدمات الدفع مثل Stripe (PSP). بغض النظر عن اتجاه تطور المعاملات الوكيلية، ستظل Visa في كلا الطرفين.

الآفاق

يمكن تلخيص رؤية Visa في جملة واحدة: بدلاً من التنافس مع بروتوكولاتها الخاصة، تفضل أن تكون بنية دفع شاملة تدعم جميع البروتوكولات.

هذا الاختيار مهم جدًا، لأن موقف Visa يختلف تمامًا عن باقي المشاركين. فـ Google وOpenAI وCoinbase يشاركون في معركة للفوز ببروتوكولات خاصة بهم. يجب أن تصبح معايير AP2 وACP أو x402 قياسية في أنظمتها البيئية لتحقيق أقصى استفادة. هذه المعركة على البروتوكولات تكاد تكون لعبة ذات نتائج صفرية.

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

هذه الاستراتيجية ليست “تسوية”، بل هي الموقف الأكثر فائدة لـ Visa. فـ Visa، التي تملك 4.8 مليار بطاقة مصرفية و150 مليون تاجر، قادرة على اتخاذ هذا الموقف.

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

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

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

شركة ماستركارد (MA)

( التقنية الأساسية

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

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

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

التحدي الحقيقي لـ Mastercard هو جعل مدفوعات الوكيل تتم بشكل تلقائي دون تدخل من التاجر. عادة، عند اعتماد طريقة دفع جديدة، يتعين على التاجر إدراج رمز برمجي على موقعه. Mastercard ألغت هذا العبء.

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

بالنسبة للتجار الذين يسعون للتكامل العميق، توجد مسارات مستقلة. يمكن للتجار الذين يرغبون في ربط أنظمتهم مباشرة بالوكلاء عبر بروتوكولات MCP وA2A وACP. في النهاية، يواجه التاجر خيارين: إما عدم القيام بأي شيء، وقبول المرور الافتراضي؛ أو ربط البروتوكول، وبناء تجربة مخصصة. وأيًا كان الاختيار، يجب أن يتم عبر Mastercard.

) الأنشطة الأساسية

هيكل إيرادات Mastercard بسيط. كل معاملة تتم عبر شبكة Mastercard تولد رسومًا. بحلول السنة المالية 2025، من المتوقع أن تصل الإيرادات إلى حوالي 32.8 مليار دولار، مع حجم معاملات يبلغ 175.5 تريليون معاملة. سواء كانت المعاملة من قبل الوكيل أو شخصي، طالما أن المعاملة تتم عبر شبكة Mastercard، ستُفرض رسوم متساوية.

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

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

التجار يمكنهم قبول الدفع الوكيل دون إجراءات إضافية. كلما زاد عدد التجار المتصلين، زادت المعاملات التي تتم عبر Mastercard.

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

بالنسبة لـ Mastercard، فإن زيادة حجم معاملات الوكيل هو امتداد طبيعي لرسوم المعاملات. هذا ليس توسعًا جديدًا، بل استمرارية للبنية الحالية في عصر الوكيل.

( الآفاق

يمكن تلخيص رؤية Mastercard في جملة واحدة: أنها، مثل Visa، لا تختار الفائز في معركة البروتوكولات، وإنما تركز على أن تكون البنية الأساسية لقبول الوكيلين.

الاستراتيجية الأساسية هي أن يتمكن التجار من قبول المدفوعات الوكيلية دون كتابة أي رمز برمجي. من خلال التعاون مع Cloudflare، أزالت Mastercard عائق الدخول أمام التجار بشكل فعال.

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

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

شركة Stripe

) التقنية الأساسية

Stripe هي الشركة الوحيدة التي دمجت معاييرها الخاصة في كل من نموذج الدفع الوكيل ونموذج الدفع مقابل كل مكالمة. البروتوكولان اللذان ناقشناهما سابقًا، ACP وSPT، مبنيان على بطاقات الائتمان، حيث يفوّض المستخدم الوكيل للشراء؛ أما MPP (بروتوكول الدفع الآلي) فهو بروتوكول مستقل مخصص لنموذج الدفع مقابل كل مكالمة، حيث يمكن للوكيل الدفع بشكل مستقل لوكلاء آخرين مقابل API أو بيانات أو موارد حسابية.

تم إصداره في 18 مارس 2026، كمعيار مفتوح، بالتزامن مع إطلاق شبكة Tempo التي طورتها Stripe وParadigm.

مثل x402، MPP هو بروتوكول دفع مفتوح مبني على نمط HTTP 402. الاختلافات الرئيسية بينهما:

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

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

هذه الاختلافات تظهر بوضوح في تصور العمليات. الدفع لمرة واحدة (Charge) يشبه x402، حيث يتم عبر معاملة واحدة على السلسلة. أما الدفع المستمر (Session)، فيتم عبر معاملة واحدة عند الشحن النهائي، مع نداءات متعددة داخل الجلسة، حيث يتم تبادل الاعتمادات خارج السلسلة.

هذا الاختلاف يجعل هدف قدرة المعالجة (تجاوز 1 مليون معاملة في الثانية) ممكنًا.

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

الأنشطة الأساسية

يقسم Stripe سوق المدفوعات الوكيلية إلى مستويين. المستوى الأول هو التوصية بالمنتجات من قبل الشركات، وهو مغطى بالفعل بواسطة بروتوكولي ACP وSPT. المستوى التالي هو الدفع الذاتي من قبل الوكيل لاستخدام API أو بيانات أو موارد حسابية أخرى من قبل وكلاء آخرين. وهو مشابه لنموذج الدفع مقابل كل مكالمة، لكنه مصمم بشكل مختلف.

x402 يدعم فقط العملات المستقرة، بينما يدعم MPP الدفع عبر البطاقات، العملات المستقرة، وشبكة Lightning الخاصة بالبيتكوين، مما يخلق تنوعًا في طرق الدفع. كشفت قائمة الشركاء في تصميم MPP الأولي عن خصائص السوق. انضمت شركات مثل Anthropic، OpenAI، Deutsche Bank، وVisa. يتم تنفيذ توسعات بروتوكول MPP بواسطة Visa (بطاقات)، Stripe (بطاقات ومحافظ)، وLightspark (Lightning).

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

في هذا الهيكل، لدى Stripe مصدران للدخل:

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

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

في النهاية، يعيد Stripe تصميم نظام الدفع مقابل كل مكالمة ليشبه نموذج Agentic Commerce. بروتوكول ACP وSPT مبنيان على مسار الدفع بالبطاقات؛ وMPP وTempo مبنيان على مسار العملات المستقرة. جميعها تعتمد على بروتوكول مفتوح، والبنية التحتية مغلقة. في النهاية، تمر جميع المدفوعات عبر Stripe.

الآفاق

رؤية Stripe لـ MPP يمكن تلخيصها في جملة واحدة: أن هذا البروتوكول هو الذي غير مسار استراتيجية Visa.

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

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

سوق الدفع الوكيل يتفكك. المعاملات البشرية المنظمة تخضع لبطاقات الائتمان؛ والمعاملات بين الوكلاء (نداءات API، عمليات حسابية، مدفوعات صغيرة) تتم عبر العملات المستقرة. رغم أن x402 أصبح المعيار الأصلي للعملات المشفرة للثاني، فإن MPP يلعب دور الجسر، يدمج بين مساري الدفع في بروتوكول واحد. أنشأت Stripe بنية لإدارة هذا الجسر.

لكن هناك متغيران:

أولاً، هناك تنافس بين معيار Coinbase x402 وx402 نفسه. معيار Coinbase قد جمع أكثر من 100 مليون معاملة، وضمن حياد الحوكمة عبر نقله إلى Linux Foundation. انضمت Stripe أيضًا إلى مؤسسة x402 كشريك، وهو استراتيجية مزدوجة، لكن من غير الواضح ما إذا كان يمكن أن يتعايشا أو يندمجا على المدى الطويل.

ثانيًا، مدى انتشار Tempo؟ مرجعية التسوية لـ MPP هي Tempo، لكن مدى جذب Tempo لحجم معاملات الوكيل لا يزال غير مؤكد. الثقة من مؤسسات مثل Visa وStandard Chartered مهمة، لكن هل سيختار المطورون ومزودو الخدمات Tempo فعلاً، هو سؤال آخر.

شركة Circle Internet Group, Inc. ###CRCL###

التقنية الأساسية

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

في سبتمبر 2025، أطلقت Circle أدوات للمطورين لإنشاء محافظ تحكم ودمج x402. في أكتوبر 2025، أطلقت شبكة اختبار Arc، ثم في مارس 2026، أطلقت شبكة اختبار Nanopayments. تتكون تقنية Circle من ثلاثة مكونات رئيسية:

[مخطط تقني يوضح مكونات النظام]

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

Arc هو خدمة دفع من الطبقة الأولى مصممة خصيصًا للتمويل المستقر. أهم ميزاته هو استخدام USDC كغاز أصلي. تشمل الوظائف الأساسية تأكيدات زمنية شبه فورية تعتمد على محرك توافق Malachite، ومحرك صرف العملات المدمج، وميزات خصوصية اختيارية، وتوافق مع EVM.

تمكن أدوات إنشاء المحافظ للمطورين من إنشاء وإدارة محافظ الوكيل عبر API واحد. كنظام يعتمد على الحوسبة متعددة الأطراف (MPC)، لا يحتاج إلى كشف المفاتيح الخاصة، ويمكنه العمل عبر عدة سلاسل (بما في ذلك Base، إيثيريوم، وArc)، مع اعتبار USDC كرصيد موحد.

عند تجميع هذه التقنيات، يمكن للوكلاء أن يحصلوا على تجربة دفع كاملة ضمن تقنية Circle: إصدار USDC (USDC) → مسار الدفع ###Nanopayments### → سلسلة التسوية (Arc) → إدارة المحافظ (Wallets).

مثال: روبوت Circle المستقل يدفع USDC لنفسه لشحن بطاريته، وهو أول حالة إثبات أن هذه التقنية فعالة.

هيكل إيرادات Circle بسيط. في 2025، تصل الإيرادات الإجمالية واحتياطياتها إلى 2.7 مليار دولار، وأكثر من 95% منها تأتي من فوائد احتياطيات USDC (دخل الاحتياطيات). طالما أن USDC يُستخدم، تتراكم فوائد الاحتياطيات في حسابات Circle. من الجدير بالذكر أن Circle وقعت اتفاقيات مع شركاء توزيع رئيسيين، مثل Coinbase، يشاركون جزءًا من فوائد الاحتياطيات. ومع ذلك، بشكل عام، طالما أن USDC يُستخدم كوسيلة دفع، فإن إيرادات Circle ستستمر في النمو.

على الرغم من أن Stripe أنشأت شبكة Tempo، إلا أنها لا تصدر عملة مستقرة على تلك الشبكة. الأمر نفسه ينطبق على Coinbase. بغض النظر عن الفائز النهائي في المنافسة على الشبكة، فإن نمو المدفوعات بالعملات المستقرة سيزيد من احتياطيات Circle.

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

بالإضافة إلى ذلك، فتحت Circle مصدر دخل ثانٍ عبر Arc. بعد انتقالها إلى الشبكة الرئيسية، ستنتج كل معاملة على السلسلة رسوم غاز، وهذه الرسوم تُدفع USDC. مع تزايد الطلب على USDC، يتم إصدار USDC جديد بنسبة متناسبة، وتزداد الاحتياطيات، مما يعزز فوائد الاحتياطيات. تعتمد بنية Tempo على اعتبار USDC كأصل خارجي، بينما تعتمد بنية Arc على أصولها الخاصة كغاز، وتحول أنشطة السلسلة إلى طلب على USDC.

في النهاية، تختلف آلية عمل Circle تمامًا عن المنافسين. Stripe وCoinbase يسعيان للحصول على المدفوعات الوكيلية عبر بروتوكولات وطبقات، بينما Circle تمتلك الأصول التي تستخدم في تلك المدفوعات.

( الآفاق

رؤية Circle يمكن تلخيصها في جملة واحدة: اللاعب الشامل الوحيد الذي يمتلك حق إصدار الأصول.

الفرق الأبرز بين Circle والمنافسين (Tempo، Base) هو احتكارها لإصدار USDC. على الرغم من أن Stripe أنشأت شبكة Tempo، إلا أنها لا تصدر عملة مستقرة على تلك الشبكة. USDC على شبكة Tempo يُصدر بواسطة Circle. كذلك، Coinbase تواجه وضعًا مشابهًا مع شبكة Base.

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

هذه الميزة تتضمن عاملين:

أولاً، حصة USDC في السوق. سوق العملات المستقرة يهيمن عليه USDT وUSDC. شركات مثل Tether، PayPal، والبنوك تصدر عملات مستقرة أيضًا. هل ستصبح USDC الخيار الافتراضي في الدفع الوكيل، أم ستقاسم السوق عملات مستقرة أخرى؟ هذا هو المتغير الأول.

ثانيًا، مدى سرعة انتشار Arc. دخول Arc إلى طبقة السلسلة هو خطوة مهمة. لكن سوق العملات المستقرة على السلسلة مكتظ جدًا حاليًا. حصلت شبكة Tempo على ثقة من مؤسسات مثل Visa وStandard Chartered، وتتصدر شبكة Base من حيث حجم المعاملات. السؤال هو: كم USDC (الأصل الفريد لـ Circle) يمكن أن يُدخل إلى نظام Arc؟ فقط عندما يزداد استخدام USDC على Arc، يمكن أن يحقق هذا التكامل الرأسي فعاليته.

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

مؤسسة Ethereum (ETH)

) التقنية الأساسية

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

في 13 أغسطس 2025، قدمت Ethereum رسمياً ERC-8004 (الوكيل غير الموثوق به)، وفي 29 يناير 2026، تم نشره على الشبكة الرئيسية.

يهدف ERC-8004 إلى أن يكون توسعة للثقة في البروتوكول. يوضح قائمة المؤلفين أن المعيار يجمع خبرات من MetaMask، Ethereum Foundation، Google، وCoinbase، مما يربط بنية الذكاء الاصطناعي، وتبادلات العملات، والمحافظ، وEthereum Foundation.

يتكون ERC-8004 من ثلاثة سجلات على السلسلة.

[مخطط يوضح مكونات السجلات]

عند دمج هذه السجلات، تتراكم معلومات هوية الوكيل، وتاريخ المعاملات، ونتائج التحقق على السلسلة. سابقًا، لم يكن من الممكن نقل سمعة الوكيل من منصة إلى أخرى. الآن، وفقًا لبروتوكول ERC-8004، تصبح السمعة أصلًا قابلًا للنقل.

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

الأهم أن الدفع ليس جزءًا من ERC-8004. طبقات الدفع مثل x402 أو تحويلات ERC-20 تُضاف بشكل منفصل، وتُرفق شهادات الدفع كردود على سجل السمعة. لم تبنِ Ethereum بروتوكول دفع، وإنما وفرت طبقة ثقة وسمعة عامة فوق الدفع.

عملية المعاملة الوكيلية وفقًا لـ ERC-8004 كالتالي:

1. يسجل مطور الوكيل نفسه في مركز الهوية، ويصدر NFT من نوع ERC-721 يشير إلى ملف التسجيل (بطاقة الوكيل)، الذي يتضمن وظائف الوكيل، ونقاط النهاية، وعنوان الدفع.

2. يبحث المستخدم أو الوكيل الآخر عن الوكيل في السجل. يمكن البحث من أي سلسلة EVM.

3. بعد إتمام المهمة، يتم تسجيل نتائج التحقق في سجل السمعة. يتم التحقق من مصدر الرد عبر توقيعات EIP-191 أو ERC-1271.

4. للمهمات عالية المخاطر، يتحقق مدقق مستقل في سجل التحقق من النتائج عبر إعادة التنفيذ، أو إثبات zkML، أو TEE، ويُسجل على السلسلة.

5. في حالة النزاع، لا يمكن حذف مؤشرات الارتباط أو التجزئة على السلسلة، مما يضمن تكامل التدقيق.

( الأنشطة الأساسية

ERC-8004 ليس هيكل دخل لشركة معينة، وإنما معيار مفتوح يشارك فيه جميع منظومة Ethereum. كلما زاد انتشار المعيار، زادت فائدة النظام البيئي لـ Ethereum. يختلف جوهر بنية Ethereum عن معايير الدفع الأخرى.

عندما تتم المعاملات عبر شبكات الدفع، تتقاضى Visa و Mastercard رسومًا. أما Stripe وCoinbase، فتربح من البنية التحتية عبر بروتوكول مفتوح.

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

الميزة التي تحصل عليها منظومة Ethereum من هذا الهيكل هي أن البيانات الوصفية التي تتراكم عند تسجيل الوكيل وسمعته على سجل الثقة، تكون عالية التوافق مع بيئة EVM. وأكد المشاركون الرئيسيون أن “سير العمل الوكيل سيكون في Ethereum وLinea L2”.

تم تصميم المعيار أصلاً للعمل على شبكات EVM، وهو الأكثر توافقًا معها. على الرغم من أن دعم غير EVM يتوسع (مثل MetaMask الذي يدعم عدة سلاسل)، فإن البيئة الافتراضية المعيارية تظل غالبًا بيئة EVM.

كلما زاد انتشار المعيار، زادت قوة مكانة نظام EVM. الهدف النهائي لمنظومة Ethereum وMetaMask عبر ERC-8004 هو أن يكونا البنية الأساسية التي تعتمد عليها جميع عمليات الدفع، بحيث تصبح معيارًا عالميًا، وتصبح منظومة Ethereum أكثر قوة.

) الآفاق

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

هذه الاختيار واضح. لم تشارك Ethereum في معركة بروتوكولات الدفع. فـ x402، MPP، والتفويض هي نماذج تركز على سلوك الدفع نفسه. أما Ethereum، فتركز على توحيد من هو المرسل، وما هو نتيجة المعاملة.

في سوق المعاملات بين الوكلاء مقابل الدفع مقابل كل مكالمة، ستُسجل أدلة المعاملات على ERC-8004، بغض النظر عن البروتوكول النهائي. مع انتشار المعيار، ستستفيد منظومة Ethereum، سواء فاز بروتوكول الدفع أم لا.

لكن هناك متغيران:

أولاً، محدودية التوافق مع بيئة EVM. ERC-8004 مبني على شبكات EVM. يمكن استخدامه مباشرة على شبكات مثل Base، Arc، Tempo، Linea، وBNB Chain. أما شبكات غير EVM مثل Solana وBitcoin Lightning، فهي بحاجة إلى موائمات خاصة. إذا أنشأت شبكات غير EVM معايير هوية وسمعة خاصة بها، فسيحدث انقسام في سوق الوكيل إلى قسم