XRPL Retires Five Legacy Amendments in xrpld 3.3.0

XRP Ledger developers have cleaned house in the latest xrpld release — but users shouldn’t panic. Version 3.3.0 officially “retired” five long-established protocol amendments, removing legacy pre-amendment code from the codebase while leaving the actual behaviors intact. What “retirement” means - Retiring an amendment only removes the old code path that existed to emulate pre-amendment behavior. It does not undo or disable the feature itself. - Once retired, the amendment’s behavior becomes an unconditional part of the core protocol, per XRPL documentation. - Developers typically wait two years after an amendment activates before retiring it. That delay preserves the old implementation for debugging and historically accurate transaction replay. Which amendments were retired xrpld 3.3.0 retires five amendments that have been active for some time: - Clawback — lets qualifying issuers recover issued tokens from holders if the issuer enabled the clawback setting (does not apply to native XRP). Active on Mainnet since Feb. 8, 2024; retirement removes the older code path, not the feature. - fixDisallowIncomingV1 — fixed a trust-line authorization issue. - fixInnerObjTemplate — addressed errors involving inner AMM objects. - fixNFTokenReserve — added reserve checks when NFT offers are accepted. - fixUniversalNumber — unified parts of XRPL’s decimal floating-point calculations. Why this matters (and why it mostly doesn’t) - For ordinary XRP holders and token users: nothing to do. No migrations, wallet updates, or transactions are required. The network’s rules remain as they were after those amendments activated. - For developers and historians: if you need to replay old ledgers exactly as they behaved years ago, you may need the xrpld version that was current at that time — because retirement removes the legacy branch that reproduced the pre-amendment behavior. - For server operators: upgrade to xrpld 3.3.0 as soon as possible to maintain service continuity. Running an older xrpld may leave a node “amendment blocked” if it lacks code for amendments that later become active. A similar situation occurred in July when nodes running older versions were amendment blocked after activation of fixCleanup3_2_0. How XRPL’s amendment process works (brief) - New protocol proposals are included in xrpld but don’t become active immediately. Validators vote on amendments; a proposal must sustain more than 80% support from trusted validators for two continuous weeks to activate. - Once active, the new behavior is permanent unless a later amendment changes it. After two years of being active, an amendment can be retired — converting its new behavior into unconditional protocol logic and removing the old code path. What’s new in 3.3.0 xrpld 3.3.0 also introduces six new amendment proposals into the software, but these are not yet active on Mainnet: - BatchV1_1 — submit up to eight inner transactions together. - ConfidentialTransfer — privacy-preserving transfers for Multi-Purpose Tokens. - DynamicMPT — adds flexibility to selected token properties. - PermissionDelegationV1_1 — updates permission delegation logic. - Sponsor — lets third parties cover transaction fees and reserve requirements. - fixCleanup3_3_0 — codebase cleanup and fixes. Each of these must still pass the >80% validator threshold for two continuous weeks to activate. Their inclusion in xrpld simply makes the code available for validators to vote on. Bottom line The recent retirements are standard protocol lifecycle housekeeping: the XRPL is removing obsolete code now that several amendments have been firmly established for years. Features like Clawback and the other retired amendments remain part of the ledger’s permanent behavior — ordinary users are unaffected. The immediate operational takeaway is for node operators to update to xrpld 3.3.0 to avoid potential amendment blocking and to ensure readiness for any future activations.