Qu’est-ce que x402B ? Comment le séquestre on-chain protège les paiements des agents IA

x402 relie les requêtes réseau aux paiements via les réponses HTTP 402 Payment Required, permettant aux AI Agents d’effectuer des transactions conformément aux conditions de paiement fournies par le serveur.

x402B s’appuie sur cette base en introduisant des contrats d’entiercement, le suivi de la livraison et des mécanismes de résolution des litiges. L’autorisation du paiement, le blocage des fonds, la livraison du produit ou du service et le règlement final peuvent ainsi être gérés comme des étapes distinctes. Boson Protocol a déployé x402B sur le réseau principal de Base le 8 juin 2026. Toutefois, son champ d’application, sa compatibilité et son niveau réel de protection doivent encore être évalués en fonction de chaque implémentation.

Points clés

• x402B est une extension d’entiercement on-chain développée par Boson Protocol pour le protocole de paiement x402. Elle utilise des smart contracts pour gérer les fonds de la transaction, permettant d’effectuer le paiement et la libération finale des fonds par étapes.

• x402 traite principalement les paiements automatisés, tandis que x402B traite également les risques liés à la livraison après paiement. Lorsqu’un service acheté par un AI Agent ne peut pas être livré immédiatement, le mécanisme d’entiercement peut fournir une protection supplémentaire.

• L’entiercement non conservateur constitue le mécanisme central de x402B. Les fonds de l’acheteur sont versés dans un contrat d’entiercement on-chain au lieu d’être transférés intégralement sur le compte du vendeur immédiatement après l’autorisation du paiement.

• La confirmation de la livraison et la résolution des litiges déterminent la libération des fonds. Selon les règles de la transaction concernée, les fonds peuvent être distribués après la confirmation de la livraison, à l’issue de la période de litige ou après une décision relative au litige.

• x402B fournit une nouvelle infrastructure transactionnelle pour le commerce entre Agents. Il convient aux scénarios commerciaux impliquant des AI Agents qui nécessitent une livraison asynchrone, une protection des transactions et un règlement automatisé, mais ne peut pas éliminer tous les risques liés à l’exécution.

Qu’est-ce que x402B ? Quel est son lien avec le protocole de paiement x402 ?

x402B peut être considéré comme une implémentation qui ajoute une protection on-chain des transactions au processus de paiement x402. L’idée centrale de x402 consiste à intégrer les exigences de paiement au processus de requête et de réponse HTTP. Lorsqu’un client demande une ressource payante, le serveur peut renvoyer un code d’état HTTP 402 et fournir les modes de paiement acceptés. Une fois l’autorisation requise effectuée, le client envoie à nouveau la requête. Le serveur vérifie ensuite les conditions de paiement et décide s’il doit fournir la ressource. Ce modèle réduit la dépendance des services automatisés à l’égard de l’inscription à un compte, de la gestion des abonnements et des processus de paiement manuels traditionnels.

Pour les appels d’API avec livraison immédiate, ce modèle de paiement est généralement simple. Par exemple, un AI Agent peut demander un service d’inférence de modèle, effectuer le paiement correspondant au prix indiqué par l’API et recevoir le résultat correspondant. Toutefois, lorsqu’une transaction porte sur un contenu personnalisé, des tâches de calcul de longue durée, des licences numériques ou des biens dont la livraison nécessite un délai, un écart temporel peut exister entre le paiement et l’exécution effective. Dans le cadre d’un paiement direct, une fois les fonds définitivement réglés, l’acheteur ne peut généralement pas exiger du vendeur qu’il les restitue en se fondant uniquement sur le protocole de paiement initial.

x402B répond à ce problème en introduisant une solution de paiement par entiercement. Le vendeur peut fournir les conditions de la transaction sous entiercement dans la réponse HTTP 402. Après la signature de l’autorisation correspondante par l’acheteur, les fonds sont bloqués dans un smart contract et le mode de libération est déterminé ultérieurement en fonction de l’état de la livraison et du litige. x402B ne remplace pas l’ensemble du protocole x402 par un nouveau réseau de paiement. Il s’appuie plutôt sur la prise en charge de différents modes de paiement par x402 afin d’étendre ses capacités de règlement des transactions.

Pourquoi les paiements automatisés des AI Agents nécessitent-ils un entiercement on-chain ?

