DEV Community: OnFinality

Staking KLAY on Klaytn: RPC Methods and Integration Checks

OnFinality — Tue, 15 Sep 2026 02:22:01 +0000

Klaytn rebranded to Kaia, but the staking mechanics developers ask about are the same: KLAY (now KAIA) holders delegate stake to governance councils or node operators, and applications need reliable RPC access to read stake state, track rewards, and submit staking transactions. This page is aimed at developers building staking dashboards, wallets, or reward trackers, and at teams deciding what RPC infrastructure to run behind them.

What you actually need before you stake

Before writing any code, confirm three things. First, the staking path you are targeting: governance council delegation, a public node operator, or a liquid staking service. Each has a different contract surface and different data you need to read. Second, the unstaking delay, because it determines how you present withdrawal timelines in your UI. Third, whether your RPC endpoint can handle the read-heavy pattern staking apps produce, since reward tracking means frequent eth_call and log queries rather than occasional transfers.

If you are building on Klaytn and want a managed endpoint instead of running your own node, OnFinality's Klaytn (Kaia) RPC exposes a public endpoint you can test against immediately:

curl -X POST https://klaytn.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

A correct response returns 0x2019, which is chain ID 8217 for Kaia Mainnet. If you get a different chain ID, you are pointed at the wrong network.

Klaytn staking model in plain terms

Klaytn runs a delegated proof-of-stake consensus. A limited set of governance council nodes produce blocks, and KLAY holders can stake toward those nodes. Staking is not a free-for-all validator set like some networks; the council structure means the set of entities you can delegate to is constrained, and governance decisions affect who participates.

For developers, the practical consequences are:

Staking operations often route through specific staking contracts rather than a generic precompile.
Reward accrual is tied to block production, so you read rewards by scanning blocks or querying contract state, not by calling a single "get rewards" method.
Unstaking is not instant. You need to model a delay in your UI and in any accounting logic.

Because the network is now branded Kaia, some documentation and block explorers use Kaia naming while older contracts and tooling still say Klaytn. Expect both terms in the wild and do not assume a contract is deprecated just because it uses the older name.

RPC methods that matter for staking apps

Staking front-ends and backends lean on a small set of JSON-RPC methods. The table below maps the job to the method you will call most often.

Job in your staking app	Primary method	Notes
Confirm you are on Kaia Mainnet	`eth_chainId`	Expect `0x2019` (8217)
Read a staking contract's state	`eth_call`	Encode function selectors for the staking contract
Track reward or staking events	`eth_getLogs`	Bound block ranges; wide ranges are expensive
Check a user's KLAY balance	`eth_getBalance`	Returns wei; format to 18 decimals
Submit a stake or unstake transaction	`eth_sendRawTransaction`	Sign locally, then broadcast
Estimate gas before submitting	`eth_estimateGas`	Do this before every staking write
Confirm a transaction landed	`eth_getTransactionReceipt`	Poll until status is `0x1` or `0x0`
Read current block for reward windows	`eth_blockNumber`	Use as the upper bound for log queries

A minimal reward-tracking loop in JavaScript looks like this:

import { createPublicClient, http, parseAbi } from 'viem';

const client = createPublicClient({
  transport: http('https://klaytn.api.onfinality.io/public'),
});

const stakingAbi = parseAbi([
  'function getReward(address account) view returns (uint256)',
]);

async function readReward(contractAddress, account) {
  const latest = await client.getBlockNumber();
  const reward = await client.readContract({
    address: contractAddress,
    abi: stakingAbi,
    functionName: 'getReward',
    args: [account],
  });
  return { reward, block: latest };
}

Replace the ABI and contract address with the actual staking contract you integrate. The point is the pattern: read state with eth_call, anchor it to a block number, and store that block number so you can reconcile later.

Choosing RPC infrastructure for a staking product

Staking apps have a read-heavy, latency-sensitive profile. Users expect reward numbers to update quickly, and they expect stake and unstake transactions to land without retries. That makes endpoint choice a product decision, not just an infrastructure detail.

When you evaluate providers for a Klaytn staking app, compare on the dimensions that actually affect staking UX:

Evaluation area	What to look for	Why it affects staking
Read throughput	Ability to serve frequent `eth_call` and `eth_getLogs`	Reward dashboards poll constantly
Log query limits	Clear guidance on block-range caps	Wide ranges silently fail or time out
Write path reliability	Stable `eth_sendRawTransaction` behavior	Failed broadcasts strand user funds in pending state
Failover	Multiple endpoints or automatic routing	A single endpoint outage freezes staking UI
Archive access	Historical state if you reconcile old rewards	Without it, backfills are impossible
Support model	Who you contact when a staking tx misbehaves	Staking bugs are time-sensitive

OnFinality provides managed Klaytn (Kaia) RPC through its API service, and teams that need isolated capacity, custom rate limits, or private networking can move to a dedicated node. For most staking dashboards, a managed endpoint with a failover plan is enough to start; dedicated infrastructure becomes worthwhile when your read volume or compliance needs outgrow shared capacity. You can compare tiers on the RPC pricing page and see the full set of supported RPC networks.

If you are still deciding between providers, the RPC provider selection guide walks through the same criteria in more depth.

Common failure modes and how to debug them

Staking integrations fail in predictable ways. Here is a symptom-to-fix table you can keep next to your logs.

Symptom	Likely cause	Fix
Reward numbers jump or reset	Reading from a different block each poll	Pin reads to a block number and store it
`eth_getLogs` returns nothing	Block range too wide or wrong address	Narrow the range; verify the contract address
Stake transaction stuck pending	Gas price too low or nonce gap	Re-estimate gas; check nonce sequence
Wrong chain data	Endpoint pointed at a testnet	Re-check `eth_chainId` returns `0x2019`
Intermittent timeouts	Single endpoint under load	Add a second endpoint and retry logic
Unstake never completes	UI ignores the unstaking delay	Model the delay explicitly in your state machine

The nonce gap problem is the one that bites hardest. If a staking transaction fails silently and you submit another without resyncing the nonce, every subsequent transaction queues behind the stuck one. Always read eth_getTransactionCount with the pending tag before broadcasting a new staking write.

A practical integration checklist

Work through this list before you ship a staking feature:

Confirm chain ID 8217 and the correct staking contract addresses for your target path.
Decide how you will read rewards: contract eth_call, event logs, or both.
Pin every read to a block number and persist it for reconciliation.
Implement gas estimation and nonce management for stake and unstake writes.
Model the unstaking delay in your UI and in any accounting.
Add a second RPC endpoint and retry logic for read failures.
Log the endpoint and block number with every staking error so you can reproduce it.
Test the full stake, reward, and unstake cycle on a testnet before mainnet.

If your team would rather not operate nodes at all, a managed endpoint removes steps 6 and 7 from your plate because failover and endpoint health become the provider's responsibility.

Key Takeaways

Klaytn is now branded Kaia, but staking mechanics and contract addresses still use both names.
Staking apps are read-heavy: eth_call and eth_getLogs dominate, not transfers.
Pin reward reads to a block number or your numbers will drift.
Nonce and gas management are the most common sources of stuck staking transactions.
Endpoint choice directly affects staking UX; compare read throughput, log limits, and failover.
OnFinality offers managed Klaytn (Kaia) RPC and dedicated nodes when shared capacity is not enough.

Frequently Asked Questions

Can I run my own Klaytn validator to stake?
Governance council participation is limited and not open to arbitrary operators. Most KLAY holders stake through delegation or a liquid staking service rather than running a validator directly.

How long does unstaking take on Klaytn?
There is a delay between requesting an unstake and receiving funds. Check the current staking contract documentation for the exact period, and model it in your UI rather than assuming instant withdrawal.

Which RPC method do I use to read staking rewards?
Usually eth_call against the staking contract, or eth_getLogs if rewards are emitted as events. There is no single global "get staking rewards" method.

Do I need an archive node for staking?
Only if you reconcile historical rewards or backfill data from old blocks. For live dashboards, a standard full node is typically sufficient.

Can I use the public OnFinality endpoint in production?
Public endpoints are useful for testing and low-volume reads. For production staking apps, evaluate a managed plan or dedicated node so you have predictable capacity and failover.

What chain ID should I expect?
Kaia Mainnet returns 0x2019, which is 8217 in decimal. If you see anything else, you are on the wrong network.

Related resources

Originally published at OnFinality.

Ethereum RPC Node Provider: How to Evaluate One

OnFinality — Tue, 15 Sep 2026 02:21:28 +0000

Choosing an Ethereum RPC node provider is really a question about how your application reads and writes chain state under load. Ethereum mainnet produces a block roughly every 12 seconds, and every wallet balance check, log query, and transaction broadcast goes through a JSON-RPC endpoint. If that endpoint is slow, rate-limited, or missing the methods you need, your users feel it before your dashboards do.

This page is for developers and infrastructure buyers comparing Ethereum RPC options. It covers what a node provider actually does, which capabilities separate a shared endpoint from a dedicated node, and how to test a provider before you commit production traffic.

Start with your workload, not the provider list

Before you compare vendors, write down what your app actually sends. Most Ethereum RPC traffic falls into a few patterns, and each one stresses a different part of the node.

Workload pattern	Typical methods	What it stresses
Wallet / dapp reads	eth_call, eth_getBalance, eth_getTransactionCount	Low-latency head state, high request volume
Indexer / analytics	eth_getLogs, eth_getBlockByNumber	Archive state, large result sets, long queries
Trading / bots	eth_sendRawTransaction, eth_getTransactionReceipt	Broadcast speed, mempool visibility, WebSocket
Bridges / relayers	eth_getProof, trace_*	Trace and proof support, deep historical state
Monitoring / alerting	eth_subscribe, eth_blockNumber	Persistent WebSocket, stable connection

If you only send eth_call and eth_getBalance, a well-run shared endpoint is usually enough. If you run eth_getLogs across wide block ranges, replay history, or need trace_* and debug_* methods, you are in archive and dedicated-node territory. That distinction drives cost far more than raw request count.

What an Ethereum RPC node provider actually runs

A provider operates Ethereum execution and consensus clients, keeps them synced to the network, and exposes them through a load-balanced JSON-RPC layer. Good providers also handle client upgrades, reorg handling, peer management, and monitoring so you do not have to.

There are three common delivery models:

Public endpoints. Free, shared, and rate-limited. Fine for prototyping and low-volume reads, but not something to point a production wallet at.
Managed RPC API. A paid shared endpoint with higher limits, API keys, and usually archive access. This is the default choice for most production dapps.
Dedicated nodes. Isolated node capacity for one team. You get predictable throughput, your own archive or trace configuration, and no noisy neighbors.

OnFinality offers Ethereum through a managed RPC API service and through dedicated nodes when you need isolated capacity. You can start on the shared endpoint and move up without changing your application code, because the JSON-RPC interface stays the same.

Ethereum chain settings at a glance

If you are wiring Ethereum into a wallet, a Hardhat config, or a backend service, you need the canonical network parameters. Use these values so your tooling connects to mainnet rather than a testnet.

Setting	Value
Network name	Ethereum Mainnet
Chain ID	1
Native currency	ETH (18 decimals)
Block explorer	https://etherscan.io
Public RPC URL	https://eth.api.onfinality.io/public
Transports	HTTP and WebSocket

A quick way to confirm an endpoint is live and on the right chain is to ask it for the chain ID and latest block:

curl -s https://eth.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

# {"jsonrpc":"2.0","id":1,"result":"0x1"}

If that returns 0x1, you are on Ethereum mainnet. If it returns anything else, you are pointed at a different chain or a testnet. For testnet work, use the Ethereum Sepolia network page instead.

Provider evaluation matrix

Once you know your workload, compare providers against the capabilities that matter for it. The table below is a practical checklist rather than a ranking.

Capability	Why it matters	What to ask
Transport support	Wallets and bots often need WebSocket for subscriptions	Is HTTP and WS both available?
Archive access	Historical eth_getLogs and state reads need archive nodes	Is archive included or a separate tier?
Trace / debug methods	Bridges and analytics rely on trace_* and debug_*	Which trace methods are exposed?
Rate limits	Bursty workloads hit shared caps	What are the request and compute-unit limits?
Failover	A single endpoint is a single point of failure	Are there multiple regions or endpoints?
Observability	You need to see errors before users do	Are usage and error metrics exposed?
Support model	Incidents need a human, not a ticket queue	What is the response path during an outage?

OnFinality appears first here because it is the provider this site operates: it offers Ethereum over HTTP and WebSocket, supports archive and trace workloads on appropriate plans, and lets teams move from shared RPC to dedicated nodes. Compare every provider on the same criteria before deciding.

Testing a provider before you commit

Do not migrate production traffic on a provider's marketing page. Run a short evaluation against your real methods. A simple script that measures latency and correctness across a few endpoints will tell you more than any benchmark table.

// probe.mjs — compare Ethereum RPC endpoints on the methods you actually use
const endpoints = [
  "https://eth.api.onfinality.io/public",
  // add other provider endpoints you are evaluating
];

async function probe(url) {
  const body = (method, params = []) =>
    JSON.stringify({ jsonrpc: "2.0", id: 1, method, params });

  const call = async (method, params) => {
    const start = performance.now();
    const res = await fetch(url, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: body(method, params),
    });
    const json = await res.json();
    return { ms: Math.round(performance.now() - start), ok: !json.error };
  };

  const block = await call("eth_blockNumber");
  const logs = await call("eth_getLogs", [
    { fromBlock: "latest", toBlock: "latest" },
  ]);
  console.log(url, { block, logs });
}

