Blab Crypto
XRPL Activates fixCleanup3_3_0 Amendment, Forcing Outdated Servers to Upgrade
On September 11, 2026, the XRP Ledger (XRPL) activated the fixCleanup3_3_0 amendment at 11:29 UTC in ledger 106,911,489, as confirmed by XRPSCAN. The amendment bundles a set of bug‑fixes that were introduced with the xrpld 3.3.0 release on August 6. The fixes address transaction handling, automated market makers (AMMs), vaults, lending, Checks, and pseudo‑accounts, and are now part of the network’s live rules.
The activation of fixCleanup3_3_0 means that any server that does not support the amendment becomes amendment‑blocked. According to XRPL documentation, an amendment‑blocked server cannot determine whether ledgers are valid, submit or process transactions, or participate in consensus. Restoring these functions requires running software that includes the amendment, and the project recommends operators upgrade to the latest xrpld release.
XRPSCAN reported that 31 of 35 validators were supporting the amendment at 01:45 UTC on September 12, surpassing the required threshold of 28. The public XRP Ledger endpoint also showed the amendment enabled on September 12. While the amendment is live, the features that were bundled with xrpld 3.3.0—such as the Native Lending Protocol, Single Asset Vaults, and permissioned trading—remain disabled until separate amendments are activated.
The code changes that triggered the amendment include:
CheckCash and CheckCancel now reject an all‑zero CheckID during preflight with the error temMALFORMED. A narrow divide‑by‑zero condition in AMMWithdraw returns tecAMM_FAILED instead of the generic tefEXCEPTION. Freeze handling for transfers involving pseudo‑accounts has been tightened. Safeguards around AMMs, permissioned markets, and cleanup processes have been strengthened.
These corrections were available in the xrpld 3.3.0 code base for weeks, but the amendment’s activation marks the point at which they become mandatory for all nodes.
The amendment system on XRPL is unique in that it allows new code to be distributed before validators make it part of the consensus rules. Once an amendment secures the required majority for the prescribed period and activates, servers that do not support it can become blocked. This process is designed to give operators time to upgrade while protecting the network’s integrity.
Several other amendments that were introduced with xrpld 3.3.0 remain disabled as of September 12. These include LendingProtocol, SingleAssetVault, BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, and Sponsor. Ripple’s public server reports support for these amendments, meaning the software can recognize them even though validators have not yet activated them.
For users who rely on maintained wallets or exchanges, the responsibility for compatibility largely falls on service providers. Firms that operate their own XRPL servers now face an immediate requirement to keep their systems current as validator‑approved amendments move from optional code into the ledger’s active rule set.
In summary, the activation of fixCleanup3_3_0 has tightened transaction handling and AMM logic on the XRPL, but it also imposes an upgrade deadline on outdated nodes. Operators who have not yet upgraded to xrpld 3.3.0 risk becoming amendment‑blocked, which would prevent them from validating ledgers or processing transactions. The network’s governance mechanism ensures that such changes are only enforced after broad consensus, but the practical impact on infrastructure operators is clear: update now or face disruption.
The activation of fixCleanup3_3_0 means that any server that does not support the amendment becomes amendment‑blocked. According to XRPL documentation, an amendment‑blocked server cannot determine whether ledgers are valid, submit or process transactions, or participate in consensus. Restoring these functions requires running software that includes the amendment, and the project recommends operators upgrade to the latest xrpld release.
XRPSCAN reported that 31 of 35 validators were supporting the amendment at 01:45 UTC on September 12, surpassing the required threshold of 28. The public XRP Ledger endpoint also showed the amendment enabled on September 12. While the amendment is live, the features that were bundled with xrpld 3.3.0—such as the Native Lending Protocol, Single Asset Vaults, and permissioned trading—remain disabled until separate amendments are activated.
The code changes that triggered the amendment include:
CheckCash and CheckCancel now reject an all‑zero CheckID during preflight with the error temMALFORMED. A narrow divide‑by‑zero condition in AMMWithdraw returns tecAMM_FAILED instead of the generic tefEXCEPTION. Freeze handling for transfers involving pseudo‑accounts has been tightened. Safeguards around AMMs, permissioned markets, and cleanup processes have been strengthened.
These corrections were available in the xrpld 3.3.0 code base for weeks, but the amendment’s activation marks the point at which they become mandatory for all nodes.
The amendment system on XRPL is unique in that it allows new code to be distributed before validators make it part of the consensus rules. Once an amendment secures the required majority for the prescribed period and activates, servers that do not support it can become blocked. This process is designed to give operators time to upgrade while protecting the network’s integrity.
Several other amendments that were introduced with xrpld 3.3.0 remain disabled as of September 12. These include LendingProtocol, SingleAssetVault, BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, and Sponsor. Ripple’s public server reports support for these amendments, meaning the software can recognize them even though validators have not yet activated them.
For users who rely on maintained wallets or exchanges, the responsibility for compatibility largely falls on service providers. Firms that operate their own XRPL servers now face an immediate requirement to keep their systems current as validator‑approved amendments move from optional code into the ledger’s active rule set.
In summary, the activation of fixCleanup3_3_0 has tightened transaction handling and AMM logic on the XRPL, but it also imposes an upgrade deadline on outdated nodes. Operators who have not yet upgraded to xrpld 3.3.0 risk becoming amendment‑blocked, which would prevent them from validating ledgers or processing transactions. The network’s governance mechanism ensures that such changes are only enforced after broad consensus, but the practical impact on infrastructure operators is clear: update now or face disruption.
