Solana RPC Nodes: Setup, Providers & Best Practices

Solana RPC nodes provide the read, submission, and subscription interfaces that applications use to communicate with the network. Provider features, limits, pricing, hardware requirements, and performance figures change over time, so production decisions should be verified against current documentation and workload tests.

Last Updated: July 2025

Solana's public endpoints may be useful for development but are not a universal production-service guarantee. If a dApp returns 429 errors, stalls on account queries, or has submission problems under load, its RPC path is one component to investigate alongside transaction construction, fees, expiry, networking, and cluster conditions.

This guide covers what a Solana RPC node is, how it differs from a validator node, how requests flow through the system, where to get public endpoint URLs, which RPC methods matter most, how to connect via @solana/web3.js, which managed providers to evaluate, what self-hosting actually requires, and how to fix the rate-limit errors you are probably already seeing.

TL;DR: For development, use the free Solana Foundation public endpoints. For production, use a managed provider such as Helius, QuickNode, Alchemy, or Triton One. Self-hosting offers more operational control but still requires capacity planning, access policies, monitoring, and current hardware guidance.

Jump to:

• What Are Solana RPC Nodes?
• RPC Node vs. Validator Node
• How Solana RPC Nodes Work
• Types of Solana RPC Nodes
• Why RPC Node Quality Matters: DeFi, NFTs, and dApp Performance
• Best Solana RPC Node Providers
• Connecting Your App Using @solana/web3.js
• Solana RPC Methods: What You Can Query
• How to Run Your Own Solana RPC Node
• Common Solana RPC Errors and How to Fix Them
• Frequently Asked Questions
• Choosing the Right Solana RPC Strategy

What Are Solana RPC Nodes?

A Solana RPC node is a server that implements the Solana JSON-RPC API, accepting requests from client applications and returning blockchain state data in response. dApps, wallets, block explorers, and automated scripts use these nodes to read account balances, submit transactions, and subscribe to on-chain events without maintaining a local copy of the ledger.

Historical materials cite a theoretical Solana throughput near 65,000 TPS and a target slot duration near 400 milliseconds. Neither is a guaranteed live result: transaction definitions, skipped slots, vote traffic, workload, cluster conditions, and software versions all affect observed performance. The target cadence and account-state volume still place substantial demands on RPC infrastructure.

Remote Procedure Call (RPC) is a communication pattern in which a program on one machine calls a function on another machine as if it were local, with the network complexity abstracted away. Your dApp can query account state and submit transactions against a remote node rather than maintaining its own ledger copy. Solana uses JSON-RPC 2.0 as its wire protocol: a lightweight format that routes calls by method name over HTTP or WebSocket, not by resource-based URL paths like REST APIs.

The Solana Foundation operates free public endpoints at https://api.mainnet-beta.solana.com and equivalent URLs for devnet and testnet. These endpoints enforce rate limits per IP address. When your application exceeds those limits, it receives HTTP 429 Too Many Requests errors, causing intermittent failures and degraded user experience under load.

RPC Node vs. Validator Node: Understanding the Difference

An RPC node serves blockchain data to external clients via the JSON-RPC API. A validator node participates in consensus and votes on block validity. These are the two primary node types on Solana, and they serve distinct purposes.

Validator nodes participate in Tower BFT consensus, a Proof-of-Stake-based voting mechanism. Proof of History (PoH), Solana's cryptographic sequencing mechanism (not its consensus protocol), establishes ordering before votes are cast. Tower BFT is the consensus layer; PoH handles timekeeping.

Gulf Stream, Solana's transaction forwarding protocol, sends transactions directly to current and upcoming leader nodes, bypassing the mempool that other blockchains use. Validators handle this forwarding process. RPC nodes do not.

Running an RPC node does not require staked SOL. Some operators run both validator and RPC functionality on the same physical machine, but the roles remain logically separate: one votes in consensus, the other serves client queries. For hardware requirements involved in self-hosting an RPC node, the RAM and storage demands run substantially higher than for a validator alone.

How Solana RPC Nodes Work: Architecture and Data Flow

A Solana RPC node maintains a local replica of the ledger and account state, serving that data to any client that sends a valid JSON-RPC request.

The JSON-RPC Request Lifecycle