for (const url of endpoints) await probe(url);

Run this at different times of day. Watch for endpoints that are fast on eth_blockNumber but slow or erroring on eth_getLogs, since log queries are where shared capacity usually shows its limits.

Where shared endpoints stop being enough

A managed shared endpoint is the right default for most teams. It stops being enough when one of these becomes true:

You regularly hit rate limits during peak traffic and cannot smooth the load.
You need eth_getLogs across large block ranges on a schedule.
You depend on trace_* or debug_* methods that shared tiers restrict.
You need a WebSocket connection that stays open for subscriptions without reconnects.
You need predictable throughput for a launch, a mint, or a trading window.

At that point, a dedicated Ethereum node gives you isolated CPU, memory, and disk, plus your own archive and trace configuration. It also removes the noisy-neighbor problem, where another tenant's traffic spike becomes your latency spike. See dedicated nodes for how that model works, and RPC pricing to compare tiers.

Failover and multi-provider strategy

Even a well-run provider can have a bad hour. Production apps should assume any single endpoint will occasionally fail and design for it.

A common pattern is a primary endpoint with one or two fallbacks, selected by health checks rather than hardcoded order:

// rpc-router.mjs — simple health-checked failover across endpoints
const pool = [
  "https://eth.api.onfinality.io/public",
  // fallback endpoints
];

async function healthy(url) {
  try {
    const res = await fetch(url, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "eth_blockNumber", params: [] }),
      signal: AbortSignal.timeout(2000),
    });
    const json = await res.json();
    return !json.error;
  } catch {
    return false;
  }
}

export async function send(payload) {
  for (const url of pool) {
    if (!(await healthy(url))) continue;
    const res = await fetch(url, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(payload),
    });
    if (res.ok) return res.json();
  }
  throw new Error("all Ethereum RPC endpoints failed");
}

Keep the fallback list short and tested. An untested fallback is worse than none, because it fails exactly when you need it.

Common failure modes and what they usually mean

When an Ethereum RPC call misbehaves, the error often points at configuration rather than the provider.

Symptom	Likely cause	Next step
`method not found`	Endpoint does not expose that method (often trace_*)	Confirm method support with the provider
`429` or rate-limit errors	Shared tier request cap exceeded	Reduce burst size or move to a higher tier
`missing trie node`	Query hit non-archive state	Use an archive endpoint for historical reads
`nonce too low`	Local nonce tracking out of sync	Re-read eth_getTransactionCount with pending
WebSocket drops	Idle timeout or unstable connection	Add reconnect logic and heartbeat pings
Slow eth_getLogs	Wide block range on shared capacity	Narrow ranges or use a dedicated node

If you are debugging transaction-level issues like nonce errors, the nonce explainer walks through the mechanics.

Key Takeaways

An Ethereum RPC node provider runs the nodes; you consume JSON-RPC over HTTP or WebSocket. The delivery model (public, managed, dedicated) matters more than the brand.
Match the provider to your workload. Reads, log queries, transaction broadcasts, and trace calls stress different parts of a node.
Ethereum mainnet uses chain ID 1, ETH as the native currency, and supports both HTTP and WebSocket transports.
Test providers against your real methods, especially eth_getLogs and any trace_* calls, before migrating production traffic.
Plan for failover. A primary endpoint plus tested fallbacks is standard practice for production apps.
Move to a dedicated node when you hit rate limits, need archive or trace access, or require predictable throughput. See supported RPC networks and RPC pricing for options.

Frequently Asked Questions

What is the difference between an Ethereum RPC provider and a node provider?

In practice they overlap. A node provider runs the Ethereum clients; an RPC provider exposes them over JSON-RPC. Most managed services do both, so the terms are often used interchangeably.

Do I need an archive node for Ethereum?

Only if you query historical state or logs beyond the recent window. Wallets and simple dapps usually do not. Indexers, analytics tools, and bridges often do.

Can I use a public Ethereum RPC endpoint in production?

Public endpoints are shared and rate-limited, so they are best for testing. Production apps generally use a managed RPC API or a dedicated node for predictable behavior.

Does OnFinality support Ethereum WebSocket subscriptions?

Ethereum on OnFinality supports HTTP and WebSocket transports. Check the Ethereum network page for current endpoint details and plan options.

How do I switch providers without rewriting my app?

Because Ethereum JSON-RPC is standardized, you usually only change the endpoint URL and API key. Keep your RPC URL in configuration, not hardcoded, so migration is a config change rather than a code change.

When should I move from shared RPC to a dedicated node?

When you consistently hit rate limits, need archive or trace methods, or require stable throughput for launches and trading windows. Dedicated nodes isolate your capacity from other tenants.

Related resources

Originally published at OnFinality.

Binance Beacon Chain Explorer: What It Was and What to Use Now

OnFinality — Tue, 15 Sep 2026 02:20:54 +0000

What the Binance Beacon Chain explorer actually showed

The Binance Beacon Chain was the proof-of-stake consensus layer that ran alongside BNB Smart Chain (BSC). It handled staking, validator registration, delegation, and governance for the BNB Chain ecosystem. Its explorer was the web interface where you could look up:

Validators and their voting power — who was producing blocks and how much BNB was bonded to each validator.
Delegations — which addresses delegated stake to which validators, and the reward history that followed.
Cross-chain events — transfers and messages between the Beacon Chain and BNB Smart Chain.
Governance proposals — on-chain votes and their outcomes.

If you searched for a "Binance Beacon Chain explorer," you were probably trying to answer one of three questions: where did my staking rewards go, which validator should I delegate to, or how do I pull this data programmatically. The first two are historical lookups. The third is where RPC infrastructure comes in, and it is the part that still matters for developers today.

Decision guide: explorer lookup vs. RPC query

Before you spend time wiring up an endpoint, decide what you actually need. Explorers are for humans reading a page; RPC is for software that needs to read state on demand.

What you need	Best tool	Why
Read a validator's delegation history	Historical explorer / archive data	Explorers index and format this for reading
Confirm a transaction status by hash	BNB Smart Chain explorer or RPC	`eth_getTransactionReceipt` returns the raw result
Build a staking dashboard	RPC + indexer	You need programmatic, repeatable queries
Monitor validator uptime	RPC + monitoring	Polling endpoints beats refreshing a web page
Debug a failed contract call	RPC with trace support	Explorers rarely expose full traces
One-off balance check	Public RPC endpoint	Fastest path, no setup

If your answer lands in the bottom half of that table, keep reading — the rest of this page is about querying BNB Chain data through RPC instead of clicking through an explorer.

Why the Beacon Chain explorer is no longer the main entry point

The BNB Chain ecosystem consolidated its architecture, and the Beacon Chain's role was folded into the broader BNB Chain stack. That means:

New development happens on BNB Smart Chain. Contracts, tokens, and most dApps live there, and that is where RPC traffic goes.
Staking data still exists, but it is accessed differently. Historical staking records may still be available through archives and indexers, but they are not the primary workflow for most builders.
Explorers and RPC serve different audiences. An explorer is a read-only UI. An RPC endpoint is a programmable interface that your backend, wallet, or bot calls directly.

So the practical question is no longer "which Beacon Chain explorer should I open" — it is "which BNB Smart Chain endpoint should my app talk to."

BNB Smart Chain RPC settings at a glance

If you are moving from explorer lookups to programmatic queries, these are the values you need. They match the BNB Smart Chain mainnet configuration used by OnFinality.

Setting	Value
Chain name	BNB Smart Chain Mainnet
Chain ID	56
Native currency	BNB (18 decimals)
Block explorer	https://bscscan.com
Public RPC endpoint	https://bnb.api.onfinality.io/public
Transport	HTTP and WebSocket

For testnet work, BNB Chain Testnet uses chain ID 97, the tBNB native token, the explorer at https://testnet.bscscan.com, and the public endpoint https://bnb-testnet.api.onfinality.io/public. You can find both on the BNB Chain network page and the BNB Chain Testnet page.

Querying BNB Chain data with JSON-RPC

Once you have an endpoint, the explorer's job becomes a set of method calls. Here is a quick curl example that fetches the latest block number:

curl -X POST https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_blockNumber",
    "params": [],
    "id": 1
  }'

To check a transaction that you previously found in an explorer, use the hash:

curl -X POST https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_getTransactionReceipt",
    "params": ["0xYOUR_TX_HASH"],
    "id": 1
  }'

In JavaScript with ethers, the same lookup looks like this:

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider("https://bnb.api.onfinality.io/public");

async function checkTx(hash) {
  const receipt = await provider.getTransactionReceipt(hash);
  if (!receipt) {
    console.log("Pending or unknown transaction");
    return;
  }
  console.log("Status:", receipt.status === 1 ? "success" : "reverted");
  console.log("Block:", receipt.blockNumber);
}

checkTx("0xYOUR_TX_HASH");

For live updates — useful if you are replacing a manual explorer refresh with a dashboard — subscribe over WebSocket:

const ws = new WebSocket("wss://bnb.api.onfinality.io/public");

ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "eth_subscribe",
    params: ["newHeads"]
  }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  if (data.params?.result?.number) {
    console.log("New block:", parseInt(data.params.result.number, 16));
  }
};

WebSocket support depends on the endpoint and plan you use. Confirm transport availability on the BNB Chain network page before you build around it.

When a public endpoint is enough — and when it is not

A public RPC endpoint is the fastest way to replace an explorer lookup with a script. It works well for:

Prototyping and one-off queries.
Low-volume wallets or internal tools.
Reading balances, blocks, and receipts at a modest rate.

It becomes a bottleneck when you need:

High request volume from a backend or bot.
Archive data for historical state, such as balances at an old block.
Trace and debug methods for failed transactions.
Consistent WebSocket subscriptions for real-time features.

At that point, the choice is between managing your own BNB node or using managed infrastructure. Running your own node means handling sync, disk growth, upgrades, and monitoring. A managed RPC API or dedicated node removes that operational load and gives you a stable endpoint your team can rely on. OnFinality provides both RPC API access and dedicated node options for BNB Chain, so you can start on a shared endpoint and move to dedicated capacity as traffic grows.

Common pitfalls when moving off explorer lookups

Explorers hide a lot of complexity. When you switch to RPC, a few things trip people up:

Assuming every endpoint is an archive node. Historical eth_getBalance calls at an old block fail on non-archive nodes. Check archive support before you depend on it.
Ignoring rate limits on public endpoints. A script that hammers a shared endpoint will get throttled. Plan for a paid tier or dedicated node if your volume is real.
Forgetting chain ID checks. Wallets and tools need chain ID 56 for mainnet and 97 for testnet. Mixing them up sends transactions to the wrong network.
Treating a receipt as final too early. A transaction can be included and later reorged. Wait for a few confirmations before you mark something settled.
Hardcoding one endpoint. If your only endpoint goes down, your app goes down. Keep a fallback and monitor both.

Production readiness checklist

If you are replacing explorer-driven workflows with RPC in a live product, run through this before launch:

Check	What to confirm
Endpoint redundancy	At least one fallback endpoint configured
Archive access	Confirmed if you query historical state
WebSocket plan	Subscriptions tested under load, not just locally
Chain ID guard	Mainnet (56) vs. testnet (97) enforced in config
Monitoring	Alerts on error rate and block lag
Rate strategy	Volume mapped to a plan that fits, not a public endpoint
Key management	API keys stored in secrets, not in client code

A simple monitoring probe can catch most issues early:

#!/bin/bash
# Poll block height and alert if it stalls
HEIGHT=$(curl -s -X POST https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  | grep -o '"result":"[^"]*"' | cut -d'"' -f4)

echo "Current block: $((HEIGHT))"
# Compare against a previous value and alert on stagnation

Where OnFinality fits

OnFinality runs RPC API endpoints and dedicated nodes for BNB Chain and many other networks. For teams moving away from explorer-based workflows, that means you get a stable endpoint, archive and trace options where supported, and the ability to scale from a shared API to dedicated infrastructure without changing your application code. You can review RPC pricing to match a plan to your workload, and browse supported RPC networks if you also build on chains beyond BNB. If you are still deciding between providers, the RPC provider selection guide walks through the evaluation criteria.

Key Takeaways

The Binance Beacon Chain explorer was a UI for staking, validators, and governance data on the BNB Chain consensus layer.
BNB Chain development now centers on BNB Smart Chain, where RPC endpoints are the primary programmatic interface.
Chain ID 56 (mainnet) and 97 (testnet) are the values you need for wallet and app configuration.
Public endpoints are fine for prototyping; production workloads usually need archive access, WebSocket support, and redundancy.
OnFinality offers RPC API and dedicated node infrastructure for BNB Chain, with plans you can match to your traffic.

Frequently Asked Questions

Is the Binance Beacon Chain explorer still available?

The Beacon Chain's role changed as BNB Chain consolidated its architecture. Historical staking data may still be reachable through archives and indexers, but new development targets BNB Smart Chain. For current data, use a BNB Smart Chain explorer or an RPC endpoint.

What is the difference between an explorer and an RPC endpoint?

An explorer is a read-only website for humans. An RPC endpoint is a programmable interface that your code calls to read state, send transactions, and subscribe to events. Explorers are good for one-off lookups; RPC is what you build on.

Which chain ID should I use for BNB Smart Chain?

Use chain ID 56 for BNB Smart Chain mainnet and chain ID 97 for BNB Chain Testnet. The native currency is BNB on mainnet and tBNB on testnet.

Can I query historical staking data over RPC?

Some historical state is available if the endpoint supports archive queries, but staking-specific data may require an indexer rather than a standard JSON-RPC call. Confirm archive support with your provider before relying on it.

