How to get a Solana RPC endpoint for DeFi in 2026

TL;DR

On Solana DeFi, a slow or rate-limited RPC endpoint doesn’t throw an error — your swap simply misses its slot, your liquidation fires a beat too late, and your aggregator quotes a pool that drained two slots ago. The cause is structural: every transaction references a blockhash that expires in roughly 60 seconds, and the chain produces blocks faster than any polling loop can keep up. This guide shows you how to get a Solana RPC endpoint built for that reality — covering public versus private endpoints, archive access, Geyser streaming, and transaction landing for DeFi workloads.

What is a Solana RPC endpoint for DeFi

A Solana RPC endpoint is the JSON-RPC interface your DeFi application uses to read on-chain state and push transactions into the cluster. Unlike an EVM chain, Solana has no global account trie you traverse by key — state lives in independent accounts owned by programs, and your endpoint exposes methods like getAccountInfo, getProgramAccounts, getMultipleAccounts, and simulateTransaction to read those accounts, plus sendTransaction to submit signed, serialized transactions. For real-time data, the endpoint also offers a WebSocket interface (accountSubscribe, slotSubscribe, logsSubscribe) and, on production providers, a Yellowstone gRPC Geyser stream that pushes account and slot changes without polling.

For a Solana DeFi app, the endpoint is in the critical path of nearly everything a user does:

• Reading AMM pool reserves, oracle accounts, and vault state before quoting a swap
• Fetching every position account for a lending or perps program via getProgramAccounts
• Simulating a route with simulateTransaction to avoid burning fees on a failed swap
• Fetching a fresh blockhash with getLatestBlockhash before signing
• Broadcasting the swap, deposit, or liquidation with sendTransaction
• Streaming pool and position changes in real time over WebSocket or gRPC

You can review the full list of supported methods in the Solana JSON-RPC API documentation.

Endpoint quality on Solana is measured at the tail, not the average. A node that answers in 30 ms on a quiet afternoon but spikes to 800 ms during a liquidation cascade will cost you exactly when capital is at risk — stale reads produce mispriced quotes, and a late sendTransaction lands your swap after the price has already moved.

How Solana RPC differs from EVM chains

If you’re coming from Ethereum, the most useful thing you can do is unlearn the account model. Solana DeFi RPC is structurally different, and the differences directly shape how you pick an endpoint:

• No eth_getLogs, no event topics. Solana has no log-topic index. To find activity you either poll getProgramAccounts (which scans every account a program owns — the single heaviest call on the chain) or subscribe to a Geyser stream. DeFi indexers that would use eth_getLogs on Ethereum lean on Geyser gRPC here.
• Accounts, not contract storage slots. Pool state, user positions, and oracle prices each live in separate accounts. Reading a protocol’s full state often means getMultipleAccounts or a filtered getProgramAccounts, not a single contract call.
• Blockhash expiry instead of nonces. Each transaction embeds a recent blockhash that is valid for only ~150 slots (about 60 seconds). A laggy endpoint that returns a stale blockhash produces transactions the cluster rejects outright — a failure mode EVM developers never see.
• Landing is not guaranteed by submission. On Ethereum, a broadcast transaction sits in the mempool. On Solana there is no mempool — sendTransaction forwards to the current leader, and under load transactions are simply dropped. Landing rate, not “did it broadcast”, is the metric that matters.
• Compute units, not gas. Fees combine a base fee with optional priority fees per compute unit. DeFi transactions competing for the same pool must bid priority fees to land in contended slots.

The practical takeaway: choosing a Solana DeFi endpoint is less about RPC compatibility and more about throughput headroom, tail latency, real-time streaming, and how reliably the provider lands your transactions.

Solana DeFi RPC endpoint options

Public vs private Solana RPC endpoints

The public vs private decision on Solana DeFi comes down to a single question: can the endpoint survive a volatility spike? DeFi traffic is bursty by nature — a memecoin launch, an oracle update, or a liquidation cascade can 10x your request volume in seconds, and that is precisely when a shared endpoint throttles you.

Official public endpoints:

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

⚠️ The Solana Foundation public endpoints are hard-capped at 100 requests per 10 seconds per IP (and just 40 per 10 seconds for a single method like getProgramAccounts), with no SLA and IP bans applied without notice. The Solana clusters documentation states plainly that public endpoints “are not intended for production applications.” For any DeFi workload, they are a devnet convenience, not infrastructure.

Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
Rate limit	100 req / 10s per IP	No aggressive throttling
getProgramAccounts	Throttled to 40 / 10s	Full support
Geyser gRPC streaming	Not available	Available
Archive access	Not available	Available

