Solana RPC Nodes and Explorers: Requirements and Options
Table of contents
A Solana RPC node is a server that answers app requests such as balances, transactions, and sending transactions. Such a server requires much more powerful hardware than an ordinary server: 16 or more cores, 512 GB RAM or more for all account indexes, and several NVMe disks are listed on Anza's requirements page. For most apps, a private RPC provider is the practical route, and Solana's production-readiness guide says to never use public RPC endpoints for production because they are rate-limited with no SLA. A block explorer is the separate tool for looking up wallets and transactions by hand.
This article covers Solana explorers, the difference between RPC and validator nodes, Anza's hardware specifications, archive data limitations, and choosing between public, provider, and self-hosting. Providers are not ranked. Specifications and prices evolve, so please consult the live documentation.
Solana Explorers
Explorer displays information about any public blockchain address without a wallet connection. According to a Helius article published on October 29, 2025, there are Solana Explorer (the first official explorer, currently maintained by Solana Foundation), Solscan (launched in 2021 and acquired by Etherscan in early 2024), SolanaFM (launched in 2021 and acquired by Jupiter in September 2024, called largely unmaintained by the article), and Orb (designed by Helius), as well as several validator dashboards such as Validators.app and Solana Beach. Helius is a vendor that operates Orb, which it lists first, so the selection is not neutral.
For address lookup, explorer will display balance, token balances, and transactions history. An explorer never requires a recovery phrase; entering one on any website is a scam sign.
RPC Node or Validator Node
According to a GetBlock article, which is a vendor content, a validator votes and maintains consensus, whereas an RPC node serves requests. According to the same article, an RPC node cannot earn SOL and requires none for running, while a validator needs to fund a voting account. It also says the Solana Foundation strongly discourages running both on one machine. These points are a vendor account and match the common distinction between the two roles.
Hardware Requirements
Anza's Agave requirements page specifies the following for an RPC node:
-
CPU. 16 cores and 32 threads or more, at a base clock of 2.8 GHz or faster. A validator requires 12 cores and 24 threads or more.
-
RAM. 512 GB or more for all account indexes. A validator requires 256 GB or more.
-
Disks. PCIe Gen3 x4 NVMe or better: accounts at 1 TB or larger, ledger at 1 TB or larger (RPC node may require more space for storing history longer than that), snapshots at 500 GB or larger. Accounts and ledger drives for RPC nodes should not be shared.
-
Network. Stable public IPv4 address, with 1 Gbit/s symmetric being sufficient for an unstaked node.
-
Software. The project runs on Ubuntu 24.04, Docker is not recommended for live clusters, and cloud VMs require much greater amount of operational knowledge.
This page is the source of the 2025 hardware requirements question, however, it lacks revision date, so the current specifications should be checked. GetBlock estimates self-hosting a node at $2,000 to $4,000 to set it up and $500 to $700 monthly to support, which is a vendor's estimate and was not verified.
A Hypothetical Cost Comparison
This example uses the vendor figures above and is not a quote. Hosting a node for 12 months would cost $2,000 + $500 × 12 = $8,000 at the low end, and $4,000 + $700 × 12 = $12,400 at the high end. GetBlock offers its managed plans starting from $39 per month, or $468 per year. Those are not directly comparable, as a basic plan is not a dedicated node, but the gap shows why hosting one's own RPC node mostly suits teams with a clear need for control.
Public, Shared, and Dedicated RPC
According to Solana's production-readiness guide, public endpoints have no SLA, are rate-limited and suitable only for development, and may fail payment flow. It recommends a private provider and checking its uptime SLA of 99.9% or higher, geographic location, transaction landing, and priority-fee API features. It also recommends a fallback RPC node, securing RPC URLs like API keys, and watching error rate.
A Chainstack article, written by a dedicated-node vendor, says public endpoints often limit requests to 40 to 100 per 10 seconds per IP, and that a dedicated node gives isolated compute resources and rate limits adjusted to the traffic. Signs that a dedicated node may be required are 429 errors while processing regular traffic, exceeding a few hundred requests per second with sustained traffic, and latency-sensitive features such as trading or payments. They are vendor guidelines and not Solana requirements.
Archive Nodes and Historical Data
A standard RPC node does not hold full history. According to an Alchemy overview, published on July 22, 2026, a standard node stores roughly the last couple of days, pruning the older data, and that the default ledger limit of 200 million shreds keeps the ledger under roughly 500 GB, and that Solana does not keep past account balances, so historical balances must be derived from transaction history. It describes two options for storing full history: Bigtable-based solution and Old Faithful, an open-source archive that Triton's documentation describes as providing gRPC streaming of bulk data. This overview is vendor content.
For wallet history, the standard method, according to the same overview, is a paginated getSignaturesForAddress request followed by getTransaction request. Helius documents their proprietary getTransactionsForAddress method combining both, and a transfers method returning parsed records. They are vendor-specific and not part of the standard Solana RPC API. An inclusion of NFT API like DAS in the plan was not covered by the pages read.
How to Run a Solana Node
Anza's page provides information about requirements only, not about setup. Setup steps were not considered in this article. One should follow Anza's documentation for installation and pay attention to the RPC flags and ledger limit setting. According to a GetBlock article, some RPC node flags are no-voting and full-rpc-api; those should be confirmed against the current Anza documentation.
Managed Hosting and CI Hooks
There is no verified source about CI hooks with managed hosting. Chainstack lists webhooks as a vendor-specific feature of dedicated nodes, and no source read mentioned CI integration. Any claims about CI hooks by a provider should be confirmed in that provider's documentation; no provider is recommended in this article.
Risks
-
Using a public endpoint in production can cause rate-limit failures.
-
A single provider is a single point of failure; thus, a fallback RPC is recommended by the Solana guide.
-
Exposing RPC keys is a security risk and may lead to usage cost abuse.
-
Self-hosting requires 24/7 monitoring and upgrading, and enough disk and RAM.
-
Fake explorer and wallet sites exist, so the address should be typed or bookmarked.
What to Check Live
-
The current Agave hardware requirements and supported operating system.
-
The provider's SLA, rate limits, and whether archive and streaming access are included.
-
The method names and limits for historical data retrieval, such as getSignaturesForAddress limits.
-
Whether the explorer is maintained and run by a known operator.
-
The hardware/plan cost versus the expected traffic.
This article is educational and is not investment advice. Interfaces and provider features were not tested for this article.
Related guides
Scroll to top