Solana RPC explained: make a request and understand the result

The interface your wallet and application use

Opening a wallet does not download the entire Solana ledger. The application usually asks a remote service for information. RPC, short for remote procedure call, defines methods such as reading an account, finding a transaction and submitting signed transaction bytes.

A node maintains a view of network state. An RPC service exposes supported operations over that state and any additional retained or indexed data. Different providers can have different limits, history and extra APIs while supporting common Solana methods.

For a wallet balance screen, the application asks for account data, interprets its units and displays the result. For a transfer, the wallet constructs a message, obtains your signature, sends the transaction and follows its outcome. Reading and submitting are separate operations.

Standard RPC does not need your recovery phrase. A signing or hosted-wallet product is a separate service with its own custody model. Identify which capability an integration actually requests.

Choose the network before looking for an account

The endpoint selects a cluster. Mainnet carries production assets. Devnet supports application development with test assets. Testnet serves network testing, and a local validator creates an independent environment on your machine.

An identical public address can have different balances across clusters or exist on only one. A mainnet transaction cannot be found by querying devnet. Check the endpoint and explorer cluster before diagnosing a missing transfer.

Use an explicit cluster in configuration, logs and test commands. Keep production and development credentials separate. A faucet supplies test SOL on its supported development network; it does not issue spendable mainnet SOL.

Shared public endpoints are useful for learning. Their existence does not imply unlimited production capacity or complete historical coverage.

Execute a read-only request

This command asks devnet for a recent blockhash and its validity boundary. It needs curl and an internet connection, with no wallet or signing key. The same request was executed during the 7 November 2026 editorial check; the returned values change.

curl https://api.devnet.solana.com \
+  -H 'Content-Type: application/json' \
+  --data '{"jsonrpc":"2.0","id":1,"method":"getLatestBlockhash","params":[{"commitment":"finalized"}]}'

The envelope names the JSON-RPC version. The method selects the operation. The params array supplies method-specific arguments. The id correlates request and response; it is not a signature or block identifier.

Read result.context alongside result.value. The value includes blockhash and lastValidBlockHeight. A transaction using that blockhash needs the matching validity boundary; an assumed number of seconds is a weaker substitute.

This call has only obtained construction inputs. No instruction was built, no signature created and no transaction submitted.

Accepted delivery and accepted execution

Decide which state your application needs

A recent processed observation can arrive before the state has its finality guarantee. Select commitment for the action you are taking: a tentative animation and releasing purchased goods can require different certainty.

On migrated mainnet, the Foundation's dated Alpenglow documentation says confirmed and finalized describe the same state after Votor activation. It recommends finalized for new code. That supersedes introductions which still draw three unchanged sequential confirmation stages.

Keep related calls coherent. A blockhash from a more advanced view may be unknown to a lagging endpoint. Where supported, minContextSlot constrains the minimum evaluation context. It does not request the account's value at an arbitrary historical slot.

Several separate reads can observe different states. Saving their context and timestamps makes that visible. A portfolio scan should not claim a perfectly simultaneous snapshot merely because all requests began together.

Interpret four different response outcomes

First handle transport and HTTP failures: a disconnected socket, timeout or HTTP 429 has not produced a normal successful method result. Then parse the JSON-RPC envelope. An HTTP 200 can still carry an error object.

A valid null result is different again. getTransaction can return null when that endpoint cannot find the transaction at the required commitment. A status query can miss an older transaction outside its default recent cache. Neither observation alone proves that a payment failed.

A returned value still needs interpretation. For a transaction, inspect the execution error. For an account, inspect its owner and data model. For a balance, preserve its unit. A correctly received response can be used incorrectly.

Log the method, non-secret parameters, cluster, fetch time, context and outcome category. This record separates a bad request from unavailable data and from an actual execution failure.

Submission begins an outcome-tracking workflow

sendTransaction accepts signed bytes and can return their first signature. Its contract does not promise that the transaction has executed. Preflight can detect problems against the selected state, but later state can differ.

Save the signature and validity information before delivery. Query status, distinguish execution failure from success, then apply your required finality. For an important operation, verify the actual receiving account or application state.

A lost HTTP response creates uncertainty about delivery. It does not establish rejection. Retrying the same signed bytes and creating a newly signed payment are different actions. The retry guide explains the distinction.

Choose production infrastructure around the needed methods, history and throughput. A payment backend, archival explorer and live balance widget have different requirements. Test those requirements rather than selecting an endpoint by one quick request.

Common questions