From idea to release

Every server on the XRP Ledger follows the same rulebook. If one server used different rules, it would work out different balances and fall out of step with the rest. So the rules cannot change one server at a time. Everyone has to switch at the same moment.

A change to the rulebook is called an amendment. A new kind of transaction is an amendment. So is a fix for a bug in how transactions are handled.

No single company can push one through. A change goes through public steps.

1. Talk. Someone posts the idea in a public forum for standards. Others pick it apart.
2. Write it down. The idea becomes a numbered document called an XLS. It says exactly what the change does.
3. Build it. Developers write the code in the open. Other developers review it.
4. Test it. The code runs on test networks first, where nothing has real value.
5. Ship it, switched off. The code goes out in a new version of the server software. The new rule is inside, but it does nothing yet.

Only then can validators vote on it. The vote is covered in The two-week vote.

Not every XLS becomes an amendment. Some describe conventions that live outside the ledger, such as how NFT metadata is laid out. Apps can adopt those without any vote.

What needs an amendment. Changes that affect transaction processing, specifically those that:

• Modify ledger rules so outcomes differ.
• Add or remove transactions.
• Affect consensus.

Bug fixes that change transaction processing need one too.

XLS categories (XLS-1):

XLS statuses. Idea and Proposal happen in discussions. A Draft is merged into the repository and gets its number. Final means the standard is fixed, and for a server change the code is merged. Other statuses: Living, Deprecated, Stagnant (a Draft inactive for 6 months) and Withdrawn.

In the code. An amendment is declared in the server source with two settings:

• Supported: no until development is complete, then yes.
• DefaultVote: yes for bug fixes. Everything else defaults to no.

DefaultVote is what a validator votes when its operator has not chosen. The default can change between releases.

Path to a release, as xrpl.org describes it:

1. Develop on a fork or branch of the server repository, XRPLF/rippled.
2. Open a pull request against develop. After approval and merge, the code can be tested on Devnet.
3. On a quarterly basis a release candidate is built from develop. It goes to Testnet and a few Mainnet nodes.
4. If no issues appear, the code is merged to master and Mainnet servers can upgrade.
5. Validators vote.

In development. The Known Amendments page lists amendments still being built. They are not open for voting on Mainnet until a stable release includes them. They may already be enabled on other networks.

Identifiers. Each amendment has a short name, such as LendingProtocol, and a 256-bit ID. The Known Amendments page lists both.

Related: Consensus, validators and the UNL.