La trappola della fiducia nei protocolli aperti: perché x402 ha bisogno di un livello di responsabilità centralizzato?

Il protocollo di pagamento x402 ha rivelato 31 nuove vulnerabilità, con il 99% delle transazioni a rischio di furto di asset.

Autore: @Jun__Yoo

Traduzione: AididiaoJP, Foresight News

Akiba di CryptoSlate (@akibablade) ha recentemente pubblicato un articolo intitolato "31 nuove vulnerabilità rendono il 99% dei pagamenti crittografici x402 a rischio di furto di asset e acquisti gratuiti".

Questo articolo si basa su un documento intitolato "Quando HTTP 402 incontra la blockchain: i rischi emergenti dei pagamenti x402", che è stato accettato e sarà presentato alla conferenza USENIX Security 2026.

Il documento si concentra su come x402 delega la verifica delle prove di pagamento e la liquidazione on-chain a un facilitatore di terze parti. Questo design concentra la fiducia e la logica di verifica su un'infrastruttura di pagamento condivisa da più commercianti indipendenti. Se un facilitatore presenta vulnerabilità, ciò può influenzare un gran numero di servizi.

I ricercatori hanno anche definito otto regole di sicurezza che i facilitatori devono seguire. La violazione di queste regole può innescare quattro tipi di attacchi: acquisti gratuiti, furto di asset, negazione del servizio e abuso di Gas. Hanno valutato 15 principali facilitatori, scoprendo 49 violazioni delle regole e 31 vulnerabilità precedentemente sconosciute. I risultati sono stati divulgati privatamente agli operatori interessati. Alcuni problemi sono stati risolti, mentre il lavoro di riparazione per gli altri è in corso.

Questa ricerca è stata possibile perché x402 è stato sviluppato come protocollo aperto fin dall'inizio. Le specifiche del protocollo e il SDK di riferimento sono pubblici, consentendo ai ricercatori di dedurre le regole di sicurezza del processo di pagamento. Hanno completato la ricerca utilizzando un SDK open source e un negozio di test costruito autonomamente.

L'open source non elimina le vulnerabilità, ma offre un percorso affinché i difetti scoperti esternamente possano essere trasformati in standard di sicurezza condivisi. Il protocollo x402 è stato trasferito alla Linux Foundation il 2 aprile e la x402 Foundation è stata ufficialmente avviata il 14 luglio, con 40 membri. Questo ha fornito un forum ufficiale per discutere i risultati delle scoperte a livello di specifiche e implementazione di riferimento, non più limitato alle patch di un singolo fornitore.

I ricercatori hanno anche rilasciato una versione pubblica di x402scope, rimuovendo il codice di sfruttamento sensibile. Stanno discutendo con Coinbase e altri principali attori dell'ecosistema su come integrare il loro controllo delle regole nei processi di verifica prima dello sviluppo e del deployment.

La discussione sulla maturità del protocollo si ferma qui. Vorrei porre una domanda più fondamentale basata su queste scoperte.

Invece di centralizzare x402 stesso, un protocollo aperto ha bisogno di un livello di responsabilità centralizzato per far rispettare gli standard di verifica e assumere i costi e le perdite derivanti da eventi di sicurezza?

La centralizzazione non equivale automaticamente a sicurezza. Ma nel campo dei pagamenti, chi esercita il potere dovrebbe anche sopportare il costo del fallimento.

Diamo un'occhiata a come funziona realmente x402. Chiunque può gestire un server o diventare un facilitatore. Ma il sistema non è completamente privo di fiducia. Il documento definisce anche il facilitatore come "un intermediario che assume fiducia". Una volta che la verifica e la liquidazione vengono delegate, l'utente deve riporre un certo grado di fiducia nel facilitatore.

Il problema è che la fiducia è centralizzata, ma il protocollo non richiede capitale, meccanismi di responsabilità o certezza di pagamento corrispondenti. Questa lacuna si manifesta in tre parti del design.

Primo, la verifica sembra più una previsione di "questa liquidazione è ancora fattibile" piuttosto che un'autorizzazione come quella delle carte di credito. Controlla firme, saldi, nonce e scadenze, ma non blocca i fondi né consuma nonce.

Secondo, la separazione di verify → logica aziendale → settle (liquidazione) è intesa a proteggere i consumatori e i commercianti. Il protocollo non ha un meccanismo per legare la verifica e la liquidazione attraverso uno stato condiviso. Se un commerciante agisce sulla base del risultato di verifica del facilitatore e la successiva liquidazione fallisce, il commerciante deve sopportare tutte le perdite.

Terzo, molti facilitatori sponsorizzano i costi di liquidazione on-chain. Gli attaccanti possono manipolare il percorso di esecuzione, costringendo il facilitatore a pagare le spese di Gas risultanti. Su Solana, gli attaccanti potrebbero persino indurre il facilitatore a pagare l'affitto per un conto controllato dall'attaccante.

I pagamenti con carta di credito separano anche autorizzazione e addebito. La differenza è che l'emittente della carta riserva una parte del credito o dei fondi del titolare della carta durante l'autorizzazione. Le regole della rete forniscono quindi un certo grado di certezza di pagamento per il commerciante. Se ci sono problemi, ci sono procedure di revoca dell'autorizzazione, chargeback, sanzioni per i commercianti e risoluzione delle controversie disponibili.

x402 non ha un emittente che blocchi i fondi e garantisca il pagamento. I server quindi controllano la fattibilità del pagamento tramite verify, eseguono la logica aziendale e poi chiamano settle. Il problema è che le due estremità non condividono uno stato. Dopo la verifica, il saldo, il nonce o la scadenza possono cambiare. Se il server esegue un'operazione irreversibile prima della liquidazione, il commerciante potrebbe subire perdite. Se il facilitatore invia una transazione manipolata, potrebbe perdere Gas o asset di sua proprietà.

