A major XRP Ledger protocol update has gone live, enforcing new transaction rules and putting non-updated servers at risk of being blocked as the network prepares for a future lending protocol rollout.
Operators running outdated XRP Ledger servers now face a clear choice: update their systems or risk being cut off from the network. The fixCleanup3_3_0 amendment, activated on September 11, 2026 at ledger 106,911,489, has turned what were previously optional code changes into mandatory protocol rules. This shift affects exchanges, custodians, and payment companies that maintain their own XRPL nodes.
Enforced protocol changes
Once an amendment activates, servers that do not support it become amendment blocked and can no longer validate ledgers, process transactions, or participate in consensus.
Among the changes: transaction paths now face stricter validation, closing off edge cases that previously slipped through. CheckCash and CheckCancel operations now reject all-zero CheckIDs during preflight, and a divide-by-zero error in AMMWithdraw returns a specific error code instead of causing an exception. Other fixes address freeze handling for pseudo-accounts and add safeguards around AMMs and permissioned markets, as detailed in the XRPL amendment registry and independent reports.
Operational impact for node operators
XRPL's amendment system lets new code be distributed before validators make it part of the network's consensus rules. Once an amendment is active, any server that doesn't support it is amendment blocked-unable to validate ledgers, process transactions, or join consensus. For businesses running their own infrastructure, failing to upgrade to the latest supported version of xrpld means immediate operational risk. XRPL documentation is clear: restoring full functionality requires running software compatible with all active amendments.
The XRP Ledger's amendment process is designed to balance innovation with network stability, requiring a supermajority of validator support before new rules become mandatory. This staged approach gives node operators time to upgrade, but once activated, compliance is enforced at the protocol level.
Lending protocol still pending
While fixCleanup3_3_0 lays technical groundwork for new features, not every capability in the 3.3.0 codebase is live. Amendments for LendingProtocol, SingleAssetVault, BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, and Sponsor remain disabled as of September 12. Ripple's public server recognizes these amendments, but validators have not yet made them active network rules. The lending protocol, in particular, is not yet available on mainnet, though the infrastructure is now in place for future activation.
Forced infrastructure upgrades are not unique to XRP Ledger. Cardano's recent Leios upgrade, for example, expanded network capacity but raised questions about user demand and staking sustainability, as reported earlier. For XRP Ledger, the immediate risk is operational: node operators who don't keep up with amendments will be locked out of the network, regardless of their business model.
Network data and validator support
The fixCleanup3_3_0 amendment reached 31 out of 35 validator approvals by 01:45 UTC on September 12, passing the 28-vote threshold for activation. The supporting code has been available since xrpld 3.3.0 was released on August 6, but only now have the rules become mandatory for all servers. Ripple's public endpoint and the XRPL amendment registry confirm the amendment's active status and the pending state of related protocol upgrades.
The amendment process aims to balance innovation with network stability, but it also draws a clear line between operators who keep up and those who don't. As new features move from code to consensus, the cost of delay is immediate: loss of network participation and transaction processing. The current upgrade cycle shows that protocol governance is not just a technical detail-it's a direct operational risk for any business that falls behind.
XRPL's amendment system allows new features and fixes to be distributed before formal activation. This staged process gives node operators time to test and deploy updates, but once an amendment is approved by a supermajority of validators, compliance is required. Servers that don't support the latest rules are automatically blocked from consensus, validation, and transaction processing. For exchanges, custodians, and payment companies, infrastructure maintenance is not optional-falling behind can mean immediate loss of network access and business disruption. The system is designed to protect network integrity and coordinate upgrades, but it also demands operational discipline and timely response to protocol changes.
