XRP Ledger Closes Bug That Could Push Accounts Into Debt

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.

Five Buys, Zero Sells: Inside Cantons’s Onchain Debut

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

1. A payment validated after October 8 and before ledger 108,112,129.
2. Signed by a delegate holding PaymentBurn, but neither PaymentMint nor Payment, at that moment.
3. 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.