XRPL 3.3.0 Nodes Hit 62 Percent as FixCleanup Nears 80 Percent Bar

More than 60 percent of XRP Ledger nodes now run xrpld 3.3.0, with upgrade tallies putting the figure at 62.5 percent of nodes and 68.5 percent of validators. XRP Ledger Operations posted an urgent call for the rest to update before mainnet activation of the accompanying amendments can leave older software amendment-blocked.

fixCleanup3_3_0 has reached roughly 68.57 percent validator consensus, less than 12 points shy of the 80 percent supermajority that starts a mandatory two-week clock. Six amendments ride on the same binary, and the package is no longer a distant software note.

The 62.5 Percent Node Threshold and the Remaining Gap

XRP Ledger Operations stated on 23 August that over 60 percent of network nodes had already moved to version 3.3.0. Separate tallies circulating the same day fixed the node figure at 62.5 percent ready and the validator share at 68.5 percent updated. The account repeated the warning that nodes on older versions risk becoming amendment-blocked once any of the new features activate.

• 62.5% of all tracked nodes on 3.3.0
• 68.5% of validators updated to the release
• 80% validator support required to start any amendment’s activation window
• ~68.57% current support for the leading fixCleanup3_3_0 amendment

The gap between updated validators and the full node set mirrors earlier rollouts. When 3.2.0 shipped, UNL validators reached high double-digit adoption weeks before the broader node population cleared 50 percent. The same pattern is visible now, only the stakes include a larger feature set.

Roughly 37 percent of tracked nodes still sit on older binaries. That share does not vote on amendments, yet it must still understand every rule the validators enable. The distance from 68.5 percent validator readiness to the 80 percent line is smaller than the distance from 62.5 percent node readiness to full coverage, which is why the Operations warning targets operators rather than the UNL alone.

Until node adoption climbs into the high 70s or beyond, each day of further delay keeps a wide slice of the network one sustained supermajority away from the blocked state. The validator tally can move first; the operational risk still lands on everyone else.

Six Amendments Riding on One Binary

Version 3.3.0, released 6 August, ships six amendments for voting plus performance work that cuts memory use by at least 10-15 percent in many configurations and improves node synchronization after the 3.2.0 experience. The xrpld 3.3.0 release notes and changelog list the new proposals in full.

The release also retires five long-active amendments (Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve, fixUniversalNumber), folding their behavior into the permanent core. Operators who stay on older code will still face the new rules once any fresh amendment enables.

Shipping the six proposals in a single binary means one upgrade covers atomic settlement, confidential amounts, mutable MPT controls, delegated permissions, sponsored fees, and the cleanup bundle together. Operators cannot pick the performance work and skip the feature votes; the code path is shared. That design raises the cost of delay and the value of an early move to 3.3.0.

fixCleanup3_3_0 Sits Closest to the 80 Percent Line

Multiple trackers put fixCleanup3_3_0 at 68.57 percent support among the default Unique Node List of 35 validators as of 24 August. That leaves it short of the 28-yes votes needed for a majority. Ripple has already voted yes on the bundle and on PermissionDelegationV1_1. Other proposals remain further back; early post-release counts showed most of them in single digits or low teens before the latest climb.

An earlier look at the fixed Batch and Confidential features noted that the V1_1 suffixes exist precisely because the original Batch and PermissionDelegation drafts were withdrawn after security researchers found flaws. The registry still carries residual vote counts on the old identifiers, a trap for anyone reading unfiltered trackers.

Less than 12 points separate the leading amendment from the supermajority line. Because support must hold continuously, a brief dip at any flag ledger resets the two-week clock even after the threshold is first crossed. The other five amendments still trail, so the near-term activation path runs through the cleanup bundle first.

What Happens When Support Crosses 80 Percent

The XRP Ledger does not flip a feature the moment a majority appears. Per the official amendment process and blocked servers documentation, support must hold above 80 percent continuously for two weeks. Flag ledgers every 256 ledgers (roughly every 15 minutes) re-evaluate the votes. A drop to 80 percent or below resets the timer.

1. Flag ledger -1: validators include amendment votes in their validation messages.
2. Flag ledger: servers tally trusted votes.
3. Flag ledger +1: an EnableAmendment pseudo-transaction appears with tfGotMajority or tfLostMajority as needed.
4. After two sustained weeks: the amendment enables permanently on the next applicable ledger; older servers that lack the code become amendment-blocked.

Blocked servers stop validating ledgers, submitting or processing transactions, participating in consensus, and voting on future amendments. The only exit is an upgrade to software that contains the enabled code. The voting configuration itself has no bearing on the block; only the presence of the source does.

Please update your XRPL nodes to 3.3.0! Over 60% of $XRP Ledger nodes have already been updated to version 3.3.0. This version includes, among other improvements, the feature amendments Batch, Dynamic MPT, Permission Delegation, Sponsor, and Confidential Transfer, as well as a fix bundle.

XRP Ledger Operations, @XRPLOperations, 23 August 2026