1. A client application (dApp, wallet, or script) sends an HTTP POST request or WebSocket message to the RPC node's endpoint URL.
2. The request body contains a JSON-RPC 2.0 payload with four fields: jsonrpc, id, method, params.
3. The RPC node receives the request and routes it to the appropriate internal handler based on the method field.
4. The node queries its local ledger replica or account state store for the requested data.
5. The node returns a JSON-encoded response containing either the requested data or a structured error object.

A concrete getBalance example:

// Request
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBalance",
  "params": ["YourPublicKeyBase58Here", {"commitment": "confirmed
}

// Response
{
  "jsonrpc": "2.0",
  "result": {
    "context": {"slot": 285823400},
    "value": 5000000000
  },
  "id": 1
}
// Note: value is in lamports. Divide by 1,000,000,000 to convert to SOL.

Unlike REST APIs that use resource-based URLs, JSON-RPC routes every call through a single endpoint using the method field. Developers with Ethereum experience will recognize the request structure. Solana differs in three key ways: there is no mempool (transactions go directly to the current leader), state lives in accounts rather than EVM contract storage, and 400ms slots are roughly 30 times faster than Ethereum's 12-second block times.

Commitment Levels: processed, confirmed, finalized

Every RPC call that reads state accepts a commitment parameter:

• processed: The most recent slot the node has seen. Fastest, but the slot could theoretically be rolled back.
• confirmed: The slot has received a supermajority of validator votes. Strong finality for most dApp use cases.
• finalized: The slot is permanently part of the chain. Use for high-stakes operations.

What a Solana RPC Node Stores

The node holds two categories of data. Current account state lives in RAM: the snapshot of every active account at the latest confirmed slot, required for fast query responses. Historical ledger data lives on NVMe SSD: all transaction records organized by slot. Solana accumulates roughly 100 to 200 GB of ledger data per day on mainnet-beta. That storage growth, combined with 400ms slots, explains why RPC nodes require 256 GB of RAM at minimum and multiple terabytes of fast storage.

For the complete Solana JSON-RPC API reference, see docs.solana.com/api.

HTTP vs. WebSocket: Choosing the Right Transport

Types of Solana RPC Nodes: Public, Private, and Self-Hosted

Solana RPC nodes are accessed in three ways: through the Solana Foundation's free public endpoints, through a managed private provider, or through a self-hosted node you operate directly.

Public Solana RPC Endpoints (Free)

The Solana Foundation operates four public RPC endpoints, one per network cluster. All are free but enforce rate limits per IP address.

Public endpoints enforce a rate limit of approximately 100 requests per 10 seconds per IP address. Exceeding this threshold returns HTTP 429 Too Many Requests. These endpoints work for development and testing. For production use, see the Solana RPC provider comparison below.

For full cluster documentation, see docs.solana.com/clusters.

Private and Managed RPC Node Providers

A managed RPC provider may offer dedicated endpoints, higher published limits, WebSocket support, service targets, and multiple regions; exact features depend on the current plan. The four primary providers for Solana:

• Helius: Solana-native provider with enhanced RPC APIs and webhook notifications
• QuickNode: Multi-chain provider with geographic distribution and an add-on marketplace
• Alchemy: Multi-chain provider with enterprise-grade developer tooling
• Triton One: Solana-native specialist focused on raw RPC performance for institutional workloads

A full comparison with pricing, WebSocket support, and differentiators is in the provider comparison section.

Self-Hosted Solana RPC Nodes

Self-hosting gives you full control over your RPC infrastructure with no rate limits, but the hardware cost starts in the thousands of dollars and ongoing DevOps maintenance is non-trivial. Full requirements and a setup overview are in How to Run Your Own Solana RPC Node.

Why RPC Node Quality Matters: DeFi, NFTs, and dApp Performance

The quality of your RPC node directly determines whether your application functions correctly under production conditions. Four use cases make this concrete.

DeFi Trading and Arbitrage Bots

DeFi protocols on Solana process time-sensitive transactions where latency determines outcomes. A trading bot calling getLatestBlockhash and sendTransaction through a rate-limited public endpoint risks a stale blockhash or a dropped transaction during a 429 timeout. On Solana's 400ms slot timeline, a 50ms difference in RPC response time can determine whether a transaction lands in the target slot or misses it entirely.

Jupiter (aggregator), Raydium (AMM/DEX), Drift (perpetuals), and Marginfi (lending) all depend on low-latency RPC access. Unlike Ethereum DeFi, Solana transactions skip the mempool entirely via Gulf Stream, going straight to the current leader. There is no ordering queue to fall back on if your RPC call arrives late.

NFT Minting and Marketplace Monitoring

High-demand NFT mints generate bursts of hundreds of concurrent sendTransaction calls from buyers competing for limited supply. A public endpoint capped at ~10 requests per second returns 429 errors to most participants during peak drops. NFT marketplaces such as Magic Eden and Tensor use WebSocket logsSubscribe subscriptions to detect mint events in real time, which requires a provider that handles stable WebSocket connections at scale.

Wallet and Portfolio Dashboards

Wallet applications call getBalance and getTokenAccountBalance for each asset a user holds, plus getAccountInfo to read on-chain metadata. A wallet serving 10,000 active users can issue tens of thousands of RPC queries per minute. A private RPC provider with sufficient QPS (queries per second) capacity keeps these queries resolving without degrading the user experience. QPS here refers to RPC request throughput, not Solana's network-level transaction throughput.

On-Chain Analytics, Indexers, and Exchange Integrations

Analytics platforms and indexers call getBlock repeatedly to replicate the full transaction history of the Solana ledger. A full historical sync issues thousands of getBlock requests in sequence. Self-hosted RPC nodes or dedicated enterprise-tier plans are the only options that sustain this volume reliably. Centralized exchanges running their own Solana RPC nodes use similar high-throughput patterns to reconcile user balances and detect deposits at scale.

Solana's 400ms slot time compared to Ethereum's approximately 12-second block time means a Solana dApp queries RPC roughly 30 times more frequently per unit of time for equivalent operations, making RPC node performance disproportionately more critical here than on most other networks. If you are hitting rate limits under production traffic, upgrading to a private RPC provider is the most direct fix.

Comparing Solana RPC Node Providers

For most production dApps, the question is not whether to use a managed RPC provider but which one fits your workload. The table covers the four primary options with the Solana Foundation's free public endpoint as a baseline.

Pricing information in this table was accurate at time of publication. Provider plans, pricing, and features change frequently. Verify current details directly at each provider's website before making a selection.

Last Updated: July 2025

Helius advertises Solana-focused RPC methods, webhooks, and transaction-parsing features. Capabilities, quotas, pricing, regions, and service terms should be checked directly at helius.dev and tested with the intended workload.

QuickNode advertises multi-chain RPC infrastructure, regional endpoints, and optional add-ons. Verify current Solana coverage, quotas, pricing, and service terms at quicknode.com, then benchmark the required methods and regions.

Alchemy advertises multi-chain developer infrastructure that includes Solana support. Confirm current method coverage, WebSocket behavior, limits, regions, and pricing at alchemy.com before treating it as equivalent to another provider.

Triton One advertises Solana infrastructure for higher-throughput workloads. Its latency, availability, geographic coverage, limits, and commercial terms require direct verification at triton.one and workload-specific testing.

GenesysGo previously operated a Solana RPC service under the Shadow brand. Verify current status at genesysgo.com before evaluating.

All major providers offer free tiers or trial plans sufficient for development and testing. Rate limits become a production concern only when your application serves real users at scale.

How to Evaluate a Solana RPC Provider

The right provider depends on your workload:

Provider latency claims are not interchangeable. p50 is the median response time, while p99 captures the slowest 1% of requests and can matter for time-sensitive operations. Actual results depend on method mix, load, geographic proximity, caching, and plan limits, so benchmark the intended request pattern before choosing a paid plan.

Connecting Your App to a Solana RPC Node Using @solana/web3.js

Switching from the Solana Foundation's public endpoint to a private provider requires changing one line in your application: the URL string passed to the Connection constructor.

Version note: Code examples in this section use @solana/web3.js v1.x, the current production standard. Solana Labs is developing v2.0 with a significantly different API. If you are using v2.0, refer to the official v2.0 documentation for equivalent methods.

Install and Connect

Step 1: Install the package

npm install @solana/web3.js

Step 2: Instantiate a Connection and query a balance

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

// Pull the endpoint from an environment variable — never hard-code a private URL
const RPC_ENDPOINT = process.env.RPC_URL ?? "https://api.devnet.solana.com";

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

async function getWalletBalance(address: string): Promise<void> {
  const publicKey = new PublicKey(address);

  // getBalance returns lamports; divide by LAMPORTS_PER_SOL (10^9) to get SOL
  const balanceLamports = await connection.getBalance(publicKey);
  const balanceSOL = balanceLamports / LAMPORTS_PER_SOL;

  console.log(`Balance: ${balanceSOL} SOL`);
}

Step 3: Read account data

async function getAccountData(address: string): Promise<void> {
  const publicKey = new PublicKey(address);

  // getAccountInfo returns null if the account does not exist
  const accountInfo = await connection.getAccountInfo(publicKey);

  if (!accountInfo) {
    console.log("Account not found");
    return;
  }

  console.log("Owner program:", accountInfo.owner.toBase58());
  console.log("Data length (bytes):", accountInfo.data.length);
  console.log("Lamports:", accountInfo.lamports);
}

Step 4: Send a transaction

import {
  Transaction,
  SystemProgram,
  Keypair,
  sendAndConfirmTransaction,
} from "@solana/web3.js";

async function transferSOL(
  sender: Keypair,
  recipientAddress: string,
  amountSOL: number
): Promise<string> {
  const recipient = new PublicKey(recipientAddress);
  const lamports = amountSOL * LAMPORTS_PER_SOL;

  const transaction = new Transaction().add(
    SystemProgram.transfer({
      fromPubkey: sender.publicKey,
      toPubkey: recipient,
      lamports,
    })
  );

  // sendAndConfirmTransaction waits for "confirmed" commitment before resolving
  const signature = await sendAndConfirmTransaction(connection, transaction, [sender]);
  return signature;
}

Step 5: Configure environment-based endpoint switching

Set up a config module to swap clusters via an environment variable rather than touching application code:

// config/rpc.ts
const RPC_ENDPOINTS: Record<string, string> = {
  "mainnet-beta": "https://api.mainnet-beta.solana.com",
  "devnet":       "https://api.devnet.solana.com",
  "private":      process.env.PRIVATE_RPC_URL ?? "",
};

const NETWORK = process.env.SOLANA_NETWORK ?? "devnet";
export const connection = new Connection(RPC_ENDPOINTS[NETWORK], "confirmed");

Security note: Never hard-code your private RPC endpoint URL in client-side JavaScript. A browser-exposed URL leaks your API key to anyone who inspects network traffic. Route it through a server-side proxy or backend API route.

For the full @solana/web3.js API reference, see solana-labs.github.io/solana-web3.js.

HTTP vs. WebSocket RPC Connections: When to Use Each

WebSocket connections use wss:// instead of https://. Most managed providers supply both endpoints under the same plan.

// WebSocket subscription: monitor account changes in real time
const publicKey = new PublicKey("YourAccountPublicKeyHere");

const connectionWithWS = new Connection(
  process.env.RPC_URL ?? "https://api.devnet.solana.com",
  {
    commitment: "confirmed",
    wsEndpoint: process.env.WSS_URL ?? "wss://api.devnet.solana.com",
  }
);

// onAccountChange returns a subscription ID used for cleanup later
const subscriptionId = connectionWithWS.onAccountChange(
  publicKey,
  (accountInfo, context) => {
    console.log("Account changed at slot:", context.slot);
    console.log("New lamport balance:", accountInfo.lamports);
  },
  "confirmed"
);

// Remove the subscription when no longer needed:
// connectionWithWS.removeAccountChangeListener(subscriptionId);

Handling Rate Limits and 429 Errors

A 429 Too Many Requests error from a public Solana endpoint means your application has exceeded the per-IP rate limit. Three strategies address this:

1. Switch to a managed private provider. Helius, QuickNode, Alchemy, and Triton One offer plans sized for production traffic. See comparing private Solana RPC providers.
2. Implement exponential backoff. On a 429 response, retry with a delay that doubles each attempt (see the code below).
3. Batch account reads with getMultipleAccounts. Fetching 20 accounts in one call consumes one request instead of 20.

// Exponential backoff wrapper for any RPC call
async function withRetry<T>(
  fn: () => Promise<T>,
  maxRetries: number = 5
): Promise<T> {
  let attempt = 0;
  while (attempt < maxRetries) {
    try {
      return await fn();
    } catch (error: any) {
      const is429 = error?.message?.includes("429");
      if (is429 && attempt < maxRetries - 1) {
        // Wait 500ms, then 1s, then 2s, then 4s, then 8s
        const waitMs = 500 * Math.pow(2, attempt);
        await new Promise((resolve) => setTimeout(resolve, waitMs));
        attempt++;
      } else {
        throw error;
      }
    }
  }
  throw new Error("Max retries exceeded");
}

Solana RPC Methods: What You Can Query

Solana's JSON-RPC API exposes over 80 methods. The table below covers those most dApp developers use regularly.

HTTP RPC Methods

getRecentBlockhash is deprecated. Use getLatestBlockhash instead. The replacement also returns lastValidBlockHeight, which enables reliable transaction expiry handling.

WebSocket Subscription Methods

WebSocket subscriptions suit any dApp that needs to react to on-chain events without polling. accountSubscribe fires when a specific account's data changes, useful for tracking a user's wallet or a Solana program's (the equivalent of a smart contract on Ethereum) state account. logsSubscribe streams transaction logs matching a program ID filter, used by DeFi protocols like Jupiter and Raydium to detect swap events as they happen.

Anchor, the most widely used Solana program development framework, generates TypeScript clients that call these methods through @solana/web3.js under the hood. RPC configuration applies identically to Anchor-based dApps.

For the complete method reference including parameters, return types, and error codes, see the Solana RPC API documentation.

How to Run Your Own Solana RPC Node: Requirements and Setup Overview

Self-hosting a Solana RPC node gives you complete control, no rate limits, and maximum data privacy. The hardware investment runs into thousands of dollars, and keeping the node healthy requires dedicated DevOps capacity. Large protocols, exchanges, and teams with existing infrastructure capabilities are the audience for this path.

Hardware Requirements

Hardware requirements evolve as the network grows. Verify current specifications against the official Solana documentation at docs.solana.com/running-validator before provisioning hardware.

Solana's account-based model stores all program state in individual accounts. A full RPC node must hold current account state for every active account in RAM for fast query responses, plus historical ledger data on NVMe SSD. Storage growth of 100 to 200 GB per day on mainnet-beta means operators must plan for continuous ledger rotation.

Setup Process Overview

Seven stages are required. Each step links to the official Solana documentation for full configuration detail.

1. Provision hardware meeting or exceeding the specifications above.
2. Install the operating system and configure Linux kernel parameters: raise ulimit file descriptor limits and tune sysctl network settings for Solana's high UDP traffic volume.
3. Install the Solana CLI and the agave validator binary (formerly solana-validator) from the official Solana Labs release channel.
4. Configure the node for RPC mode by passing the --no-voting flag to disable consensus participation, and set --rpc-port 8899 (HTTP) and --rpc-pubsub-port 8900 (WebSocket).
5. Download a snapshot from the Solana Foundation's snapshot repository to bootstrap sync from a recent state rather than replaying from genesis.
6. Start the node and monitor sync progress using solana catchup to track how far behind the node is from the cluster tip.
7. Configure firewall rules to expose ports 8899 and 8900 only to authorized IP addresses. Do not expose your RPC port publicly without authentication.

Sync Time and Ongoing Maintenance

Snapshot sync takes 1 to 3 days on recommended hardware. Syncing from genesis takes considerably longer and is not recommended.

Bare metal typically costs $500 to $1,500 per month depending on specifications and data center geography. Cloud equivalents cost more due to virtualization overhead on storage-intensive workloads. Storage growth of 100 to 200 GB per day forces a choice between pre-allocating massive volumes or automating ledger pruning.

For teams evaluating the build-vs-buy decision, compare managed provider costs in the provider comparison section before committing to hardware procurement.

Common Solana RPC Errors and How to Fix Them

429 Too Many Requests

Your application has exceeded the per-IP rate limit on the public Solana endpoint. To fix it:

1. Switch to a managed private provider. Helius, QuickNode, Alchemy, and Triton One offer plans sized for production traffic. See comparing private Solana RPC providers.
2. Implement exponential backoff. On a 429 response, retry with a delay that doubles each attempt. A code example is in the rate limit handling section.
3. Batch account reads with getMultipleAccounts. Fetching 20 accounts in one call consumes one request instead of 20.

Transaction Confirmation Timeouts

A transaction submitted via sendTransaction does not land. The blockhash may have expired, or the network may have been congested. To fix it:

1. Call getLatestBlockhash immediately before building a transaction. Do not use getRecentBlockhash (deprecated).
2. Check lastValidBlockHeight from the response and retry before that height is reached.
3. Use sendAndConfirmTransaction rather than raw sendTransaction for automatic retry on transient failures.

getProgramAccounts Rate Limit Failures

getProgramAccounts is one of the most resource-intensive RPC calls. Public endpoints often restrict or reject it entirely due to the load it places on shared infrastructure. If you see 403 or timeout errors specifically on these calls, upgrade to a private RPC provider with explicit support for large program account queries.

Frequently Asked Questions: Solana RPC Nodes

What is a Solana RPC node?

A Solana RPC node is a server that implements the Solana JSON-RPC API, accepting requests from client applications and returning blockchain state data. dApps, wallets, and block explorers use them to read account balances, fetch transaction history, and submit signed transactions to the network without running a local copy of the ledger.

What is the difference between a Solana RPC node and a validator node?

The two serve different roles. An RPC node serves data to external clients via the JSON-RPC API, does not participate in consensus, and earns no staking rewards. A validator node votes on block validity each slot, requires staked SOL, and earns SOL rewards for correct votes. Some operators run both on the same hardware, but the roles remain logically separate.

Is the Solana public RPC endpoint free to use?

Yes. The Solana Foundation's public endpoints at api.mainnet-beta.solana.com, api.devnet.solana.com, and api.testnet.solana.com are free. They enforce a rate limit of approximately 100 requests per 10-second window per IP address. These endpoints are sufficient for development and testing but are not suitable for production dApps serving real users.

How do I avoid rate limits on the Solana public RPC?

Three approaches work together: switch to a managed private RPC provider for production traffic; implement exponential backoff to retry failed requests with increasing wait intervals; and batch multiple account reads into single getMultipleAccounts calls rather than issuing one getAccountInfo per account.

What hardware does a self-hosted Solana RPC node require?

At minimum: a 12-core CPU, 256 GB DDR4 RAM, 2 TB NVMe SSD, and a 1 Gbps dedicated network connection. Recommended for production: a 24-core CPU, 512 GB RAM, 2x 2 TB NVMe SSD, and 10 Gbps network. Verify current specifications against the Solana validator documentation, as requirements increase as the network grows.

How long does it take to sync a Solana RPC node?

Plan for 1 to 3 days using a recent snapshot on recommended hardware. Syncing from genesis takes considerably longer. The Solana Foundation provides official snapshots to accelerate the process.

What is the difference between HTTP and WebSocket RPC connections on Solana?

HTTP RPC uses a stateless request-response model. Your application sends one request and receives one response, which works for one-time queries like getBalance or sendTransaction. WebSocket RPC uses a persistent connection with a subscription model. Your application subscribes to on-chain events and receives push notifications when those events occur. Use WebSocket for any real-time feature in your dApp.

How should production dApps evaluate a Solana RPC provider?

Helius and QuickNode are two frequently discussed options, but community visibility is not proof of suitability or performance. Helius fits teams building exclusively on Solana who need Solana-native enhanced APIs. QuickNode suits teams supporting multiple blockchains under one account. Triton One is the option for institutional workloads where p99 latency is the primary constraint. The right choice depends on your workload and whether Solana-specific features or multi-chain support matters more.

Related Solana Guides

• Solana Turbine block propagation
• Solana slots and block time

Explore SOL on Bybit

Readers can review current SOL market information or the SOL/USDT spot market. These links provide market information and access; they do not validate a technical claim or imply that SOL is suitable for every reader.

Choosing the Right Solana RPC Strategy for Your Use Case

Three paths exist, and most teams will recognize which one fits their current stage immediately.

RPC reliability affects application reads and transaction submission, but a target slot duration is not a confirmation guarantee and RPC latency is only one factor in whether a transaction lands. Choose the tier that matches your current scale, and plan to upgrade before rate limits become a user-facing problem.

Next steps:

• Sign up for a free development tier: helius.dev or quicknode.com
• Review the full Solana JSON-RPC method reference: docs.solana.com/api
• Review hardware specifications before provisioning for self-hosting: How to Run Your Own Solana RPC Node