Update, 22 October 2026, 05:30 UTC: fixCleanup3_4_0 will not go live on 23 October after all. Its support fell to 26 of 35 trusted validators at the 12:54 UTC flag ledger on 21 October, below the 29 now needed, and was back at 29 by 14:46 UTC, which restarted the two-week countdown. Activation is now expected at about 14:46 UTC on 4 November if the majority holds; at 04:38 UTC on 22 October it had 31 of 35 votes, according to the trackers XRPL Dashboard and XRPLWin, figures also reported by CoinDesk. The lending amendments still have no majority, with 19 of 35 votes each.
On 17 October the XRP Ledger looked less than six days away from switching on its latest bundle of fixes, while the native lending feature that drew most of the attention this year still lacked the votes to go live. The XRP Ledger amendment called fixCleanup3_4_0 had the support of 26 of the 32 trusted validators counted on the latest ledgers, or 81.25%, according to XRPScan at 19:27 UTC on 17 October. It had held that majority since 09:34 UTC on 9 October, which then put its activation at about 09:34 UTC on Friday 23 October. A dip of under two hours on 21 October has since moved that date to 4 November.
The two lending amendments, LendingProtocol and its revised version LendingProtocolV1_1, each had 17 of 32 votes (53.1%) at the same time, on the same data. SingleAssetVault, the vault standard that lending is built on, had 19 (59.4%). None of the three has a majority, so none has a date.
Bitcoin.com News reported the same split on 17 October, with slightly different counts because the number of validators voting moves from one ledger to the next. Bitcoin.com put fixCleanup3_4_0 at about 26 to 29 supporters out of 32 to 35 over the past days. Unless stated otherwise, this piece uses the XRPScan figures of 19:27 UTC on 17 October.
How an XRP Ledger amendment goes live: 80% for two weeks
The XRP Ledger has no miners and no on-chain token vote. Changes to the rules that every server applies, from a new transaction type to a rounding fix, arrive as amendments, and the network’s validators decide when they switch on. Each validator flags every amendment it knows as yes or no, and servers tally those flags on every flag ledger, one ledger in 256, which comes about every 15 minutes.
The count that matters is not every validator on the network. It is the set that most servers trust, the default list of validators known as the UNL. XRPScan counted 32 of them on the latest ledgers at 19:27 UTC on 17 October.
The rule itself is short. The known amendments page on XRPL.org says amendments “can become enabled if they hold a supermajority for at least two weeks.” The XRPL.org page on how amendments work sets that supermajority at more than 80% of trusted validators. Exactly 80% is not enough. A fix enabled in April 2021, fixAmendmentMajorityCalc, closed a rounding gap that once let an amendment pass with 28 of 36 validators (77.8%); since then the minimum is never below 80% of the trusted list.
If support drops to 80% or below at any point in those two weeks, the amendment loses its majority and the clock stops. When it regains one, a new 14-day countdown starts from zero.
On 17 October, fixCleanup3_4_0 held its majority by a single vote
Eighty per cent of 32 validators is 25.6. XRPScan lists a threshold of 25 for every amendment voted on by those 32: that is 80% rounded down, the figure support has to exceed. Since the rule asks for more than 80%, the minimum is 26 yes votes. fixCleanup3_4_0 had exactly 26 at 19:27 UTC on 17 October.
That left a margin of one. If a single supporting validator had switched to no, the amendment would have fallen to 25 of 32 (78.1%) and lost the 23 October date. A change in the size of the trusted list could do the same: with 33 validators counted, 80% would be 26.4 and the minimum would rise to 27.
That is how it went. By 21 October the trackers counted 35 trusted validators, which put the minimum at 29, and support stood at 26 at the 12:54 UTC flag ledger. Whether the longer list caused the dip, or some validators changed their vote or went offline (an offline validator counts as a no), is not known: neither XRPL Dashboard nor XRPLWin names the validators that dropped out.
On 17 October there was no sign of a switch: the majority had held without a break since 9 October. Six validators in the count were not voting yes at 19:27 UTC that day, and their reasons are not public.
Default settings matter too. According to XRPL.org, the latest stable release of xrpld ships with fixCleanup3_4_0 set to “No” by default, so the 26 operators supporting it on 17 October switched it on themselves.
The vote count on 17 October, amendment by amendment
The table below shows the amendments still open on the XRP Ledger, with the votes XRPScan recorded at 19:27 UTC on 17 October. The XLS number is the XRP Ledger Standard that describes each feature.
| Amendment | XLS standard | Votes | Share | Status |
|---|---|---|---|---|
| fixCleanup3_4_0 | None (bundle of fixes) | 26 of 32 | 81.25% | Majority since 9 Oct, 09:34 UTC (then due 23 Oct; lost on 21 Oct, now due 4 Nov) |
| SingleAssetVault | XLS-65 | 19 of 32 | 59.4% | No majority |
| ConfidentialTransfer | XLS-96 | 19 of 32 | 59.4% | No majority |
| LendingProtocol | XLS-66 | 17 of 32 | 53.1% | No majority |
| LendingProtocolV1_1 | XLS-66 | 17 of 32 | 53.1% | No majority |
| DynamicMPT | XLS-94 | 15 of 32 | 46.9% | No majority |
| Sponsor | XLS-68 | 9 of 32 | 28.1% | No majority |
Source: XRPScan amendments data, 17 October 2026, 19:27 UTC. An older fix, fixBatchInnerSigs, which XRPScan marks as deprecated, had 10 votes out of 35 in an older snapshot of the validator list at the same time.
Several amendments have already gone through in recent weeks. PermissionDelegationV1_1 (XLS-75) was enabled at 21:29 UTC on 8 October with 28 of 33 votes. The next day, fixBatchV1_2 was enabled at 14:15 UTC with all 32 votes, followed by BatchV1_1 (XLS-56) at 14:47 UTC with 27 of 32.
Those dates also show how the switch happens. BatchV1_1 gained its majority at 14:46 UTC on 25 September and went live at 14:47 UTC on 9 October, two weeks and under two minutes later. The change lands on the first flag ledger after the two weeks are up, so 09:34 UTC on 23 October was the earliest time under the first countdown. Under the new one it is 14:46 UTC on 4 November, and XRPL Dashboard expects the on-ledger steps to be complete by about 15:03 UTC.
What the cleanup fixes change on the ledger
fixCleanup3_4_0 does not add a feature. It is a collection of corrections to code that is already on the ledger, or waiting to be switched on, and it shipped with xrpld 3.4.0, the server release XRPL.org announced on 16 September.
XRPL.org lists fixes across a long range of areas: Single Asset Vaults, the Lending Protocol, automated market makers (AMMs), the permissioned blockchain, where users swap tokens directly from their own wallets without handing custody of their funds to a company.">decentralised exchange, trust lines, NFTs, multi-purpose tokens (MPTs), escrow, sponsorship, transaction signing and permission delegation. A few of the changes give an idea of the scale.
- An account with no trust line can no longer use an offer to receive tokens from an issuer that has switched on the flag blocking incoming trust lines.
- Clawback rules for AMM pools are tighter, including how they treat the last holder of a smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool’s tokens, and vault clawbacks get a rounding correction.
- Counterparty and sponsor signatures get separate signing prefixes, so that one kind of signature cannot be replayed as the other.
- Finishing or cancelling an escrow releases its owner reserve first, so returning tokens at the reserve limit no longer fails.
- Vault withdrawals accept credential IDs, and deposits, withdrawals and clawbacks round more precisely.
- A loan default is exempt from freezes and MPT locks on the transfer from the broker to the vault.
Separately, the 3.4.0 release retires an older amendment, fixAMMOverflowOffer, whose behaviour becomes a permanent part of the protocol.
Why token issuers are waiting for the PaymentBurn fix
One fix has a direct, practical use. PermissionDelegationV1_1, live since 8 October, lets an account hand specific powers to another account. One of those powers, the PaymentBurn permission, is meant for destroying tokens. XRPL.org warns that before the fix, a delegate holding it “can also mint new fungible tokens” in certain circumstances, and recommends not delegating PaymentBurn until fixCleanup3_4_0 is enabled. The fix makes the ledger reject a burn-only payment that would cross a zero balance into a mint, unless the delegate also holds the PaymentMint permission.
The issue concerns tokens issued on the ledger, such as trust-line tokens and MPTs, and XRPL.org says other permissions are unaffected. It does not concern the supply of XRP, the ledger’s native asset. Issuers and custodians who have set up delegation should keep PaymentBurn out of it until the amendment is enabled, and check that it is.
What node operators need to do before 4 November
For most operators, the answer is nothing new. A server needs to know an amendment before the network enables it; if it does not, it becomes amendment blocked. A blocked server cannot apply the new rules, so it stops following the network and can no longer validate or serve current ledger data. Funds on the ledger are not at risk. The service the node provides, to a wallet, an exchange or an application, is.
The code for fixCleanup3_4_0 has been in xrpld since version 3.4.0. In practice, though, the deadline that mattered already passed on 9 October. The emergency release xrpld 3.4.1, announced on 25 September and tagged on GitHub on 10 October, which hardened the payment engine against the flaw covered in our report on the XRP Ledger overflow bug, also carried fixBatchV1_2, and that amendment was enabled on 9 October. XRPL.org warned that servers not updated to 3.4.1 would become amendment blocked and “unable to maintain sync with the rest of the network.”
That leaves three cases:
- Servers on xrpld 3.4.1 or later already contain the fixCleanup3_4_0 code and need no action for this amendment.
- Servers still on 3.4.0 have been amendment blocked since fixBatchV1_2 went live on 9 October, and its operators need 3.4.1 to rejoin the network.
- Anything on 3.3.x or older is blocked for the same reason, and would also lack fixCleanup3_4_0 itself.
Operators who install from packages should note a change that came with 3.4.0: DEB and RPM packages are now served from packages.xrplf.org and signed with an XRPL Foundation key, so systems set up for the old repository need the new source and key.
The cleanup amendments have arrived at a steady pace this year. fixCleanup3_1_3 was enabled on 27 May, fixCleanup3_2_0 on 29 July and fixCleanup3_3_0 on 11 September. If fixCleanup3_4_0 goes live on 4 November, the gap will be close to eight weeks, between the nine and six weeks of the two before it.
XRP Ledger lending protocol: what XLS-65 and XLS-66 would add
Lending is the larger story, and the slower one. It rests on two standards that entered the server code with xrpld 3.1.0.
The first, XLS-65, creates the Single Asset Vault. Users deposit one asset into a shared vault, such as XRP or a token issued on the ledger, and receive shares that represent their part of the pool. The vault is the pot of money; on its own it does not lend anything.
The second, XLS-66, adds the Lending Protocol. A loan broker draws on a vault to make fixed-term loans. XRPL.org describes them as uncollateralised: nothing is locked as security, unlike most DeFi lending, where borrowers post collateral in smart contracts first. Credit checks happen off the ledger, through underwriting and risk management, while repayments, interest and defaults are recorded on it.
The revised version, LendingProtocolV1_1, came with xrpld 3.4.0 and changes the design in two ways. It introduces closed-ended vaults that run in three phases: subscription, when deposits come in, then investment, then redemption. Once it is enabled, new loan brokers can only be created against closed-ended vaults. It also moves vault accounting to a cash basis, so interest counts as income only when a borrower actually pays it.
That design points at institutions rather than retail traders: a fund or a bank could raise a pool for a set period, lend it to vetted borrowers and return it with interest, all recorded on a public ledger. It would fit Ripple’s push to get professional firms using XRP and its RLUSD stablecoin, as in the RLUSD collateral deal at Ripple Prime. None of that can run on the XRP Ledger mainnet until the amendments pass.
Why validators are holding back on lending
Support for lending has grown, but slowly. In early July, Digital Today reported that XLS-66 had about 20% of validator votes and XLS-65 had 22.86%. By 17 October, both lending amendments stood at 53.1% and the vault at 59.4%.
In the same Digital Today report, dated 1 July, RippleX software engineer Mayukha Vadari said validators were waiting for the fixes in the next cleanup amendment, adding: “Safety first.” The bundle she meant was fixCleanup3_2_0, enabled on 29 July. Graffe, a validator operator cited by the outlet from a post on X, said progress on XLS-65 and XLS-66 was very slow and that the vote numbers had hardly changed for a long time.
Our reading, which no validator has confirmed for this release, is that the same logic now applies to fixCleanup3_4_0. The bundle patches vault and lending code directly, and an operator who wants those patches live before turning lending on would wait for the bundle to go live, now expected on 4 November. The October overflow scare gave operators one more reason to move carefully.
The gap is still wide. With 32 validators counted, LendingProtocolV1_1 needed nine more yes votes at 19:27 UTC on 17 October to reach 26, and SingleAssetVault needed seven. At 04:38 UTC on 22 October, both lending amendments had 19 of 35 votes each, ten short of the 29 now required, according to XRPL Dashboard and XRPLWin; SingleAssetVault had 21, according to XRPLWin. Even if they arrived tomorrow, each amendment would then need two more weeks of steady support. Bitcoin.com notes that all three amendments needed for full lending sit below the supermajority, with no activation date. Neither RippleX nor the XRPL Foundation has published a lending timeline that we could find.
What to watch until 4 November, and after
The first date is fixed by the rules. If fixCleanup3_4_0 keeps more than 80% of trusted validators (29 of 35 at the 22 October count) at every flag ledger until about 14:46 UTC on Wednesday 4 November, it switches on at the next flag ledger and the PaymentBurn warning can be lifted. It has already happened once: a dip of under two hours on 21 October cost it 12 days. Any new dip would start the count again.
After that, the vote counts on SingleAssetVault and the two lending amendments are the figures to follow, on XRPScan or XRPL.org. A jump in support in the days after 4 November would fit the reading above; no change would suggest validators want something else first. No new xrpld release or amendment has been announced.
Markets have not reacted to the vote. XRP traded near $1.30 at 19:10 UTC on 17 October, down 7.5% over seven days according to Coindaro market data, and nothing ties that move to the amendment schedule. Readers new to how validators and ledgers fit together can start with our guide to what a blockchain is.