X402 - Bienvenue dans le Bazaar de Coinbase

En tant que couche de données premium pour les agents IA, la mission de Kirha est de les connecter à des données premium provenant des meilleurs fournisseurs tout en leur permettrant de payer comme ils l’entendent. Nous avons donc rejoint le Coinbase Bazaar: la plateforme où les agents peuvent découvrir les vendeurs X402.

Voici le recit cette intégration.

X402 est le nouveau protocole de paiement de Coinbase, et il représente déjà près de 20 % du volume de transactions de Base. Il donne un second souffle au code HTTP 402 pour offrir une méthode standardisée permettant aux agents IA de payer en USDC pour accéder à une ressource sur un serveur distant, sans avoir besoin d’authentification. Les fournisseurs de ressources peuvent ajouter un simple décorateur à une route d’API pour accepter l’USDC sans se soucier de la complexité de la blockchain.

L’adoption rapide de X402 valide pleinement notre vision des micro-paiements pour les agents IA :

• Les abonnements ne sont pas adaptés aux agents IA.
• La blockchain est le backend de paiement idéal pour les agents.

X402 présente toutefois des limitations importantes : il ne supporte que l’USDC pour le moment (alors que les agents pourraient vouloir payer avec leur propre token), les frais de transactions peuvent rogner, voire dépasser, le montant des petits paiements (payer 3 cents de gas pour une ressource à 2 cents n’a pas de sens), et il n’autorise pas la tarification dynamique des ressources.

Coinbase résout temporairement le problème des frais de transaction en sponsorisant toutes les transactions X402.

Nous avons dû hacker une solution pour la tarification dynamique. En effet, contrairement à un endpoint servant une ressource statique, le prix de la /search de Kirha dépend du contexte demandé par le prompt de l’agent. Obtenir le prix actuel du Bitcoin coûte 2 cents, mais demander des métriques agrégées comme le P/S et le P/F d’un protocole coûte 5 cents, et comparer plusieurs documents déposés auprès de la SEC peut dépasser 10 cents. Nous aiguillons votre agent vers le contexte approprié en temps réel, ce qui signifie que le prix n’est pas connu à l’avance.

Les propositions en cours, telles que le système de paiement différé de Cloudflare - sur le point de s’unwrap 🥁 - permettront accessoirement de résoudre ce problème.

Etre early c’est ravioli

X402 tire parti du code de statut HTTP 402, jusqu’alors inutilisé, pour créer une couche de paiement native pour le web. Le processus est simple :

1. Le client demande une ressource.
2. Le serveur répond avec 402 Payment Required et un objet paymentRequirements décrivant ce qu’il accepte (chaîne, token, prix, adresse du destinataire).
3. Le client signe un ordre de paiement (payment payload) et relance la requête avec un en-tête X-PAYMENT.
4. Un serveur facilitateur vérifie et broadcast le paiement sur la chaîne
5. Le client reçoit la ressource.

La force réside dans l’abstraction : les serveurs de ressources n’ont pas besoin d’interagir avec des wallets ou des RPCs, et les clients n’ont pas à se préoccuper des frais de transaction. Le facilitateur gère les interactions avec la blockchain. Le protocole est conçu pour être indépendant du token mais les facilitateurs choisissent les tokens qu’ils supportent, en commençant par l’USDC pour des raisons évidentes.

Mais voici la limitation que nous avons rencontrée. La spécification suppose une tarification statique : vous définissez les paymentRequirements à l’avance, le client en choisit un, et c’est terminé. Or, l’endpoint /search de Kirha ne fonctionne pas de cette manière. Le prix dépend de la requête de l’agent, et nous ne le savons qu’après avoir analysé le prompt. Nous calculons le prix à la volée, puis nous le retournons dans l’objet paymentRequirements.

Le problème ? Lorsque le client renvoie l’ordre de paiement signé, il ne spécifie que le scheme et le network. Il n’existe aucun champ pour relier le paiement aux exigences spécifiques que nous avons générées.

Regardons ce que le client envoie :

{
  "x402Version": 1,
  "scheme": "exact",
  "network": "base",
  "payload": {
    "signature": "0x2d6a75...",
    "authorization": {
      "from": "0x857b06519E91e3A54538791bDbb0E22373e36b66",
      "to": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
      "value": "10000",
      "validAfter": "1740672089",
      "validBefore": "1740672154",
      "nonce": "0xf374661..."
    }
  }
}

Pas de requirementId, aucune référence au paymentRequirements que le client est en train de satisfaire. Juste une autorisation signée pour un certain montant.

J’ai brièvement envisagé des solutions de contournement farfelues : obscurcir un ID de paiement dans le nonce, ou encoder des métadonnées dans les décimales du prix. De très mauvaises idées. Le nonce est destiné à la protection contre la relecture (replay protection), pas au transport de données. Et s’attendre à ce que votre facilitateur ne normalise pas votre 10000.000042 astucieusement conçu en 10000 n’est pas une stratégie viable en production.

Nous avions besoin d’une solution plus propre.

Redis-moi qui tu es

Puisqu’une image vaut mille mots, voici l’architecture de notre solution de contournement en attendant que X402 évolue.

Nous stockons un hachage unique de chaque requête dans Redis, ainsi que le prix qui lui est associé. Fait intéressant, même si X402 ne requiert pas d’authentification, nous acheminons quand même les paiements via notre système interne de crédits. Nous utilisons l’endpoint /top-up de Kirha pour ajouter des crédits à un compte X402 administrateur pré-enregistré. C’est le même endpoint que vos agents peuvent utiliser pour ajouter des crédits à vos comptes Kirha si nécessaire. Ils peuvent recharger avec n’importe quel token, à condition qu’il soit configuré pour leur compte. Le seul prérequis est que leur token soit listé sur un DEX avec une liquidité suffisante.

Pourquoi c’est important

Bien qu’il en soit encore à ses balbutiements, X402 est une innovation prometteuse qui s’aligne sur notre vision des micro-paiements pour les agents IA. Cependant, comme c’est souvent le cas en crypto, il est actuellement détourné pour éviter des frais lors des mints plutôt que pour alimenter de véritables services.

Kirha est en train de concrétiser le modèle que X402 était censé rendre possible : du contenu premium, à la demande, payé à l’utilisation. C’est ainsi que l’infrastructure des agents IA devrait évoluer.