XRP Ledger amendments: how voting, majority support and activation differ

Chapter 01

Amendments are built into the ledger software itself

The XRP Ledger (XRPL) upgrades its consensus rules and feature set without relying on traditional hard forks that split the network into competing chains. Instead, the network uses an on-chain governance system known as the Amendments mechanism.

When developers implement a new protocol feature or bug fix in the reference server software (rippled), the code is packaged into a new software release as an amendment. Each amendment is identified by a unique 256-bit hexadecimal hash and a descriptive name (such as fixDisparateTokenFees or XChainBridge). Crucially, the code ships in a disabled state; it cannot execute on mainnet until the decentralized validator community explicitly votes to enable it through consensus.

Chapter 02

The 80% supermajority threshold and the 14-day hold period

For an amendment to activate on the XRP Ledger, it must clear two rigorous, mathematically defined hurdles:

1. 80% Validator Supermajority: In every flag ledger (which occurs once every 256 ledgers, or approximately every fifteen minutes), validating nodes publish their supported amendments. If an amendment receives affirmative votes from more than 80% of trusted validators on a node's Unique Node List (UNL), the amendment enters a provisional approval state. 2. The 14-Day Hold Period: Achieving 80% support for a single flag ledger does not activate the amendment. The supermajority support must be sustained continuously without interruption for a full two weeks (14 days). If validator support dips below the 80% threshold at any point during this 14-day window, the countdown aborts, and the timer resets to zero.

Only when the 80% threshold is maintained unbroken across the entire 14-day window does the amendment become permanent. In the flag ledger immediately following the conclusion of the hold period, the amendment is marked as enabled, and the new rules apply to all subsequent ledgers.

Chapter 03

How validators vote without a centralized coordinator

XRPL validator voting operates through decentralized consensus rounds. Unlike proof-of-stake protocols where voting power scales with token holdings, XRPL amendment voting gives one vote to each configured validator in a participant’s Unique Node List (UNL).

Validators declare their amendment preferences in their local configuration file (rippled.cfg). By default, updating to a new software release automatically votes in favor of the amendments enabled by that release. However, node operators retain full operational sovereignty: an operator can explicitly add an [amendments] stanza to reject a proposed amendment, regardless of the software default. Because operators choose which validators to trust, no single organization—including Ripple the company or the XRPL Foundation—possesses the cryptographic authority to force an amendment onto the network.

Chapter 04

What happens to nodes that do not upgrade: amendment blocking

Because amendments introduce consensus-altering rules, network nodes must understand the active amendment set to validate ledgers correctly. If an amendment activates and an operator is running an outdated version of rippled that lacks the software implementation for that amendment, the node cannot safely validate transactions.

To protect ledger integrity, the server automatically enters an amendment blocked state. In this state, the node refuses to participate in consensus, halts processing new transactions, and logs an alert warning the operator to upgrade. Amendment blocking prevents outdated nodes from falling out of sync or relaying invalid state data to peers, maintaining absolute consistency across the network.

Chapter 05

Distinguishing protocol voting from corporate announcements

Market commentary frequently misinterprets corporate statements or community discussions as protocol guarantees. To analyze XRPL governance accurately, participants should distinguish between: - A proposal under active discussion in an XRPL Standards (XLS) pull request. - An amendment integrated into a release candidate of rippled. - An amendment currently gathering votes on mainnet, subject to the 14-day hold timer. - An enabled amendment permanently integrated into consensus.

Following the live amendment status on public XRPL explorers allows market readers to track real protocol evolution based on cryptographic evidence. Explore our parent XRP research desk and read our XRPL network resilience report for technical operational reporting.

Chapter 06

The 80% voting threshold and the 14-day hold period

Protocol upgrades on the XRP Ledger are governed entirely on-chain through the Amendment voting system. Unlike soft-fork or hard-fork mechanisms in proof-of-work systems, XRPL amendments allow new features, consensus optimizations, and bug fixes to be enabled without creating competing chain splits or requiring centralized network coordination.

An amendment begins when developers submit code containing the feature flag into the official "rippled" software repository. Once released, validating node operators can vote to enable or reject the amendment in their local configuration files. During consensus processing, validating nodes declare their votes in validation messages attached to proposed ledger closes.

Amendment Activation Rule: Support must reach or exceed 80% continuously for exactly 14 consecutive days (1,209,600 seconds).

When an amendment achieves at least 80% support across trusted UNL validators, the ledger flags the amendment as reaching majority consensus and starts an exact 14-day hold timer. If validator support drops below 80% for even a single second during this 14-day countdown, the timer is immediately aborted and reset to zero. Only if the amendment sustains the 80% supermajority continuously for the entire 14-day window does the protocol automatically activate the code, making the feature active across all validating nodes simultaneously.

Chapter 07

Node operator amendment monitoring and upgrade runbook

Node operators must actively monitor amendment statuses to avoid falling into an "amendmentBlocked" state. If a majority of the network activates an amendment that a local node does not support (for example, if the operator is running an outdated version of "rippled"), the local server will immediately cease validating or relaying new ledgers to prevent state divergence.

Inspect active amendments using the JSON-RPC call: rippled feature

The output of the "feature" RPC endpoint exposes each amendment's hexadecimal hash identifier, human-readable name, veto status, majority timestamp, and activation countdown. Operators managing institutional nodes should configure monitoring alerts that trigger whenever an unknown amendment reaches majority support, ensuring ample time to deploy the required software upgrade before the 14-day activation window concludes. Maintaining active monitoring and configuring automated alert webhooks protects mission-critical financial infrastructure against unexpected ledger desynchronization.