Do I need a dedicated node for a small project?

Not always. A public or shared RPC endpoint is often enough for low-volume apps. Move to a dedicated node when you need consistent throughput, archive access, or isolation from other users' traffic.

How do I avoid downtime if my RPC endpoint fails?

Configure at least one fallback endpoint, monitor error rates and block lag, and keep your provider's status information handy. Redundancy at the application layer is the simplest protection.

Related resources

Originally published at OnFinality.

Solana RPC Providers With Dedicated Nodes: How to Evaluate

OnFinality — Tue, 15 Sep 2026 02:20:21 +0000

Solana RPC is not a generic EVM endpoint. The chain produces blocks continuously, account state changes constantly, and many applications depend on WebSocket subscriptions rather than one-off reads. That combination means a shared public endpoint can work for a prototype but often stops being the right fit once you have real users, background indexers, or trading logic. A dedicated Solana node changes the economics: you get isolated resources for your own traffic instead of sharing a pool with other tenants.

This article focuses on how to evaluate providers that offer dedicated Solana nodes, not on listing a single winner. The right provider depends on your workload shape, your tolerance for operational work, and how much control you need over the node itself.

When a dedicated Solana node is the right fit

Before comparing providers, decide whether you actually need a dedicated node. A dedicated node is usually justified when one or more of these is true:

Your application sends a high and predictable volume of requests, and shared rate limits are the bottleneck.
You rely on WebSocket subscriptions such as accountSubscribe, logsSubscribe, or programSubscribe and need stable connection behavior.
You run indexers, backfill jobs, or analytics that scan large ranges of history.
You need consistent behavior during network congestion, when shared endpoints may throttle or degrade.
You want a private endpoint that is not exposed to the public internet and can be allowlisted.

A dedicated node is usually not the first step if you are still validating an idea, running a low-traffic dApp, or only reading occasional account balances. In those cases a managed shared RPC API is cheaper and simpler. OnFinality offers both models, so you can start on a shared RPC API and move to a dedicated node when the workload justifies it.

What "dedicated" actually means across providers

The word "dedicated" is used loosely. Two providers can both advertise dedicated Solana nodes and deliver very different things. Ask what is actually isolated:

Layer	Shared RPC API	Dedicated node
Compute and memory	Shared across tenants	Reserved for your workload
Request throughput	Pooled limits	Sized to your plan
WebSocket connections	Shared gateway	Direct to your node
Endpoint visibility	Public or keyed URL	Private, often allowlisted
Node version control	Provider-managed	Provider-managed, sometimes configurable
Failure blast radius	Affects all tenants	Limited to your node

A genuinely dedicated Solana node should give you your own process and your own connection budget. If a provider only gives you a private URL that still routes through a shared backend, you are buying a private label, not isolation.

Provider evaluation matrix for Solana dedicated nodes

Use this matrix to compare providers on the dimensions that matter for Solana specifically. Fill it in per provider rather than relying on marketing pages.

Evaluation area	What to verify	Why it matters on Solana
Node type	Full vs archive, and whether historical state is available	Backfills and analytics need older slots
Method coverage	Support for `getProgramAccounts`, `getSignaturesForAddress`, `getTransaction` with full encoding	Many apps depend on these for indexing
WebSocket support	`accountSubscribe`, `logsSubscribe`, `programSubscribe`, `slotSubscribe`	Real-time features break without stable subscriptions
Transport	HTTP and WebSocket endpoints, TLS, private networking options	Different clients need different transports
Rate and connection limits	Requests per second, concurrent connections, subscription caps	Determines whether the plan fits your traffic
Failover	Whether you can run a second node or endpoint for redundancy	Single points of failure are a production risk
Observability	Metrics, logs, and alerting exposed to you	You cannot operate what you cannot see
Support model	Response channels and escalation path	Node issues need fast human response
Migration path	How endpoint changes are rolled out	Avoids downtime during cutover

OnFinality appears first here because it offers both a managed Solana RPC API and dedicated node infrastructure, so you can evaluate the same vendor across both models. Compare other providers against the same rows rather than against a feature list.

Solana-specific methods and limits to test

Solana's JSON-RPC surface is broad, and some methods are far more expensive than others. Before you commit to a provider, test the methods your application actually uses. A minimal connectivity check looks like this:

curl -s https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getLatestBlockhash",
    "params": [{"commitment": "confirmed"}]
  }'

For a dedicated node, repeat the same call against your private endpoint and then test the heavier methods:

curl -s "$SOLANA_DEDICATED_ENDPOINT" \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "getSignaturesForAddress",
    "params": ["<ACCOUNT_PUBKEY>", {"limit": 100}]
  }'

Pay attention to how the provider handles getProgramAccounts with filters, since this method can be expensive and is often rate-limited differently from simple reads. Also confirm whether transaction responses include full metadata or only signatures, because indexers usually need the full form.

WebSocket behavior is where many providers differ

Real-time Solana applications often depend on subscriptions more than on HTTP calls. Test WebSocket behavior explicitly:

import WebSocket from "ws";

const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");

ws.on("open", () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "logsSubscribe",
    params: [{ mentions: ["<PROGRAM_ID>"] }, { commitment: "confirmed" }]
  }));
});

ws.on("message", (data) => {
  const msg = JSON.parse(data.toString());
  if (msg.method === "logsNotification") {
    console.log("slot", msg.params.result.context.slot);
  }
});

Things to check with any provider:

Does the connection stay open under load, or does it drop and require reconnection logic?
Are subscription limits per connection or per account?
Is there a documented reconnection and replay strategy?
How are missed slots or gaps surfaced to the client?

If a provider cannot answer these clearly, treat that as a risk for any real-time feature.

Migration checkpoints before you cut over

Moving from a shared endpoint to a dedicated Solana node is a configuration change, but it touches every client. Plan the cutover:

Inventory every place an RPC URL is configured, including frontend wallets, backend services, cron jobs, and CI.
Add the new endpoint alongside the old one so both are reachable during the transition.
Run a shadow period where a non-critical service reads from the dedicated node and you compare responses.
Verify commitment levels match between environments, since processed, confirmed, and finalized behave differently.
Update WebSocket clients and confirm reconnection logic works against the new endpoint.
Keep the old endpoint available as a fallback until you are confident in the new one.

A simple environment-based configuration keeps this manageable:

const SOLANA_RPC =
  process.env.SOLANA_RPC_URL ?? "https://solana.api.onfinality.io/public";

const SOLANA_WS =
  process.env.SOLANA_WS_URL ?? "wss://solana.api.onfinality.io/public-ws";

For wallet or app network configuration, keep the chain identity consistent with Solana mainnet: native currency SOL with 9 decimals, and the explorer at https://explorer.solana.com. If you are testing first, use Solana Devnet and keep devnet and mainnet configuration separate.

Cost and operations tradeoffs

Dedicated nodes shift cost from per-request pricing toward reserved capacity. That is usually favorable when your traffic is steady and high, and less favorable when it is spiky or low. Consider:

Reserved capacity is predictable but you pay for it even during quiet periods.
Shared RPC APIs scale down to zero cost when idle, which suits early-stage projects.
Running your own Solana node gives maximum control but adds significant operational work: hardware, upgrades, monitoring, and incident response.
A managed dedicated node sits between those extremes: you get isolation without owning the full operations burden.

For most teams, the practical sequence is shared RPC API first, then a dedicated node once traffic and reliability requirements are clear. Review RPC pricing to compare models, and check supported RPC networks if you also need other chains.

Operational checklist after go-live

Once the dedicated node is serving production traffic, keep these in place:

Monitor request latency, error rates, and WebSocket connection counts.
Alert on slot lag so you notice when the node falls behind the cluster.
Track subscription churn to catch clients that reconnect too often.
Keep a documented fallback endpoint and test it periodically.
Review node version and upgrade windows with your provider.

A lightweight monitoring probe can catch regressions early:

#!/usr/bin/env bash
set -euo pipefail

RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" "$SOLANA_DEDICATED_ENDPOINT" \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}')

echo "solana rpc http status: $RESPONSE"

Key Takeaways

A dedicated Solana node is justified by steady high traffic, WebSocket dependence, indexing workloads, or a need for private endpoints.
"Dedicated" varies by provider; verify what is actually isolated before comparing prices.
Test Solana-specific methods such as getProgramAccounts and getSignaturesForAddress, not just simple reads.
WebSocket subscription behavior is often the deciding factor for real-time apps.
Plan migration with a shadow period and a fallback endpoint rather than a hard cutover.
OnFinality offers both a Solana RPC API and dedicated node infrastructure, so you can match the model to your workload.

Frequently Asked Questions

Do I need a dedicated Solana node for a small dApp?

Usually not. A managed shared RPC API is a better starting point until traffic, WebSocket usage, or reliability requirements justify reserved capacity.

What is the difference between a dedicated node and a private RPC endpoint?

A private endpoint can still route through shared backend infrastructure. A dedicated node gives your workload its own compute and connection budget, which is what actually reduces contention.

Which Solana methods should I benchmark before choosing a provider?

Test the methods your app depends on, especially getProgramAccounts, getSignaturesForAddress, getTransaction, and any subscription methods used by your real-time features.

Can I use the same endpoint for HTTP and WebSocket?

No. Solana uses separate HTTP and WebSocket URLs. OnFinality exposes both, and you should configure each transport explicitly in your clients.

How do I avoid downtime when migrating to a dedicated node?

Run the new endpoint alongside the old one, shadow traffic from a non-critical service, verify commitment levels and WebSocket behavior, then cut over with a fallback still in place.

Where can I see which networks OnFinality supports?

See supported RPC networks for the current list, and RPC pricing for plan details.

Related resources

Originally published at OnFinality.

Base Node RPC: Endpoint, Chain ID & Debugging

OnFinality — Tue, 15 Sep 2026 02:19:48 +0000

Base is an Ethereum Layer 2 built on the OP Stack, which means its node RPC interface is deliberately familiar: standard JSON-RPC over HTTP, the same eth_* method names you already use on Ethereum, and a small set of OP-Stack-specific methods on top. If you are wiring up a wallet, a backend indexer, or a test suite, you mostly need the right chain settings, a working endpoint, and a clear debugging path when a request fails.

This page is a working reference for Base node RPC. It covers the settings you paste into a wallet, how to send a request with curl and with viem, what to check when a call fails, and how to decide between a public endpoint and a dedicated Base node.

Chain settings at a glance

Before you write any code, confirm the network parameters. Base mainnet and Base Sepolia are separate networks with different chain IDs, so a wallet or SDK pointed at the wrong one will look like it is working while returning the wrong data.

Setting	Base mainnet	Base Sepolia
Chain ID	8453	84532
Native currency	ETH (18 decimals)	ETH (18 decimals)
Block explorer	https://basescan.org	https://sepolia.basescan.org
RPC transport	HTTP (JSON-RPC)	HTTP (JSON-RPC)
Typical use	Production apps, real value	Development, testing, faucets

A quick sanity check: call eth_chainId and confirm it returns 0x2105 for mainnet (8453 in decimal) or 0x14a34 for Sepolia (84532). If the value does not match the network you intended, stop and fix the configuration before debugging anything else.

Adding Base to a wallet

Most wallets accept a custom network. The fields map directly to the table above:

Network name: Base
RPC URL: your Base endpoint
Chain ID: 8453
Currency symbol: ETH
Block explorer: https://basescan.org

For Base Sepolia, use chain ID 84532 and the Sepolia explorer. If you are building a wallet connection flow, you can request the network programmatically instead of asking users to type it in:

await window.ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    chainId: "0x2105",
    chainName: "Base",
    nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
    rpcUrls: ["https://base.api.onfinality.io/public"],
    blockExplorerUrls: ["https://basescan.org"]
  }]
});

If you are using OnFinality for Base, the public endpoint is https://base.api.onfinality.io/public and the Base Sepolia equivalent is https://base-sepolia.api.onfinality.io/public. For production traffic, a dedicated Base node gives you a private endpoint you can rotate without touching user configuration. See the Base network page and Base Sepolia network page for current details.

Sending your first Base RPC request

The fastest way to confirm an endpoint works is a single curl call. This checks connectivity, chain ID, and the latest block in one shot:

curl -s https://base.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -s https://base.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

A healthy response returns a JSON object with a result field. If you get an error object instead, the error.code and error.message tell you whether the problem is the request, the endpoint, or the network.

In application code, the same call looks like this with viem:

import { createPublicClient, http } from "viem";
import { base } from "viem/chains";

const client = createPublicClient({
  chain: base,
  transport: http("https://base.api.onfinality.io/public")
});

const blockNumber = await client.getBlockNumber();
const chainId = await client.getChainId();
console.log({ chainId, blockNumber });

Because Base follows Ethereum conventions, most Ethereum tooling works without a Base-specific adapter. The main differences are chain ID, explorer URLs, and a handful of OP-Stack methods.

Which Base RPC methods matter in practice

You do not need every method. Most applications lean on a small set, and knowing which ones are heavier helps you plan capacity.

Method	What it does	Notes for Base
`eth_chainId`	Returns the chain ID	Use to verify you are on 8453 or 84532
`eth_blockNumber`	Latest block height	Cheap, good for health checks
`eth_getBalance`	Account balance	Common in wallet flows
`eth_call`	Read-only contract call	Core of most dapp reads
`eth_getLogs`	Query event logs	Heaviest common method; scope by block range
`eth_getTransactionReceipt`	Transaction status	Poll after sending a tx
`eth_estimateGas`	Gas estimate	Run before sending
`eth_sendRawTransaction`	Broadcast a signed tx	Returns a tx hash, not a receipt

