/ Technische Architektur
Wie BlockVault x402 implementiert.
Von HTTP 402 Response bis zum settled Payment in unter 3 Sekunden. Technical Walkthrough der x402-Client-Architektur von BlockVault.
/ Pipeline: x402Fetch → Handler → Selection → Approval → Payload → Signer → Retry
Architektur-Überblick
Das x402-Subsystem ist eine Pipeline: x402Fetch fängt 402 ab → PaymentHandler parst Anforderungen → SelectionLogic wählt EIP-3009 oder Permit2 → ApprovalQueue zeigt Modal → PayloadBuilder konstruiert EIP-712-Daten → Signer signiert → RetryEngine sendet mit payment-signature nochmal.
Payment-Methoden-Auswahl
BlockVault priorisiert immer EIP-3009, wenn: (1) Token ist USDC, (2) Chain unterstützt transferWithAuthorization, (3) Facilitator akzeptiert es. Sonst Fallback auf Permit2.
Approval-UX
Jede x402-Zahlung läuft durch die Approval-Queue. Die Queue batcht schnelle Requests, wendet Spend-Policies an und zeigt ein Confirmation-Modal mit: Empfänger-Domain, Betrag, Token, Chain und kumulativer Spend.
Queue und Policies
Policies werden lokal vor dem Signieren ausgeführt: Daily Cap pro Domain, Max pro Request, Allowed-Token-Liste und Time-Window-Restrictions. Wenn ein Request die Policy überschreitet, wird er abgelehnt, ohne dass du was mitbekommst.
Retry und Error-Handling
Nach dem Signieren sendet x402Fetch den ursprünglichen Request mit dem payment-signature Header nochmal. Wenn der Server einen Error zurückgibt (insufficient funds, expired nonce, wrong network), zeigt das Wallet eine klare Message und retried nicht automatisch.
/ 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()Zuletzt aktualisiert: