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

TL;DR

An autonomous agent on Solana can submit a transaction, log “success,” and have nothing happen on-chain — because Solana has no public mempool and the blockhash your transaction references expires in roughly 60–90 seconds, so a congested public endpoint just drops it without an error. For a human that’s an annoyance; for an unattended agent acting in a loop, it’s a silent corruption of state it believes it changed. This guide explains why a Solana RPC endpoint for AI agents has to prioritize reliable transaction landing and push-based data streaming, and how to get one.

What is a Solana RPC endpoint

A Solana RPC endpoint is the network entry point your agent calls to read chain state, simulate and broadcast transactions, and subscribe to live updates. Solana speaks JSON-RPC over HTTP for request/response calls, exposes a parallel WebSocket interface for subscriptions, and — uniquely among major chains — offers a validator-side streaming layer (the Geyser plugin, surfaced over the network as Yellowstone gRPC) that pushes state changes the instant a validator processes them. An AI agent that only knows how to poll a JSON-RPC endpoint is using maybe a third of the surface Solana actually gives it.

For an agent operating on Solana, the endpoint is what the following actions depend on:

• Reading account state and token balances (getAccountInfo, getBalance, getTokenAccountsByOwner)
• Scanning program-owned accounts to discover positions or markets (getProgramAccounts)
• Simulating a transaction before committing capital (simulateTransaction)
• Fetching a fresh blockhash and broadcasting signed transactions (getLatestBlockhash, sendTransaction)
• Tracking confirmation and slot progression (getSignatureStatuses, slotSubscribe)
• Subscribing to logs, accounts, and programs for real-time triggers (logsSubscribe, accountSubscribe, programSubscribe)

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

For an agent, endpoint quality is not a latency nicety — it is the difference between an action that lands and an action that evaporates. On Solana there is no failed-but-visible state for a dropped transaction: the agent sees no revert, no error, just silence, and its internal model drifts out of sync with the chain. That single failure mode shapes every infrastructure decision below.

How Solana RPC differs from EVM chains

Solana is not EVM-compatible, and an agent ported from an Ethereum mindset will make wrong assumptions on day one. There is no eth_call, no eth_getLogs, no nonce-per-account, and no mempool to inspect. State lives in a flat space of accounts owned by programs rather than in contract storage slots, so “read this contract’s state” becomes “fetch these accounts and deserialize them against the program’s layout.” Transactions don’t carry an incrementing nonce; they carry a recent blockhash, and that blockhash is also their expiry clock — once it ages out past ~150 slots, the transaction is permanently invalid and must be rebuilt and re-signed.

The deeper difference for agents is how you get told something happened. On EVM chains, eth_getLogs lets you backfill historical events with one call and most real-time work is polling-shaped. On Solana, getProgramAccounts over a busy program is expensive and rate-limit-hungry, and there is no equivalent of a cheap historical log scan for arbitrary events. Real-time work is meant to be push-shaped: you subscribe over WebSocket, or — for production agents — you consume a Yellowstone gRPC stream that the validator feeds directly. EVM developers need to unlearn the polling loop and learn to let the chain push to them.

Finality semantics differ too. Instead of block confirmations, Solana exposes commitment levels — processed, confirmed, and finalized — and an agent has to choose deliberately: processed is fast but can be rolled back, finalized is safe but seconds behind. Picking the wrong commitment level is a common source of agents acting on state that later disappears.

Solana RPC endpoint options

Public vs private Solana RPC endpoints

For an autonomous agent, the public-vs-private decision is really a question of whether you can tolerate silent failure. A human refreshes and retries; an agent commits to the next step on the assumption the last one worked. The public cluster gives you neither the throughput to stream state nor the landing reliability to trust your own writes.

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 endpoint is rate-limited to roughly 40 requests per 10 seconds per IP, caps concurrent connections, carries no SLA, and the Solana docs themselves recommend using professional RPC providers for anything beyond light development. An agent that polls account state on a loop or fans out getProgramAccounts calls will hit 429 almost immediately — and sendTransaction on the public endpoint offers no priority or retry handling, which is exactly where dropped transactions come from. See the official Solana clusters and public endpoints reference for the current limits.

Property	Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
Rate limit	~40 req / 10s per IP	No aggressive throttling
Yellowstone gRPC / Geyser	Not available	Available
Transaction landing	Best-effort, no priority handling	Optimized routing + retries

For an agent, the justification for managed infrastructure isn’t “production needs reliability” in the abstract — it’s that a dropped sendTransaction produces no signal the agent can react to, and a throttled programSubscribe means the agent is acting on a stale view of the world. Both failure modes are invisible until the position is wrong.

