XRP Ledger Amendment of September 11: What Wallet, Node and AMM Users Should Know About fixCleanup3_3_0

On September 11, 2026 at 11:15 UTC the amendment fixCleanup3_3_0 can go live on the XRP Ledger. For you as an investor that means very little in most cases and a great deal in one: if your XRP sits with an exchange or in a maintained wallet app, you have nothing to do. If you run your own node, if you reach the network through a self-hosted interface, or if you hold positions in the ledger's advanced features, then September 11 is your deadline for a version check.

This analysis was carried out by cryptoticker.io itself on September 9, 2026. We asked the chain directly instead of taking the state of play from news reports: through the public interface of an XRPL node, using the feature and ledger_entry calls against the amendments object of the validated ledger. What came out of it differs on two points from what is currently being written about the date.

Amendment fixCleanup3_3_0: what happens on the XRP Ledger on September 11

An amendment is a change to the rules of the XRP Ledger protocol. The network's validators vote on it, and once the vote passes it applies permanently to every following ledger version. Nobody deploys it centrally; it is a switch the majority of operators throw together.

fixCleanup3_3_0 is a bundle of corrections, not a new feature. It tidies up in six places: at the Single Asset Vaults (vault objects that hold a single asset for a protocol), at the Lending Protocol (the planned lending business directly at protocol level), at the Automated Market Makers (trading pools that quote prices through a formula rather than an order book), at the Permissioned DEX (a trading venue that only serves approved participants), at Checks (payment promises the recipient redeems themselves) and at pseudo-accounts (technical accounts that belong to no human being because a protocol object holds them).

In concrete terms, the bundle harmonises the freeze checks on transfers from pseudo-accounts, rejects malformed check identifiers at the preliminary stage, fixes an error when removing hybrid offers, and adds a check for rounding losses on deposits, withdrawals and clawbacks in AMM pools, provided the older amendment fixAMMv1_3 is active as well. On top of that comes a new invariant called ObjectHasPseudoAccount, which makes sure that deleting a ledger entry also removes the associated pseudo-account.

That sounds like detail work, and it is. Which is precisely why the news is not a price story for you, but a maintenance story with a hard deadline.

The 80 percent rule: how an XRPL amendment is activated in the first place

The procedure is set out in the amendment documentation of the XRP Ledger and it is strict. An amendment needs the approval of more than 80 percent of the validators a server listens to, and it needs that support for two weeks without interruption. If support drops to 80 percent or below in the meantime, the clock starts again from zero. An amendment can win and lose that majority several times before it finally goes through.

The count happens at so-called flag ledgers, meaning every 256th ledger, which on average works out at roughly a quarter-hour rhythm. At the flag ledger the validators cast their votes, one ledger later the network writes a pseudo-transaction with the result, and two ledgers after the flag ledger the new rule takes effect on transactions. Activation therefore follows a count, not a ceremony at a round hour.

Anyone who knows the pattern will recognise it from other networks. On Solana, the activation of a protocol change likewise hangs on the stake weighting of the operators; we wrote that up in our article on the Alpenglow activation. The difference lies in the detail: on the XRP Ledger the two-week period is anchored in the protocol and can therefore be read off the ledger itself.

Counted on the ledger ourselves: 93 active amendments, eleven open, one majority

On September 9, 2026 at 00:52 UTC we queried a public XRPL node which at that moment carried the validated ledger with the number 106,856,830 and reported server version 3.3.0. Method: a feature call for the list of all amendments known to the server, plus a ledger_entry call against the amendments object of the ledger for the official state. All 104 amendments this server knows about were checked.

The result in figures: 93 amendments are active, eleven are open. Of those eleven, exactly one carries a majority entry in the ledger, namely fixCleanup3_3_0. The closing time stored for that entry in the object converts to August 28, 2026, 11:15 UTC. Add the prescribed fourteen days and you get the earliest possible activation moment: September 11, 2026, 11:15 UTC.

