Ripple Engineer Says Users Will Not Be Affected

In a major development in the past week, Version 3.3.0 of XRPLD, the reference server implementation of the XRP Ledger protocol, was launched.

The release introduced several new amendments including the first privacy amendment for the XRPL, ConfidentialTransfer: Privacy-preserving Multi-Purpose Token transfers (XLS-0096); BatchV1_1: Atomic batch transactions (XLS-56); DynamicMPT: Multi-Purpose Token properties that issuers can make permanently immutable (XLS-94); PermissionDelegationV1_1: Granular account permission delegation; Sponsor: Reserve and transaction sponsoring (XLS-68); fixCleanup3_3_0: a bundle of amendment-gated bug fixes.

Alongside bug fixes and build improvements, the XRPL 3.3.0 release retired five amendments. The release retires the long-active Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve, and fixUniversalNumber amendments, making them a permanent part of the XRPL protocol.

XRPL amendment retirement explained

In a recent conversation on X, RippleX software engineer Mayukha Vadari explained what “amendment retirement” on the XRP Ledger means. This is essential to prevent the error of confusing it with the feature being retired.

According to Vadari, retiring an amendment means removing the pre-amendment code that still exists in the codebase for amendments that were activated a while ago, for instance, Clawback. Vadari noted that this is purely a codebase cleanup and will not affect any users.

For instance, the Clawback amendment was activated on the XRP Ledger in February 2024, having been active for a long time before its retirement. Vadari explained why the team waits before retiring amendments rather than retiring them immediately after they are enabled.

The RippleX software engineer highlighted a wait of two years for most amendments in case there is a need for the old code when debugging old transactions.

XRPL amendments are new features or other changes to transaction processing. The amendment system uses the consensus process to approve any changes that affect transaction processing on the XRP Ledger.

Fully functional transaction processing changes are introduced as amendments; validators then vote on these changes. If an amendment gets more than 80% support for two weeks, the amendment passes, and the change applies permanently to all subsequent ledger versions.

Disabling a passed amendment requires a new amendment to do so, as well as bug fixes that change transaction processes.