هل ستستخدم وكيل الذكاء الاصطناعي بطاقة بنكية؟ لماذا لا يمكن تجنب العملات المستقرة والبلوكشين في الدفع الوكلي

المؤلف: Yokiiiya

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

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

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

في خطاب رئيس المالية في هونغ كونغ، تشن ماو بو، خلال Web3 Festival 2026، أشار إلى أن وكلاء الذكاء الاصطناعي في المستقبل سيحللون المعلومات بسرعة الآلة ويتخذون إجراءات، مع الاستفادة الكاملة من بنية blockchain التحتية في الخلفية، مما يعزز كفاءة المعاملات ويعيد تشكيل مشاهدات المالية والتجارة وإدارة الثروات وسلاسل التوريد واللوجستيات. عندما يبدأ الذكاء الاصطناعي في العمل، لم تعد المشكلة فقط في “الذكاء” نفسه، بل في كيفية تفويض هذه الأفعال، وتسويتها، وتوثيقها، وتحميل المسؤولية عنها.

واحدة من المواضيع التي تزداد أهميتها هي Agentic Payment، وهي موضوع يصعب تجاهله أكثر فأكثر. لكن في البداية، كان لدي سؤال بسيط: لماذا عندما نتحدث عن Agentic Payment أو Agentic Commerce، يبدو وكأن الجميع يفترض أنه مرتبط بشكل حتمي بـ Crypto، أو العملات المستقرة، أو Blockchain؟

هل لا يمكن لوكيل الذكاء الاصطناعي أن يستخدم بطاقة بنكية؟ أو بطاقة ائتمان؟ أو Apple Pay، أو Visa، أو Mastercard، أو Stripe، أو PayPal؟

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

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

أولاً، البطاقة البنكية تحل مشكلة التسوية، وليست حلًا لاقتصاد الوكيل

إذا كان Agentic Payment مجرد مساعدة للذكاء الاصطناعي لإنهاء خطوة الدفع الأخيرة، مثل شراء تذكرة، أو حجز فندق، أو تجديد اشتراك SaaS، فإن استدعاء البطاقات البنكية، أو الائتمانية، أو البطاقات الافتراضية، أو Apple Pay، أو Stripe، أو PayPal، لا يواجه عائقًا جوهريًا. يمكن استخدام البطاقات البنكية، والبطاقات الائتمانية، على حد سواء.

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

لذا، فإن الشركات التقليدية مثل Visa، وMastercard، وStripe لن تختفي. بل ستظل تمثل بوابات مهمة لمرحلة مبكرة من التجارة الوكيلة.

مثلاً، بروتوكول المدفوعات الآلي Machine Payments Protocol الذي أطلقته Stripe وTempo يوضح ذلك جيدًا. هو ليس مجرد دعم للعملات المستقرة، بل يتيح للتجار استلام المدفوعات مباشرة من الوكلاء، مع دعم العملات المستقرة، والبطاقات، وطرق الدفع الفورية مثل BNPL. بمعنى آخر، في المرحلة المبكرة من Agentic Payment، من المرجح أن تتعايش الطرق التقليدية والعملات المستقرة، بدلاً من أن يحل أحدهما الآخر على الفور. لكن، هذا فقط يعالج جزءًا من التجارة الوكيلة: التسوية.

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

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

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

حتى أنا، مؤخرًا، واجهت مثالاً محددًا جدًا. أردت أن أصنع مساعدًا لتحليل حركة المرور، يمكنه عند الحاجة استدعاء مصادر بيانات مثل Semrush، لمساعدتي على تحليل حركة الموقع، والكلمات المفتاحية، والمنافسين، واتجاهات السوق. لكن عند وضع خطة العمل، اكتشفت أن المشكلة ليست “هل يمكن للذكاء الاصطناعي التحليل”، بل “كيف يحصل على البيانات”. العديد من مصادر البيانات التجارية ليست مصممة على نمط “استدعاء لمرة واحدة، ودفع فوري، ورد مباشر”. على سبيل المثال، Semrush تعتمد على نظام API يعتمد على حسابات، وخطط، ووحدات API. كل طلب API يستهلك عددًا معينًا من وحدات API، ويجب أن يكون لديك وصول API أو تشتري حزمة وحدات. حتى API الاتجاهات Trends يمكن شراؤه بشكل مستقل، لكنه يعتمد على وحدات API أيضًا.

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

