Every change to how the XRP Ledger works ships as an amendment — a code change that activates only after more than 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.
Cite this day: /amendments/2026-10-17 · leaf 657e195d8c5e… · signed 2026-10-17 01:00 UTC
Amendments with a validator majority: more than 80 percent of trusted validators voting yes — 29 of the 35 on the current list, since rippled requires strictly more than 80 percent of them. The process starts at the first flag ledger after the 14 days are up, not the moment they end. Votes are counted only at flag ledgers, which come about every 16.5 minutes. In the next ledger after that flag ledger, about 4 seconds later, the network records the change, and in the ledger after that the amendment is active. If support ever drops to 80 percent or less of trusted validators, the 14-day clock starts over.
Gathers amendment-gated fixes from the 3.4.0 release for tokens, the AMM, the permissioned exchange, NFTs, vaults, lending and escrow. For example: an issuer's block on incoming trust lines now also applies to offers, so it can no longer be bypassed by making an offer; an AMM clawback no longer burns a holder's pool tokens while recovering zero when integer MPT rounding floors the amount; and finishing or cancelling an escrow that returns tokens no longer fails when the owner is right at the reserve boundary. Source: xrpl.org · xrpld 3.4.0 release notes (2026-09-16)
“Every 256th ledger is called a flag ledger.” — xrpl.org
“Flag Ledger +1: Servers insert an EnableAmendment pseudo-transaction and flag based on what they think happened” — xrpl.org
“Flag Ledger +2: Enabled amendments apply to transactions on this ledger onwards.” — xrpl.org
“If an amendment receives more than 80% support for two weeks, the amendment passes and the change applies permanently to all subsequent ledger versions.” — xrpl.org
“When an amendment is enabled, servers running earlier versions of xrpld without the amendment's source code no longer understand the rules of the network.” — xrpl.org
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.
fixCleanup3_3_0 is already enabled on mainnet; the other five still have to hold more than 80 percent of trusted validators for 14 consecutive days before activation.
All six are recognised by our node (xrpld 3.4.1) from the
feature RPC and are tracked below in the in-flight list with their live trusted-validator vote counts. 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.
“Amendments must maintain two weeks of support from more than 80% of trusted validators to be enabled.” Amendment Voting — xrpl.orgTrusted validators are the servers each node has chosen to trust. For a change to turn on, more than 80 percent of them must vote yes, and that support must hold for two full weeks.
“If support drops below 80%, the amendment is temporarily rejected, and the two week period restarts.” Amendment Voting — xrpl.orgIf support ever falls to 80 percent or less, the two-week clock resets. The count must climb back above 80 percent and hold for a fresh two weeks.
“Every 256th ledger is called a flag ledger.” Amendment Process — xrpl.orgA flag ledger is a checkpoint. Every 256th ledger is a flag ledger, which comes around about every 16.5 minutes. Votes are counted only at these checkpoints.
“Flag Ledger +1: Servers insert an EnableAmendment pseudo-transaction and flag based on what they think happened” Amendment Process — xrpl.orgIn the next ledger after the flag ledger, about 4 seconds later, the network itself adds a system entry called EnableAmendment. No person sends it.
“Flag Ledger +2: Enabled amendments apply to transactions on this ledger onwards.” Amendment Process — xrpl.orgIn the ledger after that, about 4 seconds later again, the amendment is active. Its rules apply from that ledger onward.
“If an amendment receives more than 80% support for two weeks, the amendment passes and the change applies permanently to all subsequent ledger versions.” Amendments — xrpl.orgOnce an amendment is on, it stays on. Only a new amendment can remove it.
“When an amendment is enabled, servers running earlier versions of xrpld without the amendment's source code no longer understand the rules of the network.” Amendment Blocked Servers — xrpl.orgA server that has not upgraded no longer understands the new rules. It becomes amendment blocked, which means it stops keeping up with the network until it upgrades.
Voting ledger 107,716,863 (flag ledger 107,716,864) ·
Heard 35 of 35 validators on the current UNL · needs 29 of 35 (xrpld takes 80 percent of the validators it heard and requires strictly more than that)
Next roll call at voting ledger 107,717,119, in about 7 minutes.
Next flag ledger 107,717,120 · ledgers remaining 120 · 7.7 minutes remaining · next flag
| Amendment | Yes this round | Yes incl. 24h carry | State |
|---|---|---|---|
| fixCleanup3_4_0 | 29 | 29 / 29 | majority |
| ConfidentialTransfer | 22 | 22 / 29 | short by 7 |
| SingleAssetVault | 21 | 21 / 29 | short by 8 |
| LendingProtocol | 19 | 19 / 29 | short by 10 |
| LendingProtocolV1_1 | 19 | 19 / 29 | short by 10 |
| DynamicMPT | 18 | 18 / 29 | short by 11 |
| fixXChainRewardRounding | 12 | 12 / 29 | short by 17 |
| Sponsor | 11 | 11 / 29 | short by 18 |
| XChainBridge | 6 | 6 / 29 | short by 23 |
| CryptoConditionsSuite | 0 | 0 / 29 | short by 29 |
Counts only. Source: own-node validations stream (Lenovo rippled → roll-call recorder) · 1832 rounds recorded since . A yes vote carries forward for 24 hours after a validator last sent it, matching how xrpld tallies.
Each amendment's majority window, as recorded from the ledger. If validator support drops to 80 percent of the validators heard or below, the majority is removed and the 14-day countdown restarts from the next time it is regained — which moves the projected activation date.
Correction 2026-09-25: this page previously described 28 of 35 as the number of yes votes a majority needs. rippled's rule is strictly more than its 80 percent threshold (28), so a majority needs 29 yes votes and 28 loses it — confirmed against PermissionDelegationV1_1, which sat at 28 of 35 and lost its majority at flag ledger 107181569 on 2026-09-23. Vote counts below now read "yes · needs N".
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.
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.
Currently supported by our node but not yet enabled. The vote count on each row is the XRPL Foundation's validator history (fetched time shown per row); our own roll call is above. Plain-language summaries below are hand-edited from primary sources; click each one to read.
Multi-Purpose Tokens (MPTs) are a token type on the XRP Ledger. Per xrpl.org: transaction amounts are encrypted; account balances are encrypted and only visible to the holder, issuer, and any configured auditors; validators and network observers see only encrypted ciphertexts and cryptographic proofs, never the underlying amounts, though they can tell when a balance holds the canonical encrypted zero. Who sent to whom is still visible: the ConfidentialMPTSend transaction carries the sender (Account) and Destination as ordinary account fields (XLS-0096 §9.2). Confidential transfers are only available for direct payments between accounts and do not work with the DEX, escrows, or checks.
Provides institutional-grade privacy for Multi-Purpose Tokens (MPTs) using EC-ElGamal encryption and zero-knowledge proofs. Individual balances and transfer amounts stay shielded from the public ledger while designated parties (issuers, auditors, or authorized entities) can verify total supply and meet regulatory obligations. Targets tokenized-RWA and stablecoin issuers whose compliance requirements are incompatible with fully-public balances.
Not enabled; 0 of 35 vote yes in our node's roll call; xrpl.org lists it as obsolete.
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.
Per xrpl.org, this amendment makes specific MPT properties mutable by default: the on-chain metadata, the transfer fee, and the ability to enable MPT issuance flags (capabilities such as trading or issuer clawback). Enabling an issuance flag is one-way: once enabled, no later transaction can disable it. Issuers can make any of these properties permanently immutable, at creation or later, by declaring it in an ImmutableFlags field, which is additive and can never be cleared. Other data set at issuance, such as asset scale and maximum amount, is always fixed.
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.
Gathers amendment-gated fixes from the 3.4.0 release for tokens, the AMM, the permissioned exchange, NFTs, vaults, lending and escrow. For example: an issuer's block on incoming trust lines now also applies to offers, so it can no longer be bypassed by making an offer; an AMM clawback no longer burns a holder's pool tokens while recovering zero when integer MPT rounding floors the amount; and finishing or cancelling an escrow that returns tokens no longer fails when the owner is right at the reserve boundary.
Bundles amendment-gated fixes shipped in xrpld 3.4.0 (2026-09-16), including: DisallowIncomingTrustline now applies to OfferCreate; the Permissioned-DEX invariant ignores deleted domain offers; two AMMClawback fixes (MPT rounding, owner-reserve bypass); rejects tfMPTUnauthorize on a locked MPToken; enforces the MPT balance/transfer invariants; NFT-offer and permissioned-domain checks; escrow reserve recycling; distinct signing prefixes for counterparty/sponsor signatures; vault precision fixes. The same release retires fixAMMOverflowOffer.
Not enabled. Our node's roll call: 12 of 35 trusted validators vote yes; needs 29 of 35. Source: xrpl.org Known Amendments.
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.
Together with SingleAssetVault it provides the basis for on-chain lending; both must be live for the lending stack to work.
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.
Adds "closed-ended" vaults with three phases (subscription, investment, redemption) that decide when assets can be deposited, when loans can be originated, and when assets can be redeemed. Also adds cash-basis accounting: interest counts as income only when payments are actually made. Once enabled, new loan brokers can only be created against closed-ended vaults.
Extends LendingProtocol and SingleAssetVault (xrpld 3.4.0) with closed-ended vaults — a three-phase lifecycle (subscription, investment, redemption) that decides when assets can be deposited, when loans can be originated, and when assets can be redeemed — and cash-basis accounting, under which interest is recognized as income only when payments are actually made. Once enabled, new loan brokers can only be created against closed-ended vaults.
Together with LendingProtocol it provides the basis for on-chain lending; both must be live for the lending stack to work.
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.
Under XLS-68, a sponsor can cover the transaction fees and the reserve (the XRP an account must hold) for another account, either by co-signing each transaction or by pre-funding a sponsorship, while the sponsored account keeps full control of its keys. A reserve-accounting bug found in Devnet testing (reported 2026-08-07) let a sponsor end a sponsorship without checking the owner could cover the reserve; the fix, in xrpld 3.4.0, means a sponsor can no longer end reserve sponsorship unilaterally. No funds were at risk: the amendment had not activated anywhere.
Lets one account subsidize the transaction fees and reserve requirements of another account. Sponsors can co-sign transactions or pre-fund sponsorships, covering fees and reserves while sponsees retain full control of their accounts and keys. Removes the onboarding-friction wall where a new user must acquire XRP for the base reserve before receiving any other asset — the sponsor covers it, the user keeps custody.
Not enabled. Our node's roll call: 6 of 35 trusted validators vote yes; needs 29 of 35. Source: xrpl.org Known Amendments.
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.
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 our own sovereign xrpld node via the feature RPC and the canonical Amendments ledger object; public s1.ripple.com:51234 is labeled fallback only.
Cached for up to 5 minutes; the timestamp shown is the validated ledger from the last fetch. Vote counts come from our own node's roll call (countdown boxes and the roll-call table) and from XRPL Foundation validator history (in-flight list); the feature RPC itself carries no tallies. Amendment descriptions:
xrpl.org/known-amendments.
Fetched · cached 796.7s.