eth_getLogs deserves special attention. Wide block ranges and broad topic filters can return large payloads and are a frequent cause of timeouts. Narrow the range, filter by address, and paginate where possible.

Debug path for common Base RPC failures

When something breaks, the error message usually points at the layer. Work through this table before assuming the endpoint is down.

Symptom	Likely cause	First check
`chainId` mismatch	Wrong network configured	Call `eth_chainId`, compare to 8453/84532
`method not found`	Typo or unsupported method	Confirm method name and endpoint transport
Timeout on `eth_getLogs`	Block range too wide	Reduce range, add address filter
`nonce too low`	Stale nonce after a stuck tx	Re-read `eth_getTransactionCount` with `pending`
`insufficient funds`	Gas or value exceeds balance	Check balance and gas estimate
Empty `result` on a read	Contract not deployed on this network	Verify address on the correct explorer
Intermittent 429	Shared endpoint rate limits	Move heavy reads to a dedicated node

Two patterns cause most confusion. First, mixing mainnet and testnet data: a contract address that exists on Base mainnet will not exist on Base Sepolia, and vice versa. Second, treating eth_sendRawTransaction as final: it returns a hash immediately, but you must poll eth_getTransactionReceipt to know whether the transaction succeeded.

Public endpoint or dedicated Base node?

This is the decision most teams face once an app moves past prototyping. The right answer depends on your workload shape, not on a single benchmark.

Workload	Public endpoint	Dedicated Base node
Prototypes and demos	Usually fine	Not needed yet
Low-volume reads	Usually fine	Optional
Heavy `eth_getLogs` indexing	Risky under load	Recommended
High-frequency trading or bots	Shared limits apply	Recommended
Compliance or data isolation needs	Not suitable	Recommended
Predictable production traffic	Shared capacity	Recommended

A useful rule: if your application's reliability depends on a specific request pattern that a shared endpoint cannot guarantee, isolate that pattern onto a dedicated node and leave everything else on the public endpoint. This keeps cost proportional to actual need. OnFinality offers both shared RPC API access and dedicated Base nodes; see RPC pricing for the current options and supported RPC networks for the full list.

WebSocket and subscription considerations

Base supports JSON-RPC over HTTP, which is what most applications use. If you need push-style updates, check whether your provider exposes WebSocket transport for Base before designing around subscriptions. HTTP polling of eth_blockNumber or eth_getTransactionReceipt is a reliable fallback and is easier to reason about under failure.

If you do use subscriptions, plan for reconnection logic. Long-lived connections drop, and a subscription that silently stops delivering events is worse than one that fails loudly. Treat the connection as something that will need to be re-established.

Operational checklist before launch

Before you point production traffic at any Base endpoint, confirm the following:

Chain ID is verified at runtime, not just in config.
The endpoint is reachable from your deployment environment, not only from your laptop.
Heavy methods such as eth_getLogs are scoped and paginated.
You have a fallback endpoint or a plan for one.
Errors are logged with the JSON-RPC error code, not just a generic message.
You know which network each contract address belongs to.

A simple monitoring probe keeps you ahead of problems:

async function probe(endpoint) {
  const res = await fetch(endpoint, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "eth_blockNumber", params: [] })
  });
  const json = await res.json();
  return { ok: res.ok && !!json.result, block: json.result };
}

Run this on a schedule and alert on repeated failures. It is a small amount of code that catches a large class of incidents early.

Key Takeaways

Base uses standard Ethereum JSON-RPC; chain ID 8453 for mainnet and 84532 for Sepolia.
Verify eth_chainId at runtime to avoid silently querying the wrong network.
eth_getLogs is the most common source of timeouts; scope block ranges and filters.
eth_sendRawTransaction returns a hash, not a receipt; poll for the receipt to confirm success.
Public endpoints suit prototypes and light reads; dedicated Base nodes suit heavy, predictable, or isolated workloads.
OnFinality provides Base RPC API access and dedicated nodes; check RPC pricing and supported networks.

Frequently Asked Questions

What is the Base chain ID?
Base mainnet uses chain ID 8453. Base Sepolia uses 84532. Always confirm with eth_chainId at runtime.

What is the Base RPC endpoint?
Any JSON-RPC endpoint that serves the Base network. OnFinality exposes a public Base endpoint and dedicated options; see the Base network page for current details.

Can I use Ethereum tooling with Base?
Yes. Base follows Ethereum conventions, so most Ethereum libraries and wallets work once you set the correct chain ID and endpoint.

Why does my Base transaction show as pending?
eth_sendRawTransaction returns a hash before the transaction is included. Poll eth_getTransactionReceipt until it returns a receipt, and check gas settings if it stalls.

Do I need a dedicated Base node?
Only if your workload needs private capacity, isolation, or predictable behavior under heavy reads. Prototypes and light apps usually do not.

How do I debug a Base RPC timeout?
Start with the method. eth_getLogs with a wide range is the usual culprit; narrow the range and add filters before investigating the endpoint itself.

Related resources

Originally published at OnFinality.

Base L2 on Ethereum: RPC Setup and Connection Guide

OnFinality — Tue, 15 Sep 2026 02:19:15 +0000

Base is an Ethereum Layer 2 network. It executes transactions on its own chain and posts the resulting data back to Ethereum, which is where the term "L2 on Ethereum" comes from. For developers, the practical consequence is simple: Base speaks the same JSON-RPC dialect as Ethereum, so most tools, libraries, and contracts work with only a chain ID and RPC URL change.

This page answers the immediate question, then helps you decide how to connect. If you already know what Base is and just need settings, jump to the chain settings table. If you are evaluating how to run Base in production, the decision section below is the place to start.

Quick recommendation: which connection path fits your workload

Not every project needs the same Base setup. Use the table below to match your situation to a connection approach. The right answer depends on request volume, whether you need archive or trace data, and how much operational work you want to own.

Your situation	Suggested approach	What to watch
Prototyping, scripts, low-volume reads	Public Base endpoint	Shared capacity; fine for testing, not for traffic spikes
Production dApp with steady traffic	Managed RPC API	Rate limits, failover, and monitoring matter
Heavy indexing, archive, or trace calls	Dedicated node	Storage and sync time are your responsibility
Compliance or data-residency needs	Dedicated node	You control the deployment environment
Multi-chain app including Base	Managed multi-chain RPC	Consistent tooling across chains reduces bugs

If you are unsure, start with a managed endpoint and move to a dedicated node only when you can name the specific limit you are hitting. OnFinality provides both RPC API access and dedicated node infrastructure, so you can scale the same Base workload without changing your application code.

What Base actually is, in one paragraph

Base is a Layer 2 built on the OP Stack. It batches transactions, executes them off Ethereum mainnet, and posts compressed data back to Ethereum for settlement and data availability. Users pay fees in ETH on Base, and the network exposes an EVM-compatible interface. That means eth_call, eth_getLogs, eth_sendRawTransaction, and the rest of the standard Ethereum JSON-RPC method set behave as you expect.

The important nuance for developers is that Base is not Ethereum. It has its own chain ID, its own block explorer, and its own gas market. Contracts deployed to Ethereum mainnet are not automatically available on Base; you deploy them separately. Addresses can match if you use the same deployer and nonce, but that is a convenience, not a guarantee.

Chain settings at a glance

Use these values when adding Base to a wallet, a Hardhat config, a Foundry profile, or a viem client.

Setting	Base mainnet	Base Sepolia testnet
Chain ID	8453	84532
Native currency	ETH (18 decimals)	ETH (18 decimals)
Block explorer	https://basescan.org	https://sepolia.basescan.org
Transport	HTTP	HTTP
OnFinality public RPC	https://base.api.onfinality.io/public	https://base-sepolia.api.onfinality.io/public

For a full network reference, see the Base network page and the Base Sepolia network page.

Connecting with curl and JavaScript

The fastest way to confirm your endpoint works is a single JSON-RPC call. This returns the current block number:

curl -X POST https://base.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

A successful response looks like {"jsonrpc":"2.0","id":1,"result":"0x..."}. If you get an error object instead, check the URL, the method name, and whether your client is sending a POST with a JSON body.

In JavaScript, the same call through viem looks like this:

import { createPublicClient, http } from 'viem';
import { base } from 'viem/chains';

const client = createPublicClient({
  chain: base,
  transport: http('https://base.api.onfinality.io/public'),
});

const blockNumber = await client.getBlockNumber();
console.log(blockNumber);

If you are using ethers, the pattern is similar: create a JsonRpcProvider with the Base RPC URL and call getBlockNumber(). The chain ID is validated by the library when you pass the chain object, which catches misconfigured endpoints early.

Wallet and network configuration

Adding Base to a wallet is a common first step for testers and support teams. The fields map directly to the chain settings table above. In MetaMask, choose "Add network manually" and enter the chain ID, RPC URL, and explorer URL. For Base Sepolia, use chain ID 84532 and the Sepolia explorer.

A frequent mistake is mixing mainnet and testnet values. If your wallet shows a balance of zero after a successful faucet claim, confirm you are on the testnet chain ID and that the faucet sent funds to the same address the wallet is displaying. Faucet availability changes over time, so check the current Base documentation rather than relying on a cached link.

Where Base fits in an Ethereum stack

Base is one of several L2s that share Ethereum tooling. If your application already supports Ethereum mainnet, adding Base is mostly a configuration change. The harder questions are operational: how do you handle reorgs, how do you index logs efficiently, and how do you keep latency predictable under load.

For teams running multiple chains, a consistent RPC layer matters more than any single chain's quirks. OnFinality supports Base alongside Ethereum and other networks, so you can use one provider and one set of credentials across your stack. See supported RPC networks for the current list.

Production readiness checklist

Before you point real users at a Base endpoint, work through these items. They are ordered by how often they cause incidents.

Failover. Do you have a second endpoint configured? A single URL is a single point of failure.
Rate limits. Do you know your requests per second ceiling, and does your client back off on 429 responses?
Archive and trace needs. Do you call eth_getLogs over wide block ranges, or use trace methods? These are heavier and may need a dedicated node.
Reorg handling. Base, like other L2s, can reorg. Your indexer should confirm finality before treating data as settled.
Monitoring. Do you alert on error rate and latency, not just on total downtime?
Key management. Are RPC credentials stored outside your source tree?

If several of these are unanswered, a managed provider removes most of the operational burden. If you need control over the node itself, a dedicated node gives you that at the cost of running the infrastructure.

Common failure modes and how to read them

Most Base RPC problems fall into a small number of categories. The table below maps symptoms to likely causes.

Symptom	Likely cause	Next step
`method not found`	Method not supported by the endpoint	Confirm the method is part of the standard EVM set
`429 Too Many Requests`	Rate limit reached	Add backoff and consider a higher tier
Timeouts on `eth_getLogs`	Block range too wide	Narrow the range or use an indexer
Wrong chain data	Endpoint points to a different network	Verify chain ID with `eth_chainId`
Stale block number	Caching or a lagging node	Compare against a second endpoint

A quick diagnostic is to call eth_chainId and compare the result to the expected value. For Base mainnet it should return 0x2105 (8453 in decimal). For Base Sepolia it should return 0x14a34 (84532). If those do not match, you are talking to the wrong network.

Choosing between public, managed, and dedicated

The public endpoint is a good default for development and low-volume reads. It is shared, so it is not the right choice for production traffic that needs predictable latency.

A managed RPC API sits in the middle. You get a stable URL, monitoring, and the ability to scale without running nodes. This is the common choice for dApps, wallets, and backends that need Base plus a few other chains.

A dedicated node is for teams that need archive data, trace calls, custom configuration, or a specific deployment environment. The tradeoff is that you own sync time, storage, and upgrades. For most teams, the decision comes down to whether the workload justifies that ownership. OnFinality's RPC pricing page outlines the options if you want to compare cost models.

Key Takeaways

Base is an Ethereum L2 with an EVM-compatible JSON-RPC interface, so Ethereum tooling works with a chain ID and URL change.
Base mainnet uses chain ID 8453; Base Sepolia uses 84532.
The OnFinality public endpoints are https://base.api.onfinality.io/public and https://base-sepolia.api.onfinality.io/public.
Public endpoints suit development; production workloads usually need managed or dedicated infrastructure.
Always verify chain ID with eth_chainId when debugging unexpected data.
Plan for failover, rate limits, and reorg handling before launch.

Frequently Asked Questions

Is Base the same as Ethereum?
No. Base is a separate Layer 2 network that settles to Ethereum. It uses Ethereum tooling and ETH as its native currency, but it has its own chain ID and block explorer.

What is the Base chain ID?
Base mainnet is 8453. Base Sepolia is 84532.

Can I use Ethereum RPC methods on Base?
Yes. Standard EVM JSON-RPC methods such as eth_call, eth_getLogs, and eth_sendRawTransaction work on Base. Some Ethereum-specific methods may not apply.

Do I need a dedicated node for Base?
Only if you need archive data, trace calls, custom configuration, or a specific deployment environment. Most applications do fine with a managed endpoint.

How do I test Base without spending real ETH?
Use Base Sepolia and a faucet. Confirm you are on chain ID 84532 and that the faucet sent funds to your wallet address.

Where can I find OnFinality's Base endpoints?
See the Base network page and the Base Sepolia network page. For pricing and plan details, visit RPC pricing.

Related resources

Originally published at OnFinality.

Solana Devnet RPC: Endpoint, Faucet & Debugging

OnFinality — Tue, 15 Sep 2026 02:18:43 +0000

