XRP Ledger Closes Bug That Could Push Accounts Into Debt
Almost four weeks after XRP Ledger delegation went live, a fix now stops burn-only delegates from overshooting into minting, and the code’s own test shows who carried that risk.
Key Takeaways
- Fix enabled November 4 in ledger 108,112,129.
- Delegation had run without it since October 8.
- Test’s minted units were the delegator’s own IOUs.
- Granular permissions still cannot be limited by currency.
Validators enabled the amendment, fixCleanup3_4_0, on November 4 at 14:52 UTC, and Coindoo confirmed the activation transaction in validated ledger 108,112,129, with Ripple’s public Mainnet server listing the amendment as enabled.
Activation came after a vote that briefly lost its supermajority in late October, a setback tracked in Coindoo’s pre-activation report. That report set out the checklist issuers were advised to run. The code and test committed with the fix answer a narrower question: whose tokens the overshoot actually created.
Almost Four Weeks Without a Zero-Balance Check
Delegation went live on October 8 under the PermissionDelegationV1_1 amendment, according to the XRPL amendment dashboard. From then until November 4, a delegate holding PaymentBurn could, in some configurations, push a redemption past zero. XRPL’s permission reference therefore advised against delegating that permission until this amendment was enabled. That condition was met on November 4.
The rippled commit behind the fix, authored under the GitHub handle yinyiqian1, adds the missing check. When a delegate holds only PaymentBurn, the ledger compares the payment amount with the balance the account actually holds and rejects anything larger. XRPL’s documentation already described burning as stopping at zero; for delegated payments, the code did not enforce that limit until this amendment.
Inside the Test: Alice, a Gateway and an Oversized Payment
The test in the commit uses three accounts. Alice holds 50 USD issued by an account called gateway. Gateway, in turn, has opened a trust line accepting up to 200 USD issued by alice, which the code comments describe as giving the payment engine “issuing liquidity available once the trustline reaches zero.”
Alice then grants a third account, bob, the PaymentBurn permission, and bob sends a payment from alice to gateway for twice what she holds. The trace shows how the ledger handled that payment, and the follow-ups, under each set of rules.
Test trace: bob’s payments from alice to gateway
Old rules · PaymentBurn only
- 100 USD: accepted
- Alice’s 50 redeemed, then 50 alice-issued USD created
- End state: gateway holds 50 USD issued by alice
New rules · PaymentBurn only
- 100 USD: rejected
- 20 USD: accepted, 30 left
- 30 USD: accepted, balance at zero
- 1 USD: rejected
New rules · PaymentBurn + PaymentMint
- 100 USD: accepted
- Crosses zero, since minting is authorized and gateway accepts alice’s IOUs
The New Tokens Were Alice’s Debt
Under the old rules, the payment added no units of gateway’s USD. Gateway’s obligation to alice fell from 50 to zero. What appeared instead was 50 USD issued by alice and held by gateway: alice ended the transaction owing the issuer, on the strength of a payment signed by a delegate she had authorized only to redeem.
The ledger treats those as two different assets. XRPL’s asset-format documentation identifies a trust-line token by its currency code and its issuing account, so alice’s USD and gateway’s USD share a code but not an issuer. Native XRP, which has no issuer, was outside the flaw entirely.
In the documented case, then, the risk sat with two parties: the account that delegated burn authority, which could pick up a liability it never approved, and the issuer receiving those IOUs. Holders of gateway’s USD were not facing new units of the token they held.
The Precondition That Narrowed the Flaw
The overshoot depended on one setting on gateway’s side. Without a trust line accepting alice’s IOUs, the payment had no way to create alice-issued USD. An issuer has to submit that trust line itself, which is the strongest argument that the flaw had limited practical reach.
That argument has an edge. XRPL’s delegation documentation also listed Multi-Purpose Tokens (MPTs) among the assets a burn-only delegate could mint before the fix, while the commit’s test covers only the trust-line case. Neither source describes a live incident, but the trust-line reading should not be stretched to MPT issuers without a test of their own.
One Permission Still Covers Every Currency
The amendment caps how much a burn-only delegate can redeem. It leaves untouched which tokens the permission reaches. Granular permissions are hard-coded, and the same documentation states that an account cannot grant a delegate the right to send some currencies while withholding others.
For an operations account holding USD and EUR tokens, or stablecoins from two issuers, a single PaymentBurn grant lets the delegate redeem all of them, each up to its balance. Any split by currency has to come from how holdings are divided across accounts. The Payment transaction-type permission reaches further still, covering payments of that type in general, so a review that checks only the two granular values can miss it. Coindoo’s earlier piece on how XRPL divides operational authority between accounts covers how institutions structure those roles.
What Would Show Whether the Flaw Was Used
Every grant is public. The Delegate ledger entry records the granting account, the delegate and its permission list, which makes misuse a question anyone can check onchain.
The onchain pattern
- A payment validated after October 8 and before ledger 108,112,129.
- Signed by a delegate holding
PaymentBurn, but neitherPaymentMintnorPayment, at that moment. - Sent to the token’s issuer, leaving the delegating account with a negative balance on that trust line.
A payment matching all three would confirm the overshoot happened on Mainnet. A review of every PaymentBurn grant in that window that finds none would rule it out for trust-line tokens, with MPTs as a separate check. Because DelegateSet replaces a permission list wholesale, as the pre-activation report explained, the check has to use the permissions in force when each payment was validated.
The amendment applies from ledger 108,112,129 onward. Any payment validated before it stands exactly as recorded, including any that crossed zero.
Alex is Editor-in-Chief of Coindoo and co-founder of Millennial Media Group, with nearly a decade of experience covering financial markets - crypto first, then everything else. It started in 2016 with Bitcoin. Like most people at the time, he didn't fully understand it - so he kept digging. Blockchain, tokenomics, the projects, the cycles. That curiosity never stopped, and eventually pulled him into traditional markets too: equities, commodities, macro. Not because he left crypto behind, but because you can't properly understand one without the other. What drives him is straightforward: he wants to know why something is happening, not just that it's happening. Most market coverage stops at the headline - price up, price down, here's a chart. Alex finds that kind of reporting actively unhelpful. If you walk away from an article without understanding the mechanism behind the move, what did you actually learn? He holds a degree in Tourism from New Bulgarian University - not the most obvious path into financial markets, but markets have a way of pulling in people who are simply too curious to stay out. He has authored over 200 in-depth analyses and more than 10,000 articles across crypto and traditional finance. He still thinks every day in markets teaches him something new. That's probably why he hasn't stopped.
