💻 computer science

Free-Riding in the AI Economy: Demystifying Logic Flaws in x402-Enabled Payment Systems

Questo articolo presenta la prima analisi di sicurezza completa del protocollo x402, rivelando vulnerabilità critiche quali lacune nella progettazione delle firme e race condition che consentono il free-riding e la fuga di risorse nei sistemi di pagamento guidati dall'IA, e propone mitigazioni architettoniche per mettere in sicurezza le transazioni machine-to-machine.

Autori originali: Shengchen Ling, Yihang Huang, Yuan Chen, Yajin Zhou, Lei Wu, Cong Wang

Pubblicato 2026-06-01

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Shengchen Ling, Yihang Huang, Yuan Chen, Yajin Zhou, Lei Wu, Cong Wang

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate un mercato digitale frenetico dove i robot (agenti AI) comprano e vendono servizi tra di loro a una velocità fulminea. Non hanno cassieri o manager umani; si limitano a parlare tra loro e a scambiare monete digitali istantaneamente. Per far sì che questo funzioni, è stato inventato un nuovo sistema chiamato x402. È come un cartello universale di "Pagamento all'ingresso" che i robot possono leggere e rispettare automaticamente.

Tuttavia, questo documento è un rapporto sulla sicurezza che afferma: "Le serrature di questo mercato sono rotte."

I ricercatori hanno scoperto che, poiché il sistema cerca di essere troppo veloce e troppo flessibile, ha creato un "gap" tra il momento in cui un robot dice che pagherà e il momento in cui i soldi arrivano effettivamente. Questo divario permette ad attori malintenzionati di ingannare il sistema per ottenere lavoro gratuitamente.

Ecco una ripartizione dei quattro modi principali in cui avviene questo "Free-Riding" (uso gratuito), utilizzando analogie semplici:

1. Il problema del "Biglietto Sbagliato" (Sostituzione di Risorse Incrociate)

L'Analogia: Immaginate di comprare un biglietto per un film chiamato Matrix. Il biglietto dice: "Un ingresso, $10". Ma il guardiano del cinema controlla solo il prezzo ($10) e non il titolo del film.
Il Difetto: Un hacker compra un biglietto per un film economico (Matrix) ma si presenta all'ingresso della lounge VIP per un film costoso (Dune). Il guardiano vede il biglietto da $10, annuisce e lo lascia entrare.
La Realtà: Nel sistema x402, la "firma" digitale che un robot usa per pagare non specifica rigorosamente quale servizio specifico sta pagando, ma solo quanto e a chi. Un hacker può prendere una prova di pagamento valida per una chiamata API economica e usarla per sbloccare un servizio AI premium e più costoso. Il sistema accetta il denaro ma consegna il prodotto sbagliato (e più prezioso).

2. Il problema della "Doppia Prenotazione" (Duplicazione del Servizio Probabilistica)

L'Analogia: Immaginate un hotel con una reception molto lenta. Vi avvicinate e dite: "Ho una prenotazione". L'impiegato controlla il computer, vede che il vostro nome è libero e dice: "Ottimo, vada alla sua camera!".
Mentre l'impiegato sta ancora digitando la registrazione nel registro principale, tornate alla reception con un amico e dite: "Anch'io ho una prenotazione!". Poiché l'impiegato non ha ancora finito di digitare la prima, il computer risulta ancora "libero" per la seconda persona. Entrambi ottenete una chiave per la camera, ma l'hotel vi ha addebitato un solo soggiorno.
Il Difetto: Il sistema x402 controlla se un pagamento è valido (il "controllo"), ma non blocca immediatamente la transazione affinché nessun altro possa usarla (il "blocco"). Un hacker può inviare la stessa richiesta di pagamento 20 volte in un decimo di secondo. Il server, muovendosi velocemente, dice "Sì" a tutte le 20 richieste prima che la blockchain (il registro principale) abbia il tempo di dire: "Aspetta, quel pagamento è già stato usato!". Il commerciante consegna 20 servizi, ma riceve il pagamento per uno solo.

3. Il problema dell' "Assegno in Bianco" (Sforamento delle Autorizzazioni)

