De XRP Ledger heeft een harde limiet van 100 miljard XRP. Ongeveer elf jaar lang was die limiet een suggestie. Op 9 oktober 2026 publiceerde de XRPL Foundation een onthullingsrapport dat bevestigde dat één enkele vervaardigde transactie ongeveer 18,4 biljoen besteedbare XRP had kunnen creëren, ongeveer 184 keer de totale voorraad, en dat de code die dit mogelijk maakte sinds november 2015 in de betalingsengine zat. De bug werd gevonden door een AI-agent, binnen drie dagen gepatcht en uitgerold op een manier die de ledger nog nooit had gebruikt. Niemand heeft het misbruikt. Dat is het goede nieuws. Al het andere in dit verhaal verdient een nadere blik.
Wat de XRP Ledger overflow-bug precies deed
De fout zat in het deel van de betalingsengine dat een betaling afhandelt die een orderboek doorkruist. Wanneer één betaling veel aanbiedingen tegelijk verbruikt, telt de engine de bedragen op die het aan elke aanbiedingshouder verschuldigd is. Die optelling gebruikte gewone 64-bits signed integers zonder overflow-controle. Duw het totaal voorbij 2 tot de macht 64 en de teller slaat terug naar een klein getal, zoals een kilometerteller van 999999 terugrolt naar 000000.
Hier komt het lelijke deel. De engine rekende de koper het omgeslagen totaal aan, dat minuscuul was. Aan elke aanbiedingshouder betaalde het hun volledige, niet-omgeslagen bedrag. Het verschil tussen die twee getallen is XRP dat een moment eerder niet bestond.
De ledger heeft wel een vangnet voor precies dit. Een invariant-controle genaamd XRPNotCreated draait na elke transactie en weigert alles te valideren dat de totale XRP-voorraad verhoogt. Het probleem is dat de invariant de netto XRP-verandering bijhield met dezelfde ongecontroleerde 64-bits rekenkunde. Een voldoende grote credit sloeg ook de invariant-teller om, zodat een transactie die biljoenen XRP drukte er voor de veiligheidscontrole uitzag als een routine fee-verbranding. Twee onafhankelijke bugs, twee jaar na elkaar geschreven, hieven elkaars bescherming op.
Hoe 256 aanbiedingen optellen tot 18 biljoen XRP
Veria Labs, het beveiligingsbedrijf wiens AI-agent de bug vond, publiceerde de rekensom. De aanval gebruikte 256 aanbiedingen. Elk aanbod werd verkocht voor 2 tot de macht 56, plus één drop XRP. Vermenigvuldig 256 met dat cijfer en het totaal komt precies uit op 2 tot de macht 64, plus 256 drops. De extra enkele drop per aanbod is belangrijk: zonder die drop slaat de som om naar precies nul, wat de engine zou weigeren als een droge betaling. Met die drop wordt de koper 256 drops aangerekend, ongeveer 0,000256 XRP, terwijl de 256 aanbiedingshouders gezamenlijk 2 tot de macht 64 drops ontvangen. Dat is 18.446.744.073.709.551.616 drops, oftewel ongeveer 18,45 biljoen XRP.
De aanvaller had 256 gefinancierde accounts nodig, omdat elk XRPL-account beperkt is tot 100 miljard XRP, ruim onder het bedrag per aanbod verdeeld over één account. Er was ook een paar honderd XRP nodig aan reserves en transactiekosten, allemaal terug te vorderen. Validator-toegang was niet vereist. De aanval kon worden herhaald met nieuwe accounts. Veria schatte de waarde die op het spel stond op ongeveer $94 miljard, meer dan zestig keer de $1,5 miljard Bybit-diefstal die momenteel het record houdt voor een crypto-hack die daadwerkelijk heeft plaatsgevonden.
| Ingrediënt | Waarde | Waarom het belangrijk is |
|---|---|---|
| Aanbiedingen verbruikt in één betaling | 256 | Onder de limiet van 1.000 aanbiedingen per boekdoorloop |
| Prijs per aanbod | 2^56 + 1 drops | Blijft onder de limiet van 100 miljard XRP per account |
| Totaal dat de engine berekende | 2^64 + 256 drops | Slaat om naar 256 drops in 64-bits rekenkunde |
| Wat de koper betaalde | 256 drops (0,000256 XRP) | De omgeslagen waarde |
| Wat verkopers ontvingen | Ongeveer 18,45 biljoen XRP | De niet-omgeslagen waarde, 184x totale voorraad |
| Kosten voor de aanvaller | Een paar honderd XRP, terug te vorderen | Reserves plus kosten |
| Benodigde validator-toegang | Geen | Elk gefinancierd account kon het doen |
Een AI-agent vond het op een maandagavond
De officiële melder is Cayden Liao van Veria Labs, met de AI-agent van het bedrijf als mede-crediteur. Volgens Veria's eigen verslag werd de agent op 21 september op de rippled-codebase gericht, markeerde beide overflows, werkte uit dat ze gekoppeld konden worden en produceerde een werkend proof of concept op een lokaal netwerk. Een van de oprichtende engineers werd om 4 uur 's ochtends gewekt om het te controleren. Tegen de ochtend van 22 september was het team zeker genoeg om het in te dienen via het XRPL Bug Bounty-programma, met de classificatie Major. RippleX reproduceerde het dezelfde dag en verhoogde het naar Critical. Veria claimt dat algemene coding-agents die na de onthulling op dezelfde code werden gericht het niet konden vinden. Neem dat met het gebruikelijke korreltje zout van een bedrijf dat de tool verkoopt die het deed. Het bredere punt staat hoe dan ook. De BookStep-aggregatiecode dateert van november 2015 en de XRPNotCreated-invariant van februari 2017. De XRPL heeft meer dan $1 miljoen aan bounties uitbetaald en sinds 2024 meer dan een dozijn audits en auditwedstrijden gehouden. Mensen en auditbureaus hebben deze code een decennium lang bekeken en het gemist. Het patroon wordt bekend. Coldcard verloor deze zomer ongeveer 1.367 BTC aan een vijf jaar oude firmware-bug waarvan de maker vermoedt dat die met AI-hulp is gevonden. Oude code is niet langer veilig alleen omdat die oud is.
Waarom de fix de validator-stemming oversloeg
Hier stopt het verhaal een schone beveiligingsoverwinning te zijn en wordt het een governance-argument. De XRP Ledger verandert transactieregels normaal via amendments. Een nieuwe regel wordt uitgebracht in de software, uitgeschakeld, validators stemmen erover, en die activeert pas na meer dan 80 procent steun op de standaard Unique Node List gedurende twee opeenvolgende weken. Het systeem bestaat al meer dan een decennium en is nooit bewust omzeild voor een wijziging in transactieverwerking.
Tot 25 september. De overflow-fix werd direct uitgebracht in xrpld 3.4.1 zonder amendment-gate. Die trad in werking op elke server op het moment dat die server upgradede. De redenering van de XRPL Foundation is simpel: een amendment-stemming zou de fix, en dus de bug, twee weken voor inwerkingtreding hebben gepubliceerd. Iedereen die de diff las, zou een fortnight hebben gehad om 18 biljoen XRP te drukken. De Foundation zegt dat de beslissing gezamenlijk is genomen door zichzelf, RippleX, core-ontwikkelaars en validators, en dat geen enkele partij de beslissing alleen had kunnen nemen.
De aanpak had zijn eigen risico, wat het onthullingsrapport toegeeft. Als iemand de exploit had geprobeerd terwijl het netwerk verdeeld was tussen gepatchte en niet-gepatchte servers, zouden de twee groepen het oneens zijn geweest over de ledger-status. In het slechtste geval stopt het netwerk. Het team oordeelde dat een mogelijke halt de voorkeur verdiende boven een zekere voorraadexplosie, wat moeilijk te betwisten is. Meer dan 80 procent van de standaard UNL-validators draaide 3.4.1 binnen enkele uren na de release op 25 september.
| Datum | Gebeurtenis |
|---|---|
| Nov 2015 | BookStep-aanbiedingensommatiecode geschreven met ongecontroleerde 64-bits optelling |
| Feb 2017 | XRPNotCreated-invariant toegevoegd, met dezelfde ongecontroleerde rekenkunde |
| 21 sep 2026 | Veria Labs AI-agent markeert beide overflows en koppelt ze |
| 22 sep 2026 | Gemeld via XRPL Bug Bounty, gereproduceerd door RippleX, verhoogd naar Critical |
| 23 sep 2026 | Fix privé samengevoegd in de 3.4.1 release candidate |
| 25 sep 2026 | xrpld 3.4.1 uitgebracht, meer dan 80 procent van standaard UNL-validators geüpgraded |
| 8 okt 2026 | Veria Labs ontvangt de maximale bounty van $250.000 |
| 9 okt 2026 | Openbaar onthullingsrapport gepubliceerd, Batch fix amendment activeert |
| 12 okt 2026 | ZachXBT noemt de bounty publiekelijk te laag |
Het decentralisatiegevecht dat volgde
Kort gezegd gebruikte Justin Bons van Cyber Capital, een al lang bestaande XRP-criticus, de episode om te betogen dat het marketen van XRP aan retail als gedecentraliseerd neerkomt op fraude. Zijn specifieke klachten: de release van 25 september werd alleen als gecompileerde binaries verspreid, met de broncode tijdelijk achtergehouden, en operators werden onder druk gezet om een binary te upgraden die ze niet konden inspecteren. Het XRPL-onthullingsrapport bevestigt dat de bron later werd gepubliceerd, maar zegt niet wanneer.
Praktisch gezien kwam het tegenargument net zo goed van onafhankelijke validator-operators als van de Foundation. XRP Kuwait, dat zijn eigen node draait, verwoordde het als coördinatie is niet hetzelfde als controle. Onafhankelijke operators lazen hetzelfde advies, kwamen tot dezelfde conclusie en upgradeden. Niemand dwong hen. Bitcoin heeft hetzelfde gedaan, met name met de inflatiebug uit 2018 in Bitcoin Core 0.16.x, toen ontwikkelaars stilletjes een fix uitbrachten voordat ze uitlegden wat die fixte. Elke chain met een serieuze bug komt uiteindelijk voor de keuze tussen transparantie en overleven, en elke keten heeft voor overleven gekozen. Uiteindelijk heeft Bons een punt wat betreft de binaries. Een niet-verifieerbare binary uitbrengen en validators vragen die onmiddellijk te draaien is een vertrouwensoefening, hoe gerechtvaardigd ook. De eerlijke versie van het XRPL-standpunt is dat zijn validator-set de Foundation en RippleX genoeg vertrouwde om een paar dagen niet-beoordeelde code te draaien. Of je dat gedecentraliseerd noemt, hangt af van wat je vindt dat het woord betekent.
Was $250.000 genoeg voor een bug van $94 miljard
Veria Labs ontving op 8 oktober de hoogste critical-tier uitbetaling van het XRPL-programma van $250.000. Veria noemde het waarschijnlijk de grootste bounty ooit betaald voor een bug die volledig door een AI-agent is gevonden. Vier dagen later noemde blockchain-onderzoeker ZachXBT het een slechte grap. Zijn argument: een ecosysteem waarvan de treasury miljarden bevat, betaalde een kwart miljoen voor een bevinding die het asset had kunnen beëindigen. En dat gat is precies de prikkel die de volgende onderzoeker ertoe drijft om aan een aanvaller te verkopen. Hij suggereerde zeven cijfers als ondergrens en wees op een naar verluidt zevencijferige beloning die in het Zcash-ecosysteem is betaald voor een recente vervalsingsbug. Noch Ripple noch de Foundation had op het moment van schrijven publiekelijk gereageerd.
Beide kanten hebben gelijk over verschillende dingen. Het programma betaalde zijn geadverteerde maximum, de onderzoeker meldde verantwoord, en de fix landde voordat iemand buiten de kring het wist. Dat is het systeem dat werkt. Het is ook waar dat $250.000 0,27 procent is van de $94 miljard die op het spel stond, en dat elke aanvaller met 256 accounts en een paar honderd XRP de andere 99,73 procent had kunnen pakken. Bounty-plafonds die zijn geschreven toen XRP een fractie van zijn huidige marktwaarde was, schalen niet mee met het ding dat ze beschermen.
Wat XRP-houders en crypto-gokkers hiervan moeten meenemen
De fix is server-side. Je wallet, je keys en je saldo waren nooit betrokken en aan jouw kant hoeft niets te worden geüpdatet. De voorraadlimiet hield stand omdat de bug werd gevangen, niet omdat de invariant werkte. De tweede helft van die zin is het onthouden waard.
Er zijn hier drie praktische lessen. Ten eerste: het feit dat code tien jaar live is geweest, is geen beveiligingsargument meer. AI-ondersteunde auditing maakt oude overflows goedkoop om te vinden, en aanvallers huren dezelfde modellen als onderzoekers. Ten tweede: governance-processen die zijn ontworpen voor feature-uitrollen zijn niet ontworpen voor kritieke patches. En elke chain zou vooraf moeten beslissen hoe die de volgende aanpakt in plaats van te improviseren onder druk. Ten derde: bug bounty-plafonds moeten de beveiligde waarde volgen. Een vast plafond dat in 2022 genereus leek, is in 2026 een uitnodiging. Voor het gokpubliek is de relevantie simpel. XRP is een standaard stortingsrail geworden bij crypto-casino's omdat het in vier seconden settleert voor een fractie van een cent. En die snelheid hangt af van de juistheid van de ledger-regels. Platforms die uitbetalingen automatiseren, waaronder CryptoCasino.Vegas, vertrouwen elke keer dat een XRP-opname wordt afgehandeld zonder dat een mens ernaar kijkt op de invarianten van de chain. Die invarianten hielden het deze keer omdat een onderzoeker en een AI-agent de hele nacht doorwerkten, en dat is een dunnere marge dan de limiet van 100 miljard ooit liet blijken.
De volledige technische uiteenzetting, inclusief beide overflow-locaties en de geharde rekenkunde die ze verving, staat in het vulnerability disclosure report van de XRPL Foundation voor xrpld 3.4.1.
