
After the vote
4 minDifficulty Checked 2026-11-10- An enabled amendment applies to every later ledger. Undoing it takes a new amendment.
- A server without the code for an enabled amendment becomes amendment blocked until upgraded.
- Amendments can be retired into the core rules after two years on Mainnet.
The vote passed. The amendment is on. What changes?
For users. The new feature works on the ledger from that moment. Wallets and apps can use it once their makers add support.
For server operators. Every server needs software that knows the new rule. A server that was not upgraded hits a ledger it cannot read. It does not guess. It stops and reports that it is amendment blocked. It cannot process transactions or take part in consensus until someone installs a newer version.
This is a safety feature. A server that guessed at rules it did not know could show wrong balances.
For the rulebook. The change is permanent. Validators cannot take back their votes afterward and switch it off. If a feature turns out to be a mistake, the way out is a new amendment that goes through the same vote.
Some amendments never make it. One can be pulled before it is enabled. The original Batch amendment was disabled in a server release after a bug was found, and BatchV1_1 replaced it. See Batch transactions.
Long after an amendment is enabled, it can be retired. That sounds like removal. It is the opposite. The old pre-amendment code is deleted and the new rule becomes part of the core protocol.
Amendment blocked. A blocked xrpld server cannot:
- Determine the validity of a ledger.
- Submit or process transactions.
- Participate in consensus.
- Vote on future amendments.
A server's own vote does not matter here. Blocking depends only on whether it has the code. server_info shows amendment_blocked: true, and requests can return the amendmentBlocked error. Upgrading fixes it.
The same thing happens when a production build connects to a network with experimental amendments enabled, as Devnet typically has.
A Clio server becomes amendment blocked if it meets an unknown field type while loading ledger data. The fix is a newer Clio release.
Reading status. The public feature method, per amendment:
enabled | supported | Reading |
|---|---|---|
true | true | Live, and this server understands it |
false | true | Known to this server, not enabled |
true | false | Enabled, and this server lacks the code. It may be blocked |
{ "method": "feature", "params": [{ "feature": "SingleAssetVault" }] }The admin version adds vetoed. It is a boolean for the server's own vote, or the string Obsolete.
Obsolete and vetoed. The Known Amendments page lists obsolete amendments: removed from the server, or marked for removal. A server cannot vote in favor of an amendment marked obsolete. xrpl.org calls amendments whose code was removed without being enabled "Vetoed" by the network.
Retiring (XLS-11). After two years enabled on Mainnet, an amendment can be retired:
- The pre-amendment code and the switch between old and new paths are removed.
- The amended behavior applies unconditionally.
- The
Amendmentsledger entry on networks that enabled it keeps the record. featurestill lists retired amendments.
One consequence: a current server cannot accurately replay historical ledgers built with the pre-amendment code of a retired amendment.
A new test network uses retired amendments' rules from its first ledger. They do not appear in its list of enabled amendments.
Live status for every amendment: Amendments page.
Related: Running a node: xrpld and Clio, The two-week vote.
- AmendmentsRead 2026-11-10
- Known AmendmentsRead 2026-11-10
- feature methodRead 2026-11-10
- feature admin methodRead 2026-11-10
- XLS-11 Retiring AmendmentsRead 2026-11-10
