Coinbase lance des portefeuilles agentiques et x402, 50M+…
Le flux basé sur HTTP 402 est présenté comme une poignée de main standard pour les paywalls de logiciels, avec des appels API tarifés en USDC et un chemin AWS CloudFront/WAF.
Coinbase positionne les “Agentic Wallets” et le flux de paiement x402 comme des rails précoces pour que des logiciels autonomes paient des services en ligne en stablecoins. La société affirme que x402 a traité plus de 50 millions de transactions et associe le protocole à des intégrations telles qu'une API SQL USDC à 0,10 $ par requête et un chemin d'acceptation AWS CloudFront/WAF.
Points clés
- Coinbase a lancé les “Agentic Wallets” en février 2026 avec des fonctionnalités de financement, d'envoi, de trading et de gains, utilisant des limites par session et par transaction tout en gardant les clés privées isolées du modèle d'IA.
- x402 est présenté comme un protocole de paiement ouvert construit autour de HTTP 402 “Paiement requis”, permettant aux logiciels d'accéder à une ressource payante, de recevoir des instructions de paiement, de régler sur la chaîne et de continuer automatiquement.
- Coinbase a mis un marqueur d'échelle sur cette initiative, déclarant que x402 a traité plus de 50 millions de transactions, sans définition ou vérification indépendante incluse dans le paquet.
- Les mises à jour de mars 2026 ont élargi x402 à presque n'importe quel ERC-20 via Permit2 et sponsorship-extensions de gaz, aux côtés d'intégrations comme une SQL à $0,10 USDC par requête API et un flux d'acceptation de publisher AWS CloudFront/WAF.
Coinbase propose x402 comme un rail de paiements machine après avoir revendiqué plus de 50 millions de transactions
L'argument de Coinbase est que le « commerce agent » a besoin d'une poignée de main de paiement qui ressemble au web, pas à une page de paiement. La pile dans le paquet est composée de deux parties : un wrapper de portefeuille convivial pour les agents qui contraint ce que le logiciel peut faire avec les fonds, et une boucle de paiement native HTTP (x402) qui transforme une requête payante en un règlement on-chain et un nouvel essai.
La métrique principale que Coinbase utilise pour vendre cette histoire est l'échelle. La société dit que x402 a traité plus de 50 millions de transactions. Le paquet ne fournit pas de répartition on-chain, de tableau de bord tiers, ni même de définition de ce qui qualifie une « transaction x402 », ce qui est important car ce chiffre fait la majeure partie du travail de persuasion.
Là où le cadre devient plus concret, c'est dans la distribution. Les exemples ne sont pas « les agents pourraient payer des choses un jour », mais des surfaces d'acceptation spécifiques : une API SQL USDC à 0,10 $ par requête pour les données blockchain et un chemin AWS CloudFront et AWS WAF pour que les éditeurs acceptent les paiements des agents.
Portefeuilles Agentiques : Autonomie autorisée sans remettre les clés au modèle
Une IAportefeuille d'agent, comme décrit dans le paquet, est un portefeuille conçu pour que le logiciel effectue des transactions selon des règles prédéfinies plutôt que par des clics humains directs. Le point opérationnel est de permettre à un agent d'exécuter des paiements ou des échanges de routine tout en gardant le rayon d'explosion limité lorsque l'agent se trompe, est compromis ou simplement trop enthousiaste.
Le choix d'implémentation de Coinbase est explicite : les Portefeuilles Agentiques ont été lancés en février 2026 avec des fonctions incluant le financement, l'envoi, le trading et le gain, et les contrôles sont des plafonds de dépenses par session et par transaction. Les clés privées restent isolées du modèle d'IA, ce qui est une séparation claire des fonctions. Le modèle peut demander des actions, mais il ne reçoit pas la garde des clés brutes.
Ce design ressemble à une admission concernant les modes de défaillance. Les agents peuvent mal comprendre les instructions, interagir avec des services malveillants ou effectuer des achats non autorisés.
Les plafonds et l'isolement des clés ne résolvent pas ces problèmes, mais ils les transforment de « perte totale » en « perte limitée », et ils facilitent l'ajout de filtrage des transactions et d'auditdes enregistrements sans prétendre que le modèle est un signataire de confiance.
Comment x402 transforme un mur de paiement en une boucle de règlement sur chaîne
x402 est décrit comme un protocole de paiement ouvert basé sur le code d'état HTTP 402 "Paiement requis". Mécaniquement, le flux est censé être ennuyeux de la manière dont l'infrastructure web est ennuyeuse : le logiciel demande une ressource, reçoit une réponse 402 avec des instructions de paiement, se règle sur la chaîne, puis continue automatiquement une fois le paiement validé.
La conséquence est une poignée de main de paywall standardisée pour les logiciels. Au lieu de fournir desclés API, de configurer des comptes ou de faire passer un humain par un processus de paiement, un agent peut traiter le paiement comme faisant partie du cycle de vie de la demande.
C'est la condition préalable pour que les micropaiements fonctionnent dans des environnements machine à machine, car l'unité de travail est souvent "une requête" ou "un appel", pas un abonnement mensuel.
L'exemple le plus lisible du paquet est l'API SQL de Coinbase, décrite comme permettant aux agents d'acheter des requêtes de données blockchain pour 0,10 USD chacune en USDC sans clés API, comptes ou approbation humaine. Un autre exemple est l'introduction par Exa des paiements x402 pour la recherche premium en avril 2026, où les agents peuvent découvrir, payer et consommer des services de recherche automatiquement.
Coinbase a également annoncé une intégration AWS permettant aux éditeurs utilisant CloudFront et WAF d'accepter des paiements d'agents. Le paquet ne précise pas les chaînes ou tokens pris en charge, comment le règlement est routé, à quoi ressemblent les frais, ou comment les éditeurs fixent les prix des ressources payantes. Néanmoins, la direction est claire : mettre la porte de paiement là où les éditeurs terminent déjà le trafic.
Signaux à suivre : Expansion ERC-20 via Permit2, Sponsoring de gaz, et le parallèle Agent-Registry UPI
L'expansion de mars 2026 pour prendre en charge presque n'importe quel token ERC-20 via Permit2 et des extensions de sponsoring de gaz est le mouvement de compatibilité. Permit2 est mentionné comme le mécanisme d'approbation qui élargit le support des tokens, tandis que le sponsoring de gaz est le mouvement UX qui peut permettre à un agent de payer sans détenir de tokens de gaz natifs.
Les deux réduisent les frictions, mais le paquet ne dit pas combien de l'activité x402 rapportée est centrée sur l'USDC par rapport à plusieurs tokens.
Le prochain signal est la vérification, pas les fonctionnalités. La revendication de Coinbase concernant "plus de 50 millions" de transactions x402 nécessite une répartition indépendante qui clarifie ce qui est compté et où cela se règle sur la chaîne. Sans cela, le nombre est un primitif marketing plutôt qu'un indicateur d'adoption.
Les détails de distribution sont l'autre pièce manquante. Le chemin d'acceptation AWS CloudFront/WAF n'est décrit qu'à un niveau élevé, donc les questions pratiques restent ouvertes : quelles chaînes et tokens sont pris en charge, comment les éditeurs activent et fixent le prix des ressources payantes, et à quoi ressemble le chemin de règlement et de frais.
Un troisième signal est de savoir si le modèle de tarification de 0,10 $ par appel se propage. Si davantage de services Coinbase ou tiers adoptent la tarification USDC (ou ERC-20) par demande via x402 pour les API, les données ou le calcul, c'est le type d'utilisation qui peut se cumuler enstablecoinvolume de transactions.
Enfin, les paiements traditionnels convergent vers des primitives de contrôle similaires. Le paquet indique que l'UPI a traité 24,51 milliards de transactions d'une valeur de 29,82 trillions INR en août 2026, et décrit la National Payments Corporation de l'Inde comme développant un registre pour vérifieragents IAeffectuant des paiements via l'UPI, qui devrait commencer par de petits achats et incorporer des limites de dépenses, des vérifications d'identité et des pistes de vérification. Si ces contraintes deviennent la norme dansrailsfiat, les portefeuilles d'agents en crypto seront probablement jugés sur les mêmes surfaces : limites, identité et journaux.
Mon avis : Le cas haussier est le volume, le cas baissier est la vérification et les surfaces de contrôle.
Le seuil qui compte est de savoir si x402 se transforme en une primitive de paiement mesurable et vérifiable plutôt qu'un flux de marque. Le mécanisme est plausible : HTTP 402 comme déclencheur, règlement on-chain comme reçu, et portefeuilles agents comme la couche de garde qui éloigne les clés privées du modèle tout en permettant au logiciel de dépenser.
Le scénario haussier est que les intégrations dans le paquet sont de la bonne forme pour une utilisation réelle. Une API SQL à 0,10 $ USDC par requête et une carte d'acceptation AWS CloudFront/WAF mappent les paiements machine sur la distribution existante des développeurs et des éditeurs, qui est d'où provient le volume.
Le scénario baissier est que le plus grand chiffre de l'histoire, « plus de 50 millions de transactions », n'est pas encore une métrique vérifiable, et les surfaces de contrôle qui décideront de l'adoption par les entreprises sont encore mal spécifiées.
Cela a de l'importance en termes pratiques si l'utilisation de x402 devient indépendamment lisible et que les contraintes de portefeuille deviennent suffisamment standard pour que les éditeurs puissent tarifer par demande sans prendre de risque d'agent ouvert.
