Validator and RPC Nodes
Split validator and RPC workloads when reliability, history, or indexing demands conflict.
A voting validator participates in consensus, while an RPC node serves application reads, subscriptions, and transaction requests. Those roles do not always want the same configuration; splitting them limits blast radius and lets each machine be sized for its real job.
Validator node
A validator needs stable identity, voting configuration, predictable networking, and enough local IO to keep up with the network. Keep its public RPC surface minimal when it is not intended to serve applications.
The private-cluster validator configuration uses an explicit identity, vote account, separate ledger and accounts paths, a bounded dynamic UDP range, QUIC for TPU traffic, and a limited ledger. Followers also use an entrypoint, trusted validator identities, and, where specified, an expected genesis hash. Those are all trust and reliability controls, not cosmetic flags.
Validator acceptance checks
The slot must advance across the sample interval. For a voting node, verify the vote account and leader performance separately; a healthy RPC response does not prove voting is healthy.
RPC node
An RPC node can be configured for application and indexing workloads using options such as:
| Option | Purpose | Cost to plan for |
|---|---|---|
--no-voting | Runs without vote participation. | Removes voting responsibility but not the underlying data workload. |
--enable-rpc-transaction-history | Serves transaction-history queries. | More retained data and IO. |
--full-rpc-api | Enables the complete RPC surface. | Larger attack surface; pair with authentication and rate limits. |
--account-index | Indexes selected account dimensions for richer queries. | Potentially significant disk and startup cost; enable only the indexes your product needs. |
--private-rpc is appropriate when an RPC interface exists for local operations but must not be exposed as a public service. When public access is required, place a purpose-built RPC tier behind authentication, rate limits, request-size controls, and monitoring rather than exposing a consensus validator directly.
Index planning
Account indexes should start from product queries, not from a desire to “enable everything.” For each index, document the query it serves, expected traffic, extra disk consumed after a defined time, startup/replay impact, and whether the same data could be provided by an indexer instead. Re-measure after a version upgrade or workload change.
Make the split explicit
Document which endpoint customers and applications use, which node holds the validator identity, how RPC traffic is rate-limited, and how much disk each enabled index adds in your workload. Those details prevent an application query pattern from becoming a validator reliability issue.
Capacity boundary
Do not quote a universal request-per-second number for Solana RPC. Capacity depends on enabled methods, account indexes, history retention, query shape, network version, cache behavior, and client retry patterns. Load-test the exact API contract customers will use, then set rate limits and autoscaling or routing policy from those results.