XRP Ledger's fixCleanup3_4_0 Security Fix Locks October 23 Activation

An 80% Vote Opened a Two-Week Clock

The XRP Ledger has scheduled the fixCleanup3_4_0 amendment to activate at approximately 09:34 UTC on October 23, provided validator backing stays above the 80% supermajority threshold the protocol requires. The amendment cleared that bar on October 9, which opened a mandatory two-week countdown, and explorer tracking data showed roughly 26 to 29 validators in favor out of 32 to 35 voting as of mid-October. One safeguard shapes the calendar: if support slips back to 80% or below before activation, the countdown resets, and the amendment must then hold sufficient backing uninterrupted for another two weeks. The mechanism exists to prevent a soft consensus, since a patch that activated with wavering support could split the network. A dip below the floor during the final fortnight would push the security fix back by at least two weeks, a delay the ledger's operators would rather absorb than run the change with divided consensus.

Unlike protocol changes that introduce new transaction products, this update repairs the behavior of existing software. The patch ships with the Ripple 3.4.0 release and covers lending infrastructure, automated market makers, token handling, escrow transactions and account permissions. Amendments on the ledger change behavior only when sustained supermajority consensus forms, which is why the upgrade timetable is expressed in validator votes rather than release dates. Everyday balances and the XRP price sit outside the blast radius here; the compatibility burden falls on node operators, who need updated software to keep following the network's consensus mechanism once the change goes live.

PaymentBurn Defect and the Lending Stall

The sharpest item in the package involves PermissionDelegationV1_1.1, a feature activated on October 8 that lets an account owner grant another account limited authority to carry out specific actions without surrendering the account's private key. One delegated permission, PaymentBurn, is supposed to let a delegate destroy designated tokens, yet a software defect means that under certain conditions the operation creates tokens instead, the inverse of the intended effect and one that touches token supply directly. The XRPL documentation on permission values warns operators not to grant that specific permission until the cleanup amendment is live. Other repairs in the update correct how vault withdrawals are calculated, tighten the rules for declaring a loan overdue, and prevent certain automated market maker trades from destroying liquidity tokens without returning the underlying assets, a corner of the ledger that liquidity providers active in yield farming watch closely.

Approval of the product itself has stalled, however. The proposed lending protocol would let users pool assets on the ledger and borrow on fixed terms; borrowers would not necessarily post collateral, and brokers would arrange loan terms and assess credit standing off the blockchain. Turning the full system on requires three separate amendments, and between October 15 and 17 the two lending amendments each held about 17 to 19 supporters, roughly 53%, while the required SingleAssetVault amendment counted about 19 to 21, which is why it is required alongside the other two. None has reached the supermajority, so the feature carries no activation date. Holders who keep XRP in a wallet, including an offline Ripple paper wallet, need take no action, though the delegation defect is a fresh reminder of how key discipline fails in practice, the subject of David Schwartz's scam-link warning in our earlier coverage.

Read together, the votes show validators prioritizing repairs over financial products. October 23 hardens the rails a lending system would run on, yet the product itself stays switched off until three amendments each clear the same 80% bar, with no date in sight. The practical test is the fortnight ahead: one dip below the support floor before activation resets the countdown and delays the security fix, while passage lets node operators retire the burn-permission exposure the official documentation has flagged since the delegation feature went live on October 8.