11-Year-Old Bug in XRP Ledger: A Real Threat to the 100 Billion Coin Supply Cap
Baca dalam 60 detik
- XRP Ledger Foundation mengungkap kerentanan integer overflow yang bersembunyi sejak 2015 dan berpotensi melampaui batas suplai 100 miliar XRP.
- Tidak ada koin baru yang tercipta; sekitar 99,986 miliar XRP tetap beredar setelah RippleX merilis perbaikan.
- Fondasi berencana memperkuat pertahanan dengan pengujian AI adversarial, verifikasi formal, dan program bug bounty yang lebih agresif.

A programming flaw that had lain dormant in the XRP Ledger for more than a decade has finally come to light. According to the XRP Ledger Foundation, this vulnerability could potentially allow an attacker to create new XRP beyond the 100 billion coin supply cap that underpins token holders' trust. The incident was discovered on 22 September by researcher Cayden Liao together with Veria AI and reported internally before it caused any damage.
For the crypto market, this finding is not merely a technical footnote. The XRP Ledger is an open-source layer-1 blockchain that relies on a promise of absolute scarcity: there is no mining mechanism and no supply issuance. If this flaw were exploited, trust in one of the world's largest digital assets could collapse within hours. RippleX, the developer that released the patch, confirmed that no new XRP was created and that roughly 99.986 billion coins are still in circulation today.
The vulnerability stems from what is known as an integer overflow. Picture an old arcade game scoreboard that rolls back to zero after reaching its maximum value. In the context of the XRP Ledger, once a transaction amount exceeds the numeric limit the system allows, the value flips to a very small number. As a result, standard fund checks are bypassed: the seller still receives the full amount of XRP, while the buyer is charged only a minimal cost. The difference is effectively minted out of thin air and artificially inflates the total supply.
The possible attack pattern is fairly intricate. An attacker could create a number of puppet accounts to post fictitious token sales with fantastical XRP values. Acting as the buyer, the attacker then pays in XRP and sweeps up all the tokens at once. The ledger would credit the seller's account with billions of valid XRP, but because it is overwhelmed by the extraordinary volume, the system records only a fraction of a cent in total cost for the buyer. That way, the attacker could walk away with billions of new XRP to cash out on external exchanges.
Why did this flaw go unnoticed for so long? The XRP Ledger Foundation explained that triggering it requires an extreme scale of operations. โNo normal payment comes close to the trigger. It takes hundreds of deliberately designed operations,โ the foundation said in its official explanation. The ledger's internal checks also failed to detect it because post-transaction verification relied on the miscalculated total. The maximum receivable limit per account was not triggered either, since a potential attack would spread across hundreds of accounts.
The good news is that there is no indication of actual exploitation. However, the incident highlights vulnerabilities that may lurk in other blockchains with similar architectures. The foundation noted that artificial intelligence is now accelerating the discovery of such flaws, both by malicious actors and by well-intentioned parties. As a preventive measure, they plan to apply adversarial AI testing aggressively, formal verification, and a strengthened bug bounty program. โYou will hear more about this as we make progress,โ it added.
In Indonesia, where crypto asset adoption continues to grow and XRP is one of the popular tokens, this incident serves as a reminder that the technical risks behind the promise of decentralization cannot be ignored. Regulators such as Bappebti and domestic industry players need to pay close attention to blockchain security audit standards, especially as more local projects rely on claims of limited supply. The question is whether the global crypto ecosystem will treat this finding as a momentum to tighten formal verification, or instead wait for the next flaw to be found by AI before it is fixed?



