How to get a Solana RPC endpoint for staking (2026 guide)

TL;DR

The first time you point a staking dashboard at the public Solana endpoint, the call that breaks isn’t a fancy one — it’s a plain getProgramAccounts scan of the Stake program that the node refuses with -32602: getProgramAccounts without filters is not supported, or a reward pull that quietly returns null because the epoch hasn’t closed yet. Staking infrastructure leans on exactly the two heaviest, most-throttled corners of the Solana JSON-RPC surface — full stake-account scans and epoch-boundary reward queries — and the shared public cluster caps you at 40 requests per method per 10 seconds. This guide explains how Solana staking RPC actually behaves and how to provision an endpoint that survives an epoch rollover.

What is a Solana RPC endpoint

A Solana RPC endpoint is the JSON-RPC interface your application talks to in order to read the chain’s account state and submit transactions. Solana is not EVM-compatible: there is no eth_call, no contract storage slots, and no event-log index. Everything is an account. A validator’s stake is recorded across vote accounts and individual stake accounts owned by the on-chain Stake program (Stake11111111111111111111111111111111111111), and your endpoint is how you read those accounts, watch them change across slots, and broadcast the instructions that delegate, deactivate, or withdraw stake.

For staking infrastructure specifically, the endpoint is what powers:

• Validator discovery and delinquency tracking via getVoteAccounts (current and delinquent vote accounts with their activated stake)
• Listing and decoding individual stake accounts via getProgramAccounts against the Stake program, with dataSize/memcmp filters
• Epoch-level reward attribution via getInflationReward for staking and voting rewards per address
• Epoch and schedule context via getEpochInfo, getEpochSchedule, and getLeaderSchedule
• Network-wide yield context via getInflationRate, getInflationGovernor, and getStakeMinimumDelegation
• Real-time delegation and balance changes through WebSocket accountSubscribe/slotSubscribe or Yellowstone gRPC (Geyser) streams
• Broadcasting delegate, split, merge, deactivate, and withdraw instructions through sendTransaction

You can review the full list of supported methods in the Solana JSON-RPC documentation. The quality of the endpoint behind these calls is what decides whether your reward run finishes inside the epoch boundary or stalls halfway through a 50,000-account scan — on Solana, a single epoch rollover can turn a comfortable steady-state poll into a request storm that a shared endpoint will not absorb.

How Solana RPC differs from EVM chains

If you’re coming from Ethereum, the biggest unlearning for staking work is that there are no event logs to query. On an EVM chain you’d track staking by filtering eth_getLogs for Staked/Unstaked events. Solana has no equivalent — state lives in accounts, and you discover staking activity by scanning the accounts the Stake program owns and decoding their binary layout yourself, or by subscribing to account changes in real time.

A few structural differences shape every staking integration:

• Accounts, not contract storage. Programs on Solana are stateless; all state is held in separate accounts. A stake account is a discrete account with a fixed binary layout (Initialized, Stake, RewardsPool), not a mapping inside a contract. You read it with getAccountInfo and parse it, rather than calling a getter.
• getProgramAccounts replaces log filters — and it’s expensive. To enumerate stake accounts you call getProgramAccounts on the Stake program. Unfiltered calls against large programs are rejected outright (-32602); you must supply a dataSize or memcmp filter (for example, memcmp on the staker or withdrawer authority offset). This single method does the work that eth_getLogs plus an indexer would do on Ethereum, and it is correspondingly heavy.
• Epoch-denominated rewards. Solana rewards accrue per epoch (~432,000 slots, roughly two to three days), not per block. getInflationReward only returns a value once the target epoch has fully closed, so reward attribution is inherently a batch job tied to the epoch clock — there is no streaming “reward emitted” event.
• Transactions expire. Every transaction references a recent blockhash and is dropped if it isn’t confirmed within ~150 slots. Delegation and withdrawal instructions need fresh blockhashes and retry logic, unlike a nonce-ordered EVM transaction that simply waits in the mempool.
• Different tooling entirely. There is no ethers.js or web3.py here. The modern client is @solana/kit, with @solana/web3.js v1 on a maintenance branch and solana-py for Python — and the deprecated getStakeActivation method (removed in Agave v2.0) is a trap EVM developers walk straight into.

Solana RPC endpoint options

Public vs private Solana RPC endpoints

For staking infrastructure, the public-versus-private decision comes down to one question: can the endpoint absorb an epoch rollover? Every two to three days your reward jobs and stake-account reconciliations spike at once, and that is precisely when a shared endpoint’s per-method throttle bites hardest.

Official public endpoints:

• Mainnet: https://api.mainnet-beta.solana.com
• Devnet: https://api.devnet.solana.com
• Testnet: https://api.testnet.solana.com

⚠️ The public mainnet-beta cluster caps each IP at 100 requests per 10 seconds, 40 requests per 10 seconds for any single RPC method, and 40 concurrent connections. A staking reconciliation that paginates getProgramAccounts or fans out getInflationReward across thousands of stake accounts hits the 40-per-method wall almost immediately. The Solana cluster docs themselves recommend using dedicated/private RPC servers for production rather than the public endpoints.

