Table of contents
An RPC node is a server that sits between applications and a blockchain. RPC stands for Remote Procedure Call, and on Solana these nodes are the standard interface wallets, dApps, trading bots, and block explorers use to read network data and submit transactions. Validators run consensus and produce blocks when selected as leaders. RPC nodes give most users and applications a practical way to communicate with that network.
When you open Phantom and check your SOL balance, that request usually hits an RPC node. The same is true when a decentralized exchange prepares a swap or a block explorer displays recent activity. Most user-facing interactions rely on RPC, although sophisticated trading systems can bypass it and send transactions directly to a leader’s Transaction Processing Unit, or TPU.
An RPC node maintains Solana’s current account state and a recent portion of the ledger, then exposes that information through a standardized API. Older transaction history is typically served from a separate archive when the operator supports it. Unlike voting validators, RPC nodes do not participate in consensus or earn staking rewards, but they still require substantial computing power, memory, storage, and bandwidth to keep pace with the network and answer application queries.
How RPC Nodes Work
Solana’s RPC interface uses JSON-RPC, a standard format for sending requests and receiving structured responses over HTTP or WebSocket connections. An application calls a method such as getBalance, getTransaction, or sendTransaction with the required parameters, and the RPC node returns a result.
Read requests query the node’s local account state, recent ledger, or connected archive. Transaction submission is more involved. Unless the application skips preflight, the RPC node simulates the transaction and checks for errors before relaying it toward the current or upcoming network leader. The RPC node’s acceptance of a transaction does not mean the transaction has been confirmed or included in a block.
Performance depends on hardware, network connectivity, and the path between the RPC node and upcoming leaders. A well-connected node can return fresher data and relay transactions with less delay, which matters for latency-sensitive applications such as trading systems and on-chain order books. Transaction landing still depends on the leader schedule, network congestion, priority fees or tips, and mechanisms such as stake-weighted quality of service.
Public vs. Private RPC
Solana Foundation public RPC endpoints are rate-limited and are not intended for production applications. They can work for light testing or occasional wallet queries, but applications that need consistent throughput, low latency, or operational guarantees generally use dedicated infrastructure.
Dedicated RPC can provide higher rate limits, lower latency, enhanced transaction tooling, historical data access, and service-level agreements. Production deployments also commonly use multiple endpoints so an application can continue operating if one node or network path fails.
RPC hardware requirements are comparable to, and often heavier than, those of a voting validator because query traffic, account indexes, and historical data services add memory, storage, and processing demands. RPC nodes do not receive staking rewards, so operators recover those costs through subscriptions, usage-based pricing, or broader infrastructure services.
Why RPC Performance Matters
Your RPC connection directly shapes your experience on Solana. A slow or overloaded endpoint can return stale balances, delay transaction submission, or contribute to failed trades. For DeFi users, a few milliseconds can matter, but the RPC endpoint is only one part of the transaction path.
Colocation places an RPC node in the same data center as a validator, or connects the two through a particularly short network path. This reduces the time required to relay a transaction toward a leader and can improve data freshness. A paired validator may also support stake-weighted quality of service, which can give connected transaction traffic better access to the validator’s TPU connection. None of these advantages guarantees inclusion because fees, tips, congestion, transaction validity, and the leader schedule still affect whether a transaction lands.
Solmate’s announced Infrastructure Flywheel is designed to pair dedicated RPC infrastructure with its bare-metal validator operations in the UAE. The intended advantage is a shorter path between transaction submission and validator infrastructure for institutional clients, trading firms, and developers. This should be understood as an infrastructure capability Solmate is building, not a protocol guarantee that every colocated transaction will confirm.
The Connection Between RPC and Validators
Validators and RPC nodes perform different jobs, but they are closely connected. Validators vote in consensus and produce blocks when selected as leaders. RPC nodes consume network data, maintain queryable state, and relay transactions without voting. An operator that runs both can offer block production, state access, and transaction submission through one infrastructure stack.
That model forms the basis of Solmate’s Infrastructure Flywheel. More delegated stake can give a validator more opportunities to become leader, while an adjacent RPC service can generate separate infrastructure revenue and shorten the path to the operator’s validator. The commercial value depends on execution, customer demand, network conditions, and the services included in the RPC product; it is not guaranteed by the Solana protocol.
Frequently Asked Questions
Do I Need My Own RPC Node to Use Solana?
No. Wallets and most applications connect to RPC infrastructure behind the scenes. Your wallet or application provider usually manages the connection, while developers may choose dedicated endpoints for better performance, reliability, and control.
What Is the Difference Between an RPC Node and a Validator?
A voting validator participates in consensus and can earn protocol rewards. An RPC node maintains queryable network state and relays transactions for applications, but it typically runs without voting and does not earn staking rewards. RPC infrastructure can require more memory, storage, and processing capacity than a validator when it supports heavy queries, account indexes, or historical data.
Does an RPC Node Store Solana’s Full Transaction History?
Not usually. A standard RPC node maintains current account state and a recent, locally stored portion of the ledger. Older transactions and blocks require a connected archival system if the operator offers historical access.
Why Do RPC Nodes Cost Money to Run?
Solana RPC nodes process large volumes of requests while keeping current network state available. High-core CPUs, substantial memory, fast NVMe storage, account indexes, archival services, and high-bandwidth networking can make an RPC deployment as expensive as, or more expensive than, a voting validator. Operators charge for access because RPC nodes do not receive protocol staking rewards.
What Does Colocation Mean in This Context?
Colocation means placing an RPC node and validator in the same data center, or connecting them through a short, controlled network path. It can reduce relay latency and improve data freshness, but it does not guarantee that a transaction will land or confirm.
Can an RPC Node Go Down?
Yes. Hardware failures, software bugs, traffic spikes, and network problems can take an endpoint offline. Applications that need high availability normally connect to multiple endpoints or use infrastructure with built-in redundancy.