Solana devnet is a separate cluster from mainnet-beta and testnet. It runs the same runtime as mainnet, but the ledger is disposable, tokens have no value, and the network is explicitly allowed to reset. That makes it the right place to deploy a program, run integration tests, and reproduce bugs before you ship.

The query "solana rpc devnet" usually comes from a developer who needs one of three things: a working endpoint URL, test SOL to pay for transactions, or a way to diagnose a failing request. This page answers all three, then explains when a public devnet endpoint stops being enough.

Which devnet endpoint should you use?

Pick your endpoint based on what you are doing, not on habit. Most developers start on a public endpoint and move to a managed or dedicated one when tests become part of a pipeline.

Your situation	Sensible endpoint choice	Why
Learning Solana, running a few scripts	Public devnet RPC	Free, no setup, fine for low request volume
Deploying a program and iterating	Public devnet RPC or a managed RPC plan	You need reliable `sendTransaction` and `getSignatureStatuses`
CI pipeline running on every commit	Managed RPC with a dedicated API key	Predictable access and per-project keys
Load or latency testing	Dedicated node	You control the machine and can measure without noisy neighbours
Testing WebSocket-driven UI	Endpoint that supports `ws`	Subscriptions behave differently from polling

If you only need to read accounts and send occasional transactions, a public devnet endpoint is fine. If your tests fail intermittently and you cannot tell whether the cause is your code or the endpoint, that is the signal to move to a managed service.

OnFinality exposes Solana devnet as a supported network alongside Solana mainnet. You can review the Solana Devnet network page for connection details, and compare plans on the RPC pricing page if you need a keyed endpoint for CI.

Solana devnet chain settings at a glance

When you configure a wallet, an SDK, or a framework, you are choosing a cluster and an RPC URL. Solana does not use an EVM-style numeric chain ID for devnet in the same way Ethereum does; the cluster identity is what matters.

Setting	Devnet value
Cluster name	`devnet`
Native currency	SOL (devnet, no value)
Decimals	9
Typical RPC transport	HTTP JSON-RPC
Subscription transport	WebSocket (`ws`) where supported
Block explorer	Solana Explorer with the devnet cluster selected
Mainnet equivalent	`mainnet-beta`

Keep devnet and mainnet configuration in separate files or environment variables. A large share of "it worked locally" incidents come from a build that silently pointed at the wrong cluster.

Connecting with curl and JavaScript

A minimal JSON-RPC call confirms the endpoint is reachable and returns the current slot.

curl https://your-devnet-endpoint.example \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getSlot",
    "params": []
  }'

In JavaScript, the common pattern is to create a connection object and pass the cluster or an explicit endpoint.

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

// Option A: use the built-in devnet cluster URL
const connection = new Connection(clusterApiUrl("devnet"), "confirmed");

// Option B: use your own managed devnet endpoint
// const connection = new Connection(process.env.SOLANA_DEVNET_RPC, "confirmed");

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

const balance = await connection.getBalance(connection.publicKey ?? undefined);

For WebSocket subscriptions, construct the connection with the ws endpoint and use onAccountChange or onLogs:

const wsConnection = new Connection(process.env.SOLANA_DEVNET_WS, {
  commitment: "confirmed",
  wsEndpoint: process.env.SOLANA_DEVNET_WS,
});

const subId = wsConnection.onLogs(programId, (logs) => {
  console.log(logs.signature, logs.logs);
});

If subscriptions drop silently, log the subscription id and re-subscribe on error rather than assuming the endpoint is broken.

Getting test SOL from the devnet faucet

The faucet is rate limited and shared. Treat it as a convenience, not a guarantee.

Request a small amount first and confirm the balance before running a large test.
If a request fails, wait and retry rather than hammering the endpoint.
For repeatable tests, fund a known keypair once and reuse it, or run a local validator where you can mint SOL freely.
Never reuse a devnet keypair on mainnet. Generate a fresh keypair for anything that holds real value.

When a faucet request appears to succeed but the balance does not change, check the transaction signature on the explorer and confirm you are querying the same cluster you requested from.

Common devnet failures and how to read them

Most devnet errors fall into a small number of categories. The table below maps the symptom to the likely cause.

Symptom	Likely cause	First thing to check
`AccountNotFound`	Account not yet created, or wrong cluster	Confirm cluster and that the account was initialised
`Blockhash not found`	Blockhash expired before send	Fetch a fresh blockhash and retry quickly
Transaction confirmed but state unchanged	Wrong program id or stale client	Re-check the program id and redeploy if needed
`429` or throttling	Public endpoint rate limit	Reduce request rate or move to a keyed endpoint
WebSocket stops delivering	Idle timeout or network drop	Add reconnect logic and re-subscribe
Slot jumps or data resets	Devnet ledger reset	Recreate accounts and re-run setup

Devnet resets are normal. If your tests depend on pre-existing state, build a setup step that recreates it rather than assuming it persists.

When a public devnet endpoint is not enough

Public endpoints are shared, and devnet traffic is unpredictable. Two things tend to push teams toward managed infrastructure.

First, CI. If every commit triggers a test suite that sends transactions, you want a stable endpoint with its own credentials so one noisy job does not affect another. Second, observability. When a test fails, you need to know whether the request reached the node, what the node returned, and how long it took. A managed RPC service gives you per-key usage and clearer error responses.

OnFinality provides RPC API access and dedicated node options across many networks, including Solana. If your devnet usage is light, the shared service is usually sufficient. If you are running sustained load or need isolation, a dedicated node removes the noisy-neighbour problem. You can see the full list of supported chains on the supported RPC networks page.

A practical devnet workflow

A repeatable workflow saves more time than any single optimisation.

Keep cluster configuration in environment variables, never hard-coded.
Run a local validator for unit tests where you control the ledger.
Use devnet for integration tests that need realistic network conditions.
Fund a dedicated test keypair and reuse it across runs.
Log request ids, signatures, and slot numbers so failures are reproducible.
Add a health check that calls getSlot before a test suite starts.
Move to a keyed managed endpoint once tests run in CI.

This sequence keeps the cheap, fast feedback loop local and reserves network access for the cases that actually need it.

Key Takeaways

Solana devnet is a separate cluster with no-value SOL, used for testing programs and clients before mainnet.
The cluster name is devnet; keep it in environment variables and never mix it with mainnet-beta.
The devnet faucet is rate limited, so fund a reusable test keypair instead of requesting repeatedly.
Most devnet errors are blockhash expiry, wrong cluster, or rate limiting, not node faults.
Devnet resets are expected; build setup steps that recreate state.
Move from a public endpoint to a managed or dedicated RPC service when tests run in CI or need isolation.

Frequently Asked Questions

What is the Solana devnet RPC URL?

There is no single canonical URL. You can use the cluster URL provided by your SDK, or a managed endpoint from a provider. OnFinality lists Solana devnet as a supported network; see the Solana Devnet network page for connection details.

Is Solana devnet the same as testnet?

No. Devnet and testnet are separate clusters. Devnet is the more commonly used testing environment and is more likely to be reset. Always confirm which cluster your endpoint points to.

Why does my devnet transaction fail with "blockhash not found"?

The blockhash expired before the transaction was processed. Fetch a fresh blockhash immediately before sending and retry. On a busy or throttled endpoint this happens more often.

Can I use a public devnet endpoint in production?

Devnet is for testing, not production. For production workloads you should use mainnet with a managed or dedicated RPC service. See RPC pricing for plan options.

Does OnFinality support Solana devnet?

Yes. Solana devnet is listed among OnFinality's supported networks. Check the Solana Devnet network page and the RPC API service page for current details.

How do I test WebSocket subscriptions on devnet?

Use a ws endpoint, subscribe with onLogs or onAccountChange, and add reconnect logic. Public endpoints may drop idle connections, so handle re-subscription explicitly.

Related resources

Originally published at OnFinality.

Gnosis API: Chain Settings, Methods, and Endpoint Setup

OnFinality — Tue, 15 Sep 2026 02:18:09 +0000

The Gnosis API is the JSON-RPC surface that Gnosis Chain nodes expose to applications. If you are wiring a wallet, a Safe-based treasury tool, a payments backend, or an indexer to Gnosis, this is the interface you call. This page gives you the chain settings, a working request, the methods that matter for typical Gnosis workloads, and a way to decide what kind of endpoint you actually need.

Which Gnosis endpoint fits your workload?

Before copying any URL, match the endpoint type to what your application does. Gnosis traffic is often a mix of light reads and heavier log queries, and the right choice depends on volume and consistency needs rather than on the chain itself.

Workload	Typical calls	Endpoint fit
Wallet balance display	`eth_getBalance`, `eth_call`	Shared or public endpoint is usually enough
Safe transaction service backend	`eth_call`, `eth_getTransactionReceipt`, `eth_getLogs`	Managed endpoint with predictable throughput
Payments or payroll service	`eth_sendRawTransaction`, receipt polling	Managed endpoint plus a fallback URL
Indexer or analytics pipeline	Wide `eth_getLogs` ranges, archive state	Dedicated node or archive-capable endpoint
Bridge or oracle relayer	WebSocket subscriptions, frequent reads	Dedicated node with stable connections

If your calls are occasional and read-only, a shared endpoint is a reasonable starting point. If you poll receipts in a loop, scan logs across large block ranges, or need consistent response times under load, plan for a managed or dedicated setup. You can review RPC pricing and the Gnosis network page to see what is available before you commit.

Gnosis Chain settings at a glance

These are the values you enter into a wallet, a Hardhat or Foundry config, or an ethers/viem provider. They are stable and safe to hardcode in client configuration.

Setting	Value
Network name	Gnosis
Chain ID	100
Native currency	xDAI (XDAI), 18 decimals
Block explorer	https://gnosisscan.io
Transport	HTTP JSON-RPC
Public endpoint	https://gnosis.api.onfinality.io/public

Gnosis uses xDAI as its gas token, which is a meaningful difference from chains that pay gas in a volatile asset. For payment and payroll use cases this keeps fee accounting simpler, but it also means your users need xDAI on hand before they can send transactions.

Wallet network configuration

Most EVM wallets accept a custom network entry. The fields map directly to the table above:

{
  "chainId": "0x64",
  "chainName": "Gnosis",
  "nativeCurrency": { "name": "xDAI", "symbol": "XDAI", "decimals": 18 },
  "rpcUrls": ["https://gnosis.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://gnosisscan.io"]
}

Note that 0x64 is the hexadecimal form of chain ID 100. Wallets that expect hex will reject the decimal value, so keep both forms handy when debugging connection errors.

Making your first Gnosis API request

Every Gnosis API call is a JSON-RPC POST. The shape is the same as any EVM chain, so existing tooling works without modification once the endpoint and chain ID are set.

curl -s https://gnosis.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_blockNumber",
    "params": []
  }'

A successful response returns the latest block height as a hex string. From there, the common next calls are eth_getBalance for xDAI balances, eth_call for contract reads, and eth_getLogs for event history.

In JavaScript, the same request through a provider library looks like this:

import { JsonRpcProvider, formatEther } from "ethers";

const provider = new JsonRpcProvider(
  "https://gnosis.api.onfinality.io/public",
  { chainId: 100, name: "gnosis" }
);

const block = await provider.getBlockNumber();
const balance = await provider.getBalance("0xYourAddressHere");
console.log(block, formatEther(balance));

Passing the chain ID explicitly helps libraries detect a mismatch early instead of silently querying the wrong network.

Methods that matter for Gnosis workloads

Gnosis is EVM-compatible, so the standard method set applies. In practice, a few methods carry most of the traffic:

eth_call — read contract state without a transaction. This is the backbone of Safe balance checks, token metadata reads, and most dashboard queries.
eth_getLogs — retrieve events. Log queries are the most common source of rate pressure because a single request can span thousands of blocks.
eth_getTransactionReceipt — confirm whether a submitted transaction landed. Payment services poll this heavily.
eth_sendRawTransaction — broadcast signed transactions. This is where endpoint reliability matters most, since a dropped broadcast can leave a user waiting.
eth_estimateGas and eth_gasPrice — size transactions and set fees before signing.
eth_getCode and eth_getStorageAt — inspect deployed contracts and raw state, useful for tooling and debugging.

If you rely on live event streams rather than polling, check whether your chosen endpoint supports WebSocket subscriptions such as eth_subscribe for new heads or logs. Not every shared endpoint exposes WebSocket transport, so confirm this before designing around subscriptions.

Debugging common Gnosis API failures

Most Gnosis API problems fall into a small number of categories. The fastest path is to match the symptom to the cause before changing anything else.

Symptom	Likely cause	Next step
`-32602` invalid params	Wrong parameter shape or missing block tag	Compare the request against the method spec
`-32000` or timeout on `eth_getLogs`	Block range too wide for the endpoint	Split the range and paginate
Transaction stuck as pending	Broadcast accepted but not mined, or fee too low	Re-check gas price and re-broadcast if needed
Balance looks wrong	Querying the wrong chain ID	Confirm chain ID 100 and the endpoint host
Intermittent 429 responses	Request rate above the shared endpoint budget	Add backoff, batch calls, or move to a dedicated node
WebSocket disconnects	Idle connection dropped	Add reconnect logic with resubscribe

A useful first diagnostic is a single eth_chainId call. If it does not return 0x64, your client is pointed at the wrong network and nothing downstream will behave as expected.

curl -s https://gnosis.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

When a shared endpoint is not enough

Shared public endpoints are convenient and fine for development, prototypes, and low-volume reads. They become a bottleneck when your application depends on consistent throughput or long-running queries.

The signals that you have outgrown a shared endpoint are usually operational rather than dramatic: log queries that need to be split into many smaller calls, receipt polling that occasionally times out, or a spike in 429 responses during peak hours. At that point the question is not whether Gnosis works, but whether your access pattern needs reserved capacity.

A dedicated node gives your application its own Gnosis node rather than a slice of a shared pool. That matters for indexers scanning wide log ranges, relayers that need stable WebSocket connections, and services that cannot tolerate another tenant's traffic affecting their response times. OnFinality provides both managed RPC API access and dedicated node infrastructure, so you can start on a shared endpoint and move to reserved capacity without changing your application code beyond the URL. See dedicated nodes for how that transition works.

Operational checklist before you ship

A short checklist catches most production issues before users do:

Confirm chain ID 100 in your provider config, not just in the URL.
Add a fallback endpoint so a single provider outage does not take your app down.
Batch independent reads where your library supports it, rather than firing them sequentially.
Cap eth_getLogs block ranges and paginate instead of requesting everything at once.
Add exponential backoff for 429 and 5xx responses.
Log the raw JSON-RPC error code alongside your application error, so you can tell a client bug from an endpoint limit.
For WebSocket use, implement reconnect and resubscribe rather than assuming a persistent connection.

If you are still deciding between endpoint types, the RPC provider selection guide walks through the evaluation criteria in more depth, and supported RPC networks shows where Gnosis sits alongside the rest of the catalog.

Key Takeaways

The Gnosis API is standard EVM JSON-RPC, so existing ethers, viem, Hardhat, and Foundry tooling works once chain ID 100 is set.
Gnosis pays gas in xDAI, which simplifies fee accounting but requires users to hold xDAI before transacting.
eth_call, eth_getLogs, and eth_getTransactionReceipt drive most Gnosis traffic; log queries are the usual source of rate pressure.
A shared endpoint is fine for development and light reads; dedicated nodes make sense for indexers, relayers, and high-volume backends.
Always verify eth_chainId returns 0x64 when debugging unexpected behavior.

Frequently Asked Questions

Is the Gnosis API the same as the Ethereum API?

At the protocol level, yes. Gnosis is EVM-compatible, so it uses the same JSON-RPC method names and request format. The differences are the chain ID (100), the gas token (xDAI), and the specific contracts and state on the network.

What is the Gnosis Chain ID?

Gnosis Chain uses chain ID 100, which is 0x64 in hexadecimal. Wallets and libraries that expect hex will reject the decimal form.

Do I need an API key to use the Gnosis API?

It depends on the endpoint. Public endpoints are typically open and rate-limited, while managed and dedicated endpoints use an API key tied to your account so your traffic gets its own capacity and support path.

Can I use WebSockets with Gnosis?

Gnosis supports WebSocket subscriptions at the node level, but not every shared endpoint exposes WebSocket transport. Confirm availability with your provider before designing around eth_subscribe.

Why do my `eth_getLogs` calls fail on Gnosis?

Large block ranges are the most common cause. Split the range into smaller windows and paginate through results rather than requesting a wide span in one call.

How do I move from a public endpoint to a dedicated Gnosis node?

In most cases you change the endpoint URL and add your API key. Application logic stays the same because the JSON-RPC interface does not change. Review RPC pricing and the Gnosis network page to plan the move.

Related resources

Originally published at OnFinality.

ETH Public RPC: Endpoint, Chain Settings & When to Switch

OnFinality — Tue, 15 Sep 2026 02:17:36 +0000

When a public ETH RPC is the right starting point

A public RPC is the fastest way to get an Ethereum app talking to the chain. You paste a URL into your wallet, script, or framework config, and you can read balances, fetch blocks, and send transactions without provisioning anything. For a hackathon prototype, a one-off script, or a wallet you are configuring for the first time, that is exactly the right tradeoff.

The decision to stay on a public endpoint is really a question about workload shape. If your requests are occasional, tolerant of retries, and never depend on subscriptions, a shared public RPC can carry you a long way. If your app serves real users, indexes history, or listens for events, the shared tier will become the bottleneck.

Use this quick guide to decide where you are today:

Your situation	Public RPC fit	What to do next
Learning JSON-RPC, testing a wallet	Good	Use a public endpoint, keep request volume low
Local scripts, CI smoke tests	Acceptable	Add retries and a fallback URL
dApp with live users	Poor	Move to a managed RPC plan
Indexer, analytics, or archive queries	Poor	Use an archive-capable endpoint
Bots, event listeners, WebSocket subscriptions	Poor	Use a dedicated or managed node with WS

If you are in the bottom three rows, the rest of this page explains the migration. If you are in the top two, read on for the endpoint details and debugging steps.

Ethereum chain settings at a glance

Before you debug anything, confirm you are pointed at the right network. Ethereum mainnet and Sepolia share the same JSON-RPC method set but have different chain IDs, and mixing them up is one of the most common causes of "wrong network" errors.

Setting	Ethereum mainnet	Ethereum Sepolia
Chain ID	1	11155111
Chain name	Ethereum Mainnet	Ethereum Sepolia
Native currency	ETH (18 decimals)	Sepolia Ether (18 decimals)
Block explorer	https://etherscan.io	https://sepolia.etherscan.io
OnFinality public RPC	https://eth.api.onfinality.io/public	https://eth-sepolia.api.onfinality.io/public
Transport	HTTP, WebSocket	HTTP, WebSocket

OnFinality exposes public endpoints for both networks, so you can develop against Sepolia and switch to mainnet by changing a single URL and chain ID. For network-specific details, see the Ethereum Sepolia network page and the full supported RPC networks list.

Connecting a wallet or framework

Most wallets and libraries accept a custom RPC URL plus a chain ID. A minimal wallet network configuration looks like this:

{
  "chainId": "0x1",
  "chainName": "Ethereum Mainnet",
  "nativeCurrency": { "name": "Ether", "symbol": "ETH", "decimals": 18 },
  "rpcUrls": ["https://eth.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://etherscan.io"]
}

For Sepolia, change chainId to 0xaa36a7 (11155111 in decimal) and swap the RPC URL to the Sepolia endpoint. In JavaScript, the same config works with ethers or viem:

import { createPublicClient, http } from 'viem';
import { mainnet } from 'viem/chains';

const client = createPublicClient({
  chain: mainnet,
  transport: http('https://eth.api.onfinality.io/public')
});

const blockNumber = await client.getBlockNumber();
console.log('Latest block:', blockNumber);

If you prefer raw JSON-RPC, a single curl call confirms the endpoint is reachable and returning the chain you expect:

curl -s https://eth.api.onfinality.io/public \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

The response should be {"jsonrpc":"2.0","id":1,"result":"0x1"}. If you get a different chain ID, you are on the wrong network. If you get an empty result or an HTTP error, the endpoint is unreachable or rate limited.

Debug path: what each failure actually means

Public endpoints fail in a small number of predictable ways. Match the symptom to the cause before you change anything.

Symptom	Likely cause	Fix
`429 Too Many Requests`	Shared rate limit exceeded	Back off, batch requests, or move to a managed plan
`-32005` or "limit exceeded"	Per-method or per-IP quota	Reduce polling frequency, cache results
Empty `result` for old blocks	No archive data on the shared tier	Use an archive-capable endpoint
WebSocket disconnects	Idle timeout or shared connection limits	Reconnect with backoff or use a dedicated node
`eth_getLogs` timeouts	Wide block ranges on shared capacity	Narrow the range or paginate
Wrong chain ID	Mainnet/Sepolia mismatch	Correct the URL and chain ID

A useful habit is to log the HTTP status and JSON-RPC error code together. A 429 is a capacity signal, while a -32601 (method not found) is a capability signal. They point to different fixes.

Where public endpoints stop scaling

Shared public RPCs are designed for broad, low-intensity access. Three workload patterns break that model quickly:

High-frequency polling. Wallets and dashboards that poll eth_blockNumber or eth_getBalance every second will hit shared limits fast. Batch or cache instead.
Historical and archive queries. Reading state at an old block requires an archive node. Most public endpoints serve recent state only.
Event-driven apps. WebSocket subscriptions (eth_subscribe) need a stable, long-lived connection. Shared endpoints often cap concurrent sockets or drop idle ones.

If any of these describe your app, the public tier is a prototyping tool, not a production dependency. The next section covers what to evaluate when you move.

Evaluating a managed or dedicated ETH RPC

When you outgrow the public endpoint, you are choosing between a managed RPC plan and a dedicated node. Both remove the shared-capacity problem; they differ in control, cost model, and operational burden.

Provider option	Best for	Archive / trace	WebSocket	Operational load
OnFinality RPC API	Teams that want managed Ethereum endpoints with predictable capacity	Available on request	Supported	Low — managed for you
OnFinality dedicated nodes	High-volume or compliance-sensitive workloads needing isolated capacity	Configurable	Supported	Low — OnFinality operates the node
Self-hosted node	Teams with strict data-residency or custom fork needs	Full control	Full control	High — you run and upgrade it
Other shared providers	Low-cost, low-volume apps	Varies	Often limited	Low

OnFinality is listed first because it is the option this site operates: managed RPC endpoints plus dedicated node infrastructure for teams that need isolated capacity. Compare plans on the RPC pricing page, or review dedicated nodes if you need a private node rather than a shared endpoint.

When you evaluate any provider, ask four questions:

Capacity model: Is throughput shared or reserved? What happens during a traffic spike?
Method coverage: Are debug_ and trace_ methods available, and is archive data included?
Transport: Is WebSocket supported for subscriptions, and how are idle connections handled?
Failover: Can you configure a secondary endpoint, and how do you detect a degraded primary?

These questions matter more than headline latency numbers, because they determine whether your app stays up under load.

Migration checkpoints

Moving from a public endpoint to a managed one is mostly a configuration change, but a few checkpoints prevent surprises:

Inventory your methods. List every JSON-RPC method your app calls, including eth_getLogs, eth_call, and any debug_ or trace_ usage. Confirm the new endpoint supports all of them.
Separate read and write paths. Reads can often use a shared endpoint; writes and subscriptions benefit from a dedicated connection.
Add a fallback. Configure a secondary RPC URL so a single endpoint failure does not take down your app.
Re-test on Sepolia first. Validate the new endpoint against Sepolia before switching mainnet traffic.
Monitor after cutover. Track error rates, 429 counts, and WebSocket reconnects for the first few days.

A simple monitoring probe keeps you honest:

async function probe(url) {
  const start = Date.now();
  const res = await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'eth_blockNumber', params: [] })
  });
  return { ok: res.ok, status: res.status, ms: Date.now() - start };
}

Run this against both your primary and fallback endpoints on a schedule, and alert when either degrades.

Key Takeaways

An ETH public RPC is a shared, unauthenticated endpoint — great for prototyping, weak for production.
Always confirm chain ID: 0x1 for mainnet, 0xaa36a7 for Sepolia.
429 errors mean capacity; empty archive results mean missing history; WebSocket drops mean connection limits.
Move to a managed or dedicated endpoint when you poll frequently, need archive data, or rely on subscriptions.
Evaluate providers on capacity model, method coverage, transport, and failover — not just latency.
OnFinality offers managed Ethereum RPC and dedicated nodes; see RPC pricing and supported networks.

Frequently Asked Questions

Is a public ETH RPC safe to use in production?

It can work for low-volume, read-only traffic with retries and a fallback. For user-facing apps, high-frequency polling, archive queries, or WebSocket subscriptions, a managed or dedicated endpoint is the more reliable choice.

What is the chain ID for Ethereum mainnet and Sepolia?

Ethereum mainnet uses chain ID 1 (0x1). Sepolia uses chain ID 11155111 (0xaa36a7). Setting the wrong one is a common cause of "wrong network" errors.

Why does my public RPC return empty results for old blocks?

Most public endpoints serve recent state only. Reading historical state requires an archive node, which is typically available on managed or dedicated plans.

Can I use WebSocket subscriptions on a public RPC?

Some public endpoints expose WebSocket, but shared connection limits and idle timeouts make them unreliable for long-lived subscriptions. Use a managed or dedicated endpoint for event-driven apps.

How do I switch from a public RPC to OnFinality?

Change your RPC URL and chain ID in your wallet or framework config, confirm method coverage, add a fallback endpoint, and test on Sepolia before moving mainnet traffic. See RPC pricing for plan details.

Related resources

Originally published at OnFinality.

Triton One Solana RPC: Evaluation Checklist for Production

OnFinality — Mon, 14 Sep 2026 01:55:13 +0000

What people actually mean by "Triton One Solana RPC"

Triton One is a Solana-focused RPC provider. When developers search for "triton one solana rpc," they are usually trying to answer one of three questions: what endpoint do I point my app at, how does it behave under load, and is it the right long-term choice compared with other Solana RPC options. Those are provider-selection questions, not just endpoint-lookup questions.

This article does not reproduce Triton One's documentation. Instead, it gives you a framework you can apply to any Solana RPC provider, including Triton One and OnFinality, so you can decide what to do next with evidence rather than marketing copy.

Solana RPC is not a single thing. A provider may offer a shared public endpoint, a paid shared tier, and a dedicated node. Each has different rate limits, method availability, and transport support. The name on the endpoint tells you very little about which of those you are actually getting.

Decide first: shared endpoint or dedicated node?

Before comparing providers, decide which class of service your workload needs. This is the single biggest fork in the road, and it determines which providers are even relevant.

