L'XRP Ledger ha un tetto massimo invalicabile di 100 miliardi di XRP. Per circa undici anni, quel tetto è stato un semplice suggerimento. Il 9 ottobre 2026, la XRPL Foundation ha pubblicato un report di divulgazione che conferma come una singola transazione costruita ad arte avrebbe potuto creare circa 18,4 trilioni di XRP spendibili, circa 184 volte l'offerta totale, e che il codice che lo permetteva era presente nel motore di pagamento da novembre 2015. Il bug è stato trovato da un agente IA, corretto in tre giorni e distribuito in un modo che il ledger non aveva mai usato prima. Nessuno l'ha sfruttato. Questa è la buona notizia. Tutto il resto della storia merita un'analisi più approfondita.
Cosa faceva realmente il bug di overflow dell'XRP Ledger
Il difetto risiedeva nella parte del motore di pagamento che gestisce un pagamento che attraversa un order book. Quando un singolo pagamento consuma molte offerte contemporaneamente, il motore somma gli importi che deve a ciascun proprietario dell'offerta. Quella somma utilizzava semplici interi con segno a 64 bit senza alcun controllo di overflow. Spingi il totale oltre 2 elevato alla 64 e il contatore si avvolge su un numero piccolo, come il contachilometri di un'auto che passa da 999999 a 000000.
Ecco la parte brutta. Il motore addebitava all'acquirente il totale avvolto, che era minuscolo. Pagava a ciascun proprietario dell'offerta il suo importo completo, non avvolto. La differenza tra questi due numeri è XRP che non esisteva un attimo prima.
Il ledger ha effettivamente una rete di sicurezza proprio per questo. Un controllo di invariante chiamato XRPNotCreated viene eseguito dopo ogni transazione e rifiuta di validare qualsiasi cosa che aumenti il totale di XRP. Il problema è che l'invariante tracciava la variazione netta di XRP usando la stessa aritmetica a 64 bit non controllata. Un credito abbastanza grande avvolgeva anche il contatore dell'invariante, così una transazione che stampava trilioni di XRP appariva, al controllo di sicurezza, come un normale consumo di commissioni. Due bug indipendenti, scritti a due anni di distanza, annullavano a vicenda la loro protezione.
Come 256 offerte si sommano a 18 trilioni di XRP
Veria Labs, la società di sicurezza il cui agente IA ha trovato il bug, ha pubblicato l'aritmetica. L'attacco utilizzava 256 offerte. Ogni offerta veniva venduta per 2 elevato alla 56, più un drop di XRP. Moltiplica 256 per quella cifra e il totale arriva esattamente a 2 elevato alla 64, più 256 drop. Il singolo drop extra per offerta è importante: senza di esso la somma si avvolge esattamente a zero, che il motore rifiuterebbe come pagamento a vuoto. Con esso, all'acquirente vengono addebitati 256 drop, circa 0,000256 XRP, mentre i 256 proprietari delle offerte ricevono collettivamente 2 elevato alla 64 drop. Sono 18.446.744.073.709.551.616 drop, ovvero circa 18,45 trilioni di XRP.
L'attaccante aveva bisogno di 256 account finanziati perché ogni account XRPL è limitato a 100 miliardi di XRP, ben al di sotto dell'importo per offerta diviso su un singolo account. Aveva anche bisogno di qualche centinaio di XRP in riserve e commissioni di transazione, tutto recuperabile. Non era richiesto alcun accesso da validatore. L'attacco poteva essere ripetuto con account nuovi. Veria ha stimato il valore a rischio in circa 94 miliardi di dollari, più di sessanta volte il furto Bybit da 1,5 miliardi di dollari che attualmente detiene il record per un hack crypto realmente avvenuto.
| Ingrediente | Valore | Perché è importante |
|---|---|---|
| Offerte consumate in un pagamento | 256 | Sotto il limite di 1.000 offerte per attraversamento del book |
| Prezzo per offerta | 2^56 + 1 drop | Resta sotto il limite di 100 miliardi di XRP per account |
| Totale calcolato dal motore | 2^64 + 256 drop | Si avvolge a 256 drop in aritmetica a 64 bit |
| Cosa ha pagato l'acquirente | 256 drop (0,000256 XRP) | Il valore avvolto |
| Cosa hanno ricevuto i venditori | Circa 18,45 trilioni di XRP | Il valore non avvolto, 184 volte l'offerta totale |
| Costo per l'attaccante | Qualche centinaio di XRP, recuperabile | Riserve più commissioni |
| Accesso da validatore necessario | Nessuno | Qualsiasi account finanziato poteva farlo |
Un agente IA l'ha trovato un lunedì sera
Il reporter ufficiale è Cayden Liao di Veria Labs, con l'agente IA dell'azienda accreditato al suo fianco. Secondo il resoconto di Veria, l'agente è stato puntato sul codebase rippled il 21 settembre, ha segnalato entrambi gli overflow, ha capito che potevano essere concatenati e ha prodotto un proof of concept funzionante su una rete locale. Un ingegnere fondatore è stato svegliato alle 4 del mattino per verificarlo. Entro la mattina del 22 settembre il team era abbastanza sicuro da presentarlo attraverso il programma XRPL Bug Bounty, valutandolo Major. RippleX l'ha riprodotto lo stesso giorno e l'ha elevato a Critical. Realisticamente, Veria sostiene che agenti di coding generici puntati sullo stesso codice dopo la divulgazione non siano riusciti a trovarlo. Prendetelo con il solito grano di sale da un'azienda che vende lo strumento che ce l'ha fatta. Il punto più ampio resta comunque valido. Il codice di aggregazione BookStep risale a novembre 2015 e l'invariante XRPNotCreated a febbraio 2017. L'XRPL ha pagato oltre 1 milione di dollari in bounty e ha eseguito più di una dozzina di audit e contest di audit dal 2024. Umani e società di audit hanno esaminato questo codice per un decennio e non l'hanno visto. Lo schema sta diventando familiare. Coldcard ha perso circa 1.367 BTC quest'estate a causa di un bug firmware vecchio di cinque anni che il suo produttore sospetta sia stato trovato con l'assistenza dell'IA. Il vecchio codice non è più sicuro solo perché è vecchio.Perché la correzione ha saltato il voto dei validatori
Qui è dove la storia smette di essere una vittoria di sicurezza pulita e diventa una discussione di governance. L'XRP Ledger normalmente modifica le regole di transazione attraverso emendamenti. Una nuova regola viene distribuita nel software disattivata, i validatori la votano e si attiva solo dopo aver mantenuto più dell'80 percento di supporto sulla Unique Node List predefinita per due settimane consecutive. Il sistema è in vigore da oltre un decennio e non è mai stato deliberatamente aggirato per una modifica all'elaborazione delle transazioni.
Fino al 25 settembre. La correzione dell'overflow è stata distribuita direttamente in xrpld 3.4.1 senza gate di emendamento. Ha avuto effetto su ogni server nel momento in cui quel server si è aggiornato. Il ragionamento della XRPL Foundation è semplice: un voto di emendamento avrebbe pubblicato la correzione, e quindi il bug, per due settimane prima che entrasse in vigore. Chiunque leggesse il diff avrebbe avuto quindici giorni per stampare 18 trilioni di XRP. La Foundation afferma che la decisione è stata presa congiuntamente da essa stessa, RippleX, gli sviluppatori core e i validatori, e che nessuna singola parte avrebbe potuto prendere la decisione da sola.
L'approccio comportava un rischio proprio, che il report di divulgazione ammette. Se qualcuno avesse tentato l'exploit mentre la rete era divisa tra server corretti e non corretti, i due gruppi non sarebbero stati d'accordo sullo stato del ledger. Nel peggiore dei casi, la rete si ferma. Il team ha giudicato un possibile blocco preferibile a una certa esplosione dell'offerta, cosa difficile da contestare. Più dell'80 percento dei validatori UNL predefiniti eseguiva la 3.4.1 entro poche ore dal rilascio del 25 settembre.
| Data | Evento |
|---|---|
| Nov 2015 | Codice di somma delle offerte BookStep scritto con addizione a 64 bit non controllata |
| Feb 2017 | Aggiunta l'invariante XRPNotCreated, usando la stessa aritmetica non controllata |
| 21 Set 2026 | L'agente IA di Veria Labs segnala entrambi gli overflow e li concatena |
| 22 Set 2026 | Segnalato tramite XRPL Bug Bounty, riprodotto da RippleX, elevato a Critical |
| 23 Set 2026 | Correzione unita privatamente al release candidate 3.4.1 |
| 25 Set 2026 | Rilasciato xrpld 3.4.1, oltre l'80 percento dei validatori UNL predefiniti aggiornati |
| 8 Ott 2026 | Veria Labs riceve il bounty massimo di 250.000 dollari |
| 9 Ott 2026 | Pubblicato il report di divulgazione pubblica, si attiva l'emendamento Batch fix |
| 12 Ott 2026 | ZachXBT definisce pubblicamente il bounty troppo basso |
La battaglia sulla decentralizzazione che ne è seguita
In breve, Justin Bons di Cyber Capital, critico di lunga data di XRP, ha usato l'episodio per sostenere che pubblicizzare XRP al retail come decentralizzato equivale a frode. Le sue lamentele specifiche: il rilascio del 25 settembre è stato distribuito solo come binari compilati, con il codice sorgente temporaneamente trattenuto, e gli operatori sono stati pressati ad aggiornare un binario che non potevano ispezionare. Il report di divulgazione dell'XRPL conferma che il sorgente è stato pubblicato in seguito, anche se non dice quando.
In pratica, la controargomentazione è venuta tanto dagli operatori di validatori indipendenti quanto dalla Foundation. XRP Kuwait, che gestisce il proprio nodo, l'ha riassunta così: coordinamento non è la stessa cosa di controllo. Gli operatori indipendenti hanno letto lo stesso avviso, sono giunti alla stessa conclusione e si sono aggiornati. Nessuno li ha obbligati. Bitcoin ha fatto la stessa cosa, in particolare con il bug dell'inflazione del 2018 in Bitcoin Core 0.16.x, quando gli sviluppatori hanno distribuito silenziosamente una correzione prima di spiegare cosa correggeva. Ogni catena con un bug serio prima o poi affronta la scelta tra trasparenza e sopravvivenza, e ognuna di esse ha scelto la sopravvivenza. Alla fine, dove Bons ha un punto valido è sui binari. Distribuire un binario non verificabile e chiedere ai validatori di eseguirlo immediatamente è un esercizio di fiducia, per quanto giustificato. La versione onesta della posizione dell'XRPL è che il suo set di validatori si è fidato abbastanza della Foundation e di RippleX da eseguire codice non revisionato per qualche giorno. Che tu lo chiami decentralizzato dipende da cosa pensi che significhi quella parola.
250.000 dollari erano abbastanza per un bug da 94 miliardi?
Veria Labs ha ricevuto il pagamento di livello critico massimo del programma XRPL di 250.000 dollari l'8 ottobre. Veria l'ha definito probabilmente il bounty più grande mai pagato per un bug trovato interamente da un agente IA. Quattro giorni dopo, l'investigatore blockchain ZachXBT l'ha definito una barzelletta. Il suo argomento: un ecosistema il cui tesoro detiene miliardi ha pagato un quarto di milione per una scoperta che avrebbe potuto porre fine all'asset. E quel divario è esattamente l'incentivo che spinge il prossimo ricercatore a vendere a un attaccante invece. Ha suggerito sette cifre come soglia minima e ha citato una ricompensa a sette cifre presumibilmente pagata nell'ecosistema Zcash per un recente bug di contraffazione. Né Ripple né la Foundation avevano risposto pubblicamente al momento della scrittura.
Entrambe le parti hanno ragione su cose diverse. Il programma ha pagato il suo massimo pubblicizzato, il ricercatore ha divulgato responsabilmente e la correzione è arrivata prima che qualcuno fuori dal giro lo sapesse. Questo è il sistema che funziona. È anche vero che 250.000 dollari sono lo 0,27 percento dei 94 miliardi a rischio, e che qualsiasi attaccante con 256 account e qualche centinaio di XRP avrebbe potuto prendersi l'altro 99,73 percento. I tetti dei bounty scritti quando XRP valeva una frazione del suo attuale valore di mercato non scalano con la cosa che proteggono.
Cosa dovrebbero trarre da questo i detentori di XRP e i giocatori crypto
La correzione è lato server. Il tuo wallet, le tue chiavi e il tuo saldo non sono mai stati coinvolti e nulla deve essere aggiornato da parte tua. Il tetto dell'offerta ha tenuto perché il bug è stato catturato, non perché l'invariante funzionasse. La seconda metà di quella frase è quella che vale la pena ricordare.
Ci sono tre lezioni pratiche qui. Primo, il codice è stato live per dieci anni ha smesso di essere un argomento di sicurezza. L'auditing assistito dall'IA sta rendendo i vecchi overflow economici da trovare, e gli attaccanti noleggiano gli stessi modelli dei ricercatori. Secondo, i processi di governance progettati per i rollout di funzionalità non sono progettati per le patch critiche. E ogni catena dovrebbe decidere in anticipo come gestirà la prossima invece di improvvisare sotto pressione. Terzo, i tetti dei bug bounty dovrebbero seguire il valore protetto. Un tetto fisso che sembrava generoso nel 2022 è un invito nel 2026. Inoltre, per il pubblico del gioco d'azzardo la rilevanza è semplice. XRP è diventato un binario di deposito standard nei casinò crypto perché si regola in quattro secondi per una frazione di centesimo. E quella velocità dipende dal fatto che le regole del ledger siano corrette. Le piattaforme che automatizzano i pagamenti, incluso CryptoCasino.Vegas, si fidano delle invarianti della catena ogni volta che un prelievo XRP viene liquidato senza che un umano lo guardi. Quelle invarianti hanno tenuto questa volta grazie a un ricercatore e a un agente IA che hanno lavorato tutta la notte, e questo è un margine più sottile di quanto il tetto di 100 miliardi abbia mai lasciato intendere.
L'analisi tecnica completa, incluse entrambe le posizioni degli overflow e l'aritmetica rafforzata che le ha sostituite, è nel report di divulgazione delle vulnerabilità della XRPL Foundation per xrpld 3.4.1.