That allows two figures currently in circulation to be set straight. First, the start of the vote is dated in some reports to August 6; what counts for the deadline, however, is solely the moment the majority first stood, and according to the ledger that is August 28. Second, several reports give 11:15 in US Eastern time. The ledger keeps its time in UTC, which puts the moment in the middle of the day on September 11 for readers in Europe.

One caveat belongs with this: what we measured was the state of one node; it does not cover the vote of every single validator. The most recently reported approval rate of 82.86 percent with 29 yes votes comes from third-party analysis and is a snapshot. Whether it stays above the threshold until September 11 is something nobody can promise today.

Single Asset Vault and Lending Protocol are not even live on mainnet yet

The most important finding of our query does not appear in the reports about the date. In the same list of eleven open amendments stand SingleAssetVault and LendingProtocol themselves. Both are therefore not yet switched on for mainnet. The same goes for ConfidentialTransfer, DynamicMPT, BatchV1_1, Sponsor, XChainBridge, PermissionDelegationV1_1, CryptoConditionsSuite and fixXChainRewardRounding. None of these ten amendments currently carries a majority entry.

From that follows a piece of reassurance worth remembering: if somebody tells you that you have to secure your vault or lending position on the XRP Ledger before September 11, they are describing a state of affairs that does not exist on the main network. You cannot hold a lending position directly on the XRPL protocol today, because the function is not active.

The fix, in other words, is being built in before the function opens. In software development that is the normal case and a good sign: errors found on test networks and in audits are cleared away before launch. For you it mainly means you should treat offers advertising XRPL-native lending today with scepticism. Anyone looking for yield on crypto assets will currently find it with custodians and trading venues, whose terms deserve a closer reading in every case than any announcement about a protocol function that is not yet switched on.

Amendment blocked: why an outdated node drops out of consensus

Amendment blocked is the state a server falls into when a rule its software version does not know becomes active on the network. The documentation is unambiguous on this point: a blocked server can no longer validate ledgers, can no longer submit or process transactions, can no longer take part in consensus and can no longer vote on future amendments. It stands still.

That is the real reason for the deadline. Anyone running a node has until activation to switch to a version that knows fixCleanup3_3_0. The public node we queried was running 3.3.0 at the time of measurement and reported no block. A server that lags behind will report one immediately after activation, and the disruption shows up at the moment an application runs into nothing.

The documentation also names a property many people underestimate: a server always follows the amendments the rest of the network has activated, regardless of how it voted itself. A no vote therefore does not protect an outdated server. Only an update does.

XRP on an exchange: what to check with your provider before September 11

If your XRP sits in the account of a trading platform, the node belongs to the provider. The duty to update therefore lies with them, and as a rule a switch like this passes unnoticed. Even so, a quick look before a protocol deadline is worth it, because platforms occasionally pause deposits and withdrawals for a chain for the duration of an upgrade.

The route to that is always the same. Open your provider's status or announcements page, search for the network name, and see whether a maintenance window is entered for September 11. If you find nothing, nothing is planned. Whether your provider announces such a window at all is one of the points on which platforms differ considerably.

Three questions to settle on your own account

The first question is whether you have any movements planned for September 11 at all. A withdrawal that runs a day earlier or a day later costs you nothing. The second question concerns automated orders: a savings plan or a recurring withdrawal that fires at that midday hour belongs in your calendar. The third question is the most uncomfortable and at the same time the most important: do you know for certain where your XRP is? Across several accounts held over years, that answer is less clear-cut more often than it should be.

A note on the scope of the effect. fixCleanup3_3_0 changes nothing about ordinary payments, nothing about balances and nothing about the validity of your addresses. Anyone who holds XRP and sends it will in all probability notice nothing whatsoever on September 11. The corrections bite on objects that play no part in the daily life of most investors.

Your own wallet and your own node: the version check in three steps

Things look different if you run infrastructure yourself. That affects more people than the term suggests: anyone using self-hosted wallet software with its own network access, anyone settling payments through their own interface, or anyone keeping a node running for a small service, is under the same obligation as a professional operator.

The first step is the version query on your own server. The server_info call returns the field build_version and also the field amendment_blocked, which shows the blocked state directly. If it says version 3.3.0 or higher, your software knows the amendment.

