What is Solana RPC URL and Chain ID?

To interact with the Solana blockchain, you first need to know where and how to connect to it.
Any interaction with the chain, sending a transaction or reading its data, all start with making HTTP requests to an RPC node.

That means knowing the address of the node (RPC URL) and understanding how to talk to it. Because Solana runs multiple networks, it’s also important to correctly identify the network to use.

In this guide, we’ll break down what the Solana RPC URL is, how to find or set one up for your needs, and what Solana uses as its “chain ID” – plus simple code examples to help you get started.

What is Solana RPC URL and how it works

A Solana RPC URL is the web address (like https://…) that wallets, dApps, or code will send requests to whenever they need to read data from or send transactions to Solana.

Development libraries and wallets let users and devs specify this RPC URL, or “RPC endpoint,” when initializing a connection. This allows pointing requests to the correct network.

The RPC node is the actual server that receives calls at that URL.

What is an RPC node in Solana?

An RPC node is a regular validator or full Solana node that additionally exposes an HTTP-based JSON-RPC interface.

This interface lets the node accept RPC calls to:

• Serve read requests (account data, logs, block history, etc.);
• Accept transactions.

Therefore, interacting with the network requires only a reliable RPC URL.

How Solana RPC enables transactions and data queries

Under the hood, the RPC node runs an HTTP and WebSocket server listening on ports. Together, those two listeners form the “RPC API” surface that wallets, dApps, and other tools use to interact with the chain using JSON.

All of the interactions are covered by RPC or API methods. Here are some of the most common Solana methods by category:

Category	Example Methods	Purpose
Data queries	getAccountInfo, getBalance, getSlot	Read the network and account state
Transactions	sendTransaction, simulateTransaction	Submit or dry-run txns

All calls follow the same pattern:

1. Wrap up a method name plus any parameters into a JSON object, e.g:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBalance",
  "params": [""]
}

2. POST it to the RPC URL.

The node then parses the request, executes it, and returns the response.

Sending a JSON-RPC request over HTTP to an RPC endpoint

Try this and other methods now in your project. Check out our documentation for code samples.

Structure of a Solana RPC URL

Solana endpoints follow the standard URL structure. The Solana team and community run public RPC nodes at predictable hostnames, as in the example:

https://api.mainnet-beta.solana.com

RPC services like GetBlock run their own Solana infrastructure and provide URLs to give access to their services.

Solana RPC URL example

Here, <ACCESS_TOKEN> is a unique identifier generated when creating an endpoint. It acts as the credential and routes requests to the right Solana network as set up during the token’s configuration.

Official Solana RPC URLs and chain IDs

Solana operates three clusters – Mainnet, Testnet, and Devnet. Each serves a different purpose:

1. Mainnet (officially still in “beta”): The real production network where actual SOL tokens circulate and live dApps run.
2. Devnet: A public sandbox for developers to trial-run client-side code or programs (smart contracts).
3. Testnet: An environment mainly used for stress-testing validators and protocol upgrades.

The RPC URL determines which of these networks users are talking to

Mainnet, Testnet, Devnet RPC URLs

Here’s the list of default Solana URLs for each network:

Solana Network	HTTP(s) RPC URL	WebSocket RPC URL
Mainnet	https://api.mainnet-beta.solana.com	wss://api.mainnet-beta.solana.com
Testnet	https://api.devnet.solana.com	wss://api.devnet.solana.com
Devnet	https://api.testnet.solana.com	wss://api.testnet.solana.com

These are the public RPC endpoints that are convenient and free to use, but with significant limitations. Further on, we’ll dive into these trade-offs in detail, including how to avoid them.

Corresponding chain IDs for each network

Solana does not use EVM-style integer “chain ID”. Instead, each cluster is distinguished by its genesis hash, which is the cryptographic fingerprint of the very first block’s data.

To verify the connection to the correct cluster, a client can fetch getGenesisHash from the RPC node. Comparing it to the known hash will confirm “yes, this really is mainnet” (or devnet, or testnet):

Solana cluster	Corresponding Genesis Hash (Encoded in Base58)
Mainnet	5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d
Devnet	EtWTRABZaYq6iMfeYKouRu166VU2xqa1wcaWoxPkrZBG
Testnet	4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY

Note: Solana transactions also do not carry a numeric chainId. When building and signing a transaction, a recent blockhash is included instead. Solana relies on blockhash uniqueness per cluster to prevent cross-network replay.

How to use Solana RPC in development

Solana RPC can be used with any tool that can issue HTTP POST requests. This includes curl/fetch calls, the Solana CLI, or an SDK (JavaScript, Python, Rust, etc.).

In the brief demo below, we’ll use the solana-web3.js library that has a useful functionality to interact with RPCs.

Connecting to Solana via solana-web3.js

Before writing any code, get an RPC URL for the network you intend to use. By registering at GetBlock, you can create up to 2 free RPC endpoints – ideal for following this tutorial and running tests:

1. After signing up on GetBlock, go to the Dashboard, Shared Nodes → My Endpoints.
2. Under Protocol, choose Solana.
3. Select the network (e.g. Mainnet) and API: JSON‑RPC.
4. Click Get to generate a free URL.

