What is validator voting on XRPL?

Validator voting on XRPL refers to the process by which validators participate in governance decisions and consensus formation. Validators vote on two primary things: transaction sets during each consensus round, and protocol amendments that change network rules.

### Two Types of Validator Voting

1. Consensus Voting (Continuous):

Validators continuously vote on which transactions should be included in each ledger and in what order. This happens every 3-5 seconds as new ledgers are validated.

2. Amendment Voting (Periodic):

Validators vote on proposed protocol amendments—changes to the XRPL's features, rules, and functionality. This is the governance mechanism for network evolution.

While both are called "voting," they serve different purposes and operate on different timescales.

### Consensus Voting Process

Purpose: Validators vote to reach agreement on which transactions are valid and should be included in the next ledger version.

How It Works:

1. Proposal Phase: Each validator proposes a set of transactions it believes should be included 2. Voting Rounds: Validators go through multiple rounds (typically 4-6) of voting, sharing their proposed transaction sets 3. Increasing Threshold: The agreement threshold increases each round, starting at 50% and eventually reaching 80% 4. Validation: When 80%+ of trusted validators agree on a transaction set, that ledger is validated 5. Finality: The validated ledger becomes part of the permanent ledger history

This consensus voting happens continuously, creating a new validated ledger every 3-5 seconds.

Voting Weight: In XRPL consensus voting, each validator has equal weight (unlike stake-weighted systems). A validator on your UNL either contributes to consensus or doesn't—there's no proportional influence based on stake or resources.

### Amendment Voting Process

Purpose: Amendments are "proposed changes to the transaction process changes" that modify how the protocol works. Validators vote to approve or reject these changes.

What Amendments Include:

- New transaction types (e.g., NFT support, AMM functionality) - Changes to existing features - Fee structure modifications - Protocol optimizations and improvements - Security enhancements

Voting Mechanism:

According to official documentation, "The XRPL introduces transaction process changes as amendments, and validators vote on these changes. If an amendment receives more than 80% support for two weeks, it passes and applies permanently to all subsequent ledger versions."

Flag Ledger System:

Voting occurs around special "flag ledgers" every 256 ledgers:

Flag Ledger -1: When rippled validators send validation messages, they also submit their amendment votes.

Flag Ledger: Servers interpret the votes from trusted validators to see if any amendments have gained or lost majority support.

Flag Ledger +1: Servers insert an EnableAmendment pseudo-transaction with flags: - `tfGotMajority`: Amendment has more than 80% support - `tfLostMajority`: Support decreased to 80% or less - No flag: Amendment is enabled (after maintaining 80%+ for two weeks)

Two-Week Requirement:

"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 becoming permanently enabled."

This two-week period provides: - Time for validator operators to review and understand changes - Opportunity to test amendments in development environments - Chance to identify and address concerns before activation - Protection against hasty or contentious changes

### Configuring Amendment Votes

How Validators Vote:

Validators configure their amendment votes through:

Command-Line Interface: Using the `feature` API method with admin access, validators can: - Enable support for specific amendments - Disable support for amendments they oppose - Query current voting status

Configuration File: Validators can set amendment preferences in their `rippled.cfg` file for persistent voting configuration.

Default Behavior: By default, validators vote to support all amendments included in their rippled software version. Operators must explicitly configure votes to oppose amendments.

Who Can Vote: Only servers configured as validators can vote on amendments. Regular nodes observe amendment voting but don't participate.

### Amendment Voting Thresholds

80% Supermajority Required:

The 80% threshold is deliberately high: - Prevents narrow majorities from forcing through contentious changes - Ensures broad consensus among network stakeholders - Protects minority interests from being overridden - Maintains network stability by requiring overwhelming agreement

With 35 validators on the default UNL, 28+ validators must vote yes for an amendment to activate.

No Single Entity Control:

With Ripple operating only 1 of 35+ default UNL validators, no single entity can: - Force amendments through unilaterally - Veto amendments that have broad support - Control the network's evolution

This demonstrates true decentralized governance.

### Recent Amendment Voting Examples

Native XRP Lending Amendment (January 2026):

"Native XRP Lending Amendment Enters Validator Voting Following XRPL v3.1.0 Release." This amendment introduced native lending functionality to XRPL, and validators voted on whether to activate it.

Permissioned Domains and DEX Amendments:

"XRPL Commons approve permissioned domains, DEX amendments after Devnet tests." These amendments passed through validator voting after successful testing.

Fee Reduction (December 2024):

"XRP Account Fees Fall by 90% After XRPL Validator Vote"—validators voted to reduce network fees, demonstrating governance in action.

All 34 Validators Voting (January 2026):

Reports indicated "all 34 validators were casting votes on amendments," showing active participation from the entire validator set.

### Governance Participation

Who Gets to Vote:

Only validators on Unique Node Lists participate meaningfully in governance: - Validators on the default UNL have the most influence (35+ validators) - Validators on custom UNLs influence only servers using those lists - Untrusted validators can technically vote, but their votes are ignored

Importance for Businesses:

"Validator operators that appear on a UNL also partake in the governance of the XRP Ledger through voting on fees and amendments, which are proposed changes to the protocol."

This makes validator operation valuable for businesses that: - Want input on protocol evolution - Need to protect their specific use cases - Want early visibility into upcoming changes - Value having a voice in governance decisions

### Staying Informed on Amendments

Information Sources:

Validator operators must "stay abreast of the latest updates" to vote responsibly:

- Known Amendments Page: XRPL documentation lists all proposed and active amendments - GitHub Discussions: Technical discussions about amendment proposals - Community Forums: Validator operator discussions about governance - Release Notes: New rippled versions include amendment information - XRPL Foundation Communications: Announcements about significant amendments

Responsible Voting:

Validators should: - Review amendment specifications thoroughly - Test amendments on test networks before voting - Consider impacts on their own use cases and the broader ecosystem - Engage in community discussions about contentious amendments - Vote based on technical merit and network benefit, not narrow self-interest

### Fee Voting

In addition to amendments, validators can theoretically vote on:

Network Fee Changes: Adjusting the minimum transaction fees required

Reserve Requirements: Changing the base reserve and owner reserve amounts

However, fee voting is used much less frequently than amendment voting. The December 2024 fee reduction demonstrates that it does happen when needed.

### Voting vs. Other Blockchain Governance

On-Chain Governance Comparison:

Cosmos/Polkadot: - Voting: Token-weighted—validators vote proportional to stake - Threshold: Varies by chain (50-66% typical) - XRPL Difference: Equal validator weight, 80% threshold

Tezos: - Voting: Multi-phase voting with token holder participation - Threshold: Supermajority required - XRPL Difference: Validators vote, not token holders

Decred: - Voting: Ticket-based voting by stakeholders - Threshold: 75% required - XRPL Difference: Similar high threshold, but validator-based not stake-based

Bitcoin/Ethereum: - Governance: Off-chain social consensus, no formal voting - Activation: Signaling through software versions - XRPL Difference: Explicit on-chain voting mechanism

XRPL's governance is more formal and transparent than Bitcoin/Ethereum but less stake-based than most modern PoS chains.

### Transparency and Monitoring

Public Visibility:

Amendment voting status is publicly visible: - API Methods: The `feature` method shows amendment status and voting - Block Explorers: Display amendment voting progress - XRPL Documentation: Lists known amendments and their status

Any interested party can monitor: - Which amendments are currently being voted on - How many validators support each amendment - When amendments will activate if support continues

### Contentious Amendments

What If Validators Disagree:

If an amendment is contentious: - It won't reach 80% threshold and won't activate - Discussion continues in the community - Amendments may be modified or replaced with compromise proposals - Network continues operating with existing rules

No Hard Forks:

Unlike Bitcoin or Ethereum, where contentious changes can lead to chain splits, XRPL's 80% threshold and validator identity prevent hard forks: - Changes require overwhelming agreement - Validators have known identities and reputations - The vested interest model aligns incentives toward network stability

### Practical Implications

For Validators: - Amendment voting is a key responsibility - Must stay informed about proposed changes - Should test amendments before supporting - Have real influence over protocol evolution

For Businesses: - Running a validator provides governance participation - Can influence amendments that affect your use cases - Get early visibility into upcoming protocol changes - Have a voice in network evolution

For Users: - Trust that changes require overwhelming validator agreement - Network evolution is transparent and gradual - No surprise hard forks or contentious splits

### The Bottom Line

Validator voting on XRPL encompasses:

✅ Continuous consensus voting on transaction sets every 3-5 seconds ✅ Amendment voting on protocol changes requiring 80%+ support for two weeks ✅ Equal validator weight regardless of stake or resources ✅ Transparent governance with publicly visible voting status ✅ High threshold preventing narrow majorities from forcing changes ✅ Decentralized control with no single entity able to dominate ✅ Stable evolution through requiring overwhelming agreement

This voting mechanism allows XRPL to evolve through decentralized governance while maintaining stability and preventing contentious splits. Validators with genuine vested interests in network health collectively decide the protocol's future direction.

Last updated: February 2026