Coinbase x402 contre Google A2A : Deux ordres de paiement opposés pour les paiements entre agents.

Un développeur construisant un agent de recherche qui sous-traite à trois autres (recherche, résumé, traduction) avait besoin de paiements machine à machine inférieurs au centime. Le minimum de 0,30 $ de Stripe pour un appel à 0,001 $ représente un surcoût de 300x ; le gaz L1 on-chain est similaire ; les abonnements nécessitent une négociation humaine préalable. Ils ont trouvé x402, l'implémentation par Coinbase du HTTP 402 "Paiement requis" — un facilitateur sans état pour les paiements infimes sur Base, réglant en ~2s pour ~0,0001 $ via des autorisations pré-signées EIP-3009 passées en en-têtes.

La question centrale : l'ordre des paiements

Quand on a vérifier (rapide, off-chain), régler (lent, on-chain), et le travail réel (appel LLM), trois ordres sont possibles :

• A : vérifier → exécuter → régler
• B : vérifier → régler → exécuter
• C : vérifier → réserver → exécuter → capturer (schéma de carte de crédit — impossible avec la conception unique d'EIP-3009)

Le middleware de Coinbase utilise A ; l'extension A2A x402 de Google utilise B. La différence repose sur la durée du travail : l'appelant de Coinbase est un point d'API rapide (moins de 500 ms), donc l'écart vérifier-régler est négligeable. Pour un agent appelant d'autres agents, la fenêtre s'étend à plusieurs secondes ou minutes — assez longtemps pour que le payeur vide son portefeuille après vérification mais avant le règlement, offrant du calcul gratuit.

Régler d'abord gagne pour les charges agentiques

Le développeur a choisi B (vérifier → régler → exécuter) car le travail des agents coûte de l'argent réel (0,30 $+ par appel) et est lent. Avec le règlement d'abord, un paiement échoué n'exécute jamais le LLM. Ils ont testé en conditions réelles quatre scénarios :

• Signature valide, portefeuille vidé avant que le règlement n'atterrisse → le règlement échoue, aucun calcul gaspillé (0 $ de perte).
• Deux requêtes parallèles du même portefeuille avec des nonces différents, même solde → un règlement réussit, l'autre échoue (course chaîne), n'atteint jamais le modèle.
• En-tête de paiement rejoué → détecté à la vérification du nonce avant vérification, renvoie 402.
• Délai d'attente du facilitateur à 10 s mais la chaîne confirme à 25 s → paiement orphelin (débité, tâche échouée). C'est une propriété de la chaîne sous charge, non résoluble par l'ordre.

Un mode d'échec du règlement d'abord : le paiement atterrit, mais le travail échoue (erreur 500, bogue). Le fournisseur gère avec des métadonnées nonce/auth persistées et des remboursements manuels.

Le flux complet est open source avec des tests e2e exécutant les quatre scénarios sur un ordinateur portable. github.com/GetBindu/Bindu