XRPL amendments, live

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.

rippled v3.3.0 · released 2026-08-06 · six new amendments

The 3.3.0 release bundles six amendments aimed at institutional Multi-Purpose-Token tokenization: BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, Sponsor, and fixCleanup3_3_0. Each still has to hold an 80 percent validator majority for 14 consecutive days before activation.

Two of the six — ConfidentialTransfer (XLS-96) and Sponsor (XLS-68) — currently appear on this page under In development — not yet on-chain because the XRPL node answering this request is on an earlier binary. They will migrate to the in-flight list once the responding node upgrades to 3.3.0 and returns them from the feature RPC. No manual edit here — the page follows the wire.

Release notes: xrpl.org · rippled 3.3.0. Third-party market context — CoinDesk (2026-08-07) reports RWA.xyz aggregates ~$1.38B in tokenized real-world assets on XRPL, largest cohorts RLUSD (~$845.7M) and Ondo (~$212.6M). Aggregator estimates drift daily; these figures are cited, not measured by xrpldashboard: CoinDesk 2026-08-07. For the issuer side — which institutional wallets have closed a two-way TOML attestation loop on XRPL today — see /rwa.

93
amendments live on mainnet
11
in-flight (supported, not yet enabled)
1
in 14-day activation countdown
106703923
validated ledger at fetch

In countdown

Amendments that have crossed the 80 percent validator-majority threshold. If the majority holds for 14 consecutive days, the amendment activates at the close of the first ledger after that window.

at majority · tracking 14-day window
fixCleanup3_3_0
3298D47E1F3A8A24FECAA30F699B8FE1DD234E072834BA099AD8180FFCE0FEC4
2026-09-11T11:15:00Z
if the 80 percent majority holds for the full 14-day window
projected activation · majority reached at fetch 2026-08-28T11:15:00Z

In development — not yet on-chain

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.

XLS-68 · Sponsor feature

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.

Depends on: XLS-74 Account Permissions (Final)

Source: XLS-68 Sponsored Fees and Reserves (XRPL-Standards) · status: in development, no on-chain hash

XLS-100 · Smart Escrows feature

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.

Depends on: WASM engine and API spec (companion XLS, no number assigned yet)

Source: XLS-100 Smart Escrows (XRPL-Standards) · status: in development, no on-chain hash

XLS-96 · Confidential Transfers for Multi-Purpose Tokens feature

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.

Depends on: XLS-33 MPTokensV1 (enabled on mainnet), XLS-94 DynamicMPT (in-flight; required for sfMutableFlags)

Source: XLS-96 Confidential Transfers for MPTs (XRPL-Standards) · status: in development, no on-chain hash

In-flight amendments

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.

BatchV1_1 uncatalogued

No plain-English summary is on file for this amendment yet. The node reports it as supported but we have not yet curated a primary source — until we do, we don't guess at what it does.

hash: 9F287AED3CDB50A7BD1ACEC24296A30C9B5230CCD136219317AC790E3B884377

Trusted-validator vote: 22/35 yes (28 threshold; ~62% support).
Source: XRPL Foundation validator history · fetched 2026-09-02T04:26:26Z

ConfidentialTransfer uncatalogued

No plain-English summary is on file for this amendment yet. The node reports it as supported but we have not yet curated a primary source — until we do, we don't guess at what it does.

hash: 2110E4A19966E2EF517C0A8C56A5F35099D7665B0BB89D7B126B30D50B86AAD5

Trusted-validator vote: 7/35 yes (28 threshold; ~20% support).
Source: XRPL Foundation validator history · fetched 2026-09-02T04:26:26Z

CryptoConditionsSuite feature

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.

Source: draft-thomas-crypto-conditions (IETF) · hash: 86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90

Trusted-validator vote: not published by the aggregator for this amendment.

DynamicMPT feature

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.

Source: XLS-94 Dynamic MPT (XRPL-Standards) · hash: 58E92F338758479C06084E1B6BA366BAD8F75E5329A7F0EEAFFFDA51E5106B7F

Trusted-validator vote: 7/35 yes (28 threshold; ~20% support).
Source: XRPL Foundation validator history · fetched 2026-09-02T04:26:26Z