Workload signal	Shared RPC endpoint is usually fine	Dedicated node is usually worth evaluating
Request volume	Low to moderate, bursty	Sustained high throughput
Method mix	Standard reads (getAccountInfo, getBalance, sendTransaction)	Heavy getProgramAccounts, getSignaturesForAddress, archive queries
WebSocket use	Occasional account or slot subscriptions	Many concurrent subscriptions, low-latency slot feeds
Latency sensitivity	Tolerant of variance	Trading bots, liquidators, indexers
Data depth	Recent state only	Historical or archive access
Team capacity	No node ops	Wants managed dedicated infrastructure

If most of your answers land in the right column, a shared endpoint from any provider will eventually become a bottleneck, and you should be comparing dedicated node offerings. If most land in the left column, a well-run shared endpoint is the pragmatic choice and you should focus on reliability and method coverage instead.

OnFinality offers both a Solana RPC API and dedicated nodes, so you can start on a shared endpoint and move to dedicated infrastructure without changing providers.

Solana endpoint settings at a glance

If you are wiring up a Solana endpoint, these are the values your wallet or app config needs. Use the official OnFinality public endpoint only as a starting point for testing; production apps should use an authenticated endpoint.

Setting	Value
Chain name	Solana Mainnet
Native currency	SOL (9 decimals)
HTTP RPC (public test)	https://solana.api.onfinality.io/public
WebSocket RPC (public test)	wss://solana.api.onfinality.io/public-ws
Block explorer	https://explorer.solana.com
Transports supported	HTTP, WebSocket

A minimal connection test with curl:

curl https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'

A healthy node returns a result object. If you get an error or a timeout, check the endpoint URL and your network egress before assuming the provider is down.

For wallet or app config, the same values apply. In a JavaScript client using the Solana web3 library:

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

const connection = new Connection(
  "https://solana.api.onfinality.io/public",
  "confirmed"
);

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

Swap the URL for your authenticated endpoint before shipping to production.

Which Solana methods and transports matter most

Not all Solana RPC methods are equal in cost. Some are cheap reads; others scan large state and are the first to be rate-limited on shared endpoints. When you evaluate Triton One or any provider, ask specifically about the methods you actually call.

Method	Typical cost profile	What to verify with the provider
getHealth, getSlot, getBlockHeight	Cheap	Always available, no special tier
getAccountInfo, getBalance	Cheap to moderate	Included in your plan
getTransaction, getSignaturesForAddress	Moderate	History depth and rate limits
getProgramAccounts	Expensive	Whether it is allowed and at what rate
sendTransaction	Moderate	Priority fee handling and retry behavior
WebSocket accountSubscribe, slotSubscribe	Persistent	Concurrent subscription limits

Two things trip teams up here. First, getProgramAccounts is often restricted or heavily throttled on shared endpoints because it can scan a large portion of state. Second, WebSocket subscriptions are persistent connections, and providers cap them differently from HTTP requests. If your app relies on either, confirm support before you migrate.

OnFinality's Solana endpoint supports both HTTP and WebSocket transports, which matters if you run real-time subscriptions alongside standard reads.

Testing an endpoint before you migrate

Do not migrate on the strength of a status page. Run a short, representative test against the candidate endpoint using your own traffic shape.

A simple latency and correctness probe you can run from your own infrastructure:

for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{time_total}s\n" \
    https://solana.api.onfinality.io/public \
    -X POST -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}'
done

What to look for:

Consistency, not just the best number. A tight distribution matters more than a single fast response.
Error rate under your real method mix, especially expensive calls.
WebSocket stability over several minutes, not a single message.
Behavior during Solana slot spikes, when the network is busiest.

Run the same probe against your current provider and the candidate. The comparison is the useful output, not the absolute numbers.

Failure modes to watch for on Solana RPC

Most Solana RPC problems fall into a small set of patterns. Recognizing them shortens debugging considerably.

Symptom	Likely cause	Next step
429 responses under load	Shared endpoint rate limit	Reduce request rate, batch calls, or move to a dedicated node
Timeouts on getProgramAccounts	Method throttled or disabled	Confirm method support with the provider
WebSocket disconnects	Subscription limit or idle timeout	Add reconnect logic; check concurrent subscription cap
Stale slot data	Node lagging behind the cluster	Compare getSlot against a second endpoint
sendTransaction dropped	Congestion or fee handling	Add priority fees and retry with fresh blockhash
Missing historical data	Endpoint not archive-enabled	Request archive access or a dedicated node

If you see 429s or timeouts only during peak Solana activity, that is a capacity signal, not a code bug. It usually means your workload has outgrown a shared endpoint.

How OnFinality fits into a Solana RPC evaluation

OnFinality provides RPC API access and dedicated node infrastructure across many networks, including Solana. For teams comparing Solana RPC providers, the relevant points are:

A managed Solana RPC API with HTTP and WebSocket support.
Dedicated nodes for workloads that need consistent capacity and isolation.
A single provider across multiple chains, which simplifies operations if you support more than Solana.
Transparent RPC pricing so you can model cost against your request profile.

This is not a claim that OnFinality is faster than Triton One in every scenario. The right choice depends on your method mix, latency needs, and whether you want shared or dedicated infrastructure. Use the evaluation framework above to compare both against your actual workload.

Migration checkpoints

If you decide to move from one Solana RPC provider to another, treat it as a controlled migration rather than a URL swap.

Inventory your methods. List every JSON-RPC method and WebSocket subscription your app uses.
Confirm support. Verify each method and subscription is available on the target endpoint.
Run parallel traffic. Send a percentage of read traffic to the new endpoint and compare results.
Add failover. Configure a secondary endpoint so a single provider outage does not take down your app.
Move writes last. Shift sendTransaction traffic only after reads are stable.
Monitor after cutover. Watch error rates, latency, and WebSocket reconnects for at least a full Solana activity cycle.

A simple failover pattern in JavaScript:

const endpoints = [
  "https://solana.api.onfinality.io/public",
  "https://your-secondary-endpoint.example"
];

async function withFailover(fn) {
  for (const url of endpoints) {
    try {
      return await fn(new Connection(url, "confirmed"));
    } catch (err) {
      console.warn("Endpoint failed, trying next:", url);
    }
  }
  throw new Error("All Solana RPC endpoints failed");
}

Failover is not a substitute for adequate capacity, but it prevents a single endpoint problem from becoming a full outage.

Key Takeaways

"Triton One Solana RPC" is a provider-selection question, not just an endpoint lookup.
Decide first whether you need a shared endpoint or a dedicated node; that determines which providers are relevant.
Verify support for expensive methods like getProgramAccounts and for WebSocket subscriptions before migrating.
Test candidate endpoints with your own traffic shape and compare distributions, not single numbers.
Plan a controlled migration with parallel traffic, failover, and post-cutover monitoring.
OnFinality offers both a Solana RPC API and dedicated nodes, with RPC pricing you can model against your workload.

Frequently Asked Questions

Is Triton One the same as a Solana RPC endpoint?

Triton One is a Solana-focused RPC provider. The endpoint you use depends on the plan you are on, so treat the provider name and the endpoint as separate things when you evaluate.

Can I use a public Solana RPC endpoint in production?

Public endpoints are useful for testing and low-volume use. Production apps generally need an authenticated endpoint with defined rate limits and support commitments.

Does OnFinality support Solana WebSocket subscriptions?

OnFinality's Solana endpoint supports HTTP and WebSocket transports. Confirm the specific subscriptions you need against your plan.

How do I know if I need a dedicated Solana node?

If you see repeated 429s, timeouts during peak activity, or you rely on expensive methods and many concurrent subscriptions, a dedicated node is worth evaluating.

What should I check before switching Solana RPC providers?

Inventory your methods and subscriptions, confirm support on the target endpoint, run parallel traffic, add failover, and monitor after cutover.

Related resources

Originally published at OnFinality.

Solana RPC Server: Endpoints, Config & Scaling

OnFinality — Mon, 14 Sep 2026 01:54:40 +0000

A Solana RPC server is the service your application talks to when it needs to read blockchain state or submit a transaction. Instead of running a validator or an RPC node yourself, you point your client at an HTTP endpoint (and usually a WebSocket endpoint) that speaks Solana's JSON-RPC dialect. Everything from a wallet balance check to a token swap starts with a request to that server.

This page is written for developers who already know they need a Solana RPC server and want to connect one correctly, then decide whether a shared endpoint is enough or whether a dedicated node is the better fit. If you are still comparing providers at a high level, start with how to choose an RPC provider and come back here for the Solana-specific configuration.

Choosing between public, managed, and dedicated Solana RPC

The fastest way to decide is to match your workload to the endpoint type. Most teams start on a public or shared endpoint, then move up when they hit a specific limit rather than a vague feeling that things are slow.

Your situation	Endpoint type that usually fits	What to watch for
Prototyping, scripts, low request volume	Public endpoint	Shared capacity, aggressive rate limits, no SLA
A production dApp with steady read traffic	Managed RPC API (shared, keyed)	Per-method limits, WebSocket connection caps
Indexers, bots, high `getProgramAccounts` use	Dedicated node	Memory and disk for account scans, archive needs
Trading or latency-sensitive submission	Dedicated node close to your infra	Slot lag, transaction landing rate, failover
Need historical state or full ledger	Archive-capable dedicated node	Storage growth, snapshot restore time

OnFinality provides Solana RPC through a managed RPC API service and through dedicated nodes when you need isolated capacity. The managed endpoint is the right starting point for most apps; dedicated nodes are for teams that have outgrown shared throughput or need predictable resources.

A quick rule of thumb: if your errors are mostly 429 responses, you need a keyed managed plan or a dedicated node. If your errors are timeouts on heavy calls like getProgramAccounts, you need more memory and a dedicated node rather than a bigger shared plan.

Solana RPC server settings at a glance

When you configure a wallet, a framework, or a backend service, you need the network parameters, not just the URL. For Solana mainnet these are the values to use.

Setting	Value
Chain name	Solana Mainnet
Native currency	SOL (9 decimals)
HTTP RPC URL	`https://solana.api.onfinality.io/public`
WebSocket RPC URL	`wss://solana.api.onfinality.io/public-ws`
Block explorer	`https://explorer.solana.com`
Transports supported	HTTP and WebSocket

For development and testing, use a devnet endpoint instead of mainnet so you are not spending real SOL. OnFinality exposes a separate Solana Devnet endpoint, and you can request devnet SOL from the standard Solana faucet to fund test transactions. Keep devnet and mainnet configuration in separate environment variables so a test key never points at mainnet by accident.

A common pattern is to store the endpoint in an environment variable and read it at startup:

SOLANA_RPC_URL=https://solana.api.onfinality.io/public
SOLANA_WS_URL=wss://solana.api.onfinality.io/public-ws

Connecting with curl and JavaScript

The simplest way to confirm a Solana RPC server is responding is a JSON-RPC call over HTTP. Solana uses the same JSON-RPC 2.0 envelope as other chains, but with Solana-specific methods.

curl https://solana.api.onfinality.io/public \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getLatestBlockhash",
    "params": [{"commitment": "confirmed"}]
  }'

A healthy response returns a result object containing a blockhash and lastValidBlockHeight. If you get an error object instead, the endpoint is reachable but the request was rejected, which usually points to a malformed method or parameter rather than a network problem.

In JavaScript, the @solana/web3.js library wraps these calls. Point the connection at your endpoint and pass a commitment level:

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

const connection = new Connection(
  process.env.SOLANA_RPC_URL,
  { commitment: "confirmed", wsEndpoint: process.env.SOLANA_WS_URL }
);

const balance = await connection.getBalance(
  new PublicKey("11111111111111111111111111111111")
);
console.log("lamports:", balance);

Commitment levels matter on Solana. processed is fastest but can be rolled back, confirmed is the common default for most apps, and finalized is the safest for settlement logic. Choose the level that matches the risk of the action, not the fastest one available.

WebSocket subscriptions and when to use them

Solana RPC servers also expose a WebSocket transport for push-based updates. Instead of polling getSlot or getAccountInfo in a loop, you subscribe and receive notifications when state changes.

const subId = connection.onAccountChange(
  new PublicKey("11111111111111111111111111111111"),
  (accountInfo, context) => {
    console.log("slot", context.slot, "lamports", accountInfo.lamports);
  },
  "confirmed"
);

WebSocket subscriptions are efficient, but they hold a connection open, and shared endpoints often cap concurrent subscriptions. If you run many subscriptions across many users, track your connection count and plan for reconnects. Subscriptions can drop during network congestion, so always handle the disconnect event and resubscribe rather than assuming the stream is permanent.

For high-frequency use, a dedicated node gives you a stable subscription budget and avoids competing with other tenants for notification delivery.

Common failure modes and how to read them

Most Solana RPC problems fall into a small set of symptoms. Matching the symptom to the cause saves a lot of guessing.

Symptom	Likely cause	First fix
HTTP `429` responses	Rate limit on a shared endpoint	Add a keyed plan or move to dedicated
Request timeouts on `getProgramAccounts`	Large account scan, memory pressure	Use filters, or move to a dedicated node
`Blockhash not found` on send	Blockhash expired before landing	Fetch a fresh blockhash and retry
Transaction lands slowly	Congestion or fee too low	Add priority fee, resubmit
WebSocket disconnects	Idle timeout or connection cap	Implement reconnect and resubscribe
Stale slot data	Node behind the tip	Check slot lag, consider a different node

Two of these deserve more detail. First, getProgramAccounts without filters is one of the heaviest calls on Solana. It can scan a large amount of account data, and on a shared endpoint it is often the first call to be throttled. Add data-size and memcmp filters to narrow the result set before you blame the endpoint.

