XRP Ledger Found a Bug That Could Create XRP
XRP Ledger has disclosed a decade-old payment flaw that could create spendable XRP, detailing why operators received an emergency patch before the public report.
Key Takeaways
- A payment overflow could have created spendable XRP.
- XRPL found no evidence the flaw was exploited.
- The patch shipped in xrpld 3.4.1 on September 25.
- Developers bypassed the normal amendment timeline to close the risk faster.
A payment calculation could produce XRP from nothing
XRPL’s October 9 vulnerability report describes an integer-overflow flaw in the ledger’s payment engine. Under carefully constructed conditions, a payment that consumed many order-book offers could have credited accounts with XRP that the sender had not actually paid.
Each offer in the transaction could appear valid on its own. The failure arose when the engine added the XRP amounts across all of them. Once the total exceeded the maximum size of the number used for that calculation, it could wrap around to a much smaller value instead of producing an error.
The engine would still credit the offer owners with their full XRP amounts while charging the buyer only the wrapped-around total. The difference represented newly created XRP, which could then be moved, traded or sent to an exchange like any other balance.
Why the flaw was serious
The attack did not require a large XRP balance. An attacker could have controlled the accounts placing the offers, paid account reserves and transaction fees, then spread the created XRP across those accounts.
Account keys remained unaffected
The vulnerability sat in payment arithmetic rather than wallet access. Triggering it required hundreds of deliberately priced offers and a transaction designed to consume them together; an ordinary XRP payment or trade would not approach the values needed to create the overflow.
XRPL said it found no evidence of exploitation on a public network, and no private-key compromise, loss of funds or consensus failure was reported. The flaw appears to have been present since the current payment engine was written in 2015, remaining undiscovered because normal activity never reached the arithmetic limit.
The existing protection against newly created XRP also relied on the same kind of addition. It could wrap around in the same way as the payment engine, allowing the transaction to appear normal instead of flagging the unexpected increase in balances.
Why developers used an emergency deployment
Developers released the overflow fix before publishing its technical details because a normal amendment timeline would have left a known exploit available for weeks. The patch shipped in xrpld version 3.4.1 on September 25, while the public disclosure followed on October 9.
XRPL usually changes transaction rules through amendments. Validators first upgrade their software, then maintain the required support for a set period before the new rule activates at the same ledger point across the network. That process avoids situations in which different servers reach different conclusions about the same transaction.
Waiting for that process would have created a difficult problem here. Because xrpld is open source, publishing the repair could have shown attackers where to look while older software still accepted the vulnerable transaction path. The team therefore made the new overflow check take effect when an individual server upgraded.
That faster approach carried a temporary compatibility risk: an unpatched server could have accepted an exploit transaction that an upgraded server rejected. Developers considered that less dangerous than allowing created XRP to enter the market. The report says more than 80% of validators on the default UNL had upgraded on the day version 3.4.1 was released.
READ MORE:
XRP Ledger Gives Banks New Wallet Controls
The disclosure covered a second, separate flaw
The report also detailed a validation problem in XRPL’s forthcoming Batch feature, which lets users submit several transactions as one unit. It could have caused servers running different versions of the software to disagree over a malformed Batch transaction, interrupting ledger validation or breaking applications that parse transaction data.
| Issue | Potential consequence | How it was addressed |
|---|---|---|
| Payment-engine overflow | Spendable XRP created beyond the intended supply. | Overflow checks added in xrpld 3.4.1. |
| Batch wrapper validation | Server disagreement, stalled validation or broken transaction parsers. | The fixBatchV1_2 amendment, activated on October 9. |
The Batch flaw was caught before the feature reached mainnet. The overflow issue affected existing payment-engine code, which is why its patch could not wait for a standard activation cycle.
The report arrived while XRPL was also activating new account-control tools for businesses. The changes address different parts of the ledger, yet both depend on node operators, wallet providers and developers following the same current rules.
What users and operators need to do
Regular XRP holders do not need to move funds, replace a wallet or exchange their tokens. The update concerns the software that validates transactions, not a change to account balances, wallet keys or the XRP supply held by users.
Who needs to act?
- XRP holders: No action is required.
- Exchange users: Follow platform notices if an exchange carries out maintenance on its own XRPL infrastructure.
- Node operators: Upgrade to
xrpld3.4.1 or later to remain in sync with the network.
Older servers are now amendment-blocked following the activation of the Batch fix, meaning they cannot continue following the current ledger rules until they update.
The fix protected XRP’s supply rules before they were tested
The disclosure shows how close the ledger came to a supply-integrity failure and why validators moved quickly. The flaw was fixed before its details became public, no exploit was found, and the payment engine now uses checks designed to stop the same class of arithmetic error before it reaches a validated ledger.
This article is for informational purposes only and does not constitute investment or technical advice. Node operators should review current XRPL release documentation before updating production infrastructure.
Kosta has reported on cryptocurrency markets and blockchain infrastructure since 2020, bringing over six years of hands-on experience in the crypto industry built through daily tracking of markets, trends, and emerging blockchain developments. Specializing in Bitcoin on-chain analysis, institutional ETF flows, and digital asset price action, his work at Coindoo has been cited by other news agencies and consistently covers market developments with a focus on data-driven reporting across Bitcoin, Ethereum, Solana, and XRP. Over the years, Kosta has contributed to multiple crypto media outlets in different regions, authoring over 6,000 articles across the sector. His reporting spans cryptocurrency markets and the broader fintech industry, tracking not only price action but also the technological and regulatory forces shaping the ecosystem. To support his analysis, Kosta actively leverages on-chain data and metrics from leading platforms such as Santiment, Glassnode, and CryptoQuant, enabling deeper, evidence-based market insights. He believes in the power of transparency and the data that underpins the blockchain ecosystem. His academic background in Marketing Management from Denmark further complements his analytical approach, adding a strong understanding of communication strategy and content positioning to his work.