The same account’s post, amplified by XRPL Commons and community operators, framed node adoption itself as the quiet vote that precedes the formal tally. Replies zeroed in on the enterprise package arriving together: atomic settlement, role separation, sponsored onboarding and confidential amounts as one infrastructure drop rather than staggered experiments.

Once the two-week window opens, the network is on a fixed schedule. Operators who wait for the EnableAmendment pseudo-transaction before scheduling downtime will already be late. The process above leaves no grace period after the final flag ledger that confirms sustained support.

Node Operators Carry the Real Operational Risk

Validators decide the rules. The broader set of node operators must still run code that understands those rules. When an amendment enables, any server missing the implementation enters the blocked state automatically. That risk is why the foundation and Operations accounts are pressing the remaining roughly 37 percent of nodes now, while fixCleanup is still short of the bar rather than after it clears.

History supplies the template. The prior 3.2.0 node sync problems left a large share of non-validator nodes lagging even after UNL validators had largely moved. When fixCleanup3_2_0 finally enabled, operators who had delayed faced the exact blocked-server outcome the docs describe. A parallel pattern appeared when an earlier amendment cleared while exchanges still ran outdated software; the how exchanges lagged a previous amendment episode showed service disruption risk even for parties that do not vote.

A blocked server loses several functions at once:

• Validating new ledgers
• Submitting or processing transactions
• Participating in consensus
• Voting on later amendments

The current release improves synchronization and trims memory, which should ease the operational cost of upgrading. That does not remove the hard requirement to be on 3.3.0 or later before any of the six amendments activate.

Earlier Bugs Forced the V1_1 Rerun

Batch and PermissionDelegation both appeared in earlier software, failed security review, and were pulled. The V1_1 versions that ship in 3.3.0 carry new amendment IDs. Votes cast for the withdrawn originals do not transfer. Trackers that still surface the old names can give a false picture of progress. StaticBit.io documented the mismatch the day after the 3.3.0 release, noting that residual counts on the deprecated identifiers had no path to activation.

1. 6 August 2026: xrpld 3.3.0 published with the six new amendments open for voting.
2. Early August: initial vote counts in single digits; 16 of 35 dUNL validators already on the binary within a day.
3. Mid-August: two-week initial voting window for the proposals closes without any having reached sustained 80 percent.
4. 23-24 August: Operations issues the node-upgrade call; fixCleanup3_3_0 reported at 68.57 percent; node adoption above 60 percent.

Ripple’s yes votes on fixCleanup and PermissionDelegation added early institutional weight, yet the threshold still requires a broad UNL majority that holds for fourteen continuous days.

The V1_1 identifiers exist so the ledger can discard the flawed drafts cleanly. Anyone comparing raw tracker output across the old and new names without filtering will misread momentum. Only the IDs shipped in 3.3.0 can cross 80 percent and start a clock.

Performance Work Lowers the Upgrade Burden

Version 3.3.0 is not only a feature vehicle. The same binary cuts memory use by at least 10-15 percent in many configurations and improves node synchronization, directly addressing pain left from the 3.2.0 rollout.

That matters for the operators still off the release. Earlier lag came in part from sync friction after validators had already moved. Lower memory pressure and cleaner catch-up reduce the excuse set for waiting, without changing the hard rule that missing code equals a blocked server once any amendment enables.

The performance gains and the six amendments share one upgrade path. An operator who moves for the resource savings also lands on the voting and activation surface for BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, Sponsor, and fixCleanup3_3_0. The reverse is true as well: staying put forgoes both the fixes and the headroom.

The Six Features Arrive as One Drop

Community replies to the Operations call treated the release as a single infrastructure package rather than a queue of separate experiments. Atomic batches of up to eight transactions, granular permission hand-off, third-party fee and reserve coverage, issuer-mutable MPT properties, encrypted MPT balances, and the vaults-lending-AMM cleanup all travel together.

Because activation still follows the ordinary 80 percent and two-week rules, the package can unlock in stages if only some amendments clear first. fixCleanup3_3_0 remains the nearest candidate. The operational message does not change with that sequencing: every node that lacks 3.3.0 is exposed to the first amendment that finishes the clock.

XRP Price and ETF Flows Move on Separate Rails

While the upgrade discussion ran, XRP traded near $1.46 in the source window, up more than 2 percent on the day and roughly 50 percent on the week, with a 24-hour range of $1.45-$1.54. Spot XRP ETF inflows added $39.78 million the prior week and cumulative inflows sat near a $1.55 billion record. Goldman Sachs’ Q2 13F showed $86.5 million across five spot XRP funds. Futures open interest climbed to about $3.72 billion.

Those market numbers sit beside the infrastructure story rather than inside it. Trading volume dipped 20 percent in the 24 hours around the node alert, and the price action tracked a broader crypto rebound more closely than any single amendment tally. The ledger change that matters for operators is still the binary and the vote, not the candle.

The two-week clock has not started. Until fixCleanup or another of the six clears and holds 80 percent, the network remains on the current ruleset. Every day that passes with node adoption stuck below the high 70s or 80s keeps a larger share of operators one activation away from the blocked state. The XRPL Operations update call on X is the clearest public marker of that operational urgency.