Skip to main content
X402 è un protocollo di pagamento on-chain “a pagamento HTTP 402” proposto da Coinbase: il server restituisce 402 Payment Required su richieste senza token, allegando il campo accepts: [...] che elenca le catene / asset / prezzi accettabili; il client firma localmente una transazione autorizzata (su EVM è Permit2 / EIP-712, su Solana è l’autorizzazione del trasferimento di token SPL), inserisce l’envelope codificato in base64 nell’intestazione PAYMENT-SIGNATURE e la reinvia. Dopo la verifica, il server procede al pagamento on-chain e restituisce il risultato dell’operazione.
Il client X402 di Ace Data Cloud chiama direttamente l’API di destinazione e utilizza il 402 Payment Required restituito in tempo reale e accepts come base per il prezzo e la firma. La capacità di pagamento del Facilitator può essere verificata in /.well-known/x402.
@acedatacloud/sdk e acedatacloud espongono entrambi un hook paymentHandler: quando una richiesta inviata dal SDK riceve un 402, chiama il tuo handler iniettato per ottenere l’intestazione PAYMENT-SIGNATURE, quindi reinvia la richiesta originale. Utilizzando @acedatacloud/x402-client / acedatacloud-x402 insieme al SDK, l’intero processo è completamente trasparente per il codice aziendale—basta usare client.openai.chat.completions.create(...), che appare identico al modello token, ma sotto il cofano è a pagamento per chiamata, senza necessità di ricarica anticipata. Questo articolo:
  • Ha eseguito una vera e propria catena “senza token + iniezione di handler X402” sul lato TS (Verifica T12)
  • Ha elencato le differenze tra le due catene di firma EVM / Solana
  • Ha fornito tre modalità di adattamento: modalità chiave privata viem, modalità portafoglio browser, modalità EVMAccountSigner Python
  • Ha chiarito il campo preferScheme / prefer_scheme, che è facile da fraintendere

I. Panoramica del Protocollo (da leggere assolutamente)

Una chiamata X402 di successo coinvolge 3 RTT HTTP:
L’envelope X402 è un JSON che, dopo essere stato codificato in base64, viene inserito nell’intestazione PAYMENT-SIGNATURE. Struttura (estratto):
L’elemento principale dell’envelope è x402Version: 2, e utilizza l’oggetto accepted per dichiarare il scheme e la network scelti (identificazione CAIP-2). preferScheme / prefer_scheme viene utilizzato per selezionare una preferenza quando il server offre più schemi contemporaneamente. Se il server espone solo exact, questo campo verrà ignorato; se è impostato su upto ma il server non lo espone, si tornerà al primo elemento corrispondente.

II. TypeScript: Portafoglio Browser + Due modalità di utilizzo del server viem

Installazione

Versioni testate:

createX402PaymentHandler Firma Completa

Il valore restituito è un (ctx) => Promise&lt;{ headers: Record<string, string> }> che corrisponde esattamente alla firma dell’hook paymentHandler del SDK.

Utilizzo 1: Browser (MetaMask / WalletConnect)

La prima volta che viene effettuata la chiamata, il browser mostrerà due richieste di firma: la prima è un’approvazione una tantum di Permit2 per USDC (l’importo è MaxUint256, scritto sulla catena); la seconda è la firma EIP-712 dell’envelope X402 (non sulla catena, solo per la verifica del facilitator). Le chiamate successive richiederanno solo la seconda firma, l’esperienza sarà “clicca una volta per firmare → ottieni il risultato”.

Utilizzo 2: Server Node + chiave privata viem (adatto per backend / CLI)

@acedatacloud/x402-client sul lato TS accetta solo provider EIP-1193—non gestisce direttamente le chiavi private. Nello scenario Node / CLI, la prassi standard è utilizzare viem per incapsulare la chiave privata in un WalletClient, quindi utilizzare @ethereumjs/util o l’adattamento EIP-1193 interno di viem.
Se pensi che l’adattamento EIP-1193 di viem non sia abbastanza stabile, puoi anche utilizzare un approccio più di basso livello signEVMUptoPayment, concatenando tu stesso il percorso accepts → signed envelope → PAYMENT-SIGNATURE header, saltando i ganci SDK; tuttavia, si consiglia comunque di preferire createX402PaymentHandler, per evitare di dover mantenere gli aggiornamenti del protocollo.

Uso 3: Solana

La catena Solana attualmente espone solo lo schema exact, quindi preferScheme non ha effetto su Solana.

Tre, Python: modalità chiave privata

Il acedatacloud-x402 di Python segue la strada di firmare direttamente con la chiave privata (senza astrazione EIP-1193), più adatta per server / esecutori di task.

Installazione

Versione testata:

EVM (Base / Skale)

Solana

Approvazione una tantum (solo EVM la prima volta)

Su EVM Base, X402 utilizza Permit2, richiedendo che il portafoglio approvi una volta il contratto Permit2 per USDC con un MaxUint256. acedatacloud-x402 include approve_permit2:
Questa transazione deve essere inviata solo una volta, dopo di che tutti i pagamenti X402 EVM utilizzeranno questa autorizzazione. Solana non ne ha bisogno.

Quattro, verifica di esecuzione reale

Obiettivo del test: SDK TS senza passare token, iniettare gestore X402, in grado di costruire e avviare richieste normalmente (verifica leggera senza consumare USDC sulla vera catena).
Output:
Risultati:
  • Non avendo passato apiToken, la costruzione SDK non genera errori, dimostrando che la modalità X402 è effettivamente un sostituto legittimo del token.
  • createX402PaymentHandler restituisce una funzione (gancio), che SDK utilizza solo quando riceve un 402.
  • I test end-to-end di pagamento sulla vera catena, poiché coinvolgono il prelievo reale di USDC, non sono stati inclusi in questo tutorial; puoi fare riferimento alla Guida all’integrazione X402 per esempi e2e.
Anche il lato Python create_x402_payment_handler ha effettuato la stessa verifica - il valore restituito dalla funzione è callable, e iniettando payment_handler=... non genera errori nella costruzione di AceDataCloud(...). Le semantiche sono allineate su entrambi i lati.

Cinque, confronto con la modalità “Bearer token”

Sei, trappole comuni

  1. La classe chat deve avere preferScheme=upto: usare exact farà sì che il facilitator detragga USDC in base a maxAmountRequired (non all’uso effettivo).
  2. Non passare la chiave privata nuda al createX402PaymentHandler dal lato Node: il pacchetto TS non accetta { privateKey }, deve essere incapsulato in un provider EIP-1193 (si consiglia viem WalletClient).
  3. La prima chiamata è una doppia firma: la prima volta si firma il Permit2 approve (on-chain, con gas), la seconda volta si firma l’involucro X402 (off-chain). Le chiamate successive richiederanno solo la seconda firma.
  4. Solana non ha il concetto di Permit2: si firma direttamente l’autorizzazione al trasferimento di token SPL, non è necessario approvare; ma attualmente la catena Solana supporta solo exact.
  5. Distinzione tra errori di business e errori di pagamento: 402 → il handler fallisce lanciando X402SignError (il tipo specifico varia a seconda della catena); gli errori dell’interfaccia di business dopo un nuovo invio (401 / 422 / 5xx) vengono ancora classificati come eccezioni SDK normali.
  6. Scrittura più stabile per l’adattamento di viem: evmProvider: walletClient as any perderà il controllo dei tipi ma avrà la migliore compatibilità; se si desidera mantenere i tipi, utilizzare .transport.request di viem per incapsulare separatamente l’oggetto { request }.

Scopri di più