What is the validator uptime requirement?

XRPL validators should strive for 99.9%+ uptime to remain on the default Unique Node List (UNL), though there's no single hard requirement. Instead, uptime expectations vary based on whether you're building reputation, maintaining UNL status, or operating for private purposes.

### Target Uptime Standards

Best Practice Goal: A good validator "is always running and submitting validation votes for every proposed ledger," with operators striving for 100% uptime as the ideal.

Realistic Expectation: However, "it is not reasonable to expect a diverse set of validators to maintain 100% uptime," as many factors can cause temporary unavailability including: - Hardware maintenance and upgrades - Software updates and patches - Internet connectivity problems - Unexpected hardware failures - Data center issues - Security incident response

Practical Minimum: For validators on the default UNL, the implicit requirement is approximately 99%+ uptime over extended periods (typically measured over a year). This translates to: - Less than 3.65 days of downtime per year - Less than 7.2 hours per month - Less than 1.68 hours per week

Elite Performance: Top validators on the default UNL typically achieve 99.9%+ uptime, allowing: - 8.76 hours of downtime per year - 43 minutes per month - 10 minutes per week

### Why Uptime Matters

Consensus Participation: Validators must be online to: - Receive proposed transaction sets from peers - Vote on which transactions to include in ledgers - Sign and publish validation messages - Participate in every consensus round (every 3-5 seconds)

Missing consensus rounds means your validator isn't fulfilling its purpose.

Network Reliability: The XRPL consensus mechanism requires 80%+ of trusted validators to agree. If too many validators are offline simultaneously, the network cannot reach quorum and stops validating new ledgers.

With 35 validators on the default UNL, 8 or more simultaneous outages would halt the network. Each validator's uptime directly affects overall network reliability.

Reputation and Trust: Validators with poor uptime: - May be removed from the default UNL - Lose governance voting rights - Damage their reputation in the community - Waste operational resources on ineffective infrastructure

### Official UNL Inclusion Requirements

To be added to the default UNL published by the XRP Ledger Foundation and Ripple, criteria include:

- "Running a validator with high uptime for at least a year and high agreement with the rest of the network" - Demonstrating consistent reliability over extended periods - Being "a separate and recognizable entity in the XRP Ledger community" - Running "the validator in a separate physical location than most other validators"

The "high uptime for at least a year" requirement implies that brief outages are acceptable, but sustained reliability must be proven over many months before being trusted by the network.

### Uptime vs. Agreement

Uptime is related to but distinct from agreement rate:

Uptime: Percentage of time the validator is online and issuing validation votes.

Agreement: Percentage of validations that match the network's consensus view.

A validator can have: - High uptime, high agreement: Ideal—always online and correct - High uptime, low agreement: Online but misbehaving or misconfigured - Low uptime, high agreement: Correct when online but frequently offline - Low uptime, low agreement: Neither reliable nor correct

For default UNL inclusion, validators need both high uptime AND high agreement (typically 95%+ for both metrics).

### The Negative UNL Safety Net

XRPL includes a resilience mechanism to handle temporary uptime issues:

Negative UNL: When validators go offline, the remaining validators can collectively add them to the "Negative UNL"—a temporary exclusion list. Validators on the Negative UNL are: - Temporarily ignored for consensus calculations - Excluded from the 80% quorum requirement - Allowing the network to continue with remaining online validators

How It Helps Uptime Issues:

"In cases where validators go offline one or two at a time, the remaining validators can use the Negative UNL to gradually adjust their effective UNLs, so that the network only ever needs 80% of the online validators to achieve a quorum."

This means: - Brief validator outages don't immediately halt the network - Validators can perform maintenance without catastrophic consequences - Gradual degradation is tolerated; only sudden mass outages are catastrophic

Limitations: The Negative UNL mechanism has limits: - Can't accommodate more than 25% of validators in the Negative UNL - If validators go offline faster than the Negative UNL can adjust, consensus may fail - "If more than 20% of trusted validators go offline or become unable to communicate with the rest of the network, servers stop validating new ledgers"

With 35 default UNL validators, simultaneous outages of 8+ validators would exceed this threshold.

### Planned vs. Unplanned Downtime

Planned Maintenance: Validator operators should: - Schedule maintenance during low-activity periods - Announce planned maintenance to the community - Minimize maintenance duration - Test updates in non-production environments first - Stagger maintenance across validator sets (not all at once)

Brief planned downtime for essential maintenance is acceptable and expected.