هذه الفجوة بين Agentic Payment ونموذج الأعمال التقليدي لـ API واضحة جدًا. اليوم، طرق الدفع لمعظم API تعتمد على “شراء برمجيات للشركات”، وليست مصممة لـ “شراء الموارد عند الطلب بواسطة الآلة”.

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

وهذا هو الحد الذي تصل إليه أنظمة البطاقات البنكية.

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

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

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

إذن، المشكلة الأساسية في Agentic Payment ليست في “من أين يُخصم المال”، بل في: ما الذي يخول الوكيل لإنفاق هذا المبلغ؟

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

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

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

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

وهذا يقودنا إلى مستوى آخر: إذا كانت المعاملة ليست مع تاجر تقليدي، بل مع API، أو نموذج، أو واجهة بيانات، أو حتى وكيل آخر، فكيف يمكن للآلات أن تبدأ وتُكمل عملية دفع واحدة؟ هذا هو السبب في أن بروتوكولات مثل x402، وL402، وT402 بدأت تُناقش.

ثانيًا، الوكيل الحقيقي يحتاج إلى بروتوكول دفع يمكن للآلة قراءته

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

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

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

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

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

x402 يعيد تفعيل رمز الحالة HTTP 402 Payment Required، الذي كان موجودًا منذ زمن، لكنه نادر الاستخدام. يسمح للطرف المقدم للخدمة أن يخبر العميل مباشرة على مستوى HTTP: أن الوصول لهذا المورد يتطلب دفعًا. يمكن أن يكون العميل إنسانًا أو آلة. بعد الدفع، يتحقق الطرف المقدم، ويعيد تقديم المورد أو الخدمة.

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

المهم هنا ليس “هل نستخدم Coinbase” أو “هل نستخدم USDC”. الأهم أن x402 يعيد دمج الدفع في دورة الطلب-الاستجابة على الإنترنت.

السابق كان:

• تسجيل حساب
• شراء خطة
• الحصول على API key
• استدعاء الخدمة
• التسوية في النهاية

أما الآن، مع x402، يمكن أن يكون:

• طلب مورد
• استلام 402 Payment Required
• إتمام الدفع
• الحصول على المورد

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

مثلاً:

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

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

L402 هو مسار آخر مشابه، يعتمد على بروتوكول HTTP 402، لكنه يدمج مع شبكة Lightning، أو رموز الوصول مثل macaroons، ويهدف إلى تسهيل التوثيق والمعاملات على واجهات API والخدمات الحاسوبية، مما يسهل على الوكلاء الذكيين المشاركة.

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

الإنسان لا يدفع بضعة سنتات لزيارة API، لكنه سيدفع الوكيل. الإنسان لا يستدعي مئات البيانات يوميًا، لكن الوكيل يفعل. الإنسان لا يدمج استدعاءات وخدمات في الوقت الحقيقي، لكن الوكيل يفعل.

وهذا هو السبب في أن ظهور الوكيل الذكي جعل مسار الدفع عبر HTTP-native ذو معنى.

حتى في بيئة USDT / Tether، بدأ يظهر اتجاه مماثل. وثائق x402 الخاصة بـ Tether WDK تؤكد أن x402 مهم جدًا للوكيلات، لأنها تتيح برمجيًا دفع الموارد، وتسمح للوكيل أن يكتشف الأسعار، ويوقع على الدفع، ويحصل على الموارد في دورة طلب-رد.

وفي الوقت نفسه، تصف Tether WDK نفسها بأنها معيار مفتوح للدفع الطبيعي على الإنترنت، يدعم العملات المشفرة، والعملات المستقرة، والرموز، ويهدف إلى التوافق مع نظام USDT.

لكن، من المهم أن نكون حذرين: لا أقول إنه أصبح معيارًا رسميًا من Tether، بل أن هناك استكشافات لبروتوكولات مماثلة حول USDT / Tether.

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

• AP2 يجيب على سؤال: ما الذي يخول الوكيل للدفع؟
• وT402، وL402، وx402 يجيبون على سؤال: عندما يطلب الوكيل موردًا رقميًا، كيف يطلق الطرف المقدم للخدمة طلب الدفع، وكيف ينفذ الوكيل الدفع ويحصل على المورد؟
• والعملات المستقرة والبلوكتشين يجيبون على سؤال: ما الأصل الذي يُستخدم لتسوية هذه الأموال، وأين يتم التحقق، وكيف يمكن أن يكون ذلك منخفض التكلفة، وواقعيًا، وقابلًا للبرمجة، وعابرًا للمنصات؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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