Solana RPC Guide: How to Connect and Build on Solana (2026)

Solana is one of the fastest blockchains in production: 400ms block times, sub-cent transaction fees, a throughput capacity that regularly exceeds 50,000 transactions per second. That speed is what draws developers to build on Solana. It is also what makes reliable RPC access critical.

Every interaction with Solana, whether reading an account balance, submitting a transaction, or subscribing to real-time program events, goes through an RPC endpoint. The quality of that endpoint directly affects how your application behaves. A slow or rate-limited endpoint is not just inconvenient on Solana. At 400ms block times, it is the difference between your transaction landing and missing its window entirely.

This guide covers everything you need to connect to Solana via RPC and build applications on it, including a section for developers coming from EVM chains who need to understand what is fundamentally different about Solana’s architecture.

What is a Solana RPC Endpoint

A Solana RPC endpoint is an HTTP or WebSocket URL that exposes Solana’s JSON-RPC API. You send a JSON request specifying a method and parameters, and the node returns the result. The pattern is the same as on EVM chains, but the methods, data structures, underlying blockchain model are completely different.

Solana’s JSON-RPC API uses methods like getAccountInfo, sendTransaction, getSlot rather than the eth_ prefixed methods you would see on Ethereum. There is no eth_call, no eth_getLogs, no eth_getBalance. If you try to use those methods on a Solana endpoint, they will return errors.

HTTP vs WebSocket on Solana

Solana supports both HTTP and WebSocket endpoints:

HTTP: Request-response. Best for one-off queries: fetching balances, reading account data, submitting transactions.
WebSocket: Persistent connection with push-based subscriptions. Essential on Solana because polling at 400ms block speed is expensive and often rate-limited. WebSocket subscriptions let you react to account changes, slot updates, signature confirmations in real time without polling.

For any application that needs to respond to on-chain events, WebSocket is the preferred approach on Solana.

Core Solana RPC Methods

Account Methods

getAccountInfo: returns the data stored in a Solana account. This is the fundamental read operation on Solana. Everything on the chain (including token balances, program state, NFT metadata) lives in accounts.

getBalance: returns the SOL balance of an account in lamports (1 SOL = 1,000,000,000 lamports).

getProgramAccounts: returns all accounts owned by a specific program. Used extensively by DeFi protocols and indexers to read program state. This is a resource-heavy method and should be called with filters wherever possible.

getMultipleAccounts: fetches multiple accounts in a single request. Prefer this over batching individual getAccountInfo calls.

Transaction Methods

sendTransaction: submits a signed transaction to the network.

getTransaction: retrieves a confirmed transaction by signature, including all instructions and inner instructions.

getSignaturesForAddress: returns recent transaction signatures for an address. Useful for building transaction history views.

simulateTransaction: simulates a transaction without submitting it. The Solana equivalent of eth_call for state-changing operations.

Slot and Block Methods

getSlot: returns the current slot number. Solana progresses by slot, not block. Not every slot produces a block.

getLatestBlockhash: critical method. Every Solana transaction must include a recent blockhash to prevent replay attacks. Blockhashes expire after roughly 150 blocks (~60 seconds). Call this immediately before building a transaction.

getBlockHeight: returns the current block height (blocks with actual content, not all slots).

WebSocket Subscriptions

accountSubscribe: fires whenever a specific account changes. Essential for wallets, trading bots, any application watching on-chain state.

logsSubscribe: streams transaction logs matching a filter. The closest equivalent to eth_subscribe logs on EVM chains.

slotSubscribe: fires on every slot update. The highest-frequency subscription; use it only if you genuinely need per-slot updates.

signatureSubscribe: notifies you when a specific transaction signature is confirmed. Use this after submitting a transaction instead of polling getSignatureStatuses.

Connecting to Solana RPC: Step by Step

Install the Library

npm install @solana/web3.js

Endpoint Access

Endpoint available on request. This endpoint is not part of the standard self-serve trial. Contact us and we’ll get you set up with access, pricing, and any relevant details for your use case. boltrpc.io/contact

Once you have access, replace YOUR_SOLANA_ENDPOINT in the examples below with the URL provided.

HTTP Connection with @solana/web3.js

import { Connection, PublicKey, LAMPORTS_PER_SOL } from "@solana/web3.js";

const connection = new Connection(
  "YOUR_SOLANA_ENDPOINT",
  "confirmed"
);

// Get current slot
const slot = await connection.getSlot();
console.log("Current slot:", slot);

// Get SOL balance
const address = new PublicKey("YourSolanaAddressHere");
const balanceLamports = await connection.getBalance(address);
const balanceSOL = balanceLamports / LAMPORTS_PER_SOL;
console.log("Balance:", balanceSOL, "SOL");