Unplanned Outages: Hardware failures, network problems, or security incidents cause unplanned downtime. While unavoidable occasionally, validators should: - Implement monitoring to detect outages quickly - Have incident response procedures ready - Restore service as rapidly as possible - Conduct post-mortems to prevent recurrence

Acceptable Frequency: Occasional brief outages (minutes to hours) are tolerated. Frequent multi-hour outages or extended multi-day downtime will result in UNL removal.

### Monitoring and Alerting

To maintain high uptime, validators must implement robust monitoring:

Health Check Endpoints: XRPL provides a health check API method that "automated monitoring can use to recognize outages and check several metrics to see if they are in ranges generally considered healthy."

Monitoring Systems: Validators typically use: - Prometheus: For metrics collection - Grafana: For visualization and dashboards - Alerting tools: PagerDuty, Opsgenie, or similar for incident notification

Key Metrics to Monitor: - Server uptime and process status - Validation vote participation - Agreement rates with the network - Peer connectivity and network latency - CPU, memory, and disk usage - Network bandwidth and errors

24/7 Alerting: Validators should have: - Automated alerts for service outages - On-call staff or procedures for rapid response - Redundant monitoring (monitoring the monitoring system)

### Infrastructure for High Uptime

Redundancy Options:

Some operators deploy redundant infrastructure: - Redundant network connections: Multiple ISPs or network paths - Backup power: UPS and generator systems for self-hosted hardware - Geographic redundancy: Backup validators in different locations (though only one should validate at a time to avoid confusion)

High-Availability Hosting: - Choose reliable hosting providers with SLA guarantees - Use cloud providers with redundant infrastructure - Select data centers with proven uptime records

Fault-Tolerant Storage: - Use RAID or redundant SSD configurations - Implement backup and recovery procedures - Monitor disk health proactively

### Comparison to Other Blockchains

Ethereum Validators (Proof-of-Stake): - Expected uptime: 99%+ to avoid significant penalties - Penalty mechanism: Validators are "slashed" (lose staked ETH) for extended downtime - Offline penalties: Gradually lose stake while offline - XRPL difference: No financial penalties, but reputation and UNL position at risk

Bitcoin Mining: - Uptime: Not strictly required—miners can go offline without penalty - Opportunity cost: Lost mining opportunities while offline - XRPL difference: XRPL validators must maintain consistent participation for network health

Cosmos Validators: - Uptime requirement: Typically 95-99% depending on specific chain - Slashing: Validators are slashed for excessive downtime - Jailing: Validators can be "jailed" and excluded from consensus - XRPL difference: Similar exclusion concept (Negative UNL) but no financial slashing

Solana Validators: - Uptime expectations: High uptime expected but not strictly enforced - Economic impact: Poor uptime reduces delegator rewards and trust - XRPL difference: XRPL has no delegation or rewards, so no direct economic impact

XRPL's uptime requirements are similar to other major blockchains, but enforcement is through reputation and UNL inclusion rather than financial penalties.

### What Happens with Poor Uptime

Short-Term Consequences: 1. Negative UNL addition: Temporarily excluded from consensus calculations 2. Reduced agreement rate: Missed validations lower your reliability metrics 3. Community concern: Other operators and UNL publishers notice downtime

Long-Term Consequences: 1. UNL removal warning: Publishers may contact you about reliability issues 2. Removal from default UNL: Persistent poor uptime leads to de-listing 3. Reputation damage: Known as an unreliable operator 4. Loss of governance rights: Can't vote on amendments without UNL status

### Practical Recommendations

For New Validators: - Build reliability over 12+ months before expecting UNL inclusion - Target 99%+ uptime from the start - Implement monitoring and alerting from day one - Document and address any outages promptly

For UNL Validators: - Maintain 99.9%+ uptime to preserve UNL position - Plan maintenance carefully to minimize impact - Communicate with UNL publishers about planned maintenance - Invest in redundant infrastructure for critical components

For Private Validators: - Uptime requirements depend on your specific use case - If not seeking UNL inclusion, occasional downtime is less critical - Still aim for high uptime to make your validator useful

### The Bottom Line

While there's no single hard uptime percentage enforced by protocol, the practical requirements are:

✅ Target: 99.9%+ uptime for default UNL validators ✅ Minimum: 99%+ uptime to maintain UNL inclusion ✅ Proof Period: Demonstrate high uptime for at least one year before UNL consideration ✅ Infrastructure: Invest in reliable hosting, monitoring, and incident response ✅ Resilience: The Negative UNL provides tolerance for brief outages, but not chronic unreliability

High uptime isn't optional for serious validators—it's fundamental to fulfilling your role in the consensus process and maintaining the trust of the network.

Last updated: February 2026