fixCleanup3_3_0 uncatalogued

No plain-English summary is on file for this amendment yet. The node reports it as supported but we have not yet curated a primary source — until we do, we don't guess at what it does.

hash: 3298D47E1F3A8A24FECAA30F699B8FE1DD234E072834BA099AD8180FFCE0FEC4

Trusted-validator vote: 29/35 yes (28 threshold; ~82% support).
Source: XRPL Foundation validator history · fetched 2026-09-02T04:26:26Z

fixXChainRewardRounding fix

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.

Source: xrpl.org · Known Amendments · hash: 2BF037D90E1B676B17592A8AF55E88DB465398B4B597AE46EECEE1399AB05699

Trusted-validator vote: 11/35 yes (28 threshold; ~31% support).
Source: XRPL Foundation validator history · fetched 2026-09-02T04:26:26Z

LendingProtocol feature

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.

Source: XLS-66 Lending Protocol (XRPL-Standards) · hash: 565B90CA1AB2B9D42208ED10884188C64F9E19083DECB9634AAF06EB03299509

Trusted-validator vote: 11/35 yes (28 threshold; ~31% support).
Source: XRPL Foundation validator history · fetched 2026-09-02T04:26:26Z

PermissionDelegationV1_1 feature

Re-shipped version of PermissionDelegation with the v2.6.1 bug fixed — accounts can delegate specified transaction-type permissions to another account without sharing signing keys. Shipped in rippled v3.3.0 alongside the base amendment; the pair is expected to activate together and supersede the original.

Source: XLS-75 Permission Delegation (XRPL-Standards) · hash: 0F48FF561C709540328F31F1C97FD512ACC8B4E42138A161CB0E21ECA292540B

Trusted-validator vote: 11/35 yes (28 threshold; ~31% support).
Source: XRPL Foundation validator history · fetched 2026-09-02T04:26:26Z

SingleAssetVault feature

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.

Source: XLS-65 Single Asset Vault (XRPL-Standards) · hash: 81BD2619B6B3C8625AC5D0BC01DE17F06C3F0AB95C7C87C93715B87A4FD240D8

Trusted-validator vote: 13/35 yes (28 threshold; ~37% support).
Source: XRPL Foundation validator history · fetched 2026-09-02T04:26:26Z

Sponsor uncatalogued

No plain-English summary is on file for this amendment yet. The node reports it as supported but we have not yet curated a primary source — until we do, we don't guess at what it does.

hash: BE1F90581635DBCEBFC4678C4B54FEDDC1A17B50FD02CFE765A4132A342126AC

Trusted-validator vote: 5/35 yes (28 threshold; ~14% support).
Source: XRPL Foundation validator history · fetched 2026-09-02T04:26:26Z

XChainBridge feature

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.

Source: XLS-38 Cross-Chain Bridge (XRPL-Standards) · hash: C98D98EE9616ACD36E81FDEB8D41D349BF5F1B41DD64A0ABC1FE9AA5EA267E9C

Trusted-validator vote: 5/35 yes (28 threshold; ~14% support).
Source: XRPL Foundation validator history · fetched 2026-09-02T04:26:26Z

Superseded amendments 3

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.

fixNFTokenDirV1 superseded

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.

Source: xrpl.org · Known Amendments (Obsolete) · hash: 0285B7E5E08E1A8E4C15636F0591D87F73CB6A7B6452A932AD72BBC8E5D1CBE3

fixNFTokenNegOffer superseded

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.

Source: xrpl.org · Known Amendments (Obsolete) · hash: 36799EA497B1369B170805C078AEFE6188345F9B3E324C21E9CA3FF574E3C3D6

NonFungibleTokensV1 superseded

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.

Source: xrpl.org · Known Amendments (Obsolete) · hash: 3C43D9A973AA4443EF3FC38E42DD306160FBFFDAB901CD8BAA15D09F2597EB87

Recently enabled

live on mainnet now

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

XLS-47 PriceOracle is also live — lets oracle providers publish signed price feeds as native ledger objects. DIA is currently the one production provider publishing to mainnet. Live price feed decoder → /price-data

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-09-02T04:26:26Z.