XRP Ledger Retires Five Amendments, Users Unaffected

What xrpld 3.3.0 changes mean for XRPL

The XRP Ledger (XRPL) has moved a set of long-active protocol amendments out of conditional status with the release of xrpld version 3.3.0. Five established amendments were retired from the codebase, while six new amendment proposals were added to the software for potential future activation. Crucially, retirement does not undo a feature: the post-amendment behavior stays in place and end users do not need to take any action. Node operators, however, are urged to upgrade their servers to avoid network incompatibility and amendment blocking.

Which amendments were retired and why it matters

Version 3.3.0 removes pre-amendment code for five previously activated changes: Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve and fixUniversalNumber. Retiring an amendment means the xrpld codebase no longer carries legacy branches that handled transactions before the change existed. The actual rules introduced by those amendments remain part of the protocol permanently — retirement is a cleanup step that reduces technical debt and simplifies maintenance.

Retirement versus removal: clarify the distinction

It’s important to differentiate retiring an amendment from removing a feature. Retirement eliminates the older conditional code paths that were preserved to reproduce historic ledger behavior. The amended behavior that validators already approved and that Mainnet has been running continues without interruption. In short: the rules remain; the backward-compatible, pre-amendment code is removed.

Clawback: the most visible retirement

Clawback is the most widely known of the retired amendments, and the term can be easily misread as feature removal. Clawback was activated on Mainnet on Feb. 8, 2024 and permits qualifying issuers to recover certain issued tokens from holders when the issuer has enabled the clawback setting for their issuing account. Clawback has never enabled reclaiming native XRP. Retiring the Clawback amendment simply removes the code needed to emulate a ledger state before Clawback existed; it does not disable the clawback capability in active ledgers.

The XRPL documentation and the known-amendments listing now mark pre-amendment behavior for Clawback as retired, confirming that the post-amendment logic is part of the protocol core going forward.

Other retired fixes and what they address

The remaining four retirements follow the same pattern: their corrected behaviors remain, while legacy code branches are removed.

• fixDisallowIncomingV1 — corrected a trust line authorization issue.
• fixInnerObjTemplate — fixed errors related to inner Automated Market Maker (AMM) objects.
• fixNFTokenReserve — added reserve checks when accepting NFT offers.
• fixUniversalNumber — unified parts of XRPL’s decimal floating point calculations.

Each of these amendments has been active on Mainnet long enough that the XRPL community considers their post-amendment behavior stable and fundamental, enabling retirement of the legacy code paths without impacting users.

How amendments become permanent: the retirement policy

XRPL’s governance model allows protocol amendments to be proposed and adopted by a validator vote. To activate, a proposal must sustain more than 80% approval among trusted validators for two continuous weeks. After activation, XRPL nodes temporarily retain both the new behavior and the older pre-amendment paths so developers and validators can reproduce historical behavior for debugging and verification.

The official XRPL amendment policy permits retirement of a Mainnet amendment once it has been enabled for two years. Retirement removes the pre-amendment code and converts the amended behavior into an unconditional part of the core protocol. This reduces long-term complexity and the maintenance burden that comes with preserving multiple execution branches inside xrpld.

Why developers wait two years

Maintainers typically wait two years before retiring an amendment because access to the older implementation can be important when replaying historical transactions or diagnosing ledger discrepancies. XRPL’s testing guidance warns that reproducing historically accurate transaction replays may require running the xrpld version that originally processed those transactions after retirement occurs.

New proposals added in xrpld 3.3.0

While five amendments left conditional status, xrpld 3.3.0 introduced six new amendment proposals into the node software: BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, Sponsor and fixCleanup3_3_0. Inclusion in xrpld does not mean these features are active on Mainnet — each still needs to clear the validator approval process before activation.

• BatchV1_1 — would allow accounts to submit multiple inner transactions together (up to eight), improving atomic batching for complex operations.
• ConfidentialTransfer — targets privacy-preserving transfers for Multi-Purpose Tokens, a capability aimed at institutional tokenized assets and private transfers.
• DynamicMPT — proposes more flexible management of selected token properties, enhancing token design options.
• PermissionDelegationV1_1 — refines patterns for delegating permissions and operational control.
• Sponsor — would let third parties sponsor transaction fees and reserve requirements for other accounts, enabling new UX and onboarding models.
• fixCleanup3_3_0 — an internal cleanup proposal to remove obsolete code related to past amendments.

Each of these proposals requires sustained validator support of more than 80% for two continuous weeks before activation. Support levels can fall below the threshold and reset the activation timer, so the community’s ongoing consensus is essential.

Who needs to act: users vs. node operators

For ordinary XRP holders and most wallet users, retirement of these five amendments requires no migration, wallet update, or transaction. The protocol behaviors that wallets and exchanges rely on remain unchanged and permanent.

Server and node operators have a distinct obligation: upgrading to xrpld 3.3.0 is recommended as soon as possible. Running outdated xrpld versions risks becoming amendment blocked if the network activates an amendment your server does not support. Such blockage disrupts participation in consensus and can prevent a node from relaying or validating transactions properly. The community saw this in July when the activation of fixCleanup3_2_0 left nodes on older releases amendment blocked.

Operational best practices

Operators should maintain an upgrade schedule, test new xrpld releases in staging environments, and monitor validator signals for upcoming activations. Ensure backups and snapshot strategies are in place before rolling upgrades, and coordinate with downstream services (exchanges, custodians, indexers) to avoid unexpected service impacts.

Looking ahead: governance and privacy features under review

The XRPL community attention now shifts to validator votes for the six proposals included in xrpld 3.3.0. ConfidentialTransfer is likely to draw particular interest because it expands XRPL’s privacy and institutional token capabilities. If validators approve these proposals, they will change how institutional and retail flows can be structured on XRPL — but for now, they remain proposals awaiting the standard approval process.

Meanwhile, the retirement of five legacy amendments reinforces a trend toward reducing technical complexity while locking in protocol behaviors that have proved stable in production. Retirement is not a change in network functionality; it is a maturation step for XRPL’s codebase and governance lifecycle.

Bottom line

xrpld 3.3.0 cleans up legacy code by retiring five long-established amendments while adding six new amendment proposals to the software stack. Users do not need to act: the amendments’ behaviors remain part of the protocol. Node operators should upgrade promptly to maintain compatibility and avoid amendment blocking. As the network evaluates new proposals like ConfidentialTransfer and BatchV1_1, the validator voting process will determine whether these next-generation features become active on Mainnet.