Every change to how the XRP Ledger works ships as an amendment — a code change that activates only after 80 percent of trusted validators have voted yes for 14 consecutive days. This page shows what they're voting on right now, what each change actually does, and when the next one is projected to go live.
fixCleanup3_1_3 (rippled PR #7128 (merged 2026-05-13)).
XRPL activates amendments faster than any single rippled binary updates; the next release will ship the definition.
Nothing in the 14-day activation window right now. The Amendments ledger object shows no current Majority entries.
XLS specifications published by XRPLF that haven't shipped in a rippled release yet. These amendments don't appear in the public feature RPC because no released binary carries their definition, but the spec is public and the design is far enough along that they're worth surfacing alongside the in-flight list.
Lets one account pay the transaction fees and reserves for another account, so end users can transact on XRPL without holding XRP themselves. Supports two modes: co-signed (the sponsor signs each transaction) and pre-funded (the sponsor opens a Sponsorship ledger object the other account can draw from). Defines two granular permissions — SponsorFee and SponsorReserve — both drawn from the account-permission namespace established by XLS-74.
Adds programmable conditions to XRPL Escrows: a small piece of WASM code lives on the Escrow ledger object and decides whether the escrow can be released or canceled — going beyond today's time-based and crypto-conditional gates. Stacks on top of TokenEscrow (already enabled on mainnet, which extended escrow to IOU and MPT balances), opening the door to tokenized RWA workflows like conditional release on attestation or oracle-driven triggers. The WASM engine and API are defined in a separate companion XLS that hasn't been assigned a number yet — Smart Escrows can't ship until that companion lands.
Adds confidential balances and transfers to Multi-Purpose Tokens: individual balances and transfer amounts are encrypted under EC-ElGamal and validated by zero-knowledge proofs, so validators and external observers can't see them while supply invariants are still enforced. Introduces five new transaction types covering the confidential-MPT round-trip and clawback. Builds on XLS-33 MPTokensV1 (already enabled on mainnet); the sfMutableFlags portion also requires DynamicMPT once it activates.
Currently supported by the responding XRPL node but not yet enabled. Validators may or may not be voting yes — the public RPC doesn't expose per-validator tallies. Plain-language summaries below are hand-edited from primary sources; click each one to read.
Allows multiple transactions to be bundled into one atomic group. Either every transaction in the batch succeeds, or none of them do — no partial state. Designed for multi-leg AMM routing, coordinated payouts, and workflows where 'most succeeded' is worse than 'all rolled back'.
Was intended to extend escrow's crypto-condition support beyond PREIMAGE-SHA-256 to include the other families defined in the IETF draft (PREFIX-SHA-256, THRESHOLD, RSA-SHA-256, ED25519-SHA-256). Implementation was never completed; rippled upstream has retired this amendment, though the public RPC still surfaces its hash.
Lets MPT (Multi-Purpose Token) issuers modify designated reference fields after issuance. Today the base MPT spec (XLS-33) fixes metadata, transfer fees, asset scale, and capability flags at issuance — only the lock flag is mutable post-mint via MPTokenIssuanceSet — which limits product flexibility for tokenized RWAs that need to update reference data, transfer fees, or URI metadata over time.
Companion patch for the bug that caused PermissionDelegation to be disabled in rippled v2.6.1. Designed to activate alongside a re-enabled PermissionDelegation so the network ships the feature and its fix as a coherent pair.
Ensures cross-chain transaction reward shares consistently round downward, preventing small dust losses from accumulating across many transfers. Shipped in rippled v2.2.0; the amendment has since been retired in rippled's develop branch, though the public RPC still surfaces its hash.
Adds new transaction-level invariants the consensus engine checks before committing a transaction — starting with a check that ledger entries owned by an account are deleted when the account itself is removed. A defensive amendment; no user-visible feature, but tightens the integrity floor.
Enables on-chain fixed-term loans drawn from pooled funds held in a SingleAssetVault. Pairs with SingleAssetVault — both amendments must be live for the lending stack to function. xrpldashboard's /lending page is pre-built for activation day.
Lets one wallet delegate signing authority for specific transaction types to another wallet without sharing the master key — approve-by-type instead of approve-by-key. Disabled in rippled v2.6.1 after a bug surfaced; fixDelegateV1_1 (also in this list) is the companion patch and the pair is expected to re-enable together.
A single-asset vault primitive. Depositors contribute one asset (XRP, IOU, or MPT) and receive vault shares as a Multi-Purpose Token; withdrawals redeem shares back to the underlying asset. The deposit layer the XLS-66 Lending Protocol sits on.
Native cross-chain bridge primitive. Enables trust-minimized asset transfer between XRPL mainnet and sidechains — including the EVM-compatible sidechain announced by Ripple in 2023 — via a designated set of bridge witnesses.
Amendments the responding node still lists as not-enabled, but which have been replaced by a later amendment whose effects bundle them in. The XRPL feature RPC does not expose an obsolete flag, so the dashboard maintains this list against xrpl.org's canonical registry.
Cleanup amendment for an off-by-one error in NFTokenPage assignment introduced by NonFungibleTokensV1. Superseded by NonFungibleTokensV1_1, which bundles this fix into the enabled NFT stack. The standalone amendment remains in the node's feature list for historical completeness.
Cleanup amendment that prevents NFTs from being traded for a negative amount of currency, closing a validation hole in NonFungibleTokensV1. Superseded by NonFungibleTokensV1_1, which bundles this fix into the enabled NFT stack. The standalone amendment remains in the node's feature list for historical completeness.
Original NFToken specification — introduced native NFT support on the XRP Ledger via five new transaction types and two new ledger object types. Superseded by NonFungibleTokensV1_1, which bundles this base spec together with the fixNFTokenDirV1 and fixNFTokenNegOffer cleanup amendments. V1_1 is enabled on mainnet, so native NFT functionality is live; this base amendment remains in the node's feature list for historical completeness.
The XRP Ledger's institutional stack — Credentials, PermissionedDomains, PermissionedDEX, and TokenEscrow — activated in earlier release windows and is live on mainnet today.
See the institutional page →
Live Credentials tracker → /credentials
Data sourced from the public feature RPC at s1.ripple.com:51234
and the canonical Amendments ledger object. Cached for up to 5 minutes; the timestamp shown is the validated ledger from the last fetch. Per-validator vote tallies are not exposed by the public RPC; for those, see
xrpl.org/known-amendments.
Fetched 2026-06-03T20:48:49Z.