L'Analogia: Immaginate di dare a un cameriere una carta di credito con un limite di $100 e di dire: "Ordina ciò che vuoi, non superare i $100". Il cameriere inizia a ordinare bistecche costose.
Il problema è che il cameriere ordina 10 bistecche prima che la banca abbia il tempo di controllare se avete effettivamente i soldi. Nel momento in cui la banca prova a addebitare la carta, avete già speso $500. La banca rifiuta l'addebito, ma il cameriere ha già servito il cibo. Avete ottenuto il cibo gratis; il ristorante si è fatto carico del costo.
Il Difetto: Nel mondo dell'IA, il costo di un compito non è noto finché non è terminato. Gli hacker impostano un "limite di spesa" (allowance) che è appena sufficiente per superare un controllo rapido. Successivamente, attivano compiti IA massicci ed costosi. Il sistema avvia il lavoro immediatamente (perché il controllo è passato), ma nel momento in cui il conto finale viene calcolato, l'hacker ha speso più del suo limite. La blockchain rifiuta il pagamento, ma l'IA ha già svolto il lavoro.

4. Il problema del "Ingorgo Stradale" (Negazione del Regolamento)

L'Analogia: Immaginate un casello che può elaborare solo 10 auto al minuto. Un hacker invia 50 auto attraverso il cancello tutte in una volta. Il cancello si apre per tutte le 50 perché il controllo di "ingresso" è veloce. Ma quando le auto cercano di pagare al casello alla fine, il casello è sovraccarico e può elaborare solo 10. Le altre 40 auto scappano via senza pagare.
Il Difetto: Il sistema ha un limite su quanti pagamenti può elaborare al secondo. Gli hacker inondano il sistema con richieste. Il server consegna il servizio a tutti loro perché l' "ingresso" è veloce, ma la parte relativa al "pagamento" si intasa. Il server finisce per consegnare servizi gratuiti perché non riesce a elaborare i pagamenti abbastanza velocemente da poter dire "No".

Il Quadro Generale: Perché questo è importante

Il documento sostiene che il sistema x402 sta cercando di fare due cose che non si conciliano bene:

Velocità del Web: Interazioni istantanee, basate sul "fidati di me" (come le richieste HTTP).
Sicurezza della Blockchain: Sicurezza basata sul "verifica tutto prima" (come la finalità della blockchain).

Cercando di unire queste due cose, il sistema ha creato un "gap temporale". In questo gap, gli attori malintenzionati possono infiltrarsi.

Le Soluzioni Proposte

Gli autori suggeriscono alcuni modi per risolvere il problema, dicendo essenzialmente al sistema di essere più prudente:

Legare il biglietto al posto specifico: Assicurarsi che la firma digitale indichi esattamente quale servizio viene acquistato, non solo il prezzo.
Mettere un cartello "Non disturbare" sul registro: Quando un pagamento viene controllato, bloccarlo immediatamente in modo che nessun altro possa usarlo finché non è confermato.
Non servire il cibo finché l'assegno non è saldato: Per i compiti di IA, non trasmettere i risultati all'utente finché il pagamento non è effettivamente confermato. Se il pagamento fallisce, l'utente non riceve nulla.
Controllare la capacità del casello: Se il sistema di pagamento è troppo occupato per elaborare un conto, non far entrare affatto l'auto.

In breve: Il documento rivela che le "rotaie economiche" per gli agenti IA sono attualmente piene di buchi attraverso i quali le persone possono rubare servizi. Per risolvere il problema, dobbiamo smettere di essere così ottimisti riguardo ai pagamenti e iniziare a blindare le procedure, anche se questo renderà le cose leggermente più lente.

Sintesi Tecnica: Free-Riding nell'Economia dell'IA

1. Definizione del Problema

L'emergere dell'economia agent-to-agent (A2A) richiede binari finanziari programmatici capaci di gestire transazioni ad alta frequenza e autonome. Il protocollo x402 è emerso come lo standard de facto per i pagamenti machine-to-machine, utilizzando il codice di stato HTTP 402 "Payment Required" per incorporare istruzioni di pagamento crittografiche direttamente nelle richieste del livello applicativo.

Tuttavia, l'operazionalizzazione di x402 introduce una dissonanza architettonica fondamentale: tenta di collegare cicli di richiesta-risposta HTTP sincroni ed effimeri con la finalità blockchain asincrona e probabilistica. Questo documento sostiene che le attuali implementazioni dell'ecosistema x402 non riescono a garantire invarianti di sicurezza critiche a causa di questo divario di sincronizzazione dello stato. Nello specifico, il disaccoppiamento tra verifica (off-chain) e regolamento (on-chain) crea condizioni di corsa (race conditions) e ambiguità semantiche che permettono agli attaccanti di praticare il "free-riding", costringendo i commercianti a sussidiare i costi di calcolo ed esponendo il sistema a uno sfruttamento economico sistemico.

