TL;DR: Every Solana RPC call follows the same path: a method name arrives, a node reads state, and the node returns data it assembled from shreds. Each stage has a cost, and the cost depends on the method. getSlot reads one value from memory, getProgramAccounts scans account data, and getBlock serializes several megabytes.
Solana RPC methods differ in cost because of the method itself, the data it requests, and the infrastructure serving it. This article breaks down the main Solana RPC methods, explains where each fits into an application, and connects them to the infrastructure underneath: method-aware routing and the shred feed.
What is Solana?
If you already know Solana, skip ahead to “Solana RPC” to see how methods, routing and block data work together.
Solana is a high-throughput Layer 1 blockchain built around parallel transaction execution and a proof-of-history clock. Slots last roughly 400 ms, which gives applications fast feedback for trading, payments and consumer apps. Finalization takes about 12.8 seconds under the current consensus. The Alpenglow upgrade targets roughly 150 ms finality. It activated on testnet on September 24, 2026 and on devnet on September 25, while mainnet still runs the current system and has no confirmed activation date.
According to solana.com on September 30, 2026, and active vote accounts counted through getVoteAccounts on October 1, 2026, the network runs on:
- Active addresses: 50M monthly active addresses
- Transaction volume: 3.5B transactions per month
- Throughput: 5,000+ transactions per second
- Validators: about 670 active validators
- Slot time: roughly 400 ms
- Finality: about 12.8 seconds, with Alpenglow targeting roughly 150 ms
A chain with 400 ms slots and this much traffic puts real pressure on the RPC layer between an application and the network. Understanding how requests are processed under the hood is the first step to optimizing how your application talks to the chain.
Solana RPC
Every Solana RPC request arrives with a method name, reaches a node, reads state and returns data that the node assembled from shreds. This guide follows a request through three stages:
- The method decides the cost of the work.
- The routing decides which node does the work.
- The block data decides what that node knows.
Chainstack’s Solana RPC serves 67 methods: 51 over HTTP JSON-RPC and 16 WebSocket subscription methods, on slots of roughly 400 ms. The Solana methods page lists them all.
Set up an endpoint
Chainstack serves Solana on Global Nodes, Trader Nodes and Dedicated Nodes, with HTTPS and WebSocket access. Yellowstone gRPC is available as an add-on on mainnet.
Deploy a node in three steps:
- Sign up with Chainstack.
- Select Solana by searching through the 70+ protocols, choose the node type, and click Continue.
- Give the node a name, review the deployment details, and click Deploy node.
The node is deployed and ready to use. Open Access and credentials to copy your HTTPS and WSS endpoint URLs. For the full list of supported calls, see the Solana API reference.
What each method group costs
The method field in the JSON-RPC body is the first thing a request reveals about itself. Five groups cover the practical surface:
| Group | Methods | Resource profile |
|---|---|---|
| Chain state | getSlot, getBlockHeight, getLatestBlockhash | Small responses from in-memory state |
| Accounts | getAccountInfo, getMultipleAccounts, getTokenAccountsByOwner, getProgramAccounts | From a single lookup to a scan of the account set |
| Blocks and history | getBlock, getTransaction, getSignaturesForAddress, getBlocks | Large payloads; archive data for old ranges |
| Transactions | sendTransaction, simulateTransaction, getSignatureStatuses, getRecentPrioritizationFees | Latency-sensitive writes |
| Streams | accountSubscribe, slotSubscribe, logsSubscribe, Yellowstone gRPC | Continuous delivery |
Chain state
State calls are the cheapest. A getSlot response is a few bytes read from memory, so its latency is mostly network transport and scheduling delay. This is the quickest way to confirm an endpoint works:
const options = {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ id: 1, jsonrpc: '2.0', method: 'getSlot', params: [] }),
};
fetch('YOUR_CHAINSTACK_ENDPOINT', options)
.then((res) => res.json())
.then((res) => console.log(res))
.catch((err) => console.error(err));Accounts
Account reads form the largest share of typical traffic. getMultipleAccounts retrieves several accounts in one request, which reduces network overhead compared with repeated getAccountInfo calls:
const options = {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
id: 1,
jsonrpc: '2.0',
method: 'getMultipleAccounts',
params: [
[
'9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM',
'7mhcgF1DVsj5iv4CxZDgp51H6MBBwqamsH1KnqXhSRc5',
],
{ encoding: 'base58' },
],
}),
};
fetch('YOUR_CHAINSTACK_ENDPOINT', options)
.then((res) => res.json())
.then((res) => console.log(res))
.catch((err) => console.error(err));Scans cost far more than lookups. getProgramAccounts, getSupply and getTokenAccountsByOwner are available on paid plans only. The getProgramAccounts limit depends on the size of the program you query: for smaller programs it is 20 RPS with filters and 10 RPS without, and it drops as the program grows. Scan methods also run under a 60-second execution-time limit and a per-request memory limit, and a scan that exceeds either returns error -32012 instead of hanging. See the throughput guidelines for the per-method limits.
Blocks
getBlock carries the largest payload of the read methods. Chainstack’s optimization guide measured one mainnet block in four encodings:
| Encoding | Response size |
|---|---|
base58 | 6.3 MB |
base64 | 6.3 MB |
json | 8.0 MB |
jsonParsed | 16 MB |
The requests below set maxSupportedTransactionVersion to 1. A lower value, or an omitted field, returns error -32015 when the block holds a newer transaction version. Replace the slot with a recent finalized slot from getSlot. Older slots are archive requests.
Full detail with parsed instructions, the largest response:
const slot = 452144000; // replace with a recent finalized slot
const options = {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
id: 1,
jsonrpc: '2.0',
method: 'getBlock',
params: [slot, {
encoding: 'jsonParsed',
transactionDetails: 'full',
commitment: 'finalized',
maxSupportedTransactionVersion: 1,
}],
}),
};
fetch('YOUR_CHAINSTACK_ENDPOINT', options)
.then((res) => res.json())
.then((res) => console.log(res))
.catch((err) => console.error(err));Signatures only, a much lighter response. Change the request body to:
params: [slot, {
encoding: 'json',
transactionDetails: 'signatures',
commitment: 'finalized',
maxSupportedTransactionVersion: 1,
}]Full detail with gzip compression. Ask for it with the Accept-Encoding header:
headers: { 'Content-Type': 'application/json', 'Accept-Encoding': 'gzip' },Many HTTP clients already send this header and decompress the response, so check yours. In a browser you cannot set the header yourself, but the browser negotiates compression for you. Gzip typically shrinks block responses by 70-90%, so compression belongs on every getBlock client. Older block ranges become archive calls, and an archive request counts as 2 requests while a full node request counts as 1.
Transactions
The transaction group already shows method-specific handling on Chainstack. With Warp transactions, only the sendTransaction call goes to the current leader through bloXroute’s staked validator connections, while every other request goes through the standard Chainstack Solana node. Warp is available on Trader Nodes and Global Nodes as an add-on.
Streams
Streams deliver continuously instead of per request. accountSubscribe, slotSubscribe and logsSubscribe run over WebSockets, and Yellowstone gRPC streams straight from validator memory. The Yellowstone section below covers connection details.
const WebSocket = require('ws');
const ws = new WebSocket('YOUR_CHAINSTACK_WSS_ENDPOINT');
ws.on('open', () => {
ws.send(JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'slotSubscribe',
}));
});
ws.on('message', (data) => {
console.log('Slot update received:', JSON.parse(data));
});Method-aware routing
A method-aware router reads the method field and maps the request to a node pool. Even distribution balances on connection count or position and ignores the field. Chainstack moved Solana to GEN 2.0 with method-aware routing on August 29, 2026.
Latency for any call is queue wait plus service time, and service time depends on the method. Method-aware routing gives each class of work its own placement:
| Class | Example methods | Dominant cost | Suited placement |
|---|---|---|---|
| In-memory reads | getSlot, getLatestBlockhash | Scheduling delay | Short queues, low utilization |
| Account lookups | getAccountInfo, getMultipleAccounts | Account index reads | Nodes with warm account data |
| Scans | getProgramAccounts, getTokenAccountsByOwner | Index traversal | Nodes sized for long-running queries |
| Block reads | getBlock, getTransaction | Serialization and transfer | Nodes with fast block storage access |
getSlot reads a value, getMultipleAccounts reads accounts from the account index, and getBlock reads, serializes and transmits several megabytes. Queue wait depends on what runs ahead of the call on the same node. When one node handles both getBlock and getLatestBlockhash, the fast call spends time behind the slow one.
What method-aware routing changed in the limits
Routing each method to a pool that fits it lets capacity grow per method instead of per node. In late September 2026, Chainstack used this to raise the per-method limits on Solana Mainnet Global Nodes. These are the current limits for six of the methods:
| Method | Limit now |
|---|---|
getSupply | 300 RPS |
getTokenSupply | 500 RPS |
getBlockTime | 500 RPS |
getBlock | 400 RPS |
getTokenAccountsByOwner | 150 RPS |
getMultipleAccounts | 300 RPS |
The limits are the same in every region. The current values for every method, including the getProgramAccounts limits that now depend on the program, are in the throughput guidelines.
Chainstack Compare publishes its probes, scoring formula and code, so anyone can check the numbers. In the seven-day view on October 1, 2026, Chainstack’s median on Solana was 26 ms, within 2 ms of the lowest, and its P95 was 84 ms. The tail is the number to watch: P99 was 280 ms. A strong median with a wider tail is the shape that method-level interference produces, so P99 is the metric to track as GEN 2.0 matures.
Routing decides which node answers. The next section covers what that node knows about the block it returns.
The Everstake shred feed
Where a block comes from
Every getBlock answer depends on how a node assembled the block. A leader produces entries and serializes them into shreds, packet-sized fragments that fit a UDP datagram. Data shreds carry the entries, and coding shreds carry Reed-Solomon parity. Merkle shreds typically group 32 data shreds with 32 coding shreds in an FEC set, and any 32 of the 64 reconstruct the set. Turbine spreads shreds through a stake-weighted tree of validators, so each node receives them after some number of hops.
A node follows a fixed sequence for every slot:
- Insert received shreds into the blockstore.
- Recover missing shreds by Reed-Solomon decoding when 32 or more of the 64 arrived.
- Request repairs from peers when fewer than 32 arrived.
- Replay the completed slot, after which the block becomes readable.
Steps 2 and 3 cost CPU time and network round trips. Some validators sit closer to the leader and receive shreds sooner, network hops add jitter, and late or out-of-order shreds can leave an RPC node briefly behind or missing a slot.
A shred feed adds a second delivery path. A validator positioned near the leader forwards raw shreds straight to the node. A shred that Turbine delivers late frequently arrives from the feed on time, so more FEC sets complete, fewer sets need repair, and replay starts sooner.
Jito states that ShredStream shuts down completely on September 5, 2026, with DoubleZero Edge as the recommended replacement. Ahead of that date, on September 4-5, 2026, Chainstack migrated its Solana shred feed to Everstake across five clusters: London, two in Frankfurt, New York, and Singapore. Nodes stayed online through the change and customer traffic continued to flow normally.
Missing-shred rates fell roughly 60-75% across the migrated clusters.
The effect of shred feeds on Chainstack nodes was measured a year earlier. In an October 2025 post on X, Chainstack reported that ShredStream-enabled Solana nodes delivered 37% more slots in the optimal window and 3x fewer misses. That benchmark ran on the earlier feed, and the Everstake migration extends the same mechanism to the new source.
Which methods benefit
| Method | Link to shred completeness | Developer-visible effect |
|---|---|---|
getSlot, getBlockHeight | Tip follows replay progress | Steadier tip |
getBlock | Block becomes readable after replay | Finished blocks available sooner |
slotSubscribe, blockSubscribe | Events follow node state | More even event timing |
| Yellowstone gRPC streams | Data comes from validator memory | Fewer gaps to recover |
getMaxShredInsertSlot | Direct view of blockstore inserts | Node health signal |
Routing chooses the node, and the shred feed improves what that node holds.
Check node state
getMaxShredInsertSlot returns the highest slot for which shreds were received and inserted into the blockstore. Comparing it with getSlot shows how far shred insertion runs ahead of the slot the node treats as current:
const options = {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ id: 1, jsonrpc: '2.0', method: 'getMaxShredInsertSlot', params: [] }),
};
fetch('YOUR_CHAINSTACK_ENDPOINT', options)
.then((res) => res.json())
.then((res) => console.log(res))
.catch((err) => console.error(err));Stream from the same node state
The Yellowstone gRPC Geyser plugin reads from validator memory, so streams reflect the improved shred coverage directly. The TypeScript client requires the scheme, while the Python client requires only the host and port.
const { default: Client } = require('@triton-one/yellowstone-grpc');
const client = new Client('https://yellowstone-solana-mainnet.core.chainstack.com:443', 'YOUR_X_TOKEN');
(async () => {
console.log(await client.getVersion());
})();The plugin is a paid add-on from the Growth plan on mainnet, with $49, $149 and $449 monthly tiers offering 2, 7 and 25 concurrent streams and up to 200 accounts per filter. A client that briefly disconnects can recover with from_slot. On Global Nodes the replay buffer holds roughly the last 100 slots, about a minute, and an older request returns:
broadcast from <slot> is not available, last available: <slot>Older history comes from getBlock, getSignaturesForAddress and getTransaction. The Chainstack Geyser Python tutorial includes a recover_missed_slots_with_from_slot.py example for the recovery pattern.
Builder tools
- @solana/kit: the current JavaScript and TypeScript SDK
- Anchor: the Rust framework for programs
- LiteSVM and Surfpool: local testing and mainnet forking
- Solana Trader Nodes with Warp transactions: staked transaction submission
- Yellowstone gRPC: streaming plugin and clients
- chainbench: load testing
- Chainstack MCP server: manage Solana nodes from an AI agent
- pumpfun-bonkfun-bot: an open-source Solana trading bot
- Jito: block engine and bundle infrastructure
- Everstake: supplies the shred feed Chainstack now uses
- bloXroute: provides the staked connections behind Warp transactions
- Triton One: created the Yellowstone gRPC plugin
- Anza: maintains the Agave client that RPC nodes run
Conclusion
A Solana RPC request passes through several stages, and each has a technical owner. The method sets the cost of the work. Method-aware routing places that work on the node that handles it best. The Everstake shred feed improves the block data that node holds, which shows up in getBlock, getSlot, subscriptions and gRPC streams. Chainstack Compare’s open probes, formula and code make the outcome measurable from any machine.
The public data adds an honest reading. As of October 1, 2026, Chainstack’s seven-day median on Solana is 26 ms, within 2 ms of the lowest, and its P99 is 280 ms, so the tail is where further gains show up. Which setup fits depends on what an application asks of the chain: a wallet reading balances mostly needs fast state calls, a trading bot needs landing performance and streams, and an indexer needs cheap, compressed block reads.
Frequently asked questions
Solana RPC methods are the JSON-RPC calls that applications use to read chain state, submit transactions and subscribe to updates. Chainstack serves 67 Solana methods: 51 over HTTP and 16 over WebSocket. Slots are produced roughly every 400 ms.
confirmed suits interactive reads, and Chainstack’s guide to landing transactions fetches the blockhash at confirmed. finalized suits settlement logic, since a block at that level is rooted. Finalization takes about 12.8 seconds under the current consensus. The Alpenglow upgrade targets roughly 150 ms. It activated on testnet on September 24, 2026 and on devnet on September 25, and mainnet activation has no confirmed date.
In Chainstack’s measurement, one mainnet block was 6.3 MB in base58 or base64, 8.0 MB in json and 16 MB in jsonParsed. Three changes reduce the payload: set transactionDetails to signatures, use base64 instead of json or jsonParsed, and enable gzip compression, which typically cuts block responses by 70-90%. Set maxSupportedTransactionVersion to 1 so blocks with version 1 transactions return cleanly.
Account scans and block reads. getProgramAccounts scans account data, and its rate limit depends on the size of the program you query. getBlock returns several megabytes, up to about 16 MB with jsonParsed in Chainstack’s measurement. State calls such as getSlot are the cheapest, because they read one value from memory.
getProgramAccounts, getSupply and getTokenAccountsByOwner are available on paid plans only, and getLargestAccounts is available on Dedicated Nodes only.
A full-node request counts as 1 request unit (RU) and an archive request counts as 2 RUs. getBlock, getTransaction, getSignaturesForAddress and other history methods can read archive data for older ranges.
A 429 means you hit an RPS or connection limit. Solana Mainnet is capped at 5 RPS on Developer and 50 RPS on Growth, some methods have lower caps, and getProgramAccounts depends on program size. Wait for the hint in the response before retrying, throttle your client and cut request volume.