Skip to main content
If you’re coming from an EVM chain, Solana’s JSON-RPC looks familiar on the surface (same {"jsonrpc":"2.0","method":...,"params":[...]} envelope) but uses different primitives. This page covers the concepts that show up across almost every Solana method.

​
Slots vs blocks

A slot is a ~400ms window in which a designated leader may produce a block. Not every slot produces a block (leaders can skip), so block height ≤ slot height. When EVM code reaches for eth_blockNumber, the Solana equivalent is usually getSlot; use getBlockHeight only when you specifically need produced-block count.

​
Commitment levels

Most read methods accept a commitment field that controls how finalized the data must be:
CommitmentMeaningUse when
processedThe node has processed the slot; may be skipped or rolled back.Lowest latency, optimistic UIs.
confirmedA supermajority of the cluster has voted on the block.The sensible default for most apps.
finalizedThe block has 31+ confirmed blocks on top; effectively irreversible.Accounting, settlement, anything that must not roll back.
{ "commitment": "confirmed" }

​
Lamports

SOL balances are denominated in lamports: 1 SOL = 1,000,000,000 lamports (10⁹). getBalance returns lamports; divide by 1e9 to display SOL. This is the analogue of wei on EVM chains, but with 9 decimals instead of 18.

​
Accounts, programs, and PDAs

Everything on Solana is an account: wallets, token balances, and program (smart contract) state all live in accounts identified by a base-58 pubkey. Accounts are owned by a program; getProgramAccounts enumerates every account a program owns. SPL token balances live in dedicated token accounts; list a wallet’s holdings with getTokenAccountsByOwner.

​
Encodings

Account and transaction data can be returned in several encodings, selected via the encoding config field:
EncodingReturns
base58Raw bytes, base-58 (small data only).
base64Raw bytes, base-64.
base64+zstdRaw bytes, zstd-compressed then base-64 (large accounts).
jsonParsedProgram-decoded, human-readable JSON where a parser exists (e.g. SPL token accounts). Falls back to base64.
Prefer jsonParsed for readability; use base64/base64+zstd when you’ll decode the bytes yourself. The dataSlice: { offset, length } option limits how many bytes are returned for large accounts.

​
Versioned transactions

Solana supports versioned transactions (with Address Lookup Tables). Methods that return transactions (getTransaction, getBlock, blockSubscribe) require you to opt in by setting maxSupportedTransactionVersion: 0, otherwise a versioned transaction returns an error. Always set it unless you specifically want legacy-only transactions.

​
Sending a transaction

The typical send flow:
  1. getLatestBlockhash: fetch a recent blockhash and its lastValidBlockHeight.
  2. Build, sign, and (optionally) simulateTransaction to preview the result.
  3. sendTransaction: broadcast; returns the signature immediately.
  4. getSignatureStatuses (poll) or signatureSubscribe (push): confirm.
Under congestion, add a priority fee informed by getRecentPrioritizationFees, and re-send with a fresh blockhash once lastValidBlockHeight is exceeded.

​
WebSocket subscriptions

Real-time updates use a separate WebSocket endpoint: 
wss://rpc.goldrushdata.com/v1/solana-mainnet
Subscriptions return a numeric id; cancel with the matching *Unsubscribe method (or, with @solana/kit, by aborting the subscription’s AbortController). See accountSubscribe, logsSubscribe, and programSubscribe.

Solana method reference

Every Solana method, grouped by category.

Quickstart

Your first Solana call in under a minute.