How do validators vote on amendments?

Validators vote on amendments through the rippled software using API methods or configuration files, with voting occurring on a regular schedule tied to "flag ledgers" every 256 ledger versions. The process is transparent, requires sustained 80%+ support for two weeks, and allows validators to approve or reject proposed protocol changes. ### Amendment Voting Mechanism **What Are Amendments**: Amendments are proposed changes to the XRP Ledger's transaction processing rules, features, or functionality. They allow the protocol to evolve without hard forks. **Who Votes**: Only servers configured as validators can vote on amendments. Regular nodes observe the voting process but don't participate. **Voting Authority**: Validators whose votes actually matter are those included in other servers' Unique Node Lists (UNLs), particularly the default UNL published by the XRP Ledger Foundation and Ripple. ### Technical Voting Process **Configuration Methods**: Validators can configure their amendment votes through two primary approaches: **1. Admin API Method**: Servers configured as validators can use the `feature` method, which requires admin access. This API allows validators to: - View the status of all known amendments - Enable support for specific amendments (`"vetoed": false`) - Disable/veto amendments they oppose (`"vetoed": true`) - Query whether an amendment is currently enabled - Check how many validators support each amendment Example API call structure: ``` { "method": "feature", "params": [{ "feature": "", "vetoed": false // or true to oppose }] } ``` **2. Configuration File**: Validators can set amendment preferences in their `rippled.cfg` configuration file for persistent voting configuration. This ensures votes persist across server restarts. **Default Voting Behavior**: By default, validators vote to support all amendments included in their current rippled software version. To oppose an amendment, operators must explicitly configure a veto. This default-approval approach means: - Upgrading to newer rippled versions implicitly supports new amendments - Operators who don't actively manage votes support all amendments - Conscious effort required to oppose amendments ### The Flag Ledger Voting Schedule **Flag Ledgers Every 256 Versions**: Amendment voting occurs on a regular schedule: "every 256th ledger is called a flag ledger, and the amendment process happens around it." With ledgers validated every 3-5 seconds, flag ledgers occur approximately every 12-20 minutes. **Three-Phase Process**: The voting process happens across three ledger versions: **Flag Ledger -1** (One ledger before the flag ledger): - Validators send their regular validation messages - These validation messages include their amendment votes - Votes are broadcast to the network along with ledger validation **Flag Ledger** (The 256th ledger): - Servers interpret votes from their trusted validators - Calculate what percentage of trusted validators support each amendment - Determine if any amendments gained or lost majority support **Flag Ledger +1** (One ledger after the flag ledger): - Servers insert an `EnableAmendment` pseudo-transaction - The pseudo-transaction includes flags indicating status changes: - `tfGotMajority`: Amendment has more than 80% support - `tfLostMajority`: Support decreased to 80% or less - No flag: Amendment is being enabled (after two weeks of 80%+ support) ### The Two-Week Activation Window **Sustained Support Required**: According to official documentation, "amendments must maintain two weeks of support from more than 80% of trusted validators to be enabled." This two-week period: - Equals approximately **2,419 flag ledgers** (256 ledgers × 14 days / ~3.5 seconds per ledger) - Provides time for validator operators to review changes - Allows testing in development environments - Enables discussion about potential impacts - Prevents hasty activation of untested features **Gaining and Losing Majority**: "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 means: - Validators can change their votes during the two-week period - New concerns can halt activation - The countdown resets if support drops - Only sustained overwhelming support activates amendments ### The 80% Supermajority Threshold **Why 80%**: The high threshold ensures: - Broad consensus across the validator set - Protection against narrow majorities forcing controversial changes - Minority validators retain effective veto power - Network stability through requiring overwhelming agreement With 35 validators on the default UNL, **at least 28 validators must vote yes** for amendments to activate. **Comparison to Other Thresholds**: - **Bitcoin**: Soft forks typically use 95% miner signaling - **Ethereum**: No formal voting; rough social consensus - **Cosmos**: Governance proposals typically need 50-66% - **Polkadot**: Varies by proposal type; some require supermajorities XRPL's 80% threshold balances between requiring strong agreement while remaining achievable for beneficial changes. ### Practical Voting Scenarios **Scenario 1: Widely Supported Amendment**: 1. New rippled version includes amendment 2. Validators upgrade to new version 3. Default behavior: Support the amendment 4. 80%+ support achieved immediately 5. Two weeks of sustained support 6. Amendment activates automatically Example: Native XRP Lending Amendment (January 2026) entered validator voting after the v3.1.0 release. **Scenario 2: Controversial Amendment**: 1. Amendment proposed and included in rippled 2. Some validators upgrade, some don't 3. Others upgrade but explicitly veto the amendment 4. Support remains below 80% 5. Amendment doesn't activate 6. Discussion continues in community 7. Amendment may be modified or withdrawn **Scenario 3: Initially Supported, Then Opposed**: 1. Amendment achieves 80%+ support 2. Two-week countdown begins 3. Issue discovered during testing 4. Validators change votes to veto 5. Support drops below 80% 6. Amendment loses majority status 7. Countdown resets 8. Issue must be addressed before re-attempting ### Validator Responsibilities **Staying Informed**: Validator operators must "stay abreast of the latest updates" to vote responsibly. This includes: - Monitoring rippled GitHub repository for amendment proposals - Reading release notes for new versions - Participating in community discussions about amendments - Testing amendments on test networks - Understanding impacts on their use cases and the broader ecosystem **Testing Before Supporting**: Responsible validators: - Test new amendments on Testnet or Devnet - Verify compatibility with their operational setup - Assess impacts on applications they support - Identify potential issues before mainnet activation Example: "XRPL Commons approve permissioned domains, DEX amendments after Devnet tests"—amendments were tested before validator voting. **Active Configuration Management**: Validators should: - Explicitly review amendment votes before software upgrades - Configure vetoes for amendments they oppose - Document their voting decisions - Communicate concerns to the community ### Monitoring Amendment Status **Public Visibility**: Amendment voting status is publicly visible through multiple channels: **API Queries**: - The `feature` API method shows amendment status and current support levels - The `server_info` method includes information about enabled amendments **XRPL Documentation**: - Known Amendments page lists all proposed and active amendments - Shows which amendments are currently voting - Displays activation status and history **Blockchain Explorers**: - XRPSCAN and other explorers display amendment voting progress - Show real-time vote counts - Track which amendments are close to activation **Example Monitoring**: In January 2026, reports showed "all 34 validators were casting votes on amendments," demonstrating active participation visible to the community. ### Amendment Types Amendments can propose various changes: **New Features**: - NFT support (NFTokenV1) - AMM (Automated Market Maker) functionality - Native lending protocols - Cross-chain bridges **Protocol Optimizations**: - Consensus efficiency improvements - Performance enhancements - Resource usage optimizations **Security Enhancements**: - Vulnerability fixes - Cryptographic upgrades - Attack mitigation features **Economic Changes**: - Fee structure modifications (example: December 2024 90% fee reduction) - Reserve requirement adjustments - Incentive mechanism changes **Governance Improvements**: - Voting mechanism enhancements - UNL system modifications ### Governance Power Amendment voting provides real governance power: **Protocol Evolution Control**: Validators collectively decide what features are added, removed, or modified. **Protecting Use Cases**: Businesses can vote against amendments that might harm their specific applications. **Network Direction**: The validator community shapes the long-term technical direction of XRPL. **Veto Power**: Even minority validators (21%+) can prevent amendments from activating. This governance participation is a primary reason businesses run validators despite no financial rewards. ### Communication and Coordination **No Central Authority**: There's no single entity that can force amendments through: - Ripple operates only 1 of 35+ default UNL validators - XRP Ledger Foundation operates some validators - Community and business operators control the majority - All decisions require 80% agreement **Community Discussion**: Amendments typically go through extensive discussion: - GitHub issues and pull requests - Community forums and developer calls - Validator operator communications - XRPLF and community channels **Transparent Process**: The entire process is transparent: - Proposed amendments are publicly visible in code - Voting progress is tracked on-chain - Changes are documented in release notes - Activation is recorded in ledger history ### Historical Voting Examples **Successful Amendments**: - **NFT Support**: Enabled after validator voting approved the feature - **AMM Functionality**: Validators approved automated market maker features - **Fee Reduction (December 2024)**: "XRP Account Fees Fall by 90% After XRPL Validator Vote" - **Permissioned Domains and DEX**: Approved after Devnet testing **Ongoing Voting**: - **Native XRP Lending (January 2026)**: Entered validator voting after v3.1.0 release These examples show the governance system functioning actively and continuously. ### Comparison to Other Blockchain Governance **Bitcoin**: - **Method**: Miner signaling through block versions - **Threshold**: Typically 95% for soft forks - **Issues**: Contentious forks (Bitcoin Cash, Bitcoin SV) - **XRPL Advantage**: Formal voting prevents contentious splits **Ethereum**: - **Method**: Off-chain social consensus - **Process**: Core developers propose, community discusses, implemented in clients - **Issues**: Hard forks required for major changes - **XRPL Advantage**: On-chain voting provides clearer consensus **Tezos**: - **Method**: On-chain token holder voting - **Threshold**: Supermajority required - **Similarity**: Both have formal on-chain governance - **Difference**: Tezos uses stake-weighted voting; XRPL uses validator voting **Cosmos**: - **Method**: On-chain governance proposals - **Threshold**: Varies (50-66% typical) - **Similarity**: On-chain voting process - **Difference**: Cosmos uses stake-weighted voting; XRPL has equal validator weights XRPL's governance is more formalized than Bitcoin/Ethereum but less stake-dependent than most PoS chains. ### Best Practices for Validators **Review Amendments Thoroughly**: - Read amendment specifications - Understand technical implementation - Assess impacts on network and applications - Consider security implications **Test Before Supporting**: - Deploy amendments on test networks - Verify compatibility with existing infrastructure - Identify potential issues early **Communicate with Community**: - Share concerns about problematic amendments - Explain voting decisions - Participate in governance discussions - Coordinate with other validator operators **Document Decisions**: - Record why you support or oppose amendments - Maintain voting history - Review past decisions for consistency **Stay Updated**: - Monitor rippled releases - Subscribe to amendment notifications - Follow XRPL development activity - Participate in validator communications ### The Bottom Line Validators vote on amendments through: ✅ **API methods or configuration files** to set amendment support/opposition ✅ **Flag ledger system** providing regular voting checkpoints every 256 ledgers ✅ **80% supermajority requirement** ensuring broad consensus ✅ **Two-week sustained support** preventing hasty activations ✅ **Transparent public process** with visible voting progress ✅ **Default approval** of amendments in rippled versions (explicit veto required to oppose) ✅ **Real governance power** over protocol evolution ✅ **Protection for minority concerns** through high threshold This voting mechanism enables decentralized governance while maintaining network stability and preventing contentious splits. Validators with genuine vested interests collectively decide how XRPL evolves, making validator operation valuable for businesses wanting input on the protocol's future. **Last updated: February 2026**