/ Architecture technique
Comment BlockVault implémente x402.
D'une réponse HTTP 402 à un paiement réglé en moins de 3 secondes. Plongée technique dans l'archi du client x402 de BlockVault.
/ Pipeline: x402Fetch → Handler → Selection → Approval → Payload → Signer → Retry
Vue d'ensemble de l'architecture
Le sous-système x402 est un pipeline : x402Fetch intercepte les 402, PaymentHandler parse les exigences, SelectionLogic choisit EIP-3009 ou Permit2, ApprovalQueue affiche la modale, PayloadBuilder construit les données EIP-712, Signer signe, RetryEngine renvoie avec payment-signature.
Sélection de la méthode de paiement
BlockVault privilégie toujours EIP-3009 si : (1) le token est USDC, (2) la chaîne supporte transferWithAuthorization, (3) le facilitator l'accepte. Sinon, bascule sur Permit2.
UX d'approbation
Chaque paiement x402 passe par la file d'approbation. La file regroupe les requêtes rapides, applique les politiques de dépense, présente une modale de confirmation : domaine destinataire, montant, token, chaîne, dépenses cumulées.
File et politiques
Les politiques s'exécutent localement avant toute signature : plafond quotidien par domaine, maximum par requête, liste de tokens autorisés, restrictions horaires. Si une requête dépasse la politique, elle est rejetée. Sans intervention utilisateur.
Retry et gestion d'erreurs
Après signature, x402Fetch renvoie la requête originale avec le header payment-signature. Si le serveur retourne une erreur (fonds insuffisants, nonce expiré, réseau incorrect), le wallet affiche un message clair. Pas de retry automatique.
/ Usage example
// x402Fetch is a drop-in replacement for fetch()
import { x402Fetch } from '@blockvault/x402'
const response = await x402Fetch('https://api.example.com/data', {
method: 'GET',
// If server returns 402, the wallet handles payment automatically
// EIP-3009 is preferred when token is USDC
})
// response is the final 200 OK with paid content
const data = await response.json()Dernière mise à jour: