XRP Ledger developers have retired five long active protocol amendments in xrpld version 3.3.0, but the move does not remove their features or require XRP holders to take action. Summary XRPL 3.3.0 retires five long-active amendments, making their post-activation behavior permanent within the core protocol. Clawback remains available after retirement because only obsolete pre-amendment code is removed from xrpld software. XRPL documentation allows amendment retirement after two years of Mainnet activation to reduce legacy complexity. Six new amendments entered version 3.3.0, but each still requires validator approval before Mainnet activation. Node operators should upgrade to version 3.3.0 promptly, while users face no retirement-related action required. RippleX software engineer Mayukha Vadari explained on X that retirement removes old pre-amendment code left behind after a protocol change has operated for years. The amended behavior itself stays in place. Official XRPL documentation confirms that retired amendments become unconditional parts of the core protocol. Retiring an amendment means removing the pre-amendment code that still exists in the codebase for amendments that got activated a while ago (like Clawback). This is purely a codebase cleanup and won’t affect any users.We wait 2 years in case there’s a need for the old code when…— Mayukha Vadari (@msvadari) August 8, 2026 The distinction became important after the Aug. 6 release of xrpld 3.3.0, which retired Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve and fixUniversalNumber. In other words, “retiring Clawback” does not mean XRP Ledger issuers lose clawback functionality. The network is instead dropping the older code path that described how transactions behaved before the amendment became active. XRP Ledger retirement makes old rules permanent The XRP Ledger amendment system allows protocol changes to be introduced without immediately forcing every new rule onto Mainnet. Validators vote on amendments, and a proposal must maintain support from more than 80% of trusted validators for two continuous weeks before it becomes active. Once enabled, the new behavior applies permanently unless another amendment later changes it. During the period after activation, xrpld keeps both the current logic and some pre-amendment code. That legacy code can help developers reproduce old ledger behavior when debugging or verifying historical transactions. However, keeping years of obsolete branches also adds complexity to the codebase. The official amendment documentation says a Mainnet amendment can be retired once it has been enabled for two years. Retirement removes its old code path, stops treating the change as a conditional amendment and incorporates the newer behavior into the protocol unconditionally. Vadari described the process as “purely a codebase cleanup” and said it “won’t affect any users.” She added that developers generally wait two years because the previous implementation can still be useful when debugging older transactions. XRPL’s own testing documentation similarly warns that historically accurate transaction replay may require running the xrpld version that originally processed the transaction after old amendments have been retired. Clawback is not being removed from XRPL Clawback is the most recognizable of the five retired amendments and the easiest to misinterpret. The feature became active on Mainnet on Feb. 8, 2024 and allows qualifying issuers to recover issued tokens from holders when the issuing account has enabled the required clawback setting. It does not allow an issuer to claw back native XRP. Retiring the amendment therefore means the network no longer needs code for a version of XRPL where Clawback did not exist. Current Clawback behavior remains part of the protocol. The XRPL known amendments page now explicitly marks its pre-amendment functionality as retired. The other four retirements follow the same principle. fixDisallowIncomingV1 corrected a trust line authorization issue. fixInnerObjTemplate addressed errors involving inner AMM objects. fixNFTokenReserve added reserve checks when NFT offers are accepted, while fixUniversalNumber unified parts of XRPL’s decimal floating point calculations. Their post-amendment rules remain in effect even though the older paths are being removed. This is not a new governance mechanism. XRPL has retired earlier amendments after their rules became sufficiently established. Version 3.2.0, for example, retired older changes covering Checks, Deposit Authorization, account deletion and other protocol functions. Version 3.3.0 also starts a new amendment cycle While five old amendments are leaving conditional status, version 3.3.0 adds six new proposals to xrpld. They are BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, Sponsor and fixCleanup3_3_0. Their inclusion in the software does not mean those capabilities are already active on Mainnet. As crypto.news reported, ConfidentialTransfer would support privacy preserving Multi-Purpose Token transfers, while BatchV1_1 would allow an account to submit as many as eight inner transactions together. Sponsor would allow third parties to cover fees and reserve requirements, while DynamicMPT would provide more flexibility over selected token properties. Each proposal must still clear XRPL’s validator process independently. More than 80% support must persist for two weeks before an amendment activates, and support can fall below the threshold and reset the timer. The difference between these new amendments and the five retired ones is therefore substantial. The new proposals are awaiting network approval. The retired amendments already passed that stage years ago, became established network behavior and have now reached the point where maintaining their older code is no longer considered necessary. What happens next for XRPL operators For ordinary XRP holders, no migration, wallet update or transaction is required specifically because the five amendments were retired. Clawback and the other affected protocol behaviors continue operating under the established rules. Server operators have a different consideration. The XRPL 3.3.0 release notice tells operators to upgrade to version 3.3.0 as soon as possible to maintain service continuity. Staying current is also important because servers need software containing the code for amendments that may later become active. A server lacking an activated amendment can become amendment blocked and stop participating normally in the network. In related coverage, that mechanism was demonstrated in July when activation of fixCleanup3_2_0 left nodes running older incompatible versions amendment blocked. Attention now shifts from the retired amendments to validator decisions around the six additions in version 3.3.0. As previously reported, ConfidentialTransfer is among the proposals aimed at expanding XRPL’s tools for institutional tokenized assets, but its use still depends on validator approval. For the five retired amendments, however, there is no comparable vote ahead. Retirement marks the end of their transition period rather than the end of their functionality: the amended rules are now simply part of XRP Ledger’s permanent core behavior.
