XRP Ledger Races to Shut Its Own Token-Minting Back Door

Key Takeaways

• Delegation went live on Mainnet on October 8.
• Only the PaymentBurn permission carries the minting risk.
• 33 of 35 trusted validators back the fix.
• The flaw cannot create new XRP.

The official XRPL documentation advises account holders not to delegate the PaymentBurn permission until an amendment called fixCleanup3_4_0 is enabled on the network.

What a Burn-Only Delegate Was Meant to Do

Permission delegation lets an account hand specific jobs to a second account, which signs with its own keys. XRPL’s documentation is explicit about the purpose: routine work runs on keys kept online, while the keys with full control stay offline for special tasks such as issuing tokens. Our guide to XRPL’s delegated account controls covers how institutions might split those roles.

Two of the ledger’s twelve granular permissions deal with token supply. PaymentMint covers payments that create fungible tokens or Multi-Purpose Tokens (MPTs). PaymentBurn covers payments that destroy them, and the documentation sets its boundary precisely: burning stops at a zero balance.

The flaw sits at that boundary. Before the fix, a payment sent under PaymentBurn could, in certain circumstances, run past zero and issue new trust-line tokens or MPTs. fixCleanup3_4_0 rejects any burn-only delegated payment whose amount would cross into minting, unless the same delegate also holds PaymentMint. The other eleven granular permissions are unaffected.

That makes the bug narrow in reach and awkward in what it touches. Only an account an issuer has already chosen as a delegate can use it, but what it unlocks is issuance, the one task delegation was designed to keep behind offline keys.

Cold Storage Doesn’t Cover a Delegate’s Keys

Delegated transactions are signed with the delegate’s own master key, regular key or multi-signing list. An issuer can keep its main credentials entirely offline and still be exposed if a delegate holding PaymentBurn is compromised, misconfigured or acts outside its brief.

For a fiat-backed token, the economic risk is units in circulation without matching reserves. A reserve attestation shows the assets held against outstanding tokens on a reporting date. It says nothing about which accounts could change that count between reports, and that is the control this flaw weakens.

Ethereum Price Holds Major Floor as Bulls Fight Back

Delegation Launched Before Its Fix Had the Votes

This is the second flaw found in XRPL’s delegation feature. The original version was pulled in 2025 after a community tester discovered on devnet that it could charge transaction fees to accounts that had not signed, and the official disclosure confirms it never reached Mainnet. Its replacement, PermissionDelegationV1_1, went live on October 8, according to XRPL’s amendment dashboard, while the PaymentBurn correction was still gathering validator support.

Exposure is therefore account by account: only issuers that granted PaymentBurn since launch are affected. Every grant is public, because Delegate ledger entries record the granting account, the delegate and its permission list. At the time of writing, neither the XRPL documentation nor published reporting identifies an affected issuer or any misuse.

A supply increase on its own would prove nothing, since an issuer may have granted PaymentMint deliberately. What would need explaining is a delegate holding only PaymentBurn whose payments added tokens.

What Issuers Can Check Before Wednesday

XRPL’s published advice is to stop delegating PaymentBurn until the fix is enabled. For issuers that have already granted it, the work runs in this order:

Pre-activation checklist

1. Pull every Delegate entry on the issuing account and flag any permission list containing PaymentBurn.
2. Resend DelegateSet with the complete list to keep. A new list replaces the old one, so anything left off is removed.
3. Treat a grant as revoked only once the change appears in a validated ledger.
4. Audit the delegate’s past payments separately, because revoking authority stops future use without reversing earlier transactions.
5. Delegate PaymentBurn again only after fixCleanup3_4_0 shows as enabled on Mainnet.

Why the Vote Can Still Slip

Under the official amendment rules, a change needs a supermajority of trusted validators held for two uninterrupted weeks. With 35 validators in the tracked set, that threshold is 29, and falling below it resets the clock. That reset has already happened once:

October 21
Support fell to 26 validators, pushing back an October 23 activation projection, CoinDesk reported. November 2
33 of 35 trusted validators back the fix after support recovered. November 4, around 14:46 UTC
Earliest activation window, provided support stays at 29 or above.

Even with support intact, 14:46 UTC marks when the window opens. Activation happens at a ledger voting checkpoint, so the change can take effect some time after that.

Validators are also voting on far more than this one correction. fixCleanup3_4_0 bundles 25 changes across vaults, lending, automated market makers, NFTs, escrow and sponsorship, and the PaymentBurn fix is the last item on its list. It patches lending code without switching on the Lending Protocol itself, which has its own amendment still open for voting.

For issuers, the confirmation that counts is fixCleanup3_4_0 listed as enabled on Mainnet. Until then, a PaymentBurn grant carries more authority than its name describes.