x402 est une blockchain ou un token ?

Ni l'un ni l'autre. x402 est un protocole HTTP qui utilise des blockchains existantes (Ethereum, Base, Polygon) pour le règlement. Pas de nouvelle chaîne. Pas de nouveau token.

Faut-il de l'ETH pour le gas lors d'un paiement x402 ?

Pas avec EIP-3009. Les transferts USDC via transferWithAuthorization sont gasless pour l'émetteur. Le facilitator paie le gas.

Mon agent IA peut dépenser sans mon accord ?

Uniquement dans les limites que vous définissez. BlockVault applique des plafonds par domaine, limites quotidiennes, listes de tokens autorisés. Localement, avant toute signature.

Quels tokens fonctionnent avec x402 ?

USDC sur 6 chaînes EVM via EIP-3009 (gasless). N'importe quel ERC-20 via Permit2 (nécessite du gas). La plupart des serveurs x402 acceptent USDC.

Un paiement x402, ça prend combien de temps ?

Une signature off-chain et un retry HTTP. Avec EIP-3009, pas de tx on-chain côté payeur. Le règlement prend 1 à 3 secondes.

x402 est open source ?

Oui. Le protocole est défini sur x402-foundation/x402 sur GitHub. Tout le monde peut implémenter un client ou un serveur.

Je peux protéger mon API avec x402 ?

Oui. Renvoyez HTTP 402 avec un header payment-required contenant vos conditions : token, montant, réseau, destinataire. Tout wallet compatible peut payer.

Qu'est-ce qu'un paiement agentique ?

Un paiement agentique est une transaction initiée et complétée de façon autonome par un agent IA sans intervention humaine. L'agent détecte un paywall (HTTP 402), évalue le coût selon sa politique de dépense, signe un transfert et règle le tout, dans le même cycle de requête HTTP.

Comment x402 permet-il les paiements agentiques ?

x402 encode les conditions de paiement directement dans les en-têtes HTTP. Quand un agent IA reçoit une réponse 402, il lit l'en-tête payment-required (token, montant, réseau, destinataire), signe un transfert USDC sans gas via EIP-3009, attache la signature et rejoue la requête. Pas de redirections, pas d'OAuth, pas d'approbation humaine requise pour les montants pré-autorisés.

Les paiements agentiques sont-ils sûrs sans approbation humaine ?

Oui. BlockVault applique des politiques de dépense localement : plafonds par requête, limites journalières et listes blanches de domaines. L'agent ne peut dépenser que dans les limites définies par l'utilisateur. Tout paiement dépassant la politique déclenche une fenêtre d'approbation HITL avant signature.

D'où vient HTTP 402 ?

402 Payment Required a été défini pour la première fois dans HTTP/1.1 dans le RFC 2068 (1997), repris dans le RFC 2616 (1999), puis conservé comme « reserved » dans le RFC 7231 (2014). Pendant plus de deux décennies, il est resté inutilisé. x402 est le premier protocole à lui donner une vraie sémantique de paiement, ce qui explique pourquoi vous voyez aujourd'hui des paiements 402 fonctionner en conditions réelles.

X402 native payments pour agents IA.

x402 transforme HTTP 402, un code de statut défini dans HTTP/1.1 (RFC 2616) et resté inutilisé pendant plus de 20 ans, en protocole de paiement lisible par les machines. Votre agent appelle une API, reçoit un 402 avec les conditions de paiement, signe un transfert USDC sans gas, réessaie, et la ressource se débloque. Pas de page de checkout, pas d'API keys, pas de factures mensuelles.

Disponible surGoogle Play Disponible surApp Store

Un code de statut qui a attendu deux décennies.

HTTP 402 Payment Required est dans la spec depuis HTTP/1.1 (RFC 2068, 1997 ; RFC 2616, 1999), mais est resté « reserved for future use » pendant plus de 20 ans. x402 lui donne enfin du mordant : quand un serveur renvoie 402, il inclut un en-tête payment-required décrivant les tokens acceptés, les montants et les réseaux. Le client signe un transfert de tokens off-chain, l'attache en en-tête payment-signature et rejoue la requête. Le serveur vérifie, règle et délivre la ressource. Sans redirections, sans iframes, sans SDK tiers.

Le handshake x402

Client (wallet)Server (API)

01
GET /api/resource
02
402 + payment-required
03
Sign EIP-3009 / Permit2
04
Retry + payment-signature
05
200 OK + payment-response

EIP-3009 vs Permit2.

L'en-tête 402 Payment Required nomme le token, le montant et le réseau. BlockVault règle de deux façons : EIP-3009 pour l'USDC sans gas, ou Permit2 pour n'importe quel ERC-20. Il choisit la meilleure option automatiquement, et vous pouvez toujours passer outre.

EIP-3009 (USDC gasless)

Utilise transferWithAuthorization intégré au contrat USDC. Zéro gas pour le payeur. Dispo sur Ethereum, Polygon, Base, Arbitrum, Optimism, BSC.

Gas : zéro (meta-tx)
Tokens : USDC uniquement
Chaînes : 6 réseaux EVM

Permit2 (ERC-20 universel)

Utilise le routeur Permit2 d'Uniswap pour n'importe quel ERC-20 avec une seule approbation. Le gas est payé lors du règlement.

Gas : ~60k (règlement)
Tokens : tout ERC-20
Chaînes : 6 réseaux EVM

BlockVault privilégie EIP-3009 si le token est USDC sur une chaîne compatible. Sinon, bascule sur Permit2.

Un 402 qui fonctionne enfin, deux décennies plus tard.

HTTP 402 a été défini dans HTTP/1.1 (RFC 2068, 1997 ; RFC 2616, 1999) et est resté inutilisé pendant plus de 20 ans. BlockVault est le premier wallet à implémenter l'IA embarquée et les paiements natifs x402. x402Fetch remplace fetch() et intercepte les 402, parse le header payment-required, met l'approbation en file dans l'UI, construit le payload EIP-3009 ou Permit2 et renvoie avec payment-signature. Vous voyez une confirmation. Le serveur voit une requête payée.

Endpoint de production

402.blockvault.ai

402.blockvault.ai : serveur x402 en prod qui facture l'inférence GPU (Gemma 4, Llama) par token en USDC sur Base.

Wallets x402 en un coup d'œil.

← scroll →

	BlockVault	Coinbase x402	MetaMask	Trust Wallet	Phantom	Binance
x402 natif	✓	✓	—	—	—	—
Gasless (EIP-3009)	✓	—	—	—	—	—
Multi-chain (6+ EVM)	✓	✓	✓	✓	~	✓
IA embarquée	✓	—	—	—	—	—
Auto-conservation	✓	✓	✓	✓	✓	—
Mobile-first	✓	✓	~	✓	✓	✓

Le standard de paiement agentique.

Après plus de deux décennies « reserved », HTTP 402 a enfin un travail. Les agents IA doivent payer de façon autonome : API, calcul GPU, flux de données premium. x402 leur offre un rail HTTP natif : l'agent reçoit un 402, signe un transfert USDC, réessaye. Sans page de checkout, sans abonnements, sans intervention humaine.

La bibliothèque de référence x402.

Tout ce qu'il faut pour comprendre, implémenter et déployer HTTP 402, le code de statut défini dans HTTP/1.1 et resté inutilisé pendant plus de 20 ans. De la spec à une étude de cas en production.

Lire la specEn-têtes, méthodes de signature, structures EIP-712 et réseaux pris en charge.Plongée dans l'implémentationComment le client x402 de BlockVault intercepte, signe et réessaie les paiements.Étude de cas : 402.blockvault.aiInférence GPU vendue par token via x402 en production.Glossaire30 termes définis en langage clair.

Questions sur un code de statut vieux de 20 ans.

x402 est une blockchain ou un token ?
Ni l'un ni l'autre. x402 est un protocole HTTP qui utilise des blockchains existantes (Ethereum, Base, Polygon) pour le règlement. Pas de nouvelle chaîne. Pas de nouveau token.
Faut-il de l'ETH pour le gas lors d'un paiement x402 ?
Pas avec EIP-3009. Les transferts USDC via transferWithAuthorization sont gasless pour l'émetteur. Le facilitator paie le gas.
Mon agent IA peut dépenser sans mon accord ?
Uniquement dans les limites que vous définissez. BlockVault applique des plafonds par domaine, limites quotidiennes, listes de tokens autorisés. Localement, avant toute signature.
Quels tokens fonctionnent avec x402 ?
USDC sur 6 chaînes EVM via EIP-3009 (gasless). N'importe quel ERC-20 via Permit2 (nécessite du gas). La plupart des serveurs x402 acceptent USDC.
Un paiement x402, ça prend combien de temps ?
Une signature off-chain et un retry HTTP. Avec EIP-3009, pas de tx on-chain côté payeur. Le règlement prend 1 à 3 secondes.
x402 est open source ?
Oui. Le protocole est défini sur x402-foundation/x402 sur GitHub. Tout le monde peut implémenter un client ou un serveur.
Je peux protéger mon API avec x402 ?
Oui. Renvoyez HTTP 402 avec un header payment-required contenant vos conditions : token, montant, réseau, destinataire. Tout wallet compatible peut payer.
Qu'est-ce qu'un paiement agentique ?
Un paiement agentique est une transaction initiée et complétée de façon autonome par un agent IA sans intervention humaine. L'agent détecte un paywall (HTTP 402), évalue le coût selon sa politique de dépense, signe un transfert et règle le tout, dans le même cycle de requête HTTP.
Comment x402 permet-il les paiements agentiques ?
x402 encode les conditions de paiement directement dans les en-têtes HTTP. Quand un agent IA reçoit une réponse 402, il lit l'en-tête payment-required (token, montant, réseau, destinataire), signe un transfert USDC sans gas via EIP-3009, attache la signature et rejoue la requête. Pas de redirections, pas d'OAuth, pas d'approbation humaine requise pour les montants pré-autorisés.
Les paiements agentiques sont-ils sûrs sans approbation humaine ?
Oui. BlockVault applique des politiques de dépense localement : plafonds par requête, limites journalières et listes blanches de domaines. L'agent ne peut dépenser que dans les limites définies par l'utilisateur. Tout paiement dépassant la politique déclenche une fenêtre d'approbation HITL avant signature.
D'où vient HTTP 402 ?
402 Payment Required a été défini pour la première fois dans HTTP/1.1 dans le RFC 2068 (1997), repris dans le RFC 2616 (1999), puis conservé comme « reserved » dans le RFC 7231 (2014). Pendant plus de deux décennies, il est resté inutilisé. x402 est le premier protocole à lui donner une vraie sémantique de paiement, ce qui explique pourquoi vous voyez aujourd'hui des paiements 402 fonctionner en conditions réelles.

Le wallet de votre agent est prêt.

Téléchargez BlockVault et payez APIs, inférence et données nativement avec x402. Sans abonnements. Sans intermédiaires.

Disponible surGoogle Play Disponible surApp Store