Les AI Agents peuvent appeler des services de manière autonome, comparer des devis et envoyer des demandes de paiement conformément à des tâches prédéfinies. Toutefois, effectuer automatiquement un paiement ne signifie pas qu’un AI Agent peut déterminer automatiquement si la transaction a été exécutée. Pour une requête d’API qui renvoie immédiatement un résultat, l’écart entre le paiement et la livraison du service peut être très court. Pour un rapport de recherche dont la génération prend plusieurs minutes, une tâche de calcul qui dure plusieurs heures, voire l’achat transfrontalier d’un produit, le délai entre le paiement et la livraison peut être beaucoup plus long.

Cet écart temporel crée un risque de contrepartie. Par exemple, un AI Agent peut payer 100 USDC à un prestataire de services inconnu pour obtenir un rapport de données personnalisé. Si les fonds sont directement réglés sur l’adresse du vendeur et que celui-ci ne fournit finalement pas le contenu, l’acheteur doit s’appuyer sur une procédure de remboursement supplémentaire, les règles de la plateforme ou des recours juridiques pour résoudre le problème. Pour les prestataires de services automatisés ne disposant pas d’un historique établi, les mécanismes traditionnels de réputation peuvent ne pas couvrir tous les risques.

L’entiercement on-chain réduit certains risques en modifiant l’ordre dans lequel les fonds sont libérés. L’acheteur peut d’abord bloquer les fonds dans un smart contract. Le vendeur fournit ensuite le produit ou le service convenu, après quoi les fonds sont distribués en fonction de la confirmation de la livraison, de la période de litige ou d’autres conditions de règlement. Ainsi, l’autorisation du paiement n’entraîne plus nécessairement la réception immédiate de l’intégralité des fonds par le vendeur. Toutefois, l’entiercement ne signifie pas qu’une transaction aboutira toujours et ne permet pas non plus de vérifier automatiquement la qualité d’un produit off-chain. Le niveau réel de protection dépend toujours des mécanismes de vérification de la livraison et de résolution des litiges.

Comment fonctionne le processus de transaction de x402B ?

x402B associe les interactions de paiement HTTP à l’état de l’entiercement on-chain, permettant aux AI Agents d’effectuer plusieurs étapes, de l’achat au règlement, au moyen de requêtes standardisées. Un processus type comprend la demande d’une ressource, l’obtention d’un devis, la signature d’une autorisation, le blocage des fonds, la réalisation de la livraison et le règlement final.

L’AI Agent de l’acheteur demande une ressource au serveur. Le vendeur génère un devis en fonction de la demande et fournit les conditions de paiement sous entiercement dans la réponse HTTP 402. Ces conditions peuvent inclure le prix, les tokens pris en charge, l’adresse du contrat d’entiercement et l’engagement transactionnel signé par le vendeur. Après avoir vérifié ces conditions, l’acheteur signe une autorisation de méta-transaction, puis soumet la transaction à la blockchain par l’intermédiaire d’un Facilitator ou d’une autre méthode prise en charge. Le smart contract bloque les fonds et enregistre l’état de transaction correspondant.

Une fois les fonds bloqués, le vendeur peut fournir la ressource ou la preuve de livraison. Les actions suivantes sont déterminées par l’état de la transaction et les actions exécutables. La conception de x402B utilise nextActions pour décrire les étapes qui peuvent être effectuées à ce moment-là, comme confirmer la livraison, ouvrir un litige ou procéder au règlement. Selon l’implémentation concernée, les fonds peuvent être libérés après la confirmation de la livraison, à l’issue de la période de litige ou après la résolution du litige. Ce mécanisme transforme un processus de paiement unique en un cycle de vie de transaction traçable.

Comment l’entiercement non conservateur de x402B protège-t-il les fonds d’une transaction ?

L’entiercement est un mécanisme qui conserve temporairement les fonds jusqu’à ce que les conditions de la transaction soient remplies. Dans les activités commerciales traditionnelles, l’entiercement est généralement fourni par une banque, un établissement de paiement ou une plateforme tierce. Dans x402B, les fonds sont gérés par un smart contract conformément à des règles prédéfinies. Après l’autorisation effectuée par l’acheteur, les stablecoins sont bloqués dans un contrat d’entiercement on-chain. Le vendeur ne peut pas obtenir immédiatement les fonds simplement parce qu’une demande de paiement a été reçue.

x402B utilise l’infrastructure d’entiercement de Boson Protocol pour gérer les engagements transactionnels et l’état du règlement. L’acheteur et le vendeur effectuent les opérations prévues, puis le smart contract distribue les fonds en fonction de la confirmation de la livraison, de l’état du litige et des délais applicables. La principale valeur de ce mécanisme est de réduire la dépendance à l’égard d’une plateforme de paiement ou d’une contrepartie unique pour conserver les fonds, tout en permettant de vérifier on-chain les enregistrements de la transaction et les conditions de libération des fonds.