📖 For a detailed comparison of Solana RPC providers, see Top 7 Solana RPC providers for enterprise and fintech in 2026.

Full node vs archive Solana node

For an agent, the line between a full node and an archive node is the line between “what is true right now” and “what was true at slot N.” A full node holds recent state and is what most live agents query; an archive node retains historical account states and transactions beyond the rolling window a full node keeps.

Full node access	Archive node access
Current account state and live balances	Historical account state at a past slot
Real-time slot and log subscriptions	Replaying an agent’s past instruction sequence for audit
Simulating and landing new transactions	Backfilling training data for an agent’s strategy model
Recent transaction status checks	Reconstructing P&L or fills across older epochs

Agents that learn from or report on their own behavior need archive access: reconstructing why a strategy entered a position three weeks ago, auditing an agent’s full action log for compliance, or backfilling a dataset to retrain a decision model all require state a full node has already pruned. Chainstack supports Solana archive data, billed at 2 request units per call versus 1 for a full node — worth scoping deliberately if your agent does heavy historical reads.

HTTPS vs WebSockets

For an agentic workload the transport question is really “how does my agent find out the world changed?” — and on Solana, polling over HTTPS is the expensive, late answer. An agent that polls getProgramAccounts every few seconds to watch a market burns request units, arrives after the event, and still risks throttling. Persistent subscriptions exist precisely so the agent doesn’t have to ask.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Reads, simulation, broadcasting transactions	Triggering on new mints, fills, account changes
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

WebSocket subscriptions (logsSubscribe, accountSubscribe, programSubscribe, slotSubscribe) are the baseline for reactive agents, but they have limits at scale: reconnect gaps can drop events, and busy programs can overwhelm a single socket. For production agents — sniping bots, MEV strategies, real-time analytics — Yellowstone gRPC is the upgrade: it streams account, transaction, slot, and block updates directly from the validator as binary protobuf with server-side filtering, eliminating the polling loop and the per-event rate-limit pressure entirely. Public endpoints do not offer gRPC streaming at all.

How to get a private Solana RPC endpoint with Chainstack

You can stand up a Solana RPC node on Chainstack in about a minute:

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, the modern way to connect is @solana/kit (the successor to web3.js v1, now in maintenance mode):

import { address, createSolanaRpc, lamports } from "@solana/kit";

// Point the RPC client at your Chainstack HTTPS endpoint
const rpc = createSolanaRpc("YOUR_CHAINSTACK_ENDPOINT");

// One meaningful read: fetch an account balance
const balance = await rpc
  .getBalance(address("23dQfKhhsZ9RA5AAn12KGk21MB784PmTB3gfKRwdBNHr"))
  .send();

console.log(balance.value); // lamports as bigint

📖 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 — which lets an agent deploy nodes, check status, and query live chain data through natural language rather than hand-wired API calls. Learn more about Chainstack MCP. For the bigger picture on how this fits together, see how AI agents talk to blockchains with MCP and RPC.

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

Chainstack pricing for Solana RPC

Chainstack bills on request units rather than per-method compute multipliers, which makes an agent’s cost predictable from its call count: every standard call is 1 RU, archive calls are 2 RU, with no surprise weighting on heavier methods. See the full Chainstack pricing page for plan details and overage rates.

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

Options that matter most for agentic Solana workloads:

• Yellowstone gRPC streaming — from $49/mo for one stream, scaling to 25 streams, for push-based real-time data instead of polling
• Warp Transactions — pay-per-use transaction submission ($0.15 per transaction) tuned for landing rate, directly addressing the dropped-transaction failure mode
• Dedicated Nodes — single-tenant nodes from $0.50/hour plus storage, for agents that need isolated, predictable performance
• Solana archive data — for agents that backfill or audit historical state

How to estimate monthly cost

1. Count the read calls your agent makes per minute (balance checks, account fetches, simulations) and multiply out to a monthly baseline.
2. Add subscription load — but route real-time triggers through gRPC streams rather than polling, which moves that load off your RU count entirely.
3. Estimate transaction volume and decide whether Warp Transactions’ per-tx landing reliability is worth it for your strategy.
4. Add archive reads (at 2 RU each) if the agent audits or retrains on history.
5. Buffer hard for bursts: a single agent reacting to a market event can fan out dozens of getProgramAccounts and simulation calls in a second, so an unattended fleet can exhaust a Growth plan’s RPS ceiling far faster than its monthly RU pool suggests — size for peak concurrency, not average throughput.

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
• Blockhash freshness checked before signing, with automatic rebuild-and-resubmit when a transaction isn’t confirmed before expiry
• Commitment level chosen deliberately per action (confirmed for reactive logic, finalized before treating a write as irreversible)
• Real-time triggers routed through Yellowstone gRPC or WebSocket subscriptions with gap-backfill, not polling loops that invite self-throttling

Benchmark candidate endpoints before you commit a fleet to one — the Chainstack performance dashboard shows public latency you can compare against.

Troubleshooting common Solana RPC issues

Issue	Cause	How to fix
429 Too Many Requests	Agent exceeding public/shared rate limits	Move to a managed endpoint; route real-time data through gRPC streams to cut request volume
Transaction silently dropped	Blockhash expired (>150 slots) or no priority during congestion	Refresh blockhash before signing, add priority fees, resubmit on non-confirmation, or use Warp Transactions for landing
WebSocket disconnects, missed events	Subscription dropped without backfill	Add reconnect + heartbeat logic and backfill missed slots on reconnect
getProgramAccounts times out or throttles	Scanning a large program over a shared endpoint	Add filters/dataSlice, move to a dedicated node, or switch to a gRPC stream
Agent acts on state that later disappears	Reading at processed commitment	Use confirmed for reactive logic and finalized before treating a write as final
Account data deserializes incorrectly	Wrong program layout / stale IDL	Pin the program’s IDL version and validate the account discriminator before decoding

Conclusion

The failure that ends agentic Solana projects isn’t a loud one. It’s an agent that submitted a swap, recorded it as filled, moved its internal balance, and acted on the next step — while on-chain the transaction expired in a congested moment and never landed. There’s no exception to catch, no revert to log; the agent’s model of reality simply diverged from the chain, and every decision after that compounds the error. On a network with no public mempool and a 60–90 second blockhash clock, this is the default outcome of running an autonomous agent against a shared endpoint.

The pattern that works is two-sided. For reads, stop polling and let the chain push to you — Yellowstone gRPC streams give an agent real-time state without burning request units or arriving late. For writes, treat landing as a first-class problem: fresh blockhash, priority fees, resubmission on non-confirmation, and a commitment level chosen on purpose for each action. The non-negotiable production requirement is a private endpoint with dedicated throughput and streaming — a public RPC URL cannot give an unattended agent either guarantee.

Spin up a free Solana node on the Developer plan to prototype, and move to dedicated infrastructure with gRPC streaming once your agent handles real value.

FAQ

Which Solana SDK should an AI agent use in 2026? Use @solana/kit for new TypeScript agents — it’s the actively developed successor to @solana/web3.js v1, which is now in maintenance mode. For Python agents, solana-py with the solders core is standard, and on-chain program work uses Anchor. The endpoint itself is SDK-agnostic, so your choice is about ergonomics, not compatibility.

Why does my agent’s transaction succeed in logs but never appear on-chain? Because Solana has no public mempool and your transaction references a blockhash that expires after roughly 150 slots. If a shared endpoint can’t push it through during congestion before that window closes, it’s dropped with no error returned. An agent has to verify confirmation by signature status and rebuild-and-resubmit on expiry rather than trusting a successful sendTransaction response.

Can an AI agent run on Solana’s public RPC endpoint? Only for prototyping. At ~40 requests per 10 seconds per IP with no streaming and best-effort transaction handling, the public endpoint throttles a polling agent almost immediately and gives it no landing guarantees — both failures are silent, which is the worst case for an unattended process. Move to a private endpoint before the agent touches real value.

How should an agent get real-time data on Solana without hitting rate limits? Don’t poll. Subscribe over WebSocket for lighter workloads, and use Yellowstone gRPC for production agents — it streams account, transaction, and slot updates directly from the validator with server-side filtering, so the agent reacts the moment a validator processes an event and never spends request units asking “did anything change?”

Which commitment level should an autonomous agent use? It depends on the action. Use confirmed for reactive logic where you need speed and can tolerate a rare rollback, and finalized before treating any write as irreversible — for example, before an agent reports a position as settled or releases downstream capital. Defaulting everything to processed is a common cause of agents acting on state that later disappears.

Do I need an archive node for an AI agent on Solana? Only if the agent reads history. Live trading or monitoring agents run fine on a full node, but agents that audit their own past actions, reconstruct historical P&L, or backfill datasets to retrain a strategy need archive access, since a full node prunes older state.

Additional resources

• Solana: Creating a trading and sniping pump.fun bot — a hands-on agent build on Chainstack Docs
• Solana: Geyser and Yellowstone gRPC in Node.js — push-based streaming for reactive agents
• Chainstack Solana tooling documentation
• Blockchain RPC for AI agents: infrastructure guide
• Solana RPC API documentation — official method reference
• More Solana tutorials and articles on the Chainstack Blog