Spiegazione di X402: Micropagamenti HTTP nativi per agenti AI

Lo spec X402 riutilizza lo stato standard HTTP 402 Payment Required per trasformare una normale chiamata API in un micropagamento on-chain. Gli agenti AI possono ora saldare le commissioni per query LLM o feed di dati senza l'intervento umano, e i fornitori possono addebitare costi per singola richiesta senza dover costruire un sistema di fatturazione personalizzato.

Perché gli agenti AI hanno bisogno di un protocollo di pagamento

Gli agenti autonomi mettono insieme modelli linguistici, strumenti di ricerca web e fonti di dati proprietarie. Ogni integrazione ha un costo: commissioni per token per un modello o costi per singola chiamata per un'API di dati di mercato. Gli attuali modelli di business si basano su chiavi API collegate ad account in abbonamento, ricariche manuali di credito o fatturazione postuma. Questi metodi infrangono la promessa di "assenza di intervento umano" degli agenti autonomi e aggiungono sovraccarichi operativi per i fornitori.

X402 offre una via di mezzo: un flusso richiesta-risposta che appare come qualsiasi altra chiamata HTTP, ma con un passaggio di pagamento integrato registrato su una blockchain pubblica. L'unico requisito è che il client sia in grado di firmare e trasmettere una transazione sulla chain specificata dal server.

Il handshake X402 nel dettaglio

  1. Richiesta iniziale – L'agente invia una normale GET o POST a un endpoint a pagamento. Non sono necessari header speciali.
  2. Il server risponde con 402 – La risposta contiene lo stato 402 e un corpo JSON che elenca:
    • amount – la commissione che il server si aspetta, nell'unità di token più piccola;
    • token – l'indirizzo del contratto ERC-20 (o equivalente);
    • chain – l'identificatore della blockchain dove il pagamento deve essere registrato;
    • nonce opzionale – un valore univoco che impedisce gli attacchi di replay.
  3. Il client prepara il pagamento – L'agente verifica l'indirizzo del token e la chain rispetto alla propria policy (ad esempio, solo chain affidabili). Crea quindi una transazione che trasferisce l'importo richiesto all'indirizzo fornito dal server, la firma con la propria chiave privata e la trasmette.
  4. Invio dell'hash di pagamento – Quando l'hash della transazione è disponibile, il client ripete la richiesta originale, aggiungendo questa volta un header X-Payment che contiene l'hash. Il payload rimane invariato.
  5. Il server verifica on-chain – Il server interroga la blockchain alla ricerca di un trasferimento confermato che corrisponda a importo, token, chain e nonce. Se trova una corrispondenza, restituisce i dati richiesti con uno stato 200 OK.

Qualsiasi libreria client HTTP che supporti header personalizzati e possa chiamare un SDK blockchain può eseguire questi passaggi. Non è richiesto alcun nuovo protocollo di trasporto o uno strato socket personalizzato.

Compromessi da tenere a mente

  • Latenza – La conferma sulla chain pubblica aggiunge ritardo.
  • Costi del gas – Anche le chain economiche applicano commissioni gas; i pagamenti inferiori a $0,001 potrebbero non essere convenienti.
  • Complessità – Gli agenti devono gestire transazioni fallite e riorganizzazioni della chain; una logica di retry robusta è indispensabile.
  • Sicurezza – Il nonce impedisce gli attacchi di replay, ma gli agenti devono comunque proteggere le chiavi private ed evitare di riutilizzarle su servizi non correlati.