Toutefois, non conservateur ne signifie pas sans risque. Les vulnérabilités des smart contracts, les paramètres de transaction incorrects, les périodes de litige déraisonnables et les preuves de livraison insuffisantes peuvent tous affecter le résultat final. En particulier, la qualité réelle des biens et services off-chain ne peut pas être déterminée automatiquement à partir du seul état de la blockchain. x402B fournit donc un mécanisme programmable de protection des transactions, et non une garantie inconditionnelle de tous les résultats transactionnels.

Comment x402B confirme-t-il la livraison d’un produit et gère-t-il les litiges transactionnels ?

Dans les transactions automatisées impliquant des AI Agents, le paiement et la livraison peuvent intervenir à des moments différents. Pour répondre à cette situation, x402B intègre l’état de la livraison au cycle de vie de la transaction. Par exemple, après l’achat d’un service numérique par un acheteur, le vendeur peut fournir le contenu ou la preuve de livraison par un canal désigné, puis l’acheteur effectue la confirmation requise par le protocole. Pour certains produits ou services, la livraison peut également impliquer un justificatif de retrait, une mise à jour du statut de la commande ou d’autres étapes de vérification.

Si l’acheteur estime que le vendeur n’a pas exécuté la transaction, il peut ouvrir un litige dans le délai prévu par les règles. La conception de Boson Protocol prend en charge la participation d’un Dispute Resolver. Le mécanisme concerné peut inclure une négociation entre les parties, un arbitrage par un tiers ou un règlement selon des règles de délai prédéfinies. La répartition finale des fonds dépend de l’état de la transaction, des signatures concernées et des conditions applicables au traitement du litige. Elle n’est pas déterminée unilatéralement par l’acheteur ou le vendeur.

Il est important de noter que la résolution des litiges ne signifie pas qu’un smart contract entièrement automatisé déterminera la qualité de chaque produit. Pour les livraisons off-chain, des éléments de preuve externes, un arbitrage manuel ou des mécanismes de vérification de confiance peuvent encore être nécessaires. L’avantage de x402B est de pouvoir relier l’issue du litige à l’exécution du mouvement des fonds on-chain. Toutefois, déterminer si une transaction a réellement été exécutée peut encore dépendre d’informations off-chain.

Quelles sont les principales différences entre x402 et x402B ?

La principale différence entre x402 et x402B réside dans leur approche du règlement des fonds et de la gestion du cycle de vie des transactions. Le mode de paiement exact de x402 convient davantage aux scénarios dans lesquels les ressources sont fournies immédiatement après le paiement, tandis que le mode escrow de x402B convient aux scénarios dans lesquels un délai sépare le paiement et la livraison et où une protection supplémentaire de la transaction est nécessaire.

Cette comparaison ne signifie pas que x402 ne peut être utilisé que pour des transactions simples, ni que tous les services utilisant x402 ne disposent d’aucun mécanisme de remboursement ou de gestion des litiges. Les développeurs peuvent mettre en place une protection des transactions au moyen d’autres mécanismes au niveau de l’application. La différence avec x402B est qu’il transforme le paiement sous entiercement en mode de paiement intégrable et relie directement les règles concernées à l’état on-chain des fonds.

En outre, x402B n’exige pas que tous les clients x402 existants prennent automatiquement en charge les transactions sous entiercement. Seuls les clients capables de traiter le mode de paiement correspondant peuvent identifier et exécuter correctement le processus d’entiercement. Les serveurs peuvent proposer à la fois une option de paiement direct et une option de paiement sous entiercement, afin que les différents clients puissent choisir en fonction de leurs capacités.

Comment x402B fonctionne-t-il avec EIP-712, les stablecoins et les Facilitators ?

x402B ne repose pas sur un seul smart contract pour réaliser l’ensemble de la transaction. Il combine plutôt des signatures off-chain, des autorisations en stablecoins, des contrats on-chain et des composants de relais de transactions. EIP-712 fournit une méthode de signature de données structurées, permettant aux acheteurs et aux vendeurs de signer des devis, des autorisations de transaction et d’autres paramètres. Par rapport à la signature directe de données opaques, la signature structurée permet aux wallets compatibles d’afficher plus clairement certains détails de la transaction. Les utilisateurs doivent toutefois toujours vérifier l’étendue réelle de l’autorisation.

Pour les actifs de paiement, x402B peut utiliser des stablecoins pris en charge, tels que l’USDC, afin de bloquer les fonds. Sa solution technique comprend différentes méthodes, notamment EIP-3009, EIP-2612, Permit2 et les autorisations standard de tokens. La méthode utilisée dépend de l’actif, du réseau et des conditions d’intégration. Les stablecoins servent d’unité de compte et de moyen de règlement, tandis que le contrat d’entiercement gère les conditions de libération des fonds. Ces composants répondent à des problématiques différentes.

Le Facilitator facilite principalement la soumission et l’exécution des transactions. L’acheteur peut d’abord effectuer la signature, après quoi le Facilitator soumet la transaction correspondante à la blockchain. Dans certaines implémentations, cela permet à l’acheteur de ne pas avoir à payer directement les frais de gas. Toutefois, Gasless ne signifie pas que les transactions on-chain n’ont aucun coût. Cela signifie qu’un autre participant prend ce coût en charge. x402B fournit également une voie d’opération directe on-chain afin de réduire l’impact d’une éventuelle indisponibilité d’un Facilitator sur la poursuite de l’exécution des transactions.

Quels scénarios commerciaux impliquant des AI Agents x402B peut-il prendre en charge ?

Achat de contenus numériques et de services professionnels

Un AI Agent peut avoir besoin d’acheter des rapports sectoriels, des données personnalisées, des licences logicielles ou des services de recherche fournis par des tiers. Ces produits ne peuvent généralement pas être livrés immédiatement comme une simple réponse d’API, et certains services doivent également générer du contenu en fonction des exigences de l’utilisateur. Avec x402B, l’acheteur peut bloquer les fonds au moment du paiement, puis le vendeur peut procéder au règlement après avoir livré le produit ou le service convenu.

Commerce entre Agents

Le commerce entre Agents désigne les transactions commerciales automatisées entre AI Agents. Par exemple, un Agent chargé d’études de marché peut acheter des services de calcul auprès d’un Agent d’analyse de données, qui fait ensuite appel à d’autres modèles ou sources de données pour accomplir la tâche. Plusieurs prestataires de services indépendants peuvent ne pas avoir de relation établie à long terme. Des engagements transactionnels standardisés, des fonds placés sous entiercement et des mécanismes de résolution des litiges peuvent donc réduire certains risques de contrepartie.

Commerce électronique automatisé et achat de biens physiques

Un AI Agent peut rechercher des produits, comparer des devis, passer des commandes et autoriser des paiements, tandis que la livraison dépend encore des commerçants, des prestataires logistiques et d’autres processus du monde réel. Boson Protocol a présenté un parcours d’achat combinant une boutique Facet, de l’USDC et l’entiercement x402B. Ces cas montrent que les paiements automatisés peuvent être associés à des transactions portant sur des produits réels. Toutefois, une démonstration dans un environnement de test ne constitue pas une adoption commerciale à grande échelle.

Quelles sont les principales limites techniques et commerciales de x402B ?

Tout d’abord, x402B doit répondre à la question de la vérification de la livraison. Pour les données renvoyées par une API, il peut être relativement facile de déterminer si le serveur a répondu correctement. En revanche, pour une étude personnalisée, un travail de conception ou des biens physiques, déterminer si la livraison respecte les conditions convenues implique souvent des critères subjectifs. Même lorsque l’entiercement et le règlement s’effectuent entièrement on-chain, le protocole ne peut pas déterminer si un produit présente des problèmes de qualité à partir des seuls enregistrements de transfert.

La deuxième limite concerne les capitaux bloqués et les coûts de transaction. Le mécanisme d’entiercement améliore la protection des transactions, mais peut également prolonger le délai nécessaire à la libération des fonds. Pour les requêtes d’API de faible montant et à haute fréquence, le paiement direct peut être plus simple. Si chaque transaction nécessite de maintenir un état d’entiercement, une confirmation de livraison et une période de litige, les processus et coûts d’exécution supplémentaires peuvent réduire une partie des gains d’efficacité. x402B peut donc ne pas convenir à tous les scénarios de paiement impliquant des AI Agents.

La dernière limite concerne la compatibilité et l’adoption. Le mode de paiement sous entiercement de x402B nécessite la prise en charge des clients, des serveurs et des composants de relais concernés. Il ne faut pas supposer que toutes les applications x402 disposent déjà de ces capacités. Son développement à long terme dépendra également de la sécurité des smart contracts, de la fiabilité des Dispute Resolvers, de la liquidité des actifs de paiement, des coûts d’intégration pour les développeurs et de la demande réelle de transactions. Les implémentations techniques et les cas d’utilisation commerciaux existants peuvent démontrer une certaine faisabilité, mais ils ne suffisent pas encore à prouver que ce modèle deviendra une norme universelle pour toutes les transactions du commerce entre Agents.

Que signifie x402B pour le développement du commerce entre Agents ?