// Get account info
const accountInfo = await connection.getAccountInfo(address);
console.log("Account data length:", accountInfo?.data.length);
console.log("Owner program:", accountInfo?.owner.toBase58());

The second argument to new Connection() is the default commitment level. "confirmed" is a safe default for most applications. See the commitment section below for details.

Direct JSON-RPC with curl

# getSlot
curl YOUR_SOLANA_ENDPOINT \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"getSlot"}'

# getBalance
curl YOUR_SOLANA_ENDPOINT \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBalance",
    "params": ["YourSolanaAddressHere"]
  }'

WebSocket Subscription with @solana/web3.js

import { Connection, PublicKey } from "@solana/web3.js";

const connection = new Connection(
  "YOUR_SOLANA_ENDPOINT",
  "confirmed"
);

// Watch an account for changes
const pubkey = new PublicKey("YourSolanaAddressHere");

const subscriptionId = connection.onAccountChange(
  pubkey,
  (accountInfo, context) => {
    console.log("Account changed at slot:", context.slot);
    console.log("New lamports:", accountInfo.lamports);
  },
  "confirmed"
);

// Subscribe to program logs
const programId = new PublicKey("YourProgramIdHere");

connection.onLogs(
  programId,
  (logs, context) => {
    if (logs.err) {
      console.error("Transaction failed:", logs.err);
      return;
    }
    console.log("Logs at slot", context.slot, ":", logs.logs);
  },
  "confirmed"
);

Note: The @solana/web3.js Connection class handles WebSocket internally when you use subscription methods. You pass the HTTP URL, and the library opens a WebSocket connection automatically for subscription calls.

Solana RPC vs EVM RPC: Key Differences

If you are coming from Ethereum development, Solana will require a mental model shift. The differences are not superficial.

Account Model vs Contract Storage

On Ethereum, smart contracts store their own state in contract storage slots. You read that state by calling the contract with eth_call. On Solana, all state lives in accounts. Programs (Solana’s term for smart contracts) are stateless. They process instructions but do not store data themselves. Data is stored in separate accounts that are owned by the program.

The practical consequence: reading Solana program state means reading accounts, not calling a contract. You use getAccountInfo and getProgramAccounts where you would use eth_call on Ethereum.

No `eth_` Methods

Solana’s JSON-RPC API has no eth_ prefix. There is no eth_getBalance, eth_call, eth_getLogs, or eth_sendRawTransaction. Every Solana method has a distinct name: getBalance, simulateTransaction, sendTransaction. If you try to use EVM methods on a Solana endpoint, you will get method-not-found errors.

No ethers.js or viem

Do not use ethers.js, viem, or web3.js on Solana. These libraries are built for EVM chains and do not understand Solana’s API or data structures. Use @solana/web3.js for JavaScript and TypeScript.

Commitment Levels

Solana has three commitment levels that control how confirmed a piece of data must be before it is returned:

Level	Description	Use Case
`processed`	Latest slot seen by this validator, may be rolled back	Latency-critical reads only
`confirmed`	Confirmed by supermajority, extremely unlikely to roll back	Most application reads
`finalized`	Permanently part of the canonical chain	High-value transactions, balances

EVM chains have simpler finality semantics. Ethereum has latest, safe, finalized block tags, but they map less granularly to consensus state. On Solana, commitment level selection is a real design decision you make for every query.

Rule of thumb: use confirmed as your default. Use finalized when accepting payments or making irreversible decisions. Avoid processed unless you understand the rollback risk and genuinely need the lower latency.

Transaction Structure Differences

Solana transactions are assembled differently from Ethereum transactions. They contain one or more instructions (not just one function call), must reference a recent blockhash, specify all accounts they will interact with upfront. Transactions expire if they are not included within roughly 60 seconds of the blockhash being fetched.

Common Solana RPC Challenges

Public Endpoints Are Rate-Limited

The official public Solana RPC (api.mainnet-beta.solana.com) enforces strict rate limits and is heavily congested during high-traffic periods. During NFT launches, token generation events, or volatile market conditions, public endpoints drop connections and return errors. Applications built on public endpoints fail exactly when they need to work most.

Blockhash Expiry

Every Solana transaction needs a recent blockhash. Blockhashes expire after approximately 150 slots (~60 seconds). If your transaction is built but not submitted within that window, it will be rejected with a blockhash not found error. Call getLatestBlockhash as close to transaction submission as possible, and never cache blockhashes for reuse.

Slot Skips and Forks

Not every slot produces a block. When a validator misses its slot, the slot is skipped. If you are iterating over slots to find blocks, you must handle gaps. getBlock will return null for skipped slots. Use getBlocks to fetch a list of confirmed block slots in a range, then fetch each block individually.

`getProgramAccounts` at Scale

