XRP Ledger Activates fixCleanup3_3_0 Ahead of Its Lending Protocol

A bundle of protocol corrections called fixCleanup3_3_0 went live on the XRP Ledger's main network on Friday, repairing error handling in code that a lending market and a vault feature will rely on once those are switched on. Validators pushed it past the ledger's activation bar after weeks of voting. The amendment adds nothing a user can see. It corrects behaviour in Checks, automated market makers, permissioned trading and the internal accounts that sit behind newer features. The lending protocol it clears the way for is still disabled.

What the bundle corrects

An amendment on the XRP Ledger is a change to consensus rules that ships inside the server software and stays dormant until validators vote it in. This one is housekeeping. CheckCash and CheckCancel now reject an all-zero check identifier during preflight, the first validation pass a transaction meets, returning a malformed-transaction code instead of taking it further. A divide-by-zero condition in AMMWithdraw returns an AMM failure code where it previously threw a generic exception. Freeze checks on transfers from pseudo-accounts, the internal accounts that back features such as vaults, now work the same way across transaction types. CryptoTicker counts six corrections in the bundle and alone names an invariant forcing a pseudo-account to be removed when the ledger entry that owns it is deleted.

Four accounts, four activation times

The day is broadly agreed and the clock is not. CryptoSlate puts activation at 11:29 UTC on 11 September and anchors it to validated ledger 106,911,489, the only account citing a ledger index. CryptoTicker says 11:15 UTC the same day. U.Today says 14:00 UTC. Hokanews dates the whole thing to 12 September. Three of the four land on Friday, and we could not establish which timestamp is authoritative.

The vote splits the same way. U.Today and Hokanews both report 31 of 35 validators in favour, 88.57%, at activation. CryptoSlate gives 31 of 35 as of 01:45 UTC on Saturday and describes the bar as 28 validators. CryptoTicker, working from a third-party snapshot, has 29 yes votes and 82.86%, with the majority first reached on 28 August. Reporting the vote in August, crypto.news put the requirement at more than 80% of the 35-member default validator list for two consecutive weeks, or roughly 29 votes. Twenty-eight and twenty-nine are not the same threshold, and the published figures do not reconcile.

Servers that never upgraded

The code has been in the open since xrpld 3.3.0 arrived on 6 August. That release put confidential transfers and batching in front of validators, and fixCleanup travelled with them, uncounted in some tallies of what was in voting that week. Operators still running older builds now risk becoming amendment-blocked. A blocked server cannot validate ledgers or process transactions, and it drops out of consensus and future votes until it is updated. The climb was slow: crypto.news reported on 12 August that support stood at 8 of 35 after Ripple's own validator voted yes, with no activation date in sight.

Still switched off

Clearing groundwork delivers nothing to users yet. LendingProtocol, SingleAssetVault, BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1 and Sponsor all remain disabled on mainnet, by CryptoSlate's list. Hokanews alone puts Batch at 71.43% support and Permission Delegation at 51.43%, both short of the bar, and reports that a version 1.1 of the lending protocol is being prepared for the XRPL 3.4.0 release. U.Today dates that release to next week, which nothing else in this sweep confirms. Activity on the ledger has been odd meanwhile, with order-book volume rising 79% while the trader count fell.

The XRP Ledger Foundation's director of community, Hussein Zangana, welcomed the activation in a post carried by U.Today.

"The XRP Ledger just got better! fix amendment went live for protocol hardening and the XRPL is looking great," Zangana said.

Hokanews attributes a differently worded line to the same person, calling the activation an important step in protocol hardening; neither account carries the other's wording. The fix removes reasons to keep a lending vote waiting. Scheduling that vote is somebody else's decision, and no date has been given.