Le reti di carte hanno sostenuto questo costo di fiducia attraverso il capitale dell'emittente e i team di gestione del rischio, recuperando poi i costi tramite commissioni. x402 ha rimosso quel ruolo, ma non ha eliminato i costi.

Pertanto, è necessario stabilire un livello di responsabilità sopra il protocollo aperto?

Questa centralizzazione non significa consegnare l'intero protocollo x402 a un singolo operatore. Ogni percorso di pagamento dovrebbe avere un soggetto responsabile chiaramente definito. Più operatori possono comunque competere sotto lo stesso standard aperto, e gli utenti possono cambiare facilitatore. Questa struttura concentra la responsabilità operativa, mantenendo al contempo l'apertura del protocollo e la concorrenza tra fornitori.

Il Monetization Gateway di Cloudflare è un possibile esempio. Mantiene il formato di pagamento programmabile di x402, mentre gestisce le politiche di pagamento, la verifica e il controllo degli accessi a un livello di controllo unico. Un'altra strada è utilizzare facilitatori specializzati, che offrono accordi di livello di servizio, limiti di Gas, verifica prima della liquidazione e risposta agli eventi.

ERC-8004 e i sistemi di reputazione sembrano offrire alternative. Ma la reputazione è solo un segnale aggiuntivo per valutare il rischio, non riserva fondi né fornisce garanzie di pagamento. Credo che la reputazione da sola non possa colmare la lacuna di responsabilità.

Questa prospettiva richiede anche una rivalutazione del ruolo e della struttura del livello di scoperta. Questo livello può andare oltre il semplice elenco dei servizi disponibili, diventando un livello di fiducia e instradamento, filtrando quali risorse e facilitatori soddisfano gli standard di sicurezza stabiliti. Se è necessaria una garanzia di pagamento, può chiaramente distinguere tra operatori centralizzati che forniscono garanzie e percorsi di pagamento. Da questo punto di vista, ci sono due attori chiave da tenere d'occhio:

La strategia di integrazione di CDP (@CoinbaseDev) combina Agentic Wallet, CDP Facilitator e Bazaar, fornendo funzionalità di portafoglio, pagamento, conformità e scoperta all'interno di uno stack tecnologico.

La strategia di integrazione di Orthogonal (@orthogonal_sh) unisce scoperta dei servizi, pool di chiavi API, standardizzazione delle risposte e fatturazione sotto un unico account, un saldo e una fattura. Supporta crediti, x402 e MPP. Questo riduce la complessità di gestire più fornitori e metodi di pagamento in un gateway centrale.

Queste strategie non parlano ancora di garanzia di pagamento o assorbimento delle perdite. Ma pongono le funzionalità frammentate di portafoglio, verifica, fatturazione e scoperta sotto un unico operatore, fornendo una base per un livello di responsabilità centralizzato.

Se un livello di responsabilità centralizzato diventa comune, la struttura dei pagamenti stessa potrebbe cambiare. Un possibile modello è sostituire verify → logica aziendale → settle con verify → settle → logica aziendale.

L'ordine attuale protegge i consumatori, a condizione che la liquidazione sia irreversibile. Una volta che l'operatore accetta la responsabilità per rimborsi e risoluzione delle controversie, questa ipotesi cambierà. Si può prima confermare la liquidazione, eliminando il rischio di pagamento non ricevuto per il commerciante. Se l'esecuzione successiva fallisce, l'operatore può rimborsare il consumatore. L'operatore deve quindi affrontare le esigenze di liquidità e gli obblighi di liquidazione prima della liquidazione finale, rendendo la sua struttura di capitale e responsabilità ancora più importante.

Questo modello non segue l'attuale processo di liquidazione per transazione di x402. x402 continuerà a fungere da interfaccia aperta per comunicare i termini di pagamento e i dati di autorizzazione. Gli operatori aggregano i flussi di fondi reali e completano la liquidazione finale on-chain. I record di pagamento singoli rimangono nel libro mastro interno dell'operatore, mentre la blockchain registra la liquidazione finale aggregata. Poiché il libro mastro interno è reversibile, questa struttura riduce il problema dei pagamenti irreversibili. Gli operatori possono anche gestire rimborsi e controversie come gli emittenti di carte.

Alcuni potrebbero chiedere:

Non è questo considerare la blockchain come un database di pagamento condiviso?

Sì.

Più precisamente, la blockchain diventerà un libro mastro di liquidazione condiviso che registra i saldi finali tra gli operatori. I singoli pagamenti rimarranno al di fuori della catena. Almeno in questo mercato, svolgere in modo affidabile questo ruolo potrebbe essere già sufficiente. Il sistema può comunque sfruttare i vantaggi dei bassi costi di liquidazione e delle valute programmabili.

Questo contenuto è fornito a solo scopo informativo generale e non costituisce consulenza finanziaria, di investimento, legale o fiscale. Qualsiasi evento, ricompensa, promozione online o informazione correlata menzionata nel presente documento non deve essere considerata una raccomandazione, una sollecitazione o un invito ad acquistare, vendere, fare trading o altrimenti negoziare criptovalute. Le criptovalute sono altamente volatili e possono comportare perdite. La disponibilità dei servizi, dei prodotti e degli eventi correlati di WEEX può variare a seconda della regione. È tua responsabilità assicurarti che la tua partecipazione sia conforme alle leggi e ai regolamenti locali applicabili.