What is a stock XRPL node?
Last updated:
A stock XRPL node is a multipurpose configuration of the rippled server software that provides standard XRP Ledger functionality without specialized configuration. It's the baseline, general-purpose setup that most operators use when they want to interact with XRPL without running specialized infrastructure.
### Definition and Purpose
According to official XRPL documentation, a stock server is "a multipurpose configuration for rippled that allows you to submit transactions to the XRP Ledger, access ledger history, and use the latest tools to integrate with XRP and the XRP Ledger." More technically, it's defined as "a server running in P2P Mode with a minimally-modified config file."
The term "stock" indicates that it uses mostly default settings straight from installation, without heavy customization for specific purposes like validation, high-throughput API serving, or full history archival.
### What a Stock Node Does
Core Functions:
A stock XRPL node performs all essential XRP Ledger operations:
1. Transaction Processing: - Receives transactions from clients and peer nodes - Validates transaction format, signatures, and fee requirements - Relays valid transactions to peer nodes - Applies transactions that achieve consensus to update ledger state
2. Ledger Maintenance: - Maintains the current ledger state (account balances, order books, trust lines, etc.) - Stores recent ledger history (typically the last several thousand ledgers) - Processes ledger versions as consensus is reached - Keeps synchronized with the network's validated ledgers
3. API Access: - Provides JSON-RPC and WebSocket APIs for clients - Allows querying account information, transaction history, and ledger data - Enables transaction submission directly through the node - Supports real-time subscriptions to ledger events
4. Network Participation: - Connects to peer nodes in the XRP Ledger network - Participates in the peer-to-peer network for transaction and ledger propagation - Observes consensus without voting (unlike validators) - Maintains network connectivity and health
### Default Configuration
rippled ships with default configuration that makes it work as a stock node out of the box:
Configuration File Location: On standard installations, the default configuration is at `/etc/opt/ripple/rippled.cfg`.
Key Default Settings:
Network Connection: By default, rippled connects to Mainnet (the production XRP Ledger network). No special configuration is needed to join the main network.
Node Size: The `[node_size]` parameter can be omitted, and the server will automatically choose appropriate settings based on system RAM and CPU cores. Alternatively, it can be set to small, medium, or large to match hardware capacity.
Database Path: The `[node_db]` section controls where ledger data is stored. Stock nodes use the default path unless specified otherwise.
Peer Discovery: Stock nodes automatically discover and connect to peer nodes through the network's built-in peer discovery mechanisms.
No Validation: Stock nodes do not issue validation messages—they observe consensus without participating in voting.
### Typical Use Cases
Application Backends:
Developers building applications on XRPL often run stock nodes to: - Query account balances and transaction history - Submit transactions on behalf of users - Monitor ledger events in real-time - Avoid rate limits of public API endpoints - Reduce latency by querying local infrastructure
Wallet Services:
Wallet providers run stock nodes to: - Check balances for user accounts - Broadcast payment transactions - Monitor incoming payments - Provide transaction history
Exchange Integration:
Cryptocurrency exchanges use stock nodes for: - Processing deposits and withdrawals - Monitoring deposit addresses - Submitting withdrawal transactions - Querying transaction confirmations
Development and Testing:
Developers use stock nodes for: - Local testing environments - Learning the XRPL API - Prototyping applications - Understanding consensus observation
Privacy and Reliability:
Organizations run stock nodes to: - Avoid exposing queries to third-party API providers - Ensure availability without depending on external services - Maintain operational independence
### What a Stock Node Is NOT
Not a Validator: Stock nodes do not participate in consensus voting. They observe consensus results but don't issue validation messages or vote on amendments.
Not a Full History Server: By default, stock nodes only store recent ledger history (a few thousand ledgers). They're not configured to store the complete ledger history from genesis.
Not a High-Performance API Server: Stock nodes have default API rate limits and resource allocations. They're suitable for moderate usage but not designed for high-volume public API services.
Not a Specialized Configuration: Stock nodes don't have custom optimizations for specific workloads like heavy API query loads, data analysis, or validator operations.
### Resource Requirements
Minimum Hardware Specifications:
- CPU: 64-bit x86_64 with 4+ cores - RAM: 16GB minimum (32GB recommended for better performance) - Storage: 500GB+ SSD storage (depending on how much history you retain) - Network: Stable broadband internet connection
Operating System: Linux distributions (Ubuntu, CentOS, Red Hat Enterprise Linux) are recommended for production deployments.
Bandwidth: Continuous network connectivity with reasonable bandwidth for peer-to-peer communication (typically several GB per month).
### Operating Costs
Running a stock node is relatively inexpensive:
- Cloud Hosting: $50-150/month for appropriate cloud instances - Dedicated Server: $50-100/month for suitable dedicated servers - Electricity: For self-hosted hardware, comparable to running a standard server (not energy-intensive like Bitcoin mining)
The cost is significantly lower than running a validator because stock nodes don't have the same uptime requirements or monitoring needs.
### Setting Up a Stock Node
The basic process is straightforward:
1. Install rippled: Use official installation packages for your operating system 2. Use Default Configuration: Start with minimal configuration changes 3. Start the Service: Launch rippled and let it sync with the network 4. Wait for Sync: Initial synchronization can take hours to days depending on network speed and ledger history 5. Begin Using: Once synced, the node is ready to serve API requests
The XRPL Foundation provides an "XRP Ledger Node Configurator" tool to help generate appropriate configuration files based on your use case.
### Advantages of Running a Stock Node
Independence: You're not dependent on third-party API providers that might have downtime, rate limits, or discontinue service.
Privacy: Queries to your own node don't expose your activity to external parties.
Reliability: Direct control over infrastructure availability for your applications.
Performance: Lower latency from querying local infrastructure rather than remote APIs.
Learning: Hands-on experience with XRPL infrastructure and consensus observation.
Cost-Effective: Much cheaper than paying for high-volume API access from commercial providers.
### Disadvantages and Limitations
Maintenance Burden: You're responsible for updates, security patches, and operational monitoring.
Upfront Cost: Requires server infrastructure and technical expertise to set up and maintain.
Limited History: Default configurations only store recent history, not complete ledger history from genesis.
No Governance: Stock nodes don't vote on amendments or participate in governance.
No Rewards: Running a stock node (like all XRPL infrastructure) generates no financial returns.
### Upgrading from Stock Node to Validator
One of the key advantages of stock nodes is that "if you run an XRP Ledger server to participate in the network, the additional cost and effort to run a validator is minimal."
Upgrading a stock node to a validator requires:
1. Generate validator keys: Create cryptographic keys for validation signing 2. Configure validator token: Add `[validator_token]` to rippled.cfg 3. Set up domain verification: Create xrp-ledger.toml file for validator identification 4. Enhance monitoring: Add validator-specific metrics and alerting 5. Improve infrastructure: Upgrade to higher reliability standards 6. Build reputation: Operate reliably to potentially get added to UNLs
The incremental resource requirements are minimal, but the operational commitment increases significantly.
### Stock Node vs. Other Configurations
| Configuration | Validation | Full History | API Performance | Complexity | |---------------|------------|--------------|-----------------|------------| | Stock Node | No | Recent only | Moderate | Low | | Validator | Yes | Recent only | Moderate | High | | History Node | No | Complete | Moderate | Medium | | API Server | No | Varies | High | Medium | | Clustered Setup | Varies | Varies | Very High | Very High |
### When You Need More Than a Stock Node
Consider a Validator if you: - Want governance participation - Have significant business dependency on XRPL - Want to contribute to network decentralization - Seek brand recognition in the ecosystem
Consider a Full History Server if you: - Need access to complete ledger history from genesis - Perform historical data analysis - Build blockchain explorers or analytics tools - Archive transactions for compliance
Consider a High-Performance API Server if you: - Serve public API access to many users - Have heavy query loads - Need optimized response times - Build commercial API services
Consider Clustered Configuration if you: - Need high availability with redundancy - Have extremely high transaction volumes - Require horizontal scaling - Run enterprise-grade infrastructure
### Practical Recommendation
Start with a stock node if you're: - Building applications on XRPL - Learning the system - Need API access for moderate usage - Want operational independence
Upgrade to specialized configurations only when you have specific needs that stock nodes don't satisfy.
For most developers and businesses, a stock node provides all necessary functionality at minimal cost and complexity. It's the Swiss Army knife of XRPL infrastructure—versatile, capable, and sufficient for most use cases without the overhead of specialized setups.
Last updated: February 2026