Property	Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
Per-method rate limit	40 req / 10s per method	No aggressive throttling
getProgramAccounts stake scans	Throttled, often timeout	Supported with filters
Archive / historical rewards	Not available	Available

A staking platform that reconciles delegations and distributes rewards on the epoch clock cannot run on an endpoint that throttles the exact two methods that work hardest at epoch close — managed infrastructure isn’t a nice-to-have here, it’s what keeps your reward run inside the epoch window.

📖 For a detailed comparison of Solana RPC providers, see Best Solana RPC providers for fast and reliable production in 2026.

Full node vs archive Solana node

For staking infrastructure, historical access is the difference between “what is delegated right now” and “what did every stake account earn three epochs ago” — and reward attribution lives entirely in the latter.

Full node access	Archive node access
Current stake-account state and active delegations	Historical getInflationReward for closed epochs beyond recent retention
Live validator set and delinquency via getVoteAccounts	Reconstructing stake activation/deactivation history across epochs
Real-time slotSubscribe and account change monitoring	Backfilling reward statements for tax and accounting exports

A full node holds recent state and is enough for live dashboards and delegation flows. But getInflationReward for an epoch only resolves after that epoch closes, and once you’re querying rewards from more than a couple of epochs back you need history a pruned node no longer keeps. Chainstack supports Solana archive nodes, so reward backfills and multi-epoch yield reporting run against the same provider — see Chainstack archive data for how archive access works. Tie this to your real use cases: any staking operator that produces reward statements, computes historical APY, or supports compliance and tax reporting needs archive access, not just a full node.

HTTPS vs WebSockets

Staking infrastructure is event-driven at the edges — you want to know the instant a delegation activates, a validator goes delinquent, or a stake account is deactivated — so persistent connections matter more here than for a read-mostly dashboard. The trade-off is operational complexity.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Reward batch jobs, getProgramAccounts scans, broadcasting delegate/withdraw txs	Live accountSubscribe on stake accounts, slotSubscribe, delinquency watch
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

For high-volume, low-latency stake monitoring across many accounts, the standard WebSocket PubSub interface is often supplemented by Yellowstone gRPC (the Geyser plugin), which streams account, transaction, and slot updates with lower latency than polling. Use HTTPS for your epoch-boundary reward batches and stake-account scans, and a persistent subscription for the live delegation and delinquency signals you can’t afford to poll for.

How to get a private Solana RPC endpoint with Chainstack

1. Log in to the Chainstack console (or create an account)
2. Create a new project
3. Select Solana as your blockchain protocol
4. Choose network: Mainnet or Devnet
5. Deploy the node
6. Open Access/Credentials and copy your HTTPS and WebSocket endpoints
7. Run a quick connectivity check before wiring it into production code

You can deploy a private Solana RPC node on Chainstack in a few minutes and point your staking jobs at it. Once your endpoint is live, a minimal connectivity check with the modern @solana/kit SDK looks like this:

import { createSolanaRpc } from "@solana/kit";

// Use your Chainstack HTTPS endpoint, not the public cluster
const rpc = createSolanaRpc("YOUR_CHAINSTACK_ENDPOINT");

// Current and delinquent vote accounts, with activated stake per validator
const voteAccounts = await rpc.getVoteAccounts().send();

console.log("Active validators:", voteAccounts.current.length);
console.log("Delinquent validators:", voteAccounts.delinquent.length);

📖 For the full integration guide, see the Chainstack Solana tooling documentation.

You can also access Chainstack Solana RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

Chainlist is EVM-only, so it doesn’t apply to Solana — wallets add Solana clusters directly, and there’s no Chainlist entry to swap for a managed endpoint.

Chainstack pricing for Solana RPC

Chainstack bills on request units rather than opaque compute credits, which makes a staking workload’s bursty epoch-boundary spikes easier to model against a monthly budget. See the full Chainstack pricing page for plan details and overage rates.

Plan	Cost	Requests/Month (RU)	RPS	Overage (per 1M extra RU)
Developer	$0	3M	25	$20
Growth	$49	20M	250	$15
Pro	$199	80M	400	$12.50
Business	$499	200M	600	$10
Enterprise	from $990	400M+	Unlimited	$5

Advanced options relevant to staking infrastructure:

• Archive node access (included from the Growth plan) — archive requests consume 2 RU each versus 1 RU for full-node requests; link your reward-history backfills to Chainstack archive data.
• Unlimited Node add-on — a flat monthly fee at a fixed RPS, which fits the predictable-but-heavy getProgramAccounts scans staking platforms run.
• Dedicated Nodes — from $0.50/hour per node plus storage, for isolated resources when stake-account scans and reward jobs must not contend with other traffic.

How to estimate monthly cost