Le développement du commerce entre Agents pousse les infrastructures de paiement à évoluer, passant de simples transferts de fonds à une gestion complète des transactions. Lorsqu’un AI Agent doit uniquement acheter un service d’API qui renvoie immédiatement un résultat, des capacités de paiement automatisé peuvent suffire. Toutefois, lorsque les Agents commencent à acheter des services personnalisés, à coordonner plusieurs fournisseurs ou à participer à des transactions portant sur des produits réels, l’autorisation du paiement, la confirmation de l’exécution, les remboursements et la résolution des litiges doivent devenir des étapes interconnectées.

x402B fournit une voie technique pour relier ces étapes. Grâce aux requêtes de paiement HTTP, à l’entiercement on-chain, aux signatures structurées et aux états de transaction exécutables, les AI Agents peuvent bénéficier d’un certain niveau de protection des transactions tout en réduisant le besoin d’intervention humaine. Ce modèle peut également contribuer à créer des processus d’achat automatisés plus standardisés, permettant à différents développeurs et prestataires de services de concevoir des applications autour d’interfaces communes de paiement et de règlement.

Toutefois, la maturité du commerce entre Agents ne dépend pas uniquement de la technologie de paiement. La vérification de l’identité, l’autorisation des transactions, l’évaluation de la qualité des services, la gouvernance des litiges et les cadres de conformité doivent également évoluer de manière coordonnée. x402B ne traite que certains problèmes liés à l’entiercement et au règlement des fonds. Sa valeur réelle devra finalement être évaluée au regard du volume réel des transactions, des taux d’exécution, de la sécurité des fonds et de l’adoption par les développeurs.

Résumé

x402B est une extension d’entiercement on-chain développée par Boson Protocol sur la base du système de paiement x402. Contrairement aux méthodes de règlement direct principalement conçues pour les paiements immédiats, x402B intègre le blocage des fonds, la livraison du produit ou du service, la gestion des litiges et le règlement final dans un même processus transactionnel. Il fournit ainsi une protection supplémentaire aux AI Agents qui achètent des services dont la livraison n’est pas immédiate.

Sa valeur centrale n’est pas d’accélérer les paiements des AI Agents, mais d’établir un lien plus clair entre les paiements automatisés et l’exécution des transactions. À mesure que les AI Agents participent à des achats de services numériques et à des transactions commerciales plus complexes, l’entiercement non conservateur pourrait devenir un élément important de l’infrastructure du commerce entre Agents. Toutefois, sa sécurité, son champ d’application et sa maturité commerciale doivent encore faire l’objet d’une validation continue.

FAQ

Qu’est-ce que x402B ?

x402B est une extension de paiement de x402 développée par Boson Protocol. Elle utilise un contrat d’entiercement on-chain non conservateur pour gérer les fonds des transactions et prend en charge la confirmation de la livraison ainsi que la résolution des litiges.

x402B est-il le même protocole que x402 ?

Il ne s’agit pas exactement du même concept. x402 est un protocole de paiement natif au réseau, tandis que x402B est une extension spécifique qui ajoute des capacités de transaction sous entiercement au cadre d’interaction de paiement x402. Tous les clients x402 ne le prennent pas automatiquement en charge.

x402B exige-t-il qu’un AI Agent détienne de l’ETH pour payer les frais de gas ?

Pas nécessairement. Dans les scénarios prenant en charge le relais des transactions, un Facilitator peut soumettre la transaction et payer les frais de gas. L’acheteur n’a donc pas besoin de détenir le token natif requis pour payer ces frais. Toutefois, l’exécution on-chain entraîne toujours des coûts.

x402B peut-il garantir qu’un AI Agent ne sera pas victime d’une fraude ?

Non. L’entiercement on-chain peut réduire certains risques de non-livraison après le paiement, mais il ne peut pas éliminer les problèmes tels que les vulnérabilités des smart contracts, les fausses preuves de livraison ou les décisions incorrectes relatives aux litiges.

x402B peut-il utiliser uniquement de l’USDC ?

Non. L’USDC est un stablecoin utilisé dans les cas d’intégration existants. Les actifs pris en charge dépendent du réseau concerné, du mécanisme d’autorisation des tokens et de la configuration du serveur.

À quels types de transactions x402B convient-il ?

Il convient davantage aux transactions dans lesquelles un délai sépare le paiement et la livraison, ou lorsque l’acheteur et le vendeur ont besoin d’une protection supplémentaire de l’exécution. Parmi les exemples figurent les services numériques personnalisés, l’achat de logiciels, les tâches de calcul asynchrones et certaines transactions portant sur des produits.