L'ère du paiement par agent IA : comment x 402, AP 2 et ERC-8004 peuvent-ils construire conjointement les bases de l'économie machine ?

À mesure que les AI Agent évoluent d’outils vers des entités économiques autonomes, ils deviennent capables de prendre des décisions, d’exécuter des opérations et d’effectuer des échanges de valeur de manière indépendante. Cependant, les infrastructures de paiement traditionnelles ne répondent pas aux besoins fondamentaux des Agents, tels que les transactions autonomes, l’interaction inter-écosystèmes et l’identification vérifiable.

Ces limitations ont donné naissance à une nouvelle génération de protocoles — x 402, Agent Payments Protocol (AP 2) et ERC-8004 — qui établissent une base fiable pour l’échange de valeur dans l’économie des machines à venir. Cet article analyse en profondeur les principes techniques, les cas d’utilisation et l’état de l’écosystème de ces trois protocoles, révélant comment ils façonnent ensemble le paysage des paiements dans l’économie des AI Agent du futur.

![] ( https://img-cdn.gateio.im/social/moments-f 8 a 84661 da 3 b 3223 c 824 ab 2 c 2 cadc 3 f 7)

( x 402 : Protocole de paiement on-chain natif HTTP

x 402, lancé par Coinbase, innove en activant le code d’état HTTP 402 (“PaymentRequired”), rarement exploité sur Internet, et en intégrant la logique de paiement directement dans le flux de requête-réponse web. Cela permet de réaliser des paiements lors d’appels API, avec règlement via Stablecoin ou autres cryptomonnaies, afin de résoudre les frictions des paiements traditionnels.

) # Détails du protocole

x 402 est un protocole ouvert basé sur le code d’état HTTP 402, utilisant une architecture client/serveur. Le client est l’acheteur du service/produit, le serveur est le vendeur. Sur cette base, Coinbase propose aux vendeurs un service de Facilitators pour simplifier la vérification et le règlement des paiements entre acheteurs et vendeurs.

Prenons l’exemple du serveur Canza, classé premier sur x 402 scan, qui fournit des informations de Trader via l’IA. L’utilisateur initie une requête depuis le client pour accéder au service payant de Canza.

![] ### https://img-cdn.gateio.im/social/moments- 4 f 562918407 b 8 c 6 d 44 d 85 aaf 72 de 30 b 6###

Le serveur Canza définit ensuite l’exigence de paiement via une réponse HTTP 402 : le client doit fournir le X-PAYMENTHeader et payer en USDC sur la Base chain. Voir l’illustration ci-dessous :

![] ( https://img-cdn.gateio.im/social/moments- 72 db 5 ed 3693 dcad 8223 f 342 f 1 be 14558)

Après avoir analysé le contenu JSON de la réponse 402, le Portefeuille invite à la Signature d’un message TransferWithAuthorization (implémenté via ERC-3009). Ce message permet au signataire de déléguer à une adresse EOA tierce ou à une adresse de Futures le transfert sans frais de Gas depuis l’adresse du signataire. Dans cet exemple, nous déléguons l’Adresse de réception de Canza 0x4e9bCe2547A9491b09ed092c433B19888e665edB pour transférer des USDC depuis notre Portefeuille.

![] ( https://img-cdn.gateio.im/social/moments-ced 25702 a 668725 f 0 d 611 e 908 bfaebb 0)

L’utilisateur signe ensuite le message, le client soumet le Payload encodé en base64 dans le X-PAYMENTHeader. Le serveur Canza, après réception du Payload, le fait vérifier par les Facilitators et procède au Règlement sur la blockchain. Une fois le paiement confirmé, Canza fournit le service demandé à l’utilisateur.

Le processus du protocole x 402 peut être résumé comme suit :

![] ( https://img-cdn.gateio.im/social/moments-aa 24950 f 66 af 54874 bd 099 ad 64 a 9 dbe 8)

Il est important de noter que le protocole x 402 prend en charge plusieurs blockchains (Base, Avalanche et autres chaînes EVM, Solana) et divers Actifs cryptographiques (compatibles ERC-3009, USDC par défaut) pour le paiement, selon la configuration du serveur :

![] ( https://img-cdn.gateio.im/social/moments- 9 bef 6355 fe 7269 cc 5 ac 08 f 119377 c 363)

( Agent Payments Protocol (AP 2) : Système de paiement fiable pour l’écosystème Agent

AP 2 est un cadre de paiement ouvert basé sur le protocole de communication AgenttoAgent (A2A) et l’extension Model Context Protocol (MCP). Son objectif principal est de résoudre trois problèmes majeurs dans le commerce des Agents : vérification d’Approbation (prouver que l’Agent a reçu l’autorisation de l’utilisateur), authenticité (garantir que la transaction reflète le besoin réel de l’utilisateur) et responsabilité transactionnelle (déterminer la responsabilité en cas de litige), afin de permettre aux AI Agent de Trader en toute sécurité avec tout Marchand conforme.

Le fonctionnement du protocole AP 2 repose sur le concept central de Mandates numériques, qui sont des contrats numériques inviolables et signés cryptographiquement, servant de preuve vérifiable des instructions de l’utilisateur. Il existe trois types de Mandates :

1. Intent Mandate

Utilisé pour les transactions automatisées en l’absence de l’utilisateur. L’utilisateur fournit à l’AI Agent des instructions d’opération préalables, avec des conditions explicites, par exemple “acheter un billet de concert, budget maximum 500 euros”.

![] ) https://img-cdn.gateio.im/social/moments-a 370234 d 3 d 86 da 6913 cc 5 e 3338930569(

2. Cart Mandate

Utilisé pour les transactions confirmées en présence de l’utilisateur. Généré lorsque l’Agent prépare les produits et prix spécifiques à valider par l’utilisateur. L’approbation de l’utilisateur se traduit par la Signature du Cart Mandate, créant un enregistrement sécurisé et immuable des produits et prix exacts, garantissant que ce qui est vu est ce qui est payé.

![] ) https://img-cdn.gateio.im/social/moments- 720852 d 4 fe 6 f 0636 e 2 d 64271993973 ab (

3. Payment Mandate

Mandat indépendant partagé avec le réseau de paiement et l’émetteur, destiné à transmettre les informations sur la participation de l’AI Agent et la présence de l’utilisateur, facilitant la résolution des litiges, l’évaluation des risques et la régulation.

![] ) https://img-cdn.gateio.im/social/moments- 810 a 9480851 e 7 e 4 ef 2 a 7 ae 46 e 7 eb 4 e 24###

( ERC-8004 : Système décentralisé d’identification et de réputation des AI Agent

ERC-8004 est une solution décentralisée d’identification des AI Agent sur Éther, visant à garantir l’authenticité de l’identification des AI Agent, la fiabilité et la vérifiabilité de leurs historiques d’activité. Contrairement à AP 2, ERC-8004 se concentre sur la construction de la confiance entre AI Agent, et non sur la confiance transactionnelle entre utilisateur, AI Agent et Marchand.

La conception d’ERC-8004 repose sur trois registres légers, chacun couvrant un aspect du modèle de confiance :

1. Identity Registry (Registre d’identification)

Implémenté sur la base du standard ERC-721, avec extension de la fonctionnalité URIStorage, permettant la compatibilité de l’identification des AI Agent avec l’écosystème NFT existant.

![] ) https://img-cdn.gateio.im/social/moments- 7251 bc 0031726 b 9 d 8 d 1 acee 3 c 5257 ff 6(

Chaque AI Agent s’inscrit via la fonction register, obtenant un agentId unique (tokenId ERC-721). Lors de l’inscription, l’Affilié doit fournir un tokenURI pointant vers son Agent Registration File, au format JSON standardisé, contenant le nom, la description, l’endpoint et les modèles de confiance pris en charge.

2. Reputation Registry (Registre de réputation)

Fournit une interface standard pour Poster et obtenir des retours sur les services des AI Agent, avec un système de notation de 0 à 100, des catégories de tags et l’association de preuves de paiement. Ce registre adopte une architecture hybride on-chain/off-chain, garantissant la composabilité des données essentielles sur la blockchain tout en déléguant les calculs complexes à l’off-chain pour plus d’efficacité.

![] ) https://img-cdn.gateio.im/social/moments- 3 f 55 c 5102 f 78 dd 664 faf 90 fceff 7 f 016(

La structure du contrat du registre de réputation est étroitement liée à celle du registre d’identification — l’adresse du registre d’identification doit être fournie lors du déploiement, garantissant que seuls les AI Agent inscrits peuvent obtenir des enregistrements de réputation.

3. Validation Registry (Registre de validation)

Fournit un HOOK universel pour demander et enregistrer des résultats de validation indépendants, prenant en charge divers mécanismes de validation, dont le staking économique (les validateurs réexécutent la tâche) et les preuves cryptographiques (preuve TEE, validation zkML, etc.). Cette conception permet la coexistence de différents mécanismes de validation selon les besoins de sécurité au sein du même écosystème.

L’interface du contrat du registre de validation est relativement simple, comprenant principalement deux fonctions : ValidationRequest pour soumettre une demande de validation, et ValidationResponse pour enregistrer le résultat.

ERC-8004 est le protocole de couche d’identification de l’écosystème AI Agent. Il fournit une identification vérifiable, un système de réputation et un mécanisme d’inscription on-chain pour les AI Agent, constituant la base de la confiance dans l’économie des machines.

x 402, AP 2 et ERC-8004 forment ensemble un système de paiement complet pour les AI Agent : ERC-8004 résout la question de l’identification des AI Agent, x 402 répond à “comment effectuer des micropaiements fréquents en cryptomonnaie”, et AP 2 offre un cadre sécurisé et standardisé pour le protocole de paiement x 402, définissant les limites des comportements économiques autonomes des AI Agent. Cela leur permet de traiter l’information, de détenir et de gérer des Actifs, et de participer réellement à l’échange de valeur commercial, donnant naissance à une nouvelle forme d’économie pilotée par les machines autonomes.