The second step applies to the wallet you use every day. Open the settings, find the version number and compare it with the provider's current release. Anyone who lets their wallet update automatically through the app store is usually on the safe side here; anyone maintaining a desktop version by hand often is not. Which wallet programs are properly maintained and which have stood still for months is shown by our software wallet comparison, with the update status of each.

The third step concerns everything that sits between you and the chain: a script, an accounting tool, a portfolio tracker with its own network access. Check which endpoint these tools talk to, and whether that endpoint is maintained. A blocked node will at some point simply stop answering, without spelling out an error message in plain language.

AMM positions on the XRP Ledger: what the precision fix changes on deposits and withdrawals

One part of the bundle concerns a function that really does run on mainnet: the Automated Market Maker of the XRP Ledger. An AMM is a trading pool into which two assets are deposited and which sets its prices through a fixed formula; whoever deposits receives shares in the pool and in return carries the risk of an unfavourable price move between the two assets.

The correction adds a check for rounding losses on deposit, withdrawal and clawback, specifically when the older amendment fixAMMv1_3 is active as well. Rounding losses arise when a calculation with a limited number of digits cuts off decimal places on very small or very unevenly distributed amounts. In total those are tiny sums, but in unfavourable combinations they can be exploited deliberately.

If you hold shares in an XRPL AMM pool, activation changes nothing about your holding. It may be, however, that a transaction which went through until now is rejected with an error after September 11 because the new check bites. That is the intended effect. So do not plan tightly timed reallocations for activation day, and expect a rejected transaction to need a second, adjusted attempt.

Timeline until activation: what happens between September 9 and September 11

Until the deadline the count simply carries on. Roughly every fifteen minutes the network reaches a flag ledger, the validators cast their votes, and the majority entry in the amendments object stays in place as long as approval is above 80 percent. If it falls below at one of those points, the entry disappears and the fourteen days start again.

That is why September 11 counts as the earliest possible date and not as a commitment. Whether activation actually takes place that midday can only be said on the day itself. Anyone who wants to know precisely can query the state at any time, exactly as we did for this article, or follow the developer blog of the XRP Ledger, where releases and activations are announced.

How to recognise that activation has happened

After activation, fixCleanup3_3_0 moves in the feature query from the list of open amendments to the list of active ones, and the number of active entries in the amendments object rises from 93 to 94. That is the cleanest confirmation there is, and it works without any report from outside.

What the date means for the XRP price, and what it does not

Restraint is in order here. A bundle of fixes that harmonises internal checks and catches rounding losses is not an event from which a price direction could be derived. It raises no transaction capacity, lowers no fees and unlocks no new function.

What it does is indirect and slow: it clears errors out of precisely those building blocks on which the still-pending functions for vaults and lending are meant to sit. Anyone who ties the valuation of a network to its future feature set will read that positively. Anyone looking for short-term movement will find nothing here. Both are assessments and not forecasts; the current price situation and the arguments on both sides are something we collect continuously on our XRP page.

A remark on how to read the coverage: over the past few days the date has been described in several places as a "major upgrade". Judging by what is in the bundle, that description does not hold. This is maintenance on advanced objects, two of which are central and not even switched on for the main network.

Checking the XRP Ledger amendment: what to take away

1. First establish where your XRP is. On a trading platform the provider carries the duty to update, and all you check is their status page for a maintenance window on September 11. In self-custody the duty is yours. If this question makes you pause, that is the real finding of the day: sort out your holdings and look at which custody solution suits you, for instance in the hardware wallet comparison.
2. Check the version of every piece of software that talks to the network itself. On your own server, server_info shows the fields build_version and amendment_blocked; 3.3.0 or higher is the safe state. For wallets a glance at the settings is enough. Anyone noticing that their program has not seen an update in months will find maintained alternatives in the software wallet comparison.
3. Push planned reallocations back by a day. If you hold shares in an AMM pool or have larger movements planned for September 11, move them to September 10 or September 12. And if offers reach you that already advertise lending directly on the XRP Ledger, compare them with the routes actually available in the crypto lending comparison before you move any money.

(As of September 9, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)