Second, transaction landing is not just about the RPC server. Solana uses a blockhash that expires after a short window, so a transaction built with an old blockhash will fail even on a perfectly healthy endpoint. Fetch a fresh blockhash, set a reasonable priority fee, and retry with backoff.

Production readiness checklist

Before you send real traffic to a Solana RPC server, work through these items. They are the difference between a demo and something that survives a busy day.

Separate environments. Keep devnet and mainnet endpoints and keys in distinct configuration.
Set commitment levels deliberately. Use confirmed for most reads and finalized for settlement.
Handle rate limits. Detect 429 responses and back off instead of retrying immediately.
Plan for failover. Configure a secondary endpoint so a single outage does not take down your app.
Monitor slot lag. Track how far your node is behind the cluster tip.
Watch WebSocket health. Log disconnects and resubscription success.
Budget for heavy calls. Know which methods your app uses most and size accordingly.

If several of these items are already painful on a shared endpoint, that is the signal to evaluate a dedicated node. You can compare plans on the RPC pricing page and see the full list of supported RPC networks if you also operate on other chains.

Running your own Solana RPC server vs renting one

You can run a Solana RPC node yourself. The tradeoff is operational, not just financial. A Solana RPC node needs substantial RAM, fast NVMe storage, and ongoing attention to snapshots, upgrades, and monitoring. The ledger grows continuously, so storage planning is a recurring task, not a one-time setup.

Renting a managed endpoint or a dedicated node shifts that operational load to the provider. You still choose the region, the capacity, and the transport, but you are not patching the node or restoring snapshots at 2am. For most product teams, that is the better use of engineering time. For teams with strict data-locality or compliance requirements, self-hosting may still be the right call, and a hybrid approach (self-hosted primary, managed failover) is common.

OnFinality sits in the managed camp: you get a Solana RPC endpoint and, when needed, a dedicated node without running the infrastructure yourself. The Solana network page lists the current endpoint details and transports.

Migrating from a public endpoint without breaking things

Moving from a public Solana RPC server to a managed or dedicated one should be a configuration change, not a rewrite. The steps are straightforward if you prepare them.

Add the new endpoint alongside the old one. Do not delete the public URL yet.
Route a small percentage of traffic to the new endpoint and compare error rates and latency.
Update WebSocket configuration separately, since HTTP and WS endpoints are distinct.
Verify commitment levels behave the same on the new endpoint.
Switch the default once error rates are stable, keeping the old endpoint as failover.
Remove the public endpoint only after a full traffic cycle with no regressions.

Because Solana RPC is JSON-RPC over HTTP, the migration is usually a URL swap in your environment variables plus a redeploy. The risk is in the details: forgetting the WebSocket URL, or changing commitment levels at the same time as the endpoint, which makes it hard to tell what caused a change in behavior.

Key Takeaways

A Solana RPC server is the HTTP and WebSocket interface your app uses to read state and submit transactions.
Mainnet uses chain name Solana Mainnet, SOL with 9 decimals, and the explorer at explorer.solana.com.
Start on a shared or public endpoint, then move to a managed or dedicated node when you hit rate limits or heavy-call timeouts.
Commitment levels (processed, confirmed, finalized) should match the risk of each action.
WebSocket subscriptions are efficient but need reconnect and resubscription handling.
getProgramAccounts and expired blockhashes are two of the most common sources of confusion.
Migration is usually a configuration change, but update HTTP and WebSocket endpoints together.

Frequently Asked Questions

What is a Solana RPC server?

It is a service that exposes Solana's JSON-RPC API over HTTP and WebSocket, letting your application read accounts, submit transactions, and subscribe to events without running a node yourself.

What is the Solana RPC URL for mainnet?

OnFinality exposes Solana mainnet at https://solana.api.onfinality.io/public for HTTP and wss://solana.api.onfinality.io/public-ws for WebSocket. Always confirm current endpoints on the Solana network page.

Why am I getting 429 errors from my Solana RPC endpoint?

A 429 means you hit a rate limit, which is common on shared or public endpoints. A keyed managed plan or a dedicated node removes that shared ceiling.

Should I use HTTP or WebSocket for Solana?

Use HTTP for request-response calls and WebSocket for push updates such as account or slot changes. Most production apps use both.

Can I use a public Solana RPC endpoint in production?

You can, but public endpoints are shared and often rate limited. For steady production traffic, a managed or dedicated endpoint gives you more predictable behavior and a clear upgrade path.

How do I test without spending SOL?

Use a devnet endpoint and request devnet SOL from the faucet. Keep devnet configuration separate from mainnet so keys never cross over.

Related resources

Originally published at OnFinality.

solana.io: The Solana RPC Endpoint Developers Need

OnFinality — Mon, 14 Sep 2026 01:54:07 +0000

What solana.io is, and what it is not

If you typed solana.io into a browser or a config file expecting a Solana RPC endpoint, you have hit a naming collision. The domain solana.io is not the canonical Solana developer portal, and it is not a JSON-RPC endpoint you can POST requests to. The Solana network is accessed through RPC providers that expose HTTP and WebSocket endpoints, and the official developer documentation lives on the Solana docs site rather than a .io domain.

The practical takeaway: stop looking for solana.io as an endpoint. What you actually need is a Solana mainnet or devnet RPC URL, the right transport (HTTP for request/response, WebSocket for subscriptions), and a decision about whether a shared public endpoint is enough or whether your workload needs dedicated capacity.

This article answers that directly, then walks through connection settings, a working request, and the failure modes that show up when a Solana endpoint is not sized for your traffic.

Which Solana endpoint should you point at?

Before copying any URL, match the endpoint to the environment and the workload. The table below is the fastest way to decide.

Your situation	Environment	Transport	Recommended access
First script, learning JSON-RPC	Devnet	HTTP	Public devnet endpoint
Wallet or dApp testing	Devnet	HTTP + WebSocket	Public or shared endpoint
Production dApp reads	Mainnet	HTTP	Shared or dedicated RPC
Real-time account or slot updates	Mainnet	WebSocket	Endpoint with WS support
High request volume or indexing	Mainnet	HTTP + WebSocket	Dedicated node
Latency-sensitive trading or bots	Mainnet	HTTP + WebSocket	Dedicated node, co-located

Two rules keep you out of trouble. First, never point production traffic at a devnet endpoint, and never point tests at mainnet. Second, if your app opens WebSocket subscriptions, confirm the endpoint advertises WebSocket support before you ship.

OnFinality exposes Solana mainnet over both HTTP and WebSocket, so the same provider can cover request/response calls and subscription-based flows. You can review the network details on the Solana RPC network page, and use Solana Devnet while you are still building.

Solana chain settings at a glance

When you configure a wallet, a framework, or a custom client, these are the values that matter for Solana mainnet.

Setting	Value
Chain name	Solana Mainnet
Native currency	SOL (9 decimals)
HTTP RPC	`https://solana.api.onfinality.io/public`
WebSocket RPC	`wss://solana.api.onfinality.io/public-ws`
Block explorer	`https://explorer.solana.com`

Note that Solana does not use an EVM-style numeric chain ID in the same way Ethereum networks do. If a tool asks for a chain ID, check that tool's Solana-specific documentation rather than guessing a number.

For devnet work, keep your devnet and mainnet configuration in separate environment variables so a copy-paste mistake cannot send test transactions to mainnet.

# .env
SOLANA_MAINNET_RPC=https://solana.api.onfinality.io/public
SOLANA_MAINNET_WS=wss://solana.api.onfinality.io/public-ws
SOLANA_DEVNET_RPC=<your-devnet-endpoint>

A working Solana JSON-RPC request

Solana uses JSON-RPC over HTTP. The example below fetches the current slot, which is a lightweight way to confirm your endpoint is reachable and returning data.

curl https://solana.api.onfinality.io/public \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getSlot",
    "params": [{"commitment": "confirmed"}]
  }'

A healthy response looks like a JSON object with a result field containing a number. If you get an error object instead, jump to the debugging section below.

The same call in JavaScript with fetch:

const res = await fetch("https://solana.api.onfinality.io/public", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "getSlot",
    params: [{ commitment: "confirmed" }],
  }),
});

const data = await res.json();
console.log(data.result);

Once basic calls work, move to the methods your app actually needs: getAccountInfo for balances and account data, getTransaction for confirmation checks, sendTransaction for writes, and getProgramAccounts for program-scoped queries. getProgramAccounts is the method most likely to expose an underpowered endpoint because it can return large result sets.

Public endpoint or dedicated node?

This is the decision that determines whether your app stays responsive as usage grows. A public or shared endpoint is fine for development, low-volume scripts, and early testing. A dedicated node makes sense when your traffic is predictable but heavy, when you need consistent access to WebSocket subscriptions, or when you are running indexers and bots that issue many concurrent calls.

Signals that you have outgrown a shared endpoint:

You see intermittent 429 responses during peak hours.
WebSocket subscriptions drop and reconnect frequently.
getProgramAccounts or large getTransaction batches time out.
Your p95 latency varies widely across the day.
You need predictable capacity for a launch or a trading window.

If two or more of those apply, evaluate dedicated capacity. OnFinality offers dedicated nodes for teams that need isolated resources, and you can compare access tiers on the RPC pricing page. For a broader framework covering archive access, trace methods, and failover, see how to choose an RPC provider.

Debug path for common Solana RPC failures

When a call fails, the error usually points to one of a few causes. Work through this table before changing providers.

Symptom	Likely cause	Next step
`429 Too Many Requests`	Rate limiting on a shared endpoint	Reduce concurrency or move to dedicated capacity
`Method not found`	Method not enabled on that endpoint	Confirm method support with the provider
Timeout on `getProgramAccounts`	Large result set, endpoint limits	Add filters, paginate, or use a stronger endpoint
WebSocket disconnects	Subscription limits or network instability	Add reconnect logic, confirm WS support
`Blockhash not found`	Stale blockhash in a transaction	Fetch a fresh blockhash before signing
Empty `result` for an account	Wrong commitment level or account not yet created	Retry with `confirmed` or `finalized`

Two debugging habits pay off. First, log the raw JSON-RPC error object, not just the HTTP status, because Solana returns useful error codes in the body. Second, test the same call against a second endpoint to separate an application bug from an endpoint problem.

If you are chasing rate-limit and authentication issues specifically, the Solana RPC access article goes deeper on those failure modes.

Commitment levels and why they change results

Solana lets you choose how finalized a response must be. This affects both correctness and latency.

processed returns the fastest but least settled data.
confirmed is a common default for user-facing reads.
finalized is the safest for anything irreversible, such as crediting a deposit.

A frequent bug is reading a balance at processed and treating it as final. For anything that moves value, read at confirmed or finalized, and be explicit about the commitment in every call rather than relying on a default.

Running subscriptions over WebSocket

Real-time features such as watching an account or tracking slots need a WebSocket connection. Solana exposes subscription methods like accountSubscribe and slotSubscribe over the WebSocket transport.

const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");

ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "slotSubscribe",
    params: [],
  }));
};

ws.onmessage = (event) => {
  console.log(JSON.parse(event.data));
};

Production subscription code should include reconnect logic with backoff, a heartbeat to detect dead connections, and a cap on the number of simultaneous subscriptions per client. Dropped subscriptions that silently stop delivering updates are one of the hardest bugs to notice, so monitor message arrival rather than assuming the socket is healthy.

Key Takeaways

solana.io is not the Solana RPC endpoint or the official developer portal; use a real JSON-RPC URL instead.
Solana mainnet is reachable over HTTP at https://solana.api.onfinality.io/public and over WebSocket at wss://solana.api.onfinality.io/public-ws.
Match the endpoint to the environment: devnet for building, mainnet for production, and never mix the two.
Choose commitment levels deliberately; use confirmed or finalized for anything that moves value.
Move from shared to dedicated capacity when you see sustained 429s, dropped subscriptions, or timeouts on large queries.
Log raw JSON-RPC error bodies and test against a second endpoint to separate app bugs from endpoint limits.

Frequently Asked Questions

Is solana.io the official Solana RPC endpoint?

No. solana.io is not a JSON-RPC endpoint. Solana is accessed through RPC providers that expose HTTP and WebSocket URLs, and the official developer documentation lives on the Solana docs site.

What is the Solana mainnet RPC URL?

OnFinality exposes Solana mainnet over HTTP at https://solana.api.onfinality.io/public and over WebSocket at wss://solana.api.onfinality.io/public-ws. You can review the network on the Solana RPC network page.

Do I need a WebSocket endpoint for Solana?

Only if your app uses subscriptions such as accountSubscribe or slotSubscribe. If you only make request/response calls, HTTP is enough. If you need real-time updates, confirm the endpoint supports WebSocket before shipping.

When should I move off a public Solana endpoint?

When you see sustained rate-limit errors, dropped WebSocket subscriptions, or timeouts on large queries like getProgramAccounts. At that point, evaluate dedicated nodes and compare tiers on the RPC pricing page.

How do I test a Solana endpoint quickly?

Send a getSlot request with curl as shown above. A numeric result confirms the endpoint is reachable and responding; an error object tells you to check the method, commitment, or rate limits.

Where can I see all the networks OnFinality supports?

The full list is on the supported RPC networks page, including Solana mainnet and devnet.

Next steps

Start by pointing a test script at the Solana mainnet endpoint and confirming a getSlot response. Then add the methods your app needs, set explicit commitment levels, and add WebSocket reconnect logic if you use subscriptions. When your traffic grows past what a shared endpoint handles comfortably, review dedicated nodes and RPC pricing, and keep the supported RPC networks page handy as you expand to other chains.

Related resources

Originally published at OnFinality.