XRP Ledger Activates fixCleanup3_4_0 on November 4 With 33 of 35 Validators

fixCleanup3_4_0 Activates on November 4

The XRP Ledger will activate the fixCleanup3_4_0 amendment at approximately 14:46 UTC on November 4, closing a flaw that let accounts holding only burn authority issue new tokens. The change lands on the ledger's mainnet with 33 of the 35 trusted validators behind it, five more than the 28 votes, or 80% of the pool, that activation requires. Amendments reach the XRP Ledger without a hard fork: validators signal support on-chain, a two-week countdown runs only while support stays above the threshold, and a single drop to 80% or below resets it. The patch was first scheduled for roughly 09:34 UTC on October 23, and the timer was restarted on October 21 before the vote stabilized. The two-week window exists to give operators time to prepare before any rule change takes effect. XRPL's amendment machinery, in which trusted validators that run the server software vote continuously, differs from upgrades on other chains where a foundation can switch features on directly.

Inside xrpld 3.4.0

The bug itself sits in PermissionDelegationV1_1, an amendment that went live on October 8 and introduced permission delegation, a mechanism that lets an account grant specific permissions to another account without sharing its secret keys. One of those permissions, PaymentBurn, was meant to let a delegate burn tokens. The ledger's own permission delegation documentation states the problem plainly: before the fix, a delegate granted PaymentBurn could also mint new fungible tokens, in some cases on trust-line tokens or multi-purpose tokens (MPTs). The documentation advises against delegating PaymentBurn until fixCleanup3_4_0 is enabled. Other fine-grained permissions are unaffected, and the minting path was unique to PaymentBurn. fixCleanup3_4_0 tightens the delegation system inside the wider XRP ecosystem and is one of several cleanup amendments the developers ship to polish earlier features. The XRP price hovered near $1.25 on November 3 as the activation approached.

fixCleanup3_4_0 ships inside xrpld 3.4.0, the current release of the ledger's core server software. The official release notes describe the amendment as cleanup for the 3.4.0 line: once enabled, it rejects PaymentBurn payments that carry a zero balance, the route through which a burn-only account could mint. The same release hardens automated market maker rebate logic, vault accounting, escrow reserves and signature handling, and asks node operators to upgrade as soon as possible. Servers running 3.4.0 enforce the new rule the moment the amendment activates; older versions cannot. The notes frame the package as routine maintenance rather than an emergency patch, even though it closes a real vulnerability.

Progress on the ledger's other pending upgrades is slower. Amendment tracking data puts LendingProtocolV1_1 at 19 votes, the original LendingProtocol amendment at 19 and SingleAssetVault at 21, each short of the 28 required to start a two-week countdown. None of the three has reached the support window that fixCleanup3_4_0 cleared this week. Taken together, the proposals would give the ledger native lending. Until they clear, that program stays parked even as institutional usage grows: Ripple's RLUSD stablecoin recently gained support from the crypto exchange Coinbase across the XRP Ledger and other chains.

The fix also caps a turbulent stretch for ledger security. Last month developers disclosed a decade-old flaw that could have let an attacker mint XRP beyond the fixed supply; it was patched quietly in September, and there is no evidence it was ever exploited. XRP was hit as collateral in the recent Binance hack, which targeted that exchange's wallets rather than the ledger itself. Neither incident involved a failure of the amendment process. On the market side, XRP trades inside the $1.25 support zone after last week's dip to $1.20, a setup our XRP technical analysis follows closely.

PaymentBurn Delegation After November 4

For everyday holders, activation changes nothing: balances, transfers and trust lines all behave as before. The effect lands on issuers, trading venues and businesses that delegate account permissions, and once the amendment is live, the ledger's documentation allows PaymentBurn to be re-delegated safely. The episode also demonstrates the design that the ledger's co-architect David Schwartz has defended for years. A flaw that shipped with PermissionDelegationV1_1 on October 8 is being corrected through ordinary on-chain voting, with no emergency fork and no intervention by a single operator. From around 14:46 UTC on November 4, upgraded servers will reject PaymentBurn payments that attempt to mint, and hardened 3.4.0 code will be running across the network for the first time.