What is the difference between a validator and a node on XRPL?
Last updated:
Understanding the distinction between validators and nodes is fundamental to comprehending how the XRP Ledger achieves consensus and maintains security. While all validators are nodes, not all nodes are validators—the difference lies in their roles in the consensus process.
### Basic Definitions
XRPL Node: A node is any server running the rippled software that connects to the XRP Ledger peer-to-peer network. Nodes perform several functions:
- Transaction Validation: Ensure transactions meet protocol requirements and are "valid" according to the rules - Ledger Maintenance: Maintain a copy of the ledger state and history - Transaction Relay: Propagate transactions across the network - API Access: Provide interfaces for applications to query ledger data and submit transactions - Historical Data Storage: Store ledger history for queries and analysis
All nodes verify that transactions are properly formatted, have valid signatures, and follow protocol rules.
XRPL Validator: A validator is a special type of node that performs all standard node functions PLUS participates in the consensus process by:
- Issuing Validation Messages: Publishing votes on which transactions should be included in ledgers - Proposing Transaction Sets: Suggesting which transactions should be processed in each consensus round - Voting on Amendments: Participating in governance decisions about protocol changes - Creating Consensus: Working with other validators to agree on the official ledger state
The key distinction is that validators issue validation messages that are used during the XRPL consensus process, while regular nodes simply follow consensus without voting.
### Functional Differences
What All Nodes Do:
Every XRPL node, whether validator or not:
1. Receives transactions from clients and peers 2. Validates transaction format (proper structure, valid cryptographic signatures, sufficient fees) 3. Maintains ledger state (current account balances, trust lines, order books) 4. Processes consensus results (applies validated transactions to create new ledger versions) 5. Serves API requests (allows applications to query data and submit transactions) 6. Stores ledger history (maintains historical ledger versions for queries)
What Only Validators Do:
Validators perform additional consensus-specific functions:
1. Issue validation votes for proposed ledger versions during each consensus round (every 3-5 seconds) 2. Propose transaction sets to other validators for consideration 3. Vote on amendments to change protocol features and functionality 4. Participate in fee voting (rare, but possible for adjusting network fee requirements) 5. Sign ledger versions with their validator key to attest to correctness
These validation messages are what distinguish validators from regular nodes.
### Trust and the UNL System
The Critical Difference—Trust:
The most important distinction between validators and nodes concerns trust:
Regular Nodes: All nodes observe validation messages from validators, but they don't influence the consensus process unless they're on someone's UNL.
Trusted Validators: A validator only influences consensus if other servers add it to their Unique Node List (UNL). The UNL is each server's list of validators it trusts not to collude.
Untrusted Validators: You can run a validator and issue validation messages, but if no one adds you to their UNL, your votes are ignored. Other servers see your messages but don't count them for consensus.
This means there are effectively three tiers:
1. Regular nodes: Don't issue validation messages at all 2. Untrusted validators: Issue validation messages that are ignored 3. Trusted validators: Issue validation messages that influence consensus for servers that trust them
### Consensus Participation
How Nodes Experience Consensus:
Regular nodes participate passively in consensus:
1. Observe proposals from validators they've configured in their UNL 2. Watch validation votes to see which ledger version achieves 80%+ agreement 3. Apply the consensus result by adopting the validated ledger 4. Continue from the new state without voting or proposing
They benefit from consensus without contributing to the voting process.
How Validators Drive Consensus:
Validators actively drive the consensus process:
1. Propose transaction sets to include in the next ledger 2. Vote iteratively through multiple rounds (typically 4-6 rounds per ledger) 3. Reach agreement when 80%+ of their trusted validators agree on a transaction set 4. Sign and publish validation attesting to the final ledger version 5. Influence future rounds through their reputation and continued participation
Validators are the decision-makers, while nodes are followers of those decisions.
### Configuration Differences
Running a Stock Node:
To run a basic XRPL node:
- Install rippled software - Use default or minimally modified configuration - Connect to peer network - Start syncing ledger history - Begin serving API requests
Running a Validator:
To run a validator requires additional configuration:
- Generate a validator key pair (distinct from regular node identity) - Configure `[validator_token]` in rippled.cfg - Set up domain verification (xrp-ledger.toml file) - Configure monitoring for validation performance - Request inclusion in UNLs (for your validator to be trusted) - Maintain higher uptime and reliability standards
The technical requirements are similar, but validators require identity verification and reputation building.
### Performance and Resource Requirements
Node Resource Usage:
- CPU: Moderate (transaction processing and API queries) - RAM: 16GB+ recommended - Storage: Depends on history stored (500GB-2TB typical) - Network: Standard internet connection sufficient - Uptime: Important for API availability, but brief downtime acceptable
Validator Resource Usage:
- CPU: Slightly higher (consensus participation adds minimal overhead) - RAM: 32GB recommended for production validators - Storage: Similar to nodes - Network: Must be very stable and low-latency for timely validation votes - Uptime: Critical—validators should target 99.9%+ uptime
According to official documentation, "if you run an XRP Ledger server to participate in the network, the additional cost and effort to run a validator is minimal." The incremental resource requirements are small.
### Use Cases for Each
When to Run a Regular Node:
- Private API access: Direct ledger queries without third-party dependencies - Transaction submission: Submit transactions directly without using public endpoints - Historical data analysis: Store and query ledger history for your applications - Development and testing: Local environment for XRPL development - Privacy: Query balances and transactions without exposing queries to third parties - Reliability: Don't depend on external API providers
Businesses often run nodes for operational purposes without the commitment of validation.
When to Run a Validator:
- Governance participation: Vote on amendments and protocol changes - Network contribution: Support network decentralization and security - Brand reputation: Demonstrate commitment to XRPL ecosystem - Business dependency: Ensure reliable consensus for your operations - Community standing: Gain recognition as a serious ecosystem participant
Validators are for organizations with significant XRPL stakes wanting governance rights and reputation.
### Analogy to Help Understand
Think of XRPL consensus like a committee meeting:
Regular Nodes are like audience members: - They listen to the discussion - They observe the voting - They accept the committee's decisions - They cannot vote or influence outcomes - They benefit from the decisions without participating
Validators are like committee members: - They propose agenda items (transaction sets) - They vote on proposals - They must reach 80% agreement to pass motions - They're trusted by the organization (in UNLs) - They're accountable for their votes and reliability
Untrusted Validators are like people who try to vote but aren't committee members: - They can speak and cast votes - But their votes aren't counted - They don't influence outcomes - They must build reputation to join the committee (get added to UNLs)
### Practical Implications
For Most Users: Running a node provides sufficient functionality for: - Wallet operations - Payment processing - DeFi application backends - Trading platforms - Data analytics
For Ecosystem Stakeholders: Running a validator makes sense when you: - Want governance participation - Have significant business dependency on XRPL - Can maintain high reliability and uptime - Want to contribute to decentralization - Seek brand recognition in the community
### Network Statistics
As of February 2026:
- 150+ validators actively issuing validation messages - 35+ validators on the default UNL (actually trusted by most of the network) - 700+ full nodes participating without validation - 35+ countries hosting validators and nodes
The network has more nodes than validators, which is healthy—not everyone needs to validate, but many benefit from direct network participation.
### Comparison to Other Blockchains
Bitcoin: - Full nodes: Validate all transactions and blocks, similar to XRPL nodes - Miners: Create new blocks through proof-of-work, somewhat analogous to validators but with very different mechanisms - Key difference: Mining requires specialized hardware and earns rewards; XRPL validation requires standard servers and earns no rewards
Ethereum: - Full nodes: Maintain blockchain state and validate transactions - Validators: Stake 32 ETH and participate in consensus (proof-of-stake) - Key difference: Ethereum validators must stake significant capital and earn rewards; XRPL validators require no stake and earn no rewards
Cosmos/Polkadot: - Full nodes: Sync blockchain state - Validators: Participate in Tendermint/BABE consensus with staked tokens - Key difference: Limited validator slots and high token requirements; XRPL has open validator participation with no tokens required
### The Bottom Line
Nodes are sufficient for most operational needs—they provide API access, transaction submission, and ledger queries.
Validators add governance participation and network contribution, but require higher reliability commitments and public accountability.
The distinction allows for flexible participation: you can contribute to network infrastructure without the responsibility of consensus participation, or you can take on validation duties if you have sufficient stake in the network's evolution.
Most XRPL users interact with nodes through wallets and applications, never thinking about validators. But validators are the backbone ensuring that the ledger everyone trusts is actually trustworthy.
Last updated: February 2026