blockchain updates

The XRP Ledger has activated a foundational maintenance update that clears the way for multiple upcoming features, including a new lending protocol. Operators running outdated server software now risk becoming unable to process transactions or validate ledgers.

• The fixCleanup3_3_0 amendment went live on September 11 at 11:29 UTC on validated ledger 106,911,489.
• Thirty-one of thirty-five validations supported the amendment against a required threshold of twenty-eight.
• Seven additional feature amendments remain disabled, including LendingProtocol, SingleAssetVault, and ConfidentialTransfer.

• Sept. 11 Date fixCleanup3_3_0 went live on the XRP Ledger network
• 31 of 35 Validations supporting the amendment versus required threshold
• 7 Separate feature amendments still awaiting activation after this update
• Aug. 6 Release date of xrpld 3.3.0 with supporting code

The XRP Ledger activated fixCleanup3_3_0, a package of technical corrections spanning transaction handling, automated market makers, and protocol infrastructure. The amendment became enforceable on September 11 after securing validator approval during its two-week majority period, according to XRPSCAN data. The update bundles fixes across multiple systems including Checks, AMMs, pseudo-accounts, permissioned trading, Single Asset Vaults, and the Lending Protocol, cementing them into the network’s consensus rules.

Amendment activation represents a critical governance process within the XRP Ledger ecosystem. For a proposed change to become enforceable across the entire network, it must secure supermajority support from the network’s validator set during a designated voting window. This decentralized approval mechanism ensures that protocol changes reflect broad consensus among network participants, protecting the ledger from unilateral decisions while allowing gradual evolution of functionality.

Maintenance Fixes Target Edge Cases and Error Handling

The amendment addresses specific transaction failure scenarios that could occur under narrow conditions. CheckCash and CheckCancel operations now reject all-zero CheckID values during preflight validation with a temMALFORMED error, preventing malformed requests from advancing further in processing. A divide-by-zero condition in AMMWithdraw transactions that previously triggered a tefEXCEPTION now returns tecAMM_FAILED instead, improving error clarity.

Additional fixes adjust freeze handling for transfers involving pseudo-accounts and strengthen validation rules around AMM operations, permissioned markets, and cleanup processes. These technical refinements address subtle edge cases that developers and network participants identified during testing phases. While individual fixes may appear minor, collectively they enhance protocol robustness by eliminating unexpected failure modes that could create confusion or operational difficulties.

The code supporting these changes has been available since xrpld 3.3.0 released on August 6, but remained optional until the amendment activated. This staged rollout allows developers and operators to test new functionality before mandatory activation, reducing the risk of unforeseen compatibility issues. Once validators approve an amendment, it transitions from optional software support into mandatory network rules that servers must recognize to remain compatible.

Outdated Servers Face Immediate Operational Constraints

Network operators running unsupported xrpld versions now risk becoming amendment blocked, a state that prevents servers from validating ledgers, submitting transactions, or participating in consensus. This technical constraint exists by design: the network enforces consistency by requiring all validating servers to operate under identical consensus rules. Servers operating under outdated rules cannot reliably interpret new transaction types or ledger state changes introduced by activated amendments.

For exchanges, custodians, payment processors, and other entities operating their own XRP Ledger infrastructure, this creates a practical requirement to update immediately. Delaying upgrades exposes these operators to service interruptions and inability to process customer transactions during peak activity periods. XRPL documentation specifies that restoring full functionality requires deploying software that supports the active amendment, with the project recommending use of the latest appropriate xrpld release.

The operational pressure from amendment activation cycles creates a maintenance burden that grows with each new feature deployment. Network operators must monitor amendment signaling closely, plan upgrade windows, test new versions in staging environments, and coordinate deployment across their infrastructure. This ongoing upgrade cycle differs from traditional software maintenance because amendment activation deadlines are absolute and network-wide, leaving no flexibility for gradual rollouts.

Ripple’s public server reported support for seven additional pending amendments on September 12: LendingProtocol, SingleAssetVault, BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, and Sponsor.

For end users relying on maintained wallets or third-party exchanges, the compatibility burden falls primarily on service providers rather than individual operators. However, firms managing their own XRPL infrastructure now face pressure to maintain current software as validator-approved amendments continuously shift from available code into active ledger rules. Watch for validator signaling on the seven disabled amendments, particularly LendingProtocol and SingleAssetVault, to determine which features activate next and when operators must perform their next required upgrade cycle.