XRP Ledger has activated a fix for a security loophole that could let an account trusted to destroy issued tokens create new ones without the necessary permission. The change matters for stablecoin operations, where a company may give a payment partner limited access to handle redemptions without handing over control of token issuance.
The amendment, called fixCleanup3_4_0, became active on November 4 at ledger 108,112,129. It changes the network's transaction rules, closing a gap between permission to burn tokens and permission to mint them. The issue concerned issued assets, including stablecoins, rather than the native XRP cryptocurrency.
How a burn permission could turn into minting
The problem sat inside permission delegation, a feature that lets an account authorize another account to carry out specific tasks. A business can keep its most powerful keys offline while separate accounts handle routine transactions.
That arrangement depends on each permission doing exactly what it says. PaymentBurn is meant to allow the destruction or redemption of issued tokens. PaymentMint is the separate permission for creating them.
The official documentation had warned:
"Before the fix, a delegate with the PaymentBurn granular permission can also mint new fungible tokens (trust line tokens or MPTs) in certain circumstances."
The warning advised against delegating PaymentBurn until the amendment was enabled. It also said other granular permissions were unaffected. MPTs are Multi-Purpose Tokens, another format for issuing assets on the ledger.
The underlying mistake involved payments that crossed a zero balance. A transaction could begin by redeeming tokens an account held, then continue past that balance and start issuing the account's own tokens. The initial balance direction passed the old permission check, even though the rest of the payment could do something the delegate was not authorized to do.
Developers explained the boundary in the code change:
"Redeeming stops at the balance held; beyond that the payment engine crosses zero and issues the account's own IOUs, which is a mint."
The fix checks where the payment ends
The amended rules check the payment amount against the balance available to redeem. A delegate holding only PaymentBurn cannot take the transaction past zero into issuance. Crossing that boundary requires PaymentMint authorization as well.
The project's regression tests cover both sides of the change. Burn-only payments that exceed the available balance are rejected, while smaller redemptions and payments that settle exactly at zero remain allowed. A delegate granted both minting and burning permissions can still perform the broader operation.
For an issuer, that restores the distinction between a partner authorized to process redemptions and one authorized to create tokens. Delegation remains available, and an account owner can update or revoke a delegate's permissions through a DelegateSet transaction.
Validator voting delayed activation
The correction shipped in server version 3.4.0 in September. Network activation came later because an amendment must hold the required validator support continuously through a two-week approval period.
XRPLWin's tracker records an initial majority beginning October 9, followed by a loss of majority on October 21. That interrupted the first countdown. Support returned later on October 21, starting the approval period again and leading to November 4 activation.
The enabled amendment also appears in the validated ledger's amendment list. That puts the fix beyond the software-release stage: participating servers are now applying the changed transaction rules on mainnet.
The same package contains other corrections, including changes to automated market maker clawbacks, permissioned trading and transaction signatures. One signing change separates sponsor and counterparty roles so a signature intended for one cannot be reused for the other.
It also adjusts accounting and permission checks for Single Asset Vaults and the Lending Protocol. Those are separate amendments with their own activation requirements; enabling this maintenance package does not by itself switch on the proposed lending system.