The Amendment Process, In Depth

A detailed look at how the XRP Ledger's protocol rules can change, and the safeguards built into that process.

Every native feature described throughout this wiki's Technology section — the AMM, NFTs, escrow, and so on — reached the XRP Ledger through the same formal mechanism: the amendment process. This page goes deeper than the brief mention in What Is the XRP Ledger?.

What an amendment is

An amendment is a proposed, discrete change to the XRP Ledger's protocol rules — anything from adding an entirely new transaction type (like the AMM or NFTs) to fixing an edge case in existing behavior. Amendments are identified by name and by a unique hash, and are implemented in the rippled codebase ahead of time, shipped in a software release, but not activated until the network itself votes them in.

Why activation is separate from the code shipping

This is a deliberate safety design. Software developers can write and ship the code for a new amendment well in advance, giving node and validator operators time to update their software — but the new rules don't actually take effect on the live network until validators explicitly signal support. This separates "the code exists and is available" from "the network has agreed to use it," preventing any single software release from silently changing consensus rules.

The voting mechanism

Once code supporting an amendment is deployed, validators can include a "yes" vote for that amendment in the ledgers they help produce. An amendment activates only once:

1. At least 80% of trusted validators are voting in favor of it, and
2. That 80%+ support level is sustained continuously for two weeks.

If support drops below the threshold at any point before the two weeks elapse, the countdown resets. This makes the process deliberately resistant to a brief, temporary spike in support — real, sustained consensus is required.

What this prevents

• No unilateral changes. Not even Ripple, despite running validators and publishing a widely-used default UNL (see Unique Node List and Validators), can activate an amendment on its own — it requires broad agreement across the trusted validator set.
• No silent forced upgrades. Node operators who disagree with a proposed change can simply not upgrade their software to support it, and as long as enough of the network agrees with them, the change won't activate.
• No accidental permanent mistakes without warning. The two-week sustained-supermajority requirement gives the ecosystem — exchanges, wallet providers, application developers — real advance notice before a change takes effect, rather than an instant flip.

What happens if the network disagrees

In principle, if a meaningful minority of validators refuse to support an amendment that a majority wants, and that disagreement is irreconcilable, the network could split into two incompatible chains (a "hard fork") — though in practice, the XRPL's amendment history has not seen a contentious split of this kind, with proposed amendments generally converging toward either broad acceptance or being set aside after community discussion (see XLS: How New Features Get Proposed for the discussion stage that happens well before a feature ever reaches validator voting).

Retiring old amendments

Amendments can also be marked "obsolete" once functionality has been fully superseded, cleaning up the codebase over time without disrupting already-activated behavior on the live network.