Solana RPC URL setup via GetBlock’s dashboard / Image by GetBlock

Now that we have the URL, we can proceed with solana-web3.js SDK.

1. Make sure you’ve got Node.js v14 or later installed on your machine, and prepare a Node.js project:

mkdir your-project-name  //  makes a new folder in your current location
cd your-project-name  //  enter your new directory
npm init -y //  initialize your Node.js project

2. Install @solana/web3.js in the project’s root folder.

npm i @solana/web3.js 

3. Create an RPC connection. In your JavaScript or TypeScript file, create a Connection and point it at the RPC URL:

const { Connection, clusterApiUrl } = require("@solana/web3.js");
 
// Option A: Connect via GetBlock (replace with your actual RPC URL)
const rpcUrl = "https://go.getblock.io/<Your_Access_Token>";
const connection = new Connection(rpcUrl);
 
// Option B: Use the public Solana endpoint
// const connection = new Connection(clusterApiUrl("mainnet-beta"));

This is how you spin up a Connection object that knows exactly which cluster you’re talking to.

Example: Fetching account data using RPC

With the RPC connection ready, we can use getAccountInfo method. It will ask the node for everything it knows about the given account. Below is a minimal Node.js script showing how to call getAccountInfo:

//  Additionally import PublicKey object when calling methods like getAccountInfo, or anything that requires an address input 
 
const { Connection, PublicKey } = require("@solana/web3.js");
 
const rpcUrl = "https://go.getblock.io/<Your_Access_Token>";
const connection = new Connection(rpcUrl);
 
(async () => {
   const pubkey = new PublicKey("Your_base58_Solana_address");
   const accountInfo = await connection.getAccountInfo(pubkey);
   console.log(accountInfo);
 })();

When executed, it returns either “null”, meaning there is no account at that address, or prints these fields:

{
  data: ,
  executable: false,
  lamports: 111626071,
  owner: PublicKey [PublicKey(11111111111111111111111111111111)] {
    _bn: 
  },
  rentEpoch: 18446744073709552000,
  space: 0
}

Any of Solana’s JSON‑RPC methods can be invoked following this structure.

Handling rate limits and connection errors

When using an RPC endpoint, plan for two classes of failures:

• HTTP 429 (Too Many Requests): Returned when exceeding rate limits.
• HTTP 503 (Service Unavailable): On timeouts, dropped connections, or when the node is overloaded.

These errors are especially common with public RPC endpoints. So, for production use or even serious testing, switching to private nodes is highly recommended.

Choosing the right Solana RPC provider

Anyone building on Solana or creating complex transaction workflows needs a reliable RPC access. This section is dedicated to comparing different ways of getting this access.

Public vs private RPC nodes

The terms public and private describe two ways of accessing a node. Mainnet, testnet, and devnet URLs under the solana.com domain are all public. Their RPC URLs are known, and anyone can use them for free without special credentials.

While convenient, there are trade-offs to be aware of:

• strict rate-limits;
• per-method caps and data transfer caps;
• no guaranteed availability.

In other words, public endpoints are “use at your own risk” – great for hobby projects or low-volume use, but not for mission-critical projects.

For anything in production or higher throughput, private nodes are a must. This option includes:

1. Self-hosting an RPC server.
2. Subscribing to a node provider.

Self-hosting a Solana RPC node – Pros and cons

Running Solana infrastructure is known to be more expensive than other chains. Because of parallelized architecture and high TPS goals, its nodes simply demand more CPU, RAM, storage IOPS, and network throughput. In practice, it requires data‑center–grade servers.

For the up-to-date hardware and network specs, check out our Solana Full Nodes guide.

The table below summarizes valid reasons to run a node and corresponding trade-offs.

Pros	Cons
No third‑party dependencies	Full responsibility for maintenance, updates & security
No rate limits other than your own server’s capacity	High hardware requirements, growing with the performance demands
Contributing to network decentralization by adding another independent participant to the network	Requires in-depth Solana expertise to set up and maintain

Sizing up these benefits versus risks helps guide a decision: build your own node or use an RPC provider.

Top RPC providers

For most dApps, a managed RPC solution delivers the same reliability and performance of self-hosted solutions at a fraction of the effort and expense. Top node providers maintain endpoints optimized for Solana’s high request rates and offer formal uptime or performance guarantees.

Here’s a clear look at the capabilities of GetBlock, one of the best Solana RPC services:

• Fully managed, production‑grade endpoints with API access – zero ops, instant access;
• High, predictable throughput with optional node clusters scaling to 1,000+ RPS;
• Endpoints in every major region (US, Asia, Europe) where the Solana network has strong, low‑latency connectivity;
• Extra free services like built-in MEV protection;
• Jito MEV, bloXroute, gRPC, DAS API add-ons, or other custom options;
• Collaboration features for development teams or large enterprises;
• Rich analytics and professional support.

Sign up for an account and start testing GetBlock with free 50,000 compute units/day – enough to try most features and start individual projects before committing to paid plans with premium reliability.