XRP ledger abolished 5 revisions, leaving users unaffected

XRP Ledger developers retire five long-active agreement amendments

XRP Ledger developers retire five long-active agreement amendments in xrpld version 3.3.0, but this will not remove its functionality and require no action by XRP holders.

Summary

XRPL 3.3.0 retires five long-active amendments, making its post-activation behavior a permanent part of the core agreement. The Clawback feature remains available after retirement because only outdated pre-fix code has been removed from the xrpld software. The XRPL document stipulates that amendments can be retired two years after being activated on the main network to reduce the complexity of legacy code. Six new amendments have been included in version 3.3.0, but each still requires validator approval to be activated on the main web. Node operators should upgrade to version 3.3.0 as soon as possible, without users having to take any action due to retirement.

RippleX software engineer Mayukha Vadari explained on social media that retirement refers to the removal of old pre-revision code left behind years of protocol changes, and the revised behavior itself remains unchanged. The official XRPL document confirms that the retirement amendment will become an unconditional part of the core agreement.

"Retirement of an amendment means removing old code that still exists in the codebase for an earlier activated amendment, such as Clawback. This is purely codebase cleanup and will not affect any users. We wait two years in case the old code is still needed during debugging..."

This difference became particularly important with the release of xrpld 3.3.0 on August 6, which retired Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve, and fixUniversal Number. In other words,"retiring Clawback" does not mean that XRP Ledger issuers have lost Clawback functionality, but that the network has abandoned the old code path that describes trading behavior before the amendment was activated.

XRP Ledger decommises old rules

XRP Ledger's amendment system allows protocol changes to be introduced without immediately forcing the main network to implement new rules. Verifiers vote on the amendment, and the proposal must be supported by more than 80% of trusted verifiers for two consecutive weeks before it can be activated. Once enabled, the new behavior will apply permanently unless it is subsequently changed by another amendment.

During the post-activation period, xrpld retains both current logic and some pre-correction code. This legacy code helps developers reproduce old ledger behavior when debugging or verifying historical transactions. However, retaining branches that have been outdated for many years also increases the complexity of the code base.

The official amendment document states that the Mainnet Amendment can be retired two years after its introduction. Retirement removes its old code path, no longer treats the change as a conditional amendment, and unconditionally incorporates the new behavior into the agreement.

Vadari described the process as "pure codebase cleanup" and said it "will not affect any users." She added that developers typically wait two years because previous implementations may still be useful when debugging old transactions. XRPL's own test documentation also warns that accurate playback of historical transactions after the old amendment is retired may require running the version of xrpld that originally handled the transaction.

Clawback not removed from XRPL

Clawback is the most well-known and easily misunderstood of the five retirement amendments. This feature, activated on February 8, 2024, allows eligible issuers to withdraw issued tokens from the holder if the required Clawback settings have been enabled for the issuing account. It does not allow issuers to take back native XRP.

Therefore, retiring the amendment means that the network no longer needs to reserve code for earlier versions of XRPL that did not exist in Clawback. Current Clawback behavior remains part of the agreement. XRPL's Known Amendments page now explicitly marks its pre-amendment features as "retired."

The other four retirements follow the same principles. fixDisallowIncoming V1 fixes trust quota authorization issues;fixInnerObjTemplate resolves errors involving internal AMM objects;fixNFTokenReserve adds reserve checks when accepting NFT quotes;fixUniversalNumber unifies XRPL partial decimal floating point calculations Its revised rules remain valid even after the old path has been removed.

This is not a new governance mechanism. XRPL had previously retired from early amendments after its rules were fully established. For example, version 3.2.0 retires old changes involving Checks, Deposit Authorization, account deletion, and other protocol features.

Version 3.3.0 also opens a new amendment cycle

While five old amendments have exit conditions, Version 3.3.0 adds six new proposals to xrpld. These are BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, Sponsor, and fixCleanup3_3_0. Just because they are included in software does not mean that these features have been activated on the main network.

According to media reports, ConfidentialTransfer supports privacy-protected multi-purpose token transfers, while BatchV1_1 allows one account to submit up to eight internal transactions at the same time. Sponsor allows third parties to bear fees and reserve requirements, while DynamicMPT provides more flexibility in selecting token attributes.

Each proposal still needs to pass the XRPL's validator process independently. Support exceeding 80% must last for two weeks to activate the amendment, and if the support rate falls below the threshold, the timer will reset.

As a result, there are significant differences between these new amendments and the five retirement amendments. The new proposal is awaiting network approval, and the retirement amendment passed this stage many years ago, became established network behavior, and has reached a stage where old code no longer needs to be maintained.

What should XRPL operators do next

For ordinary XRP holders, there is no need for migration, wallet updates, or transactions due to retirement due to the five amendments. Clawback and other affected agreement behavior will continue to operate under established rules.

Server operators should pay attention. XRPL 3.3.0 issued a notice requiring operators to upgrade to version 3.3.0 as soon as possible to maintain service continuity. It's also important to keep it up to date because the server needs to contain amendment codes that may be activated in the future. Servers that lack activated amendments may be "blocked" by the amendment and cannot participate in the network normally.

Related reports show that this mechanism was reflected in the activation of fixCleanup3_2_0 in July, when nodes running older versions of incompatible software were "blocked by amendments."

Attention now shifts from retirement amendments to validators decisions about six new features in version 3.3.0. As mentioned earlier, ConfidentialTransfer is one of the proposals aimed at extending XRPL's institutional tokenization asset tool, but its use still depends on validator approval.

However, there are no similar votes ahead for the five retirement amendments. Retirement marks the end of its transition period, not the end of its functionality: the revised rules are now part of XRP Ledger's permanent core behavior.