/ Implementation deep-dive
How BlockVault implements x402.
From HTTP 402 response to settled payment in under 3 seconds. A technical walkthrough of BlockVault's x402 client architecture.
/ Pipeline: x402Fetch → Handler → Selection → Approval → Payload → Signer → Retry
Architecture overview
The x402 subsystem is a pipeline: x402Fetch intercepts 402 responses → PaymentHandler parses requirements → SelectionLogic picks EIP-3009 or Permit2 → ApprovalQueue presents the modal → PayloadBuilder constructs EIP-712 data → Signer signs → RetryEngine replays with payment-signature.
Payment method selection
BlockVault always prefers EIP-3009 when: (1) the token is USDC, (2) the chain supports transferWithAuthorization, and (3) the facilitator accepts it. Otherwise it falls back to Permit2.
Approval UX
Every x402 payment passes through the approval queue. The queue batches rapid-fire requests, applies spend policies, and presents a single confirmation modal showing: recipient domain, amount, token, chain, and cumulative spend.
Queue & policies
Policies run locally before any signature: per-domain daily cap, per-request max, token allow-list, and time-window restrictions. If a request exceeds policy, it is rejected without user interaction.
Retry & error handling
After signing, x402Fetch retries the original request with the payment-signature header. If the server returns an error (insufficient funds, expired nonce, network mismatch), the wallet surfaces a clear error and does not retry automatically.
/ 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()Last updated: