Solana RPC methods: what they do and why they matter

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

🧵

Solana trading in 2026 is becoming an infrastructure game ⚡

Alpenglow → sub-150ms finality
Firedancer → 1M+ TPS testing
MEV → maturing with Jito + PBS.

The edge now lives in execution infrastructure.

Full breakdown 👇🏻https://t.co/ddXeYvah3A

— Chainstack 💙🛠️ (@ChainstackHQ) March 25, 2026

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:

1. Sign up with Chainstack.
2. Select Solana by searching through the 70+ protocols, choose the node type, and click Continue.
3. 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:

1. Insert received shreds into the blockstore.
2. Recover missing shreds by Reed-Solomon decoding when 32 or more of the 64 arrived.
3. Request repairs from peers when fewer than 32 arrived.
4. 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.

If you want predictable Solana data and fewer missed slots → always use ShredStream-enabled Solana nodes.

We benchmarked it on Chainstack and got:
– +37% slots in the optimal window
– 3× fewer misses

For indexers, analytics, and real-time apps, it delivers more consistent…

— Chainstack 💙🛠️ (@ChainstackHQ) October 17, 2025

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

Additional resources

• Solana methods
• Solana API reference
• Throughput guidelines
• Optimize your Solana getBlock performance
• Yellowstone gRPC Geyser plugin
• Solana Trader Nodes and Warp transactions
• Chainstack Compare
• chainbench: load-test your RPC endpoint