XRP Ledger developers have retired five long-running amendments in XRPLD version 3.3.0. The Aug. 6 release removes obsolete pre-amendment code while preserving every activated feature. XRP holders do not need to update wallets, move funds, or complete any transaction.

The retired amendments are Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve, and fixUniversalNumber. Their established rules now operate as unconditional parts of the core protocol.

Retiring an amendment means removing the pre-amendment code that still exists in the codebase for amendments that were activated some time ago, such as Clawback. RippleX software engineer Mayukha Vadari said the process is a codebase cleanup and does not affect users. Developers kept the older code after activation because it remained useful for investigating historical transactions.

XRP Ledger introduces transaction-processing changes through its amendment system rather than through hard forks, the upgrade mechanism used by blockchains such as Bitcoin and Ethereum. Trusted validators vote on each proposal before it reaches Mainnet. An amendment needs support from more than 80% of trusted validators for two continuous weeks. Support of 80% or lower resets the approval period. Once enabled, the new rule applies permanently unless another amendment changes it.

xrpld initially retains both the new rules and the earlier transaction logic. That approach helps developers reproduce past ledger behavior during testing or investigations. However, the legacy code adds maintenance work and software complexity.

Official XRP Ledger documentation allows developers to retire an amendment after two years of Mainnet activation. Retirement removes the earlier code path and places the approved behavior directly into the protocol. Historically accurate testing can then require the xrpld version that originally processed a transaction.

Features that remain active after retirement

Clawback is the best-known of the five retired amendments. It was activated on Feb. 8, 2024. Issuers of eligible tokens are able to reclaim their tokens if the appropriate account setting is enabled.

The feature does not support native XRP tokens. With Clawback now retired, XRPLD no longer enforces any transaction restrictions from the pre-Clawback era. Issuers still retain the ability to use the same recovery mechanism.

The other four amendments addressed technical issues. fixDisallowIncomingV1 restored trust-line authorizations for users who have disallowed incoming trust lines. fixInnerObjTemplate fixed the inability to read certain properties in automated market makers' objects. fixNFTokenReserve enforced reserve checks when accepting an NFT offer, ensuring accounts do not complete a purchase unless reserve requirements are met. fixUniversalNumber standardized some of the ledger's floating-point numbers.

Six new proposals enter XRPLD 3.3.0

The release also included six new proposals: BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, Sponsor, and fixCleanup3_3_0. Adding these proposals to XRPLD does not activate them on Mainnet, and each one still requires validator approval.

BatchV1_1 would enable an account to submit eight inner transactions. ConfidentialTransfer would enable private multi-purpose token transfers with compliance measures. DynamicMPT would give issuers the ability to update certain aspects of tokens. Sponsor would allow third parties to pay fees on behalf of other accounts and transactions. PermissionDelegationV1_1 would provide account permissions. fixCleanup3_3_0 combines fixes for various protocol functions.

Collectively, these proposals address transaction privacy, account-level permissions, and fee delegation—capabilities relevant to enterprise and regulated tokenization use cases that multiple programmable blockchains are actively pursuing.

XRP Ledger server operators should upgrade to version 3.3.0 to maintain service continuity. Older servers risk becoming amendment blocked if the network activates an unsupported amendment. Amendment blocked servers cannot process transactions, validate ledgers, vote, or join consensus.

All five retirements do not require another validator vote because they mark the completion of transitional periods.