The moment two users interact with your DeFi app at the same time during a market event, a shared 100-req/10s endpoint stops being a constraint and becomes the reason transactions silently fail — which is why a private endpoint is the baseline for production Solana DeFi, not an optimization.

📖 For a detailed comparison of Solana RPC providers for DeFi, see Best Solana RPC providers in 2026.

Full node vs archive Solana node

For Solana DeFi, the line between a full node and an archive node is the line between “what is the pool worth now” and “what was this position worth at the slot it got liquidated.” A full node serves recent state and is enough for live trading; an archive node retains the complete history needed for P&L reconstruction and audit trails.

Full node access	Archive node access
Live AMM pool reserves and oracle prices	Historical pool reserves at a past slot
Current user positions and vault balances	Position P&L reconstruction at liquidation time
Real-time swap routing and simulation	Backfilling a DeFi analytics index from genesis

Archive access on Solana matters most for analytics dashboards, liquidation post-mortems, and compliance reporting where you need to prove the on-chain state at a specific historical slot. Chainstack supports Solana archive nodes — billed at 2 request units per call and starting at $49/month — so you can pull historical state through the same interface as live data. See Chainstack archive data for details.

HTTPS vs WebSockets vs gRPC

For real-time DeFi, the transport you pick decides how stale your view of the market is. Polling over HTTPS means your pool state is only as fresh as your last request; persistent connections push changes as they happen. On Solana this is not a minor optimization — the gap between polling getProgramAccounts every few seconds and subscribing to a Geyser stream is the gap between reacting after a swap and reacting to it.

Feature	HTTPS	WebSocket	gRPC (Geyser)
Model	Request/response	Persistent subscription	Persistent structured stream
Complexity	Simple operationally	Reconnect/heartbeat logic	Reconnect + schema handling
Best for	Quotes, simulation, tx submission	Account/slot subscriptions	High-throughput DEX & position monitoring
Latency	Standard	Lower for frequent updates	Lowest, single-digit ms
Connection overhead	Per request	One-time handshake	One-time handshake

For most DeFi apps, HTTPS handles transaction submission and on-demand reads, WebSocket covers slot and account subscriptions, and Yellowstone gRPC Geyser is the production answer when you need to watch many pools or positions at once without hammering getProgramAccounts. WebSocket and gRPC streaming are available only on managed providers — the public endpoints do not offer them.

How to get a private Solana RPC endpoint with Chainstack

You can deploy a private Solana RPC node on Chainstack in a few minutes:

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

Once you have the endpoint, connecting takes a few lines. Using solana-py:

from solana.rpc.api import Client
from solders.pubkey import Pubkey

# Replace with your Chainstack HTTPS endpoint from node Access details
client = Client("YOUR_CHAINSTACK_ENDPOINT")

# Read an AMM pool or vault account by its on-chain address
pool = Pubkey.from_string("23dQfKhhsZ9RA5AAn12KGk21MB784PmTB3gfKRwdBNHr")
print(client.get_account_info(pool))

📖 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.

For latency-critical DeFi — sniping, arbitrage, and liquidations — Chainstack also offers Solana Trader Nodes, which route sendTransaction through the bloXroute Trader API for transaction propagation, reaching up to a 99% landing rate on high-priority transactions as of 2026. Switching is a one-URL change, which is the core promise of Chainstack’s DeFi infrastructure: no rate limits, no throttling, and landing-optimized submission without rewriting your app.

Chainlist is EVM-only, so it does not apply to Solana — there is no Chainlist entry to add a Solana endpoint to a wallet.

Chainstack pricing for Solana RPC

Chainstack bills on request units rather than per-method compute multipliers, so a getProgramAccounts call costs the same one unit as a getSlot call — which makes DeFi spend far easier to forecast than compute-unit models that penalize heavy reads. The full Chainstack pricing page lists every plan tier and overage rate.

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

DeFi-relevant add-ons:

• Archive Node — historical state at 2 request units per call (Chainstack archive data)
• Yellowstone gRPC Geyser — real-time streaming from $49/month for one stream
• Warp transactions — bloXroute-routed submission at $0.15 per transaction on paid plans
• Unlimited Node — flat-fee, RPS-tiered access for sustained high-throughput DeFi
• Dedicated Nodes — isolated compute from $0.50/hour per node plus storage

How to estimate monthly cost

1. Count your average requests per second across reads, simulations, and submissions
2. Multiply that RPS by ~2.6M (the number of seconds in a month) to get requests per month at steady state
3. Add the load from any polling loops and position-tracking jobs
4. Add a buffer for failover requests and retries
5. On Solana, a single bot polling getProgramAccounts every slot can burn through a Growth plan’s RPS ceiling during one volatile session — size for your peak, not your average, and move heavy monitoring to a Geyser stream instead of polling.

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
• Priority fee strategy in place so DeFi transactions land in contended slots
• Real-time data moved to WebSocket or Geyser gRPC instead of polling getProgramAccounts
• Blockhash freshness validated before signing to avoid expired-blockhash rejections