1. Count your baseline read calls per second across dashboards and live subscriptions.
2. Add your write volume (delegate, deactivate, withdraw broadcasts).
3. Multiply by seconds in a month for steady-state RU.
4. Add archive RU (2 RU each) for any historical reward queries.
5. Size for the epoch rollover, not the average. On Solana, your getInflationReward fan-out and full Stake-program scans land in a tight window every ~2–3 days when an epoch closes — buffer for a 3–5x spike over baseline in that window, or you’ll exhaust your RPS exactly when reward attribution runs.

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set
• Retry logic with exponential backoff implemented
• Credentials stored in env/secret manager (never hardcoded)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation
• getProgramAccounts calls against the Stake program always carry a dataSize or memcmp filter — never an unfiltered scan
• Archive endpoint confirmed for getInflationReward queries beyond recent epoch retention
• Deprecated getStakeActivation replaced with getAccountInfo-based activation parsing before any Agave v2.0 upgrade
• Per-method rate limiter in place so epoch-boundary reward fan-out doesn’t self-throttle

Troubleshooting common Solana RPC issues

Issue	How to fix
-32602: getProgramAccounts without filters is not supported	Add a dataSize or memcmp filter (e.g. on the staker/withdrawer authority offset); run the scan against a dedicated or archive node rather than the public cluster.
getInflationReward returns null for an epoch	The epoch hasn’t fully closed yet — query the previous completed epoch; for older epochs, point the call at an archive node.
getStakeActivation method not found after Agave v2.0	The method was removed; reconstruct activation state (inactive/activating/active/deactivating) from getAccountInfo plus the current epoch from getEpochInfo.
429 Too Many Requests during epoch-boundary reward runs	You’re hitting the 40-req-per-method public cap; move to a managed endpoint and add a per-method rate limiter.
Stake-account scans time out	Paginate with tighter memcmp filters, use an archive or dedicated node, and avoid scanning the full Stake program in one call.
WebSocket accountSubscribe/slotSubscribe disconnects	Implement reconnect with heartbeat, resubscribe on reconnect, and backfill missed changes with a getProgramAccounts reconciliation pass.

Conclusion

The failure mode that catches staking teams isn’t dramatic — it’s silent and badly timed. Your dashboards look fine for two days, then the epoch closes, your reward job fans getInflationReward across every delegator and your reconciliation paginates the entire Stake program at the same moment, and the public endpoint starts returning 429 and null for the exact calls your accounting depends on. Because it only happens at epoch boundaries, it’s miserable to reproduce in testing and easy to misdiagnose as a bug in your own batch logic.

The pattern that works: provision a managed Solana endpoint with archive access from the start, always filter your getProgramAccounts stake scans, treat getInflationReward as an epoch-clocked batch job against historical data, and replace getStakeActivation before it disappears under you. Size your plan for the rollover spike, not the steady state. These aren’t optimizations — they’re the difference between reward statements that reconcile and a support queue that fills up every third day. The same managed RPC that survives this is what lets you build staking and DeFi flows without rate limits on Solana.

Start on the free Developer plan to prototype, then move to a dedicated or archive-backed endpoint before your first production epoch close.

FAQ

Which SDK should I use for Solana staking integrations? Use @solana/kit, the modern, tree-shakeable JavaScript SDK that replaces the class-based @solana/web3.js v1 (now on a maintenance branch). For Python, solana-py is the standard RPC client. All of them talk to the same JSON-RPC endpoint, so your provider choice is independent of SDK choice — but pin your version, because the Stake program account layouts and deprecated methods like getStakeActivation are exactly where SDK drift bites.

Is the public endpoint enough for a staking dashboard? For local development, yes. For anything reconciling real delegations, no — the 40-request-per-method-per-10-seconds cap on the public mainnet-beta cluster throttles the getProgramAccounts and getInflationReward calls that staking work depends on, and it does so hardest at epoch close when those calls all fire at once.

How do I get stake activation state now that getStakeActivation is deprecated? The method was removed in Agave v2.0. Fetch the stake account with getAccountInfo, parse its delegation fields (activation and deactivation epochs), and compare against the current epoch from getEpochInfo to derive whether the stake is activating, active, deactivating, or inactive.

Do I need an archive node for staking rewards? Yes, if you report on more than the most recent epoch or two. getInflationReward only resolves after an epoch closes, and historical reward data for older epochs is pruned from full nodes — reward statements, historical APY, and tax/compliance exports all require archive access.

How do I list all stake accounts for a validator or authority efficiently? Call getProgramAccounts on the Stake program (Stake11111111111111111111111111111111111111) with a memcmp filter on the relevant authority offset, plus a dataSize filter. Never send an unfiltered request — large-program scans without filters are rejected with -32602, and even filtered scans should run against a dedicated or archive node, not the public cluster.

What should I monitor for Solana staking infrastructure? Track per-method latency and error rate (especially on getProgramAccounts and getInflationReward), 429 throttling counts, WebSocket reconnect frequency, and your distance to the next epoch boundary so you can pre-scale ahead of the reward run.

Additional resources

• Solana: Geyser and Yellowstone gRPC in Node.js — streaming account and slot updates for live stake monitoring
• Chainstack Solana tooling documentation — SDK setup and connection guides
• getProgramAccounts method reference — filtering stake-account scans correctly
• How to use the Solana Geyser plugin to stream data with Yellowstone gRPC — Chainstack Blog
• More Solana tutorials and articles on the Chainstack Blog