BuildNot yet confirmed elsewhere1 publisher2 min readPublished
An integer overflow in XRPL's payment engine could have charged a buyer a much smaller wrapped total
Researchers found an integer overflow in the XRPL payment engine that could theoretically have created XRP from nothing. The 18 trillion XRP figure came from controlled testing, and a dev.to write-up says nobody minted it on the public ledger.
The Engineer · Build desk
Key figures: 18 trillion XRP from one modeled scenario in controlled security testing, not an observed change to public supply; XRP's 100 billion XRP allocation; the test figure is 180 times the allocation.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Modeled in controlled security testing, one scenario | 18,000,000,000,000 XRP | Not an observed public supply change | 9 |
| XRP allocation | 100,000,000,000 XRP | 14 | |
| Test figure vs allocation | 180 times | 16 |
What happened
- The vulnerable code summed several XRP amounts held in fixed-size integers while a payment consumed offers from the decentralized order book.
- If that sum overflowed, offer owners could still receive their full amounts while the buyer was charged only the much smaller wrapped total.
- Per the official disclosure, an attacker could build many offers, each trading a small amount of another asset for a very large XRP amount, and consume them in one payment.
- XRPL's invariant check for XRP creation was meant to reject such a transaction, but the same class of arithmetic problem potentially affected that calculation too.
Why it matters
- constraint A supply check built on the same addition, at the same width, as the code it audits is not an independent control. Review has to ask whether one input can fool both paths.
- exposure Any code that validates each line item against a range limit and then sums them is exposed. Every credit passes, and only the aggregate wraps.
- decision Teams that total balances have to choose where the overflow check lives. The post's answer is more than one mechanism, with checked arithmetic at the sum and an independently computed total behind it.
No single operation in this bug is wrong. Each offer credit was valid within the allowed numeric range, and the failure appeared only when the engine totaled what the payer owed [8]. In our view that is why it survives review. A validator that checks each credit against the range limit passes every one of them.
The second failure is the part to copy into review checklists. The post's stated lesson is that a safety check is independent only if it does not reproduce the assumptions and failure modes of the code it validates [11]. We would put the test in practical terms. If the check adds the same numbers at the same width as the code under test, one overflow defeats both.
The supply rule being protected is simple: total XRP before a transaction equals total XRP after, plus legitimate fees burned [13]. A check that recomputes that identity has to total the balances by a route the payment path does not share.
For application code, we think the narrow fix is checked addition at every site that sums balances, with the transaction rejected on overflow. The source's own description of the bug is the contrast: the engine did not reject the calculation, it wrapped [5]. The post lists checked arithmetic, explicit overflow detection, independent accounting calculations, property-based testing, fuzzing, formal verification and runtime assertions. It says the key is not relying on only one [12]. Integer overflow is one of the oldest bug classes in software [15], and it still reached a ledger that had a check built for exactly this event [17].
The 18 trillion figure is 180 times the 100 billion XRP allocation [16]. The post says it came from controlled security testing and models one exploitation scenario [9]. It does not say how the testers sized that scenario, whether it is a ceiling, or what the patch changed. Read it as the output of one test scenario. The post reports developers found no evidence of exploitation on Mainnet or another public network [10].
What to watch
- Whether the official XRPL disclosure or release notes say how the supply invariant now totals balances, and whether it uses a route independent of the payment path.
- Whether the testers publish how the 18 trillion scenario was sized and whether it is a ceiling.
- Whether any public network reports evidence of exploitation, which the post says developers had not found.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence50
- Adoption
- Insufficient
- Hype gap−20
- Incentives
- Insufficient
- Confidence45
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Researchers found an integer-overflow bug in the XRPL payment engine that could theoretically have allowed an attacker to create XRP from nothing.
- [2]
No one actually minted 18 trillion XRP on the public XRP Ledger.
- [3]
A payment can consume multiple offers from the decentralized order book while calculating how much XRP should be transferred between participants.
- [4]
The vulnerable code had to sum multiple XRP amounts, and those balances are represented using fixed-size integers.
- [5]
If the combined value exceeded the maximum representable integer, the arithmetic could overflow; instead of rejecting the calculation, the total could wrap around to a much smaller number.
- [6]
Individual offer owners could receive the full XRP amounts specified by their offers, but the buyer could be charged only the much smaller wrapped total; the difference would effectively become newly created XRP.
- [7]
According to the official vulnerability disclosure, an attacker could construct many specially designed offers, each attacker-controlled account offering a small amount of another asset in return for an unusually large amount of XRP, then create one payment that consumed many of those offers in a single operation.
ReportedSupportedSource: dev.to post by tapbitoffical, citing the official vulnerability disclosureView cited source - [8]
Each credit was individually valid within the allowed numeric range; the problem appeared when the payment engine calculated the combined amount the payer owed.
- [9]
The 18 trillion figure came from controlled security testing and represents one modeled exploitation scenario, not an observed change to XRP's public supply.
- [10]
Developers reported no evidence that the vulnerability had been exploited on Mainnet or another public network.
- [11]
A safety check is only independent if it does not reproduce the same assumptions and failure modes as the code it is validating; if both implementations rely on similar arithmetic, the same overflow can defeat both.
- [12]
The post lists checked arithmetic, explicit overflow detection, independent accounting calculations, property-based testing, fuzzing, formal verification and runtime assertions as techniques to protect invariants, and says the key is not relying on only one mechanism.
- [13]
The simplified supply rule is that total XRP before a transaction equals total XRP after the transaction plus legitimate fees burned.
- [14]
XRP has a 100 billion XRP allocation, which the post says did not suddenly become 18 trillion XRP in circulation.
- [15]
Integer overflow is one of the oldest bug classes in software.
- [16]
The 18 trillion XRP test figure is 180 times the 100 billion XRP allocation.
- [17]
XRPL already had a safety mechanism designed to prevent exactly this kind of event: an invariant that checks whether a transaction creates XRP and should reject an impossible supply increase even if an earlier calculation contained a bug.
- [18]
The same class of arithmetic problem affected the invariant calculation, so the bug potentially existed both in the operation that could create the invalid state and in the mechanism intended to detect it.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toThe XRPL Overflow Bug: What Developers Can Learn From a Supply-Invariant Failure
1 article · October 12, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Integer overflowFollow
- Blockchain SecurityFollow
- Software TestingFollow