You can benchmark endpoint latency before committing with the Chainstack performance dashboard.

Troubleshooting common Solana DeFi RPC issues

Issue	Cause	How to fix
429 Too Many Requests	Exceeded shared endpoint rate limit during a volatility spike	Move to a private endpoint with dedicated RPS headroom
Transaction never lands	No mempool — sendTransaction dropped by the leader under load	Add priority fees and route through Trader Nodes / Warp for higher landing rates
Blockhash not found / expired	Stale getLatestBlockhash from a lagging node, or signing too slowly	Fetch a fresh blockhash immediately before signing; use a low-latency node
getProgramAccounts times out	Heaviest call on the chain, throttled or too slow on shared endpoints	Use a private node, narrow filters with dataSlice/memcmp, or switch to Geyser streaming
Stale pool reserves / mispriced quotes	Reading from a node lagging behind the cluster head	Check slot lag with getSlot; pin to a co-located, low-latency endpoint
WebSocket disconnects mid-stream	Dropped subscription without reconnect handling	Implement reconnect with heartbeat and backfill missed account changes on resume

Conclusion

The expensive failures in Solana DeFi are the silent ones. A throttled endpoint does not return a clear error during a liquidation cascade — it returns a 429 you retry into oblivion while the position you were going to close moves against you. A lagging node hands you pool reserves from two slots ago, and you quote a swap against liquidity that no longer exists. An expired blockhash gets your transaction rejected with no on-chain trace to debug. None of these look like infrastructure problems in your logs; they look like bad luck, until you realize they all cluster around the exact moments your app handles the most money.

The pattern that works is straightforward: never run production DeFi on a public endpoint, put a private node with real RPS headroom in the critical path, move all real-time monitoring off getProgramAccounts polling and onto a Geyser gRPC stream, and route latency-critical submissions through landing-optimized infrastructure with explicit priority fees. Configure a fallback provider before launch, not after your first outage.

Start on the free tier to validate your integration, then scale into Dedicated Nodes and Trader Nodes when your DeFi workload demands it.

FAQ

Which SDK should I use to connect to a Solana RPC endpoint? For Python, solana-py with the solders types is the standard. For JavaScript and TypeScript, use @solana/web3.js or the newer modular @solana/kit. Any of them accept your Chainstack HTTPS endpoint as the connection URL — no provider-specific client is required.

Why isn’t the public Solana RPC endpoint enough for a DeFi app? The Solana Foundation public endpoints cap at 100 requests per 10 seconds per IP — and only 40 per 10 seconds for a single method like getProgramAccounts. A DeFi app reading pool state, simulating routes, and submitting transactions for even a handful of concurrent users blows past that instantly during a market event, and the public endpoints carry no SLA and can IP-ban without notice.

How do I stop my DeFi transactions from silently failing to land? Solana has no mempool, so submission does not guarantee inclusion. Attach priority fees so your transaction competes for contended slots, fetch a fresh blockhash immediately before signing so it doesn’t expire, and route latency-critical submissions through Trader Nodes with Warp, which propagate via bloXroute for landing rates up to 99%.

Should I poll getProgramAccounts to track pools and positions? For production DeFi, no. getProgramAccounts is the heaviest call on Solana and is throttled or disabled on shared endpoints; polling it every slot is slow and expensive at scale. Use a Yellowstone gRPC Geyser stream to receive account and slot changes in real time instead.

Do I need an archive node for Solana DeFi? Only if you need historical state — reconstructing a position’s P&L at the slot it was liquidated, charting historical pool reserves, or producing compliance reports. Live trading and routing run fine on a full node; archive access (2 request units per call) is for analytics and audit workloads.

What latency should I target for a Solana DeFi endpoint? Watch p99, not average. Arbitrage, liquidation, and routing engines operate in sub-50 ms territory, and a node that averages 30 ms but spikes to several hundred milliseconds under load will cause slippage and missed fills exactly when volume peaks. Co-locate your endpoint with the validator region you target and monitor tail latency continuously.

Additional resources

• Real-time Solana DEX monitoring with Yellowstone gRPC Geyser — Chainstack tutorial
• Chainstack Solana tooling documentation
• Solana JSON-RPC API reference — official Solana documentation
• Solana Trader Nodes with Warp transactions
• More Solana tutorials and articles on the Chainstack Blog