getProgramAccounts can return thousands of accounts for popular programs. Without filters, it will return all of them. Always use the filters parameter (memcmp or dataSize) to narrow results. Without filters, this method is expensive and may time out or be rejected by some providers under load.

// Filtered getProgramAccounts: much more efficient
const accounts = await connection.getProgramAccounts(programId, {
  filters: [
    { dataSize: 165 },  // Filter by account data size
    {
      memcmp: {
        offset: 32,     // Byte offset to compare
        bytes: ownerAddress.toBase58(),  // Base58 value to match
      },
    },
  ],
});

WebSocket Connection Stability

At Solana’s throughput, WebSocket connections can receive large volumes of messages. Use the @solana/web3.js subscription helpers rather than managing raw WebSocket frames. Implement reconnection logic for production applications.

SaaS vs Dedicated vs Self-Hosted Solana RPC

There are three ways to access Solana RPC, each with different trade-offs:

SaaS (managed provider): You connect to a provider’s endpoint. Fastest to start, no infrastructure management. Best for most teams. BoltRPC (beta) falls here.
Dedicated node: A full Solana RPC node provisioned exclusively for you. Higher cost, but isolated resources and no shared rate limits. Right for high-throughput production apps.
Self-hosted: You run your own Solana RPC node. Maximum control, maximum operational burden. Requires significant hardware (1TB+ NVMe, 512GB+ RAM for a full node). Only makes sense for teams with dedicated infrastructure engineers.

For most developers: start with a managed provider, move to dedicated when you hit throughput limits.

Choosing a Solana RPC Provider

For development and testing, the public Solana RPC endpoint works. For anything that needs to be reliable, you need a dedicated provider.

Key criteria:

Stability under load. Solana regularly spikes. Your provider needs to handle that without dropping connections.
WebSocket support. Essential for any event-driven application. Not all providers offer WebSocket on Solana.
Commitment level support. Ensure the provider supports all three commitment levels: processed, confirmed, finalized.
Infrastructure for high-throughput workloads. Solana applications often make far more RPC calls than equivalent EVM applications. Wallet UIs check dozens of token accounts. Trading bots poll multiple accounts continuously.

BoltRPC offers Solana RPC access currently in beta. The endpoint supports HTTP and WebSocket, all commitment levels, the full Solana JSON-RPC method set. It is built on the same dedicated infrastructure used for BoltRPC’s 20+ EVM chain endpoints, backed by Matrixed.Link’s ISO/IEC 27001:2022 certified operations. For production Solana deployments during the beta period, contact us directly so we can advise on current capabilities.

Trusted by clients including Chainlink, Tiingo, Gains Network, Enjin.

Solana RPC Infrastructure in 2026

Solana’s network has evolved significantly. Two key upgrades worth knowing:

Firedancer: A new validator client built by Jump Crypto. It is designed to dramatically increase Solana’s throughput capacity. As Firedancer nodes come online, the network becomes more resilient and higher capacity. For RPC users, this means more stable, higher-throughput access over time.
Alpenglow: Solana’s upcoming consensus protocol redesign aimed at reducing confirmation times further. Still in development as of 2026.

Why this matters for RPC: as the network upgrades, RPC providers that keep pace with validator client diversity and infrastructure investment will offer more stable access than those running legacy setups.

FAQ

What is the Solana mainnet RPC URL?

The BoltRPC Solana endpoint is available on request. It is not part of the standard self-serve trial. Contact us at boltrpc.io/contact and we’ll get you set up with access, pricing, and any relevant details for your use case.

How is Solana RPC different from Ethereum RPC?

Solana uses a completely different JSON-RPC API. There are no eth_ prefixed methods. Solana’s methods are named differently (getAccountInfo, sendTransaction, getSlot), the data model is account-based rather than contract storage-based, and transactions are structured differently. You cannot use ethers.js, viem, or web3.js with Solana. Use @solana/web3.js instead.

What commitment level should I use for Solana RPC calls?

Use confirmed as your default. It balances speed and safety for most queries. Use finalized when accepting payments or making high-value decisions where a rollback would be harmful. Avoid processed unless you have a specific latency requirement and understand that data at that commitment level can be rolled back.

Can I use WebSocket with Solana RPC?

Yes. BoltRPC’s Solana endpoint supports WebSocket subscriptions. Use accountSubscribe to watch account changes, logsSubscribe to stream transaction logs, slotSubscribe for slot updates, signatureSubscribe to track transaction confirmation. With @solana/web3.js, subscription methods work via the standard Connection object using the HTTP endpoint URL.

Get Access to the BoltRPC Solana Endpoint

The Solana endpoint is available on request. It is not part of the standard self-serve trial.

boltrpc.io/contact

See all supported networks: boltrpc.io/networks