XRP Ledger has activated a software update that closes a vulnerability allowing accounts with permission to destroy issued tokens to create new ones under certain conditions, without affecting the native XRP cryptocurrency.
Summary
- XRP Ledger activated the fixCleanup3_4_0 amendment on November 4 at 14:52 UTC, at ledger 108,112,129.
- The update closes a permission flaw that could allow an account authorized to burn issued tokens to create new tokens under certain conditions.
- The vulnerability concerned issued assets, including stablecoins and Multi-Purpose Tokens, not XRP’s native supply.
- Validator support briefly fell below the required threshold on October 21, restarting the mandatory 14-day approval period.
- The amendment includes corrections for trading pools, vault accounting and transaction signing, but does not independently activate XRP Ledger’s planned lending system.
The XRPLWin amendment tracker confirmed that the fix, named fixCleanup3_4_0, took effect on November 4 at 14:52 UTC, at ledger 108,112,129. The activation followed two consecutive weeks of validator support after a brief interruption in October forced the network to restart its approval process.
The correction addresses a flaw in XRP Ledger’s permission delegation system, which allows account holders to authorize other accounts to perform specific transactions without surrendering complete control.
XRP Ledger fixes unauthorized token creation vulnerability
The vulnerability involved a delegated permission called PaymentBurn, which allows an approved account to destroy tokens issued by another account.
Under normal circumstances, an issuer could grant that permission to a payment service handling stablecoin redemptions. When a customer exchanges stablecoins for dollars, the service could destroy the redeemed tokens without receiving permission to create replacements.
However, XRP Ledger’s previous transaction rules could allow an account holding only PaymentBurn authorization to create issued tokens under certain conditions.
The problem arose when payments using the delegated permission crossed a zero-balance boundary. The latest amendment prevents transactions from crossing that boundary, separating token destruction from issuance.
The official XRPL release notes describe the correction as rejecting “PaymentBurn payments that cross a zero balance.”
The vulnerability affected assets issued on the network, including stablecoins, trust-line tokens and Multi-Purpose Tokens. XRP itself was outside the affected permission system, meaning the flaw did not allow unauthorized creation of the network’s native cryptocurrency.
No publicly confirmed exploitation of the vulnerability has been reported, and the available disclosures do not identify an issuer that suffered unauthorized token creation.
The fix follows the network’s previously disclosed token-minting flaw, which crypto.news covered on November 2 when the amendment was still awaiting activation.
Validator approval delay pushed the fix into November
Although developers included the correction in XRP Ledger server version 3.4.0 in September, its release did not immediately change the network’s transaction rules.
Protocol amendments require support from more than 80% of trusted validators for 14 consecutive days before they become active.
With 35 validators on the tracked default list, at least 29 must support an amendment throughout that period.
The first approval period began on October 9, putting the update on course for activation around October 23.
However, validator support dropped below the required threshold on October 21, interrupting the countdown before the amendment became eligible for activation.
XRPLWin records show that the first attempt lasted 12 days and three hours. A new majority was established later on October 21, beginning another two-week waiting period.
The second attempt lasted 14 days and five minutes before the network enabled the amendment on November 4.
XRP Ledger’s voting process requires uninterrupted support, so even a temporary decline below the threshold can postpone an upgrade.
Software update repairs trading and transaction controls
Beyond the token-creation vulnerability, fixCleanup3_4_0 introduces corrections across several XRP Ledger transaction functions.
Among them are changes to automated market maker clawbacks, which issuers use to recover certain assets from liquidity pools.
The update prevents a transaction from destroying a liquidity provider’s tokens when rounding calculations would otherwise result in the issuer recovering no underlying assets.
Developers corrected permissioned trading rules to prevent accounts from receiving certain tokens through offers when issuer restrictions should block those transactions.
Separate changes address escrow reserves, Multi-Purpose Token authorization and transaction signatures.
Previously, some signing procedures used overlapping authorization structures. The amendment introduces distinct signing prefixes to prevent signatures intended for one transaction role from being reused in another.
These corrections were included in the September software release, with developers urging server operators to upgrade their software before the new rules took effect.
XRP Ledger lending remains subject to separate approval
The activation includes accounting corrections intended for Single Asset Vaults and the proposed XRP Ledger lending protocol.
The vault system would allow users to deposit assets into pools that could support fixed-term loans. Developers have adjusted calculations involving deposits, withdrawals and recoverable assets.
Lending-related corrections address how the network determines when payments become overdue and how impaired loans affect vault accounting.
However, the maintenance amendment does not activate those lending features, which require separate validator approval.
Ripple previously supported the lending amendments designed to introduce Single Asset Vaults and fixed-term institutional borrowing.
The proposals would permit loan brokers to evaluate borrowers and arrange loans using assets deposited into vaults, while the ledger records repayments and associated transactions.
The additional LendingProtocolV1_1 amendment proposes closed-ended vaults with subscription, investment and redemption periods, alongside accounting that recognizes interest when borrowers make payments.
Each lending amendment must independently satisfy the network’s validator approval requirements before its associated features can operate on mainnet.