2. Metodologia

Gli autori impiegano un rigoroso framework di analisi della sicurezza che combina la modellazione formale e la validazione empirica:

Modellazione Formale del Sistema: Il flusso di lavoro del pagamento è modellato come un sistema di transizione di stato che coinvolge quattro entità: Shopper ( $S$ ), Merchant ( $M$ ), Facilitator ( $F$ ) e Blockchain ( $B$ ).
Invarianti di Sicurezza: Gli autori definiscono cinque Invarianti di Sicurezza fondamentali che un'implementazione sicura deve rispettare:
1. Integrità del Pagamento (I1): La consegna implica un regolamento on-chain confermato.
2. Consistenza del Valore (I2): Il valore della transazione deve soddisfare la logica di pricing delle risorse.
3. Vincolo di Contesto (I3): L'autorizzazione al pagamento deve essere crittograficamente legata all'identificatore specifico della risorsa.
4. Unicità dell'Autorizzazione (I4): Un nonce di pagamento deve essere consumato esattamente una volta.
5. Conservazione dell'Esecuzione (I5): Il lavoro computazionale significativo non deve essere avviato a meno che il pagamento non sia garantito.
Analisi delle Vulnerabilità: Gli autori analizzano la specifica del protocollo e sottopongono a audit gli SDK ufficiali (TypeScript, Python, Java, Go) e i middleware deployment live (Thirdweb, Coinbase).
Validazione Empirica: Sono stati condotti esperimenti controllati su molteplici testnet (Base Sepolia, Solana Devnet, Arbitrum Sepolia) e contro i deployment ufficiali per quantificare i tassi di successo degli attacchi identificati.

3. Risultati Chiave e Vulnerabilità

L'analisi rivela che le attuali implementazioni violano sistematicamente le invarianti definite, portando a tre classi primarie di vulnerabilità:

A. Sostituzione di Risorsa Cross-Resource (Violazione I3)

Meccanismo: Il design del protocollo x402 si basa su firme EIP-712 che legano i fondi a un indirizzo del merchant ma sono agnostici rispetto al contesto riguardo all'identificatore specifico della risorsa ( $ID_r$ ).
Difetto: Gli SDK ufficiali non legano crittograficamente la firma al contesto della richiesta HTTP (URI, metodo, corpo).
Exploit: Un attaccante può generare una firma di pagamento valida per una risorsa a basso valore o non protetta ( $r_A$ ) e utilizzarla per accedere a una risorsa diversa, di alto valore o protetta ( $r_B$ ), con lo stesso prezzo.
Risultato: Negli esperimenti, ciò ha portato a un tasso di successo del 100% nella sostituzione delle risorse. In scenari concorrenti, ha permesso la "duplicazione del servizio" dove un singolo pagamento ha sbloccato più risorse.

B. Duplicazione del Servizio Probabilistica (Violazione I4)

Meccanismo: Esiste una condizione di corsa Time-of-Check to Time-of-Use (TOCTOU) tra la verifica off-chain di un nonce e il suo regolamento on-chain.
Difetto: La logica di verifica del Facilitator è stateless e di sola lettura; non blocca il nonce.
Exploit: Un attaccante trasmette $N$ richieste concorrenti con lo stesso payload firmato. Molteplici thread del server verificano il nonce come "non utilizzato" simultaneamente prima che il primo thread aggiorni con successo lo stato sulla blockchain.
Risultato: Il merchant eroga il servizio $N$ volte, ma viene regolata on-chain una sola transazione. Gli esperimenti sulla testnet Base Sepolia hanno dimostrato un tasso di successo del 6% per la duplicazione del servizio, ponendo un rischio di arbitraggio scalabile per gli agenti IA ad alta frequenza.

C. Drift di Stato Specifici per l'IA (Violazione I2 e I5)

Nel dominio dell'inferenza IA, il passaggio a un pricing dinamico (utilizzando schemi di autorizzazione "upto") esacerba le vulnerabilità:

Overdraft dell'Allowance: Poiché il costo dell'inferenza LLM è ignoto fino al completamento, i merchant devono verificare un limite di spesa ( $V_{max}$ $V_{ma x}$ ) piuttosto che un importo esatto. Gli attaccanti sfruttano la mancanza di locking atomico sull'allowance. Lanciando $N$ $N$ richieste concorrenti dove $\sum v_i \gg V_{max}$ $\sum v_{i} ≫ V_{ma x}$ , l'attaccante consuma le risorse per tutte le richieste. La blockchain annulla le transazioni in eccesso, ma il merchant ha già consegnato l'output computazionale.
- Impatto: Gli esperimenti hanno mostrato un rapporto di perdita ( $\rho$ ) fino al 97,76%, il che significa che gli attaccanti hanno ricevuto quasi il 100% delle risorse computazionali pagando solo una frazione del costo.
Negazione del Regolamento: Gli attaccanti possono inondare il sistema con richieste valide che superano i limiti di velocità di regolamento del Facilitator (es. 10 tx/s). Lo strato di verifica accetta il burst, e il merchant fornisce il servizio, ma l'API di regolamento rifiuta le transazioni in eccesso.
- Impatto: In casi estremi, ciò ha portato a un rapporto di perdita del 100%, dove il merchant ha fornito il servizio completo a costo zero.

4. Mitigazioni Proposte

Il paper propone quattro strategie di difesa gerarchiche per ripristinare le invarianti di sicurezza:

Vincolo del Contesto Crittografico: Estendere gli schemi EIP-712 per includere un hash dell'intera richiesta HTTP (Metodo, URI, Corpo) nella firma. Ciò elimina il divario semantico, rendendo le firme invalide se riutilizzate contro risorse diverse.
Linearizzazione dei Nonce Stateful: Implementare un modello "Check-and-Set" a livello di Facilitator utilizzando lock distribuiti (es. SETNX). Ciò assicura che anche se più thread verificano un nonce, solo il primo ad acquisire il lock procede al regolamento, eliminando le race conditions.
Consegna Pessimistica delle Risorse:
- Consegna Differita: Bufferizzare l'output dell'inferenza IA fino a quando il regolamento non è confermato. Ciò neutralizza l'incentivo economico al furto (l'attaccante non ottiene alcun dato se il pagamento fallisce).
- Two-Phase Locking: Per scenari ad alto rischio, trasferire il cap massimo in un contratto di escrow prima dell'esecuzione per atomizzare il controllo dell'allowance.
- Anti-Griefing Crittoeconomico: Richiedere agli agenti di mettere in staking un "gas bond" per coprire potenziali revert di regolamento, riducendo lo stake se l'agente tenta di fare griefing al merchant.
Design Failure-Closed: Sincronizzare i limiti di velocità e i controlli di fatturazione con l'ingresso delle richieste. Se la capacità di regolamento è superata, la richiesta dovrebbe essere rifiutata immediatamente (429) invece di essere elaborata e consegnata gratuitamente.

5. Significatività e Rivendicazioni

Il paper sostiene di essere la prima analisi di sicurezza completa dell'ecosistema x402. La sua significatività risiede nel:

Identificare il Rischio Sistemico: Dimostra che la dissonanza architettonica tra i protocolli web e le blockchain non è un semplice bug di implementazione, ma un difetto strutturale che mina il modello di fiducia economica dell'economia degli agenti.
Formalizzare le Invarianti di Sicurezza: Stabilisce un framework formale (le cinque invarianti) necessario per proteggere i sistemi ibridi agentici, fornendo una base per il futuro design dei protocolli.
Esporre la Minaccia del "Free-Riding": Quantifica come gli attuali modelli di pricing dinamico nell'IA possano essere trasformati in armi per costringere i merchant a sussidiare i costi di calcolo su larga scala, minacciando la sostenibilità dell'economia dell'IA.
Disclosure Responsabile: Tutti i problemi identificati sono stati comunicati a Coinbase e Thirdweb, evidenziando la necessità immediata di un passaggio da una "rilassatezza ergonomica" a un "vincolo crittografico rigoroso".

Gli autori concludono che senza l'adozione di middleware state-aware e meccanismi di locking pessimistici, l'economia dell'IA rischia di costruire la propria fondazione finanziaria su binari soggetti a un free-riding sistemico.