Amendments represent new features or other changes to transaction processing.
The amendment system uses the consensus process to approve any changes that affect transaction processing on the XRP Ledger. Fully-functional, transaction process changes are introduced as amendments; validators then vote on these changes. If an amendment receives more than 80% support for two weeks, the amendment passes and the change applies permanently to all subsequent ledger versions. Disabling a passed amendment requires a new amendment to do so.
Note: Bug fixes that change transaction processes also require amendments.
The Contributing Code to the XRP Ledger topic walks through the workflow to develop an amendment from an idea to activation on the XRP Ledger.
After the code for an amendment is built into a software release, the process to enable it happens within the XRP Ledger network, which checks the status of amendments every flag ledger (typically about 15 minutes apart).
Every 256th ledger is called a flag ledger. The flag ledger doesn't have special contents, but the amendment process happens around it.
Flag Ledger -1: When
rippledvalidators send validation messages, they also submit their amendment votes.
Flag Ledger: Servers interpret the votes from trusted validators.
Flag Ledger +1: Servers insert an
EnableAmendmentpseudo-transaction and flag based on what they think happened:
tfGotMajorityflag means the amendment has more than 80% support.
tfLostMajorityflag means support for the amendment has decreased to 80% or less.
- No flag means the amendment is enabled.
Note: It's possible for an amendment to lose 80% support on the same ledger it reaches the required two-week period to be enabled. In these cases, an
EnableAmendmentpseudo-transactions is added for both scenarios, but the amendment is ultimately enabled.
Flag Ledger +2: Enabled amendments apply to transactions on this ledger onwards.
Each version of
rippled is compiled with a list of known amendments and the code to implement those amendments. Operators of
rippled validators configure their servers to vote on each amendment and can change it at any time. If the operator doesn't choose a vote, the server uses a default vote defined by the source code.
Amendments must maintain two weeks of support from more than 80% of trusted validators to be enabled. If support drops below 80%, the amendment is temporarily rejected, and the two week period restarts. Amendments can gain and lose a majority any number of times before they become permanently enabled.
Amendments that have had their source code removed without being enabled are considered Vetoed by the network.
Amendment blocking is a security feature to protect the accuracy of XRP Ledger data. When an amendment is enabled, servers running earlier versions of
rippled without the amendment's source code no longer understand the rules of the network. Rather than guess and misinterpret ledger data, these servers become amendment blocked and can't:
- Determine the validity of a ledger.
- Submit or process transactions.
- Participate in the consensus process.
- Vote on future amendments.
The voting configuration of a
rippled server has no impact on it becoming amendment blocked. A
rippled server always follows the amendments enabled by the rest of the network, so blockages are based solely on having the code to understand rule changes. This means you can also become amendment blocked if you connect your server to a parallel network with different amendments enabled. For example, the XRP Ledger Devnet typically has experimental amendments enabled. If you are using the latest production release, your server likely won't have the code for those experimental amendments.
You can unblock amendment blocked servers by upgrading to the newest version of
The Clio server can become amendment blocked if it encounters an unknown field type while loading ledger data. This occurs if the field is newer than the
libxrpl dependency that was used when building Clio. To unblock your Clio server, upgrade to a newer Clio release that was built with a compatible
When amendments are enabled, the source code for pre-amendment behaviors remain in
rippled. While there are use-cases for keeping old code, such as reconstructing ledger outcomes for verification, tracking amendments and legacy code adds complexity over time.
The XRP Ledger Standard 11d defines a process for retiring old amendments and associated pre-amendment code. After an amendment has been enabled on the Mainnet for two years, it can be retired. Retiring an amendment makes it part of the core protocol unconditionally; it's no longer tracked or treated as an amendment, and all pre-amendment code is removed.