DEV Community: SwiftNodes

opBNB RPC: A Developer's Guide (Chain ID 204)

SwiftNodes — Tue, 29 Sep 2026 06:26:27 +0000

opBNB is BNB Chain's layer 2. It runs the OP Stack, the same software as Optimism and Base, with one structural difference: its layer 1 is BNB Smart Chain, not Ethereum. That one change explains most of what you will see over RPC. Blocks arrive every 250 milliseconds, finalized trails the head by well under a minute, and the L1 data fee is paid to BSC.

We measured it through our endpoint on 2026-09-29, and found one trap on the way that is worth the whole post: a public endpoint reporting a finalized block nearly four hours old.

The essentials

	opBNB mainnet
Chain ID	204 (`0xcc`)
Settles to	BNB Smart Chain
Gas token	BNB
Block time	250 ms (1,000 blocks in 250 s; 79 `newHeads` in 20 s)
Gas limit	100,000,000 per block
`eth_gasPrice`	0.001 gwei
`safe` / `finalized`	about 30 to 50 s behind `latest` on healthy nodes
`eth_getLogs` range	50,000 blocks at most (`exceed maximum block range: 50000`)
Recent state	about the last 100 blocks on full nodes
Tracing	`debug_traceBlockByNumber` and `eth_getBlockReceipts` yes; `trace_*` no
Node client	opBNB's `op-geth` (`Geth/v0.5.9-stable`)

It is EVM-equivalent. viem, ethers, Foundry and Hardhat work with the chain ID set to 204, and viem ships an opBNB chain definition.

Four blocks a second

At 250 ms per block, habits from Ethereum stop scaling:

Polling latest every block is 345,600 calls a day. Subscribe to newHeads or, better, to the logs you actually need. The eth_subscribe logs guide shows the pattern.
Block counts are not time. "Wait 12 confirmations" is 3 seconds. Use block tags or timestamps.
The 50,000-block eth_getLogs cap is about 3.5 hours. A one-day backfill is seven requests; a month is about 210. The error message states the limit, so a client can read it and adapt; eth_getLogs range caps covers chunking.

Finality, and the stale-head trap

Because BSC finalizes its own blocks within seconds, opBNB's finalized head moves quickly. On the official BNB Chain endpoint, dRPC and NodeReal, finalized trailed the newest block by 27 to 51 seconds across repeated checks.

One widely used public endpoint told a different story. On about half of our requests it returned a finalized block 13,631 seconds, about 3.8 hours, old, and a fresh one on the rest: a load-balanced pool with some backends stuck. Its WebSocket did the same, at 15,107 seconds. That endpoint was the primary opBNB upstream behind our own service, so we moved opBNB to the official endpoint and dRPC that morning; our endpoint now returns finalized 32 to 38 seconds behind on every request.

The lesson is general. A node that serves a stale finalized doesn't error. A deposit flow that waits for finalized just waits, for hours, and a load-balanced endpoint can even make finalized appear to jump backwards between two calls. Check the tag's timestamp, not just its number:

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

const client = createPublicClient({
  chain: opBNB,
  transport: http("https://rpc.swiftnodes.io/rpc/opbnb?key=YOUR_API_KEY"),
});

const [latest, finalized] = await Promise.all([
  client.getBlock({ blockTag: "latest" }),
  client.getBlock({ blockTag: "finalized" }),
]);
const lagSeconds = Number(latest.timestamp - finalized.timestamp);
if (lagSeconds > 300) {
  // opBNB normally finalizes in under a minute: this node's view of BSC is stuck
  throw new Error(`finalized head is ${lagSeconds}s behind`);
}

The same idea for the head itself is in is your RPC node synced?.

Fees: the L1 part matters here

opBNB receipts carry the OP Stack L1 fee fields (l1Fee, l1GasPrice, l1GasUsed, l1BlobBaseFee and the scalars), and on opBNB they are not negligible. Across 12 recent user transactions:

	Total
L2 execution fee (`gasUsed × effectiveGasPrice`)	289,556,149,631 wei
L1 data fee (`l1Fee`)	171,390,813,185 wei
L1 share of the total	37%

That is the opposite of Katana, where the L1 part was 0.2%. Both are tiny in absolute terms: the sample averaged about 0.00000004 BNB per transaction, a small fraction of a cent. But if you estimate cost as gasUsed × gasPrice alone, you will be about a third low. Use the receipt's l1Fee, or ask the GasPriceOracle predeploy at 0x420000000000000000000000000000000000000F with getL1Fee(bytes) before sending; for 100 bytes of calldata it returned 8,840,000,065 wei.

State and tracing

Full opBNB nodes keep very little history. Through our endpoint, eth_getBalance worked up to about 90 blocks back and failed with missing trie node beyond roughly 127 blocks: about 30 seconds of state. The official endpoint and dRPC also refused a state query 100,000 blocks back. If you need balances or contract state at older blocks, you need an archive node; plan for that before you build a backfill around eth_call at historical heights.

For execution detail, debug_traceBlockByNumber with callTracer works and eth_getBlockReceipts returns a block's receipts in one call. The trace_* namespace (trace_block, trace_filter) is not available, so tools built on trace_filter need to switch to debug_* tracing.

If you're coming from BSC or Optimism

From BSC: same token for gas (BNB) and much of the same ecosystem, but a separate chain with its own chain ID, 250 ms blocks instead of BSC's, and OP Stack L1 fees on top of execution. The BNB Smart Chain RPC guide covers the L1 side.
From Optimism or Base: the same predeploys at 0x4200…, the same deposit transactions (type 0x7e) at the start of each block, and the same safe/finalized semantics, but finality measured in seconds rather than the minutes an Ethereum-settled rollup takes. The sequencer's role is the same as described in what is a sequencer.

The short version

Chain ID 204, BNB for gas, OP Stack settling to BSC.
250 ms blocks: subscribe, don't poll; count time, not blocks.
finalized should be under a minute old. If it's hours old, your node's view of BSC is stuck: check timestamps.
The L1 data fee was 37% of the total in our sample; include l1Fee in cost estimates.
eth_getLogs caps at 50,000 blocks, full nodes keep about 100 blocks of state, and debug_* works while trace_* doesn't.

opBNB HTTP and WebSocket endpoints are on our opBNB RPC page, with the live block height. The same key covers 83 chains, and SwiftNodes has a free tier to try it.

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Shibarium RPC: A Developer's Guide (Chain ID 109)

SwiftNodes — Mon, 28 Sep 2026 06:21:14 +0000

Shibarium is the Shiba Inu ecosystem's own chain, live since August 2023. If you have built on Polygon PoS, you already know most of it: Shibarium runs the same two-layer design, with Bor producing blocks and executing the EVM, and Heimdall validators writing checkpoints to Ethereum. That inheritance explains almost every quirk you will hit over RPC, including a native token that is also a contract and a safe block tag that doesn't answer.

This guide covers what we measured through our Shibarium endpoint on 2026-09-28.

The essentials

	Shibarium mainnet
Chain ID	109 (`0x6d`)
Gas token	BONE, 18 decimals
First block	2023-08-05
Block time	about 7 s (6.97 s averaged over the last 10,000 blocks)
Gas limit	20,000,000 per block
`eth_gasPrice`	0.40 gwei (in BONE)
`finalized` head	13 to 17 blocks (65 to 85 s) behind `latest`
`safe` head	returned an error on every attempt
`eth_getLogs` range	a 1,000,000-block range was accepted
Historical state	full archive, back to block 1
Tracing	`debug_traceBlockByNumber` yes; `trace_*` no

It is EVM-compatible: Foundry, Hardhat, viem and ethers work with the chain ID set to 109. The differences are in what Bor adds on top.

BONE is gas, and also a contract

Fees are paid in BONE, the native token. As on Polygon PoS, the native token is also exposed as an ERC-20-style contract at a fixed system address:

cast call 0x0000000000000000000000000000000000001010 "symbol()(string)" \
  --rpc-url "https://rpc.swiftnodes.io/rpc/shibarium?key=YOUR_API_KEY"
# "BONE"

The contract at 0x…1010 returns name "Bone Token", symbol "BONE" and 18 decimals. Two practical consequences:

A wallet's BONE balance is eth_getBalance. balanceOf on 0x…1010 returns the same number (we compared them), because the contract mirrors native balances rather than holding separate ones. An indexer that adds the two together, or treats 0x…1010 as just another ERC-20, will double-count.
Native transfers emit logs from 0x…1010. A plain BONE transfer we checked produced two logs from that address: LogTransfer (topic 0xe6497e3e…) for the value and LogFeeTransfer (topic 0x4dfe1bbb…) for the gas fee. Filter eth_getLogs on LogTransfer and you can follow native BONE movements without traces. That is by design on Bor chains.

Don't confuse the gas token with the Ethereum-side tokens. SHIB, LEASH and BONE on Ethereum are ordinary ERC-20s; on Shibarium, only BONE is native.

Finality: use `finalized`, not `safe`

Bor finalizes blocks through milestones agreed by Heimdall validators. In our samples, finalized trailed the newest block by 13 to 17 blocks, a bit over a minute. That is the tag to wait for before you treat a deposit as settled:

import { createPublicClient, http, defineChain } from "viem";

const shibarium = defineChain({
  id: 109,
  name: "Shibarium",
  nativeCurrency: { name: "Bone", symbol: "BONE", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/shibarium?key=YOUR_API_KEY"] } },
});

const client = createPublicClient({ chain: shibarium, transport: http() });
const finalized = await client.getBlock({ blockTag: "finalized" });

The safe tag is a different story: every request for it failed through our endpoint. Code written for Ethereum or OP Stack chains often asks for safe as a middle ground; on Shibarium, drop straight to finalized. The general model behind these tags is in L2 finality: soft vs hard.

Finality on Shibarium is not the same as settlement on Ethereum. Heimdall checkpoints batches of blocks to Ethereum, and bridge withdrawals wait for them: the Shib team put bridge withdrawals at about 45 minutes after a May 2024 upgrade (Shib Daily), down from up to seven days for BONE.

Logs, history and tracing

Three things are easier on Shibarium than on most chains:

eth_getLogs over big ranges. Our endpoint accepted a single address-filtered query over 1,000,000 blocks, about 80 days of chain. That still isn't a reason to skip pagination: a busy contract over that range can return more logs than you want in one response. The trade-offs are in eth_getLogs range caps.
Full history. eth_getBalance answered at 128, 10,000 and 1,000,000 blocks back, and at block 1, so historical state queries work without a separate archive endpoint. See full node vs archive node for what that buys you.
debug_* tracing. debug_traceBlockByNumber with callTracer works.

One gap: the Parity-style trace_* methods (trace_block, trace_filter) are not available. Tools that depend on trace_filter for internal transactions need to switch to debug_traceTransaction with callTracer, one transaction at a time. What that costs is covered in the real cost of debug_traceTransaction.

Bor-specific methods are there as well. bor_getAuthor returns a block's producer, and bor_getCurrentValidators returned three validators for the current span when we checked. That is a small active producer set, worth knowing if your application's security assumptions depend on the chain's decentralisation.

Security history you should know

In September 2025 an attacker used a large BONE stake to push three fraudulent checkpoints into the Ethereum contracts that secure the Shibarium bridge, and drained about 224.57 ETH and 92.6 billion SHIB, around $2.4 million at the time. Heimdall halted the chain when its state no longer matched the checkpoints on Ethereum, and the network was later restored with new safeguards, including blacklisting on the Plasma bridge (MEXC News, TradingView).

For RPC users, the lesson is practical: a chain can halt. A health check that only asks whether the RPC answers will not notice: a halted chain's endpoints keep answering, with the same block. Compare the latest block's timestamp with the clock instead. At a 7-second block time, a head that hasn't moved in a minute is worth an alert.

If you're coming from Polygon PoS

Most of what you know transfers directly: the 0x…1010 native-token contract, bor_* methods, milestone finality and checkpoint-based withdrawals all work the same way. The differences are the gas token (BONE, not POL), the chain ID, a slower block time than Polygon's 2 seconds, and a much smaller validator set. Our Polygon RPC guide covers the shared architecture from the Polygon side.

The short version

Chain ID 109, BONE for gas, Bor and Heimdall under the hood.
Native BONE is also a contract at 0x…1010: use eth_getBalance for balances, and expect native-transfer logs from that address.
Use finalized (about a minute behind); safe doesn't answer.
Wide eth_getLogs ranges, full archive, debug_* tracing; no trace_*.
Watch block timestamps, not just block numbers.

Shibarium HTTP and WebSocket endpoints, with the live block height, are on our Shibarium RPC page. The same key covers 83 chains, and SwiftNodes has a free tier to try it.

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Katana RPC: A Developer's Guide to the DeFi-First L2

SwiftNodes — Sun, 27 Sep 2026 07:28:19 +0000

Katana looks like every other OP Stack chain from the RPC side: the same eth_* methods, the same predeploys at 0x4200…, the same L1 fee fields on receipts. Two things underneath are different, and both change how you write code against it. Blocks come every second, not every two. And Katana settles with ZK validity proofs instead of a seven-day fraud-proof window, so "finalized" arrives in minutes rather than a week.

Katana is a DeFi-focused Ethereum L2 incubated by Polygon Labs and GSR. It opened its public mainnet in June 2025. Per L2BEAT, it runs the Agglayer CDK in its OP Stack configuration: an OP Stack chain proven with OP Succinct (SP1 validity proofs), using Agglayer as its canonical bridge. Bridged assets go through VaultBridge, which puts deposits into yield-generating vaults on Ethereum and routes the yield back into Katana's ecosystem.

This guide covers what we measured through our endpoint on 2026-09-27, and what it means for your code.

The essentials

	Katana mainnet
Chain ID	747474 (`0xb67d2`)
Gas token	ETH
Block time	1.00 s (1,000 blocks in 1,000 s; 20 `newHeads` in 20 s, no gaps)
Gas limit	120,000,000 per block
Base fee	0.001 gwei
`safe` head	341 blocks (about 5.7 minutes) behind `latest`
`finalized` head	1,589 blocks (about 26.5 minutes) behind `latest`
Node client	`conduit-op-reth/v2.3.0`
`eth_getLogs` range	up to 30,000 blocks per request
Historical state	full archive, back to block 1
Tracing	`debug_` and `trace_` (block and transaction), plus `eth_getBlockReceipts`

It is EVM-equivalent: Foundry, Hardhat, viem and ethers all work unchanged. Point them at the RPC and set the chain ID.

One block per second

A 1-second block time is twice as fast as Base or Optimism, and it changes a few habits:

Polling is expensive. A loop that calls eth_getBlockByNumber("latest") every block makes 86,400 requests a day. Use a WebSocket newHeads subscription instead, or better, subscribe to exactly the logs you care about. The eth_subscribe logs guide shows the pattern.
Block ranges are shorter in time. The 30,000-block eth_getLogs limit covers about 8.3 hours of Katana history. A backfill over one month is about 87 requests, not one. The general approach for ranges is in eth_getLogs range caps.
Confirmation counts mean less. "Wait 12 blocks" is 12 seconds on Katana. Count confirmations with block tags, not block numbers.

Finality: latest, safe, finalized

OP Stack chains expose three levels through standard block tags, and Katana's numbers are unusual:

Tag	Lag behind `latest` (measured)	Meaning
`latest`	0	Produced by the sequencer, not yet on L1
`safe`	about 5.7 minutes	Batch data posted to Ethereum
`finalized`	about 26.5 minutes	Batch data in a finalized Ethereum block

On an optimistic rollup, a withdrawal to L1 still waits seven days after finalized for the fraud-proof window. Katana has no such window: its state transitions are proven with validity proofs, and Succinct puts Katana's finality at "under an hour" (case study). For anything that moves value off-chain, such as crediting a deposit or releasing funds, wait for finalized:

import { createPublicClient, http, defineChain } from "viem";
import { chainConfig } from "viem/op-stack";

export const katana = defineChain({
  ...chainConfig,
  id: 747474,
  name: "Katana",
  nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/katana?key=YOUR_API_KEY"] } },
});

const client = createPublicClient({ chain: katana, transport: http() });

const finalized = await client.getBlock({ blockTag: "finalized" });
const isFinal = (txBlock) => txBlock <= finalized.number;

viem does ship a katana chain in viem/chains, but as of viem 2.47 it is a plain chain definition without the OP Stack formatters, so receipt fields like l1Fee come back as raw hex strings. Spreading chainConfig from viem/op-stack, as above, adds them.

The soft/hard distinction is covered in general terms in L2 finality: soft vs hard.

Fees: almost all execution, almost no L1

Katana receipts carry the standard OP Stack L1 fee fields: l1Fee, l1GasPrice, l1GasUsed, l1BlobBaseFee, l1BaseFeeScalar, l1BlobBaseFeeScalar. On most OP Stack chains the L1 data fee is a large part of what a user pays. On Katana it isn't. Across 12 recent user transactions:

	Total
L2 execution fee (`gasUsed × effectiveGasPrice`)	35,373,690,000,000 wei
L1 data fee (`l1Fee`)	62,987,722,419 wei
L1 share of the total	0.2%

That sample averaged about 0.000003 ETH per transaction, under a cent at current ETH prices. The practical upshot: on Katana, eth_estimateGas × eth_gasPrice is a good estimate of the full cost. If you want the L1 part anyway, the chainConfig formatters above parse the receipt fields into bigints:

const receipt = await client.getTransactionReceipt({ hash: "0x..." });
const total = receipt.gasUsed * receipt.effectiveGasPrice + (receipt.l1Fee ?? 0n);

Or ask the GasPriceOracle predeploy (0x420000000000000000000000000000000000000F) with getL1Fee(bytes) before sending. For 100 bytes of calldata it returned 420,810,233 wei, a fraction of a millionth of an ETH.

Archive and tracing

The node behind our Katana endpoint is op-reth, and it serves full history: eth_getBalance worked 128, 10,000 and 1,000,000 blocks back and at block 1. The Reth tracing APIs are there too:

debug_traceBlockByNumber and debug_traceTransaction with callTracer
trace_block and trace_transaction
eth_getBlockReceipts for all receipts in one call

With a block every second, eth_getBlockReceipts matters: indexing a day of Katana receipts is 86,400 calls with it, and one call per transaction without it. For internal calls and value transfers, see trace_filter and trace_transaction.

Trust model, briefly

Katana is Stage 0 on L2BEAT. Validity proofs protect state transitions, but the sequencer and proposer are centralized. Users can force a transaction through L1 with a delay of up to 12 hours if the sequencer censors them. Contract upgrades have no exit window. None of that changes how you call the RPC, but it belongs in the risk section of anything that holds user funds on the chain. The sequencer's role in general is explained in what is a sequencer.

The short version

Chain ID 747474, ETH for gas, standard OP Stack JSON-RPC.
1-second blocks: subscribe instead of polling; 30,000-block eth_getLogs windows cover about 8 hours.
finalized is about 26 minutes behind latest, and there is no seven-day withdrawal window: validity proofs settle it.
Fees are almost entirely L2 execution; the L1 data fee was 0.2% in our sample.
Full archive, debug_* and trace_* are available.

Katana HTTP and WebSocket endpoints, with the live block height and WebSocket status, are on our Katana RPC page. The same key works across 83 chains, and SwiftNodes has a free tier to start with.

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Kusama RPC: A Developer's Guide After the Asset Hub Move

SwiftNodes — Sat, 26 Sep 2026 05:23:39 +0000

Most Kusama RPC tutorials were written for a chain that no longer exists in the same shape. Until October 2025, the Kusama relay chain was where balances lived, where you bonded and nominated, and where governance ran. On October 7, 2025, Kusama completed its Asset Hub migration: balances, staking and governance moved off the relay chain to Kusama Asset Hub, through runtime upgrades, with no action required from holders.

The code that broke is the code that still queries the relay chain for things that moved. It doesn't throw. It returns an empty account and a zero balance. This guide covers what the Kusama relay RPC still does, what moved, and the numbers we measured through our own endpoint on 2026-09-26.

The essentials

Everything in this table was read live from https://rpc.swiftnodes.io/rpc/kusama:

	Kusama relay chain
`system_chain`	`Kusama`
Runtime (`specName`)	`kusama`, `specVersion` 2003002, `transactionVersion` 26
Node	Parity Polkadot 1.24.0
Token	KSM, 12 decimals (`system_properties`)
SS58 address prefix	2
Block time	6.38 s average over a 90-second sample
Finality (GRANDPA)	finalized head trailed the best head by 2-3 blocks (about 13-19 s)
RPC surface	120 methods: `system_`, `chain_`, `state_`, `author_`, `chainHead_v1_`, `grandpa_`, `beefy_`, `mmr_`, and others
`eth_*` methods	none

If you're coming from Ethereum, the same rules as Polkadot apply. There is no eth_blockNumber, viem and ethers won't connect, and storage is SCALE-encoded rather than ABI-encoded. Our Polkadot RPC guide covers that translation; everything there carries over to Kusama except the numbers. DOT has 10 decimals, KSM has 12. Kusama addresses use SS58 prefix 2, Polkadot's use 0, so the same public key encodes to a different address string on each network.

Big change: balances moved to Asset Hub

This is the gotcha worth the whole post. We read the Balances.TotalIssuance storage item and counted System.Account entries on both chains:

	Relay chain	Kusama Asset Hub
`Balances.TotalIssuance`	24,939 KSM	18,889,082 KSM
`System.Account` entries	2,343	more than 30,000 (we stopped counting)

The relay chain now accounts for roughly 0.1% of the KSM supply. If your wallet backend, tax tool or exchange integration still reads system.account on the relay chain, almost every user shows a zero balance, and nothing errors to tell you so.

The fix is to point balance, transfer, staking and governance queries at Asset Hub:

import { ApiPromise, WsProvider } from "@polkadot/api";

// Kusama Asset Hub: balances, transfers, staking, governance
const assetHub = await ApiPromise.create({
  provider: new WsProvider("wss://kusama-asset-hub-rpc.polkadot.io"),
});

const { data } = await assetHub.query.system.account("YOUR_KUSAMA_ADDRESS");
console.log("free KSM:", Number(data.free.toBigInt()) / 1e12);

Two details trip people up here:

Asset Hub's runtime is still called statemine. state_getRuntimeVersion on Kusama Asset Hub returns specName: "statemine", the parachain's original name. If your code identifies networks by specName, add it.
Addresses don't change. Asset Hub uses the same SS58 prefix (2) and 12 decimals, so a user's address and balance units are identical; only the chain you ask is different.

Staking follows the same rule. Bonding, nominating and unbonding are Asset Hub extrinsics now. The relay chain still has consensus work to do, so some staking-related storage remains there, but it is not where a nominator's position is managed.

What the relay chain RPC is still for

The relay chain didn't become useless; it became specialised. Query it directly for:

Block production and finality. BABE produces relay blocks and GRANDPA finalizes them. If you need to know that something is final across the Kusama network, the relay chain's finalized head is the source.
Parachain validation. Which parachain blocks were backed and included is relay-chain state.
Bridge and light-client proofs. The beefy_* and mmr_* methods exist for bridges and light clients that need compact proofs of relay-chain history.
Validator operations. Session keys are still set on the relay chain.
Indexing relay events. Explorers and indexers that follow the relay chain itself.

For a dApp that only shows balances and sends transfers, the relay chain is now the wrong endpoint.

Follow finalized heads, not new heads

Kusama's new heads can be re-organised before GRANDPA finalizes them. In our sample, finality ran 2-3 blocks behind the best head. For anything that credits a user, subscribe to finalized heads:

import { ApiPromise, WsProvider } from "@polkadot/api";

const api = await ApiPromise.create({
  provider: new WsProvider("wss://rpc.swiftnodes.io/ws/kusama?key=YOUR_API_KEY"),
});

await api.rpc.chain.subscribeFinalizedHeads((header) => {
  console.log("finalized", header.number.toNumber());
});

The same logic applies as on any chain: a WebSocket that stops delivering is not the same as a chain with no new blocks. At 6.4 seconds per block, 30 seconds without a finalized head is worth a reconnect. The pattern is in reconnecting without losing events.

Runtime upgrades change your types

Kusama is Polkadot's canary network, so runtime upgrades usually reach it first and more often. Every upgrade can change storage layouts, call indices and the transactionVersion that signed transactions commit to. Polkadot-JS reloads metadata by itself when the runtime changes. What breaks is everything that doesn't: hand-written SCALE decoders, cached type definitions, and offline signers carrying old metadata.

Watch for upgrades instead of discovering them from failed transactions:

await api.rpc.state.subscribeRuntimeVersion((v) => {
  console.log("runtime", v.specName.toString(), v.specVersion.toNumber(), "tx version", v.transactionVersion.toNumber());
});

When specVersion changes, reload metadata before decoding anything new. When transactionVersion changes, an offline signer with old metadata will produce transactions the chain rejects.

History: 256 blocks of state

Our Kusama relay endpoint is a pruned node. We asked for the Timestamp.Now storage item at increasing depths:

Blocks back	State available
64, 128, 200, 250, 256	yes
300, 500, 1,000 and deeper	no: `State already discarded` (error 4003)

So state queries work for the last 256 blocks, about 27 minutes at 6.4 s per block. Blocks and headers are still available further back through chain_getBlockHash and chain_getBlock; it's the storage at old blocks that is pruned. For balance history, staking history or anything else that needs state_getStorage at an old block hash, you need an archive node, and the migration splits it in two: account history from before October 7, 2025 is relay-chain state, and everything after is on Asset Hub. The general trade-off is in full node vs archive node.

New JSON-RPC API: `chainHead_v1`

Our Kusama node exposes the newer JSON-RPC interface alongside the legacy one: nine chainHead_v1_* methods plus transaction_* and transactionWatch_*. Polkadot-JS uses the legacy chain_* and state_* methods. The newer polkadot-api (PAPI) client is built on chainHead_v1. Both work against the same endpoint. The archive_v1_* methods are not available, which matches the node being pruned.

The short version

Balances, transfers, staking and governance: use Kusama Asset Hub. The relay chain holds about 0.1% of KSM.
Finality, parachain inclusion, bridge proofs, validator operations: use the relay chain.
KSM has 12 decimals and SS58 prefix 2, on both chains.
Credit users on finalized heads, 2-3 blocks behind the best head.
Subscribe to runtime versions; Kusama upgrades often.
Relay state is kept for 256 blocks on our endpoint; older state needs an archive node.

Kusama relay-chain RPC over HTTP and WebSocket is on our Kusama RPC page, with the live block height and WebSocket status. The same key covers Polkadot and 81 other chains. SwiftNodes has a free tier if you want to try it.

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

We Tested 945 Public RPC Endpoints. Half Don't Work.

SwiftNodes — Fri, 25 Sep 2026 05:34:41 +0000

Public RPC lists are how most developers find an endpoint: open Chainlist, copy the first URL, paste it into a config. The lists tell you an endpoint was added at some point. They do not tell you whether it works today.

So we tested all of them. On 2026-09-24 we took every keyless endpoint listed on Chainlist and chainid.network for the 65 EVM chains we serve (945 third-party URLs: 800 HTTP and 145 WebSocket) and ran the same checks against each one. 395 of the 800 HTTP endpoints answered correctly: 49.4%. Of the 145 WebSocket endpoints, 76 actually streamed a new block: 52.4%.

The full results, endpoint by endpoint, are on our public RPC leaderboard, re-run every week.

How we tested

Every HTTP endpoint got the same sequence:

eth_chainId, which must return the chain the list says it serves.
eth_blockNumber three times, for median latency and the head.
How far that head trails the best head seen for the chain in the same run.
eth_getLogs over 1,000 and then 10,000 blocks, filtered to one address.
eth_getBalance 128 and 1,000,000 blocks back, to see how much history it keeps.

Every WebSocket endpoint: eth_chainId, then eth_subscribe("newHeads"), and it passes only if a new block actually arrives within 15 seconds. On chains that produce blocks less often than that, an accepted subscription with no block yet is counted as inconclusive, not as a failure.

A few things to keep in mind about the numbers:

One server, one run. Latency is from a single location. Head lag, limits and pass/fail are not location-dependent in the same way, but a flaky endpoint can pass one day and fail the next.
Rate limits count as failures only after backoff. Calls are paced, and a rate-limited call is retried three times with increasing waits before we give up. 98 endpoints still refused. A client sending a request every few seconds might get through where our test did not; a real application under load will not.
Our own endpoint is excluded from these totals. It is on the leaderboard, labelled, and measured in a separate pass (details at the end).

Why half of them fail

For the 405 HTTP endpoints that did not pass:

Failure	Endpoints
Unreachable: DNS, TLS or connection refused	111
Rate limited, even after backoff	98
Other HTTP 4xx responses	56
HTTP 5xx and other server errors	30
Answered `eth_chainId`, then failed `eth_blockNumber`	25
Monthly or daily usage limit already reached	19
Provider discontinued ("Blast API is no longer available")	13
Timeout	13
Other (invalid key, auth required, empty responses)	40

The biggest groups tell a simple story: lists outlive endpoints. Domains lapse, providers shut down or move their free tier behind a signup, and the list entry stays. Thirteen URLs from one discontinued provider are still listed across chains. Others now answer "API key required", "invalid API key" or a usage-limit message, which is a reasonable business decision for the provider but a broken entry for anyone who copied it.

"Working" is not the same as "usable"

Of the 395 endpoints that answered correctly:

Check	Result
Head within 3 blocks of the best	201 (51%)
More than 100 blocks behind	11
Worst lag	4,375,016 blocks behind
`eth_getLogs` over 10,000 blocks accepted	160
Refused even 1,000 blocks	164
State readable 1,000,000 blocks back (archive depth)	214
No historical state at all (not even 128 blocks)	110
Median latency	49 ms (p90: 172 ms)

The lag numbers matter most, because a lagging node does not fail — it answers, confidently, with old data. An endpoint 4.4 million blocks behind returns a perfectly valid block number; it is just from long ago. If you read balances or wait for confirmations through a node like that, your application is wrong without any error to tell you so. Always compare eth_blockNumber against a second source, or check the latest block's timestamp against the clock.

The eth_getLogs split is the other trap. Two in five working endpoints (164 of 395) refuse a 1,000-block log query, which is small for any indexer or backfill. If your code was written against a generous endpoint and falls back to a stricter one, it will start failing with range errors you never saw in development.

WebSockets are worse than they look

Only 76 of 145 WebSocket endpoints delivered a block. Another 9 accepted the subscription on slow chains (Metis, Arbitrum Nova, HAQQ, Syscoin, Rootstock) that produced no block inside the window, so we count them as inconclusive. The other 60 failed:

WebSocket failure	Endpoints
Could not connect, or timed out	40
Subscription rejected ("not available on free plan", "unsupported subscription")	14
Subscription accepted, then no block delivered (on chains with frequent blocks)	4
Other (chain ID errors)	2

The rejected and silent groups are why "the socket connected" proves nothing. An endpoint can complete the handshake, answer eth_blockNumber, accept your subscription with a valid ID, and then send nothing. Your application sees a healthy connection and waits forever. The only real test is a delivered event. We covered the client-side pattern for this in reconnecting without losing events, and the specific errors are in eth_subscribe errors explained.

Which endpoints held up

Some providers' public endpoints passed nearly everywhere they are listed. Counting HTTP endpoints that answered correctly out of those listed:

Provider	Working / listed
dRPC	50 / 51
PublicNode	29 / 29
Pocket Network	26 / 27
Sentio	24 / 24

These are free, keyless endpoints, and they deserve credit for staying up across dozens of chains. They still come with the usual public-endpoint limits: per-IP rate limits, tight eth_getLogs caps on some chains, and shared capacity. For WebSocket, PublicNode streamed on 18 of 27 and Pocket Network on 13 of 15.

How to pick a public endpoint

Based on what failed:

Test before you trust the list. Our RPC tester runs these checks on any endpoint from your browser: chain ID, head lag, eth_getLogs range, archive depth and whether its WebSocket really streams.
Check freshness, not just liveness. A lagging node is worse than a dead one because it fails silently.
Configure two endpoints, not one. Most failures above are permanent (dead domains, discontinued providers), but rate limits are not, and a second endpoint turns an outage into a retry.
Match the endpoint to the job. A wallet reading the latest balance can use almost any working endpoint. An indexer needs a generous eth_getLogs range and historical state; that eliminates most of the list.
Re-check periodically. Every failing entry here was added to a list by someone, presumably when it worked. Endpoints decay; the list does not update itself.

Our own endpoint, measured the same way

We ran our keyless endpoint through the same checks in a separate pass, so our rate limiter did not collide with the rest of the test. It answered correctly on 63 of 65 chains over HTTP. Over WebSocket it streamed on 45 of 65. On the other 20, either we have no WebSocket upstream for that chain or the subscription did not deliver during the test; each chain page shows our current measured WebSocket status rather than a blanket claim. Our keyless and free tiers are limited to 2 requests per second; paid plans start at 50.

The per-chain pages list every endpoint with its latency, lag, limits and WebSocket result, ours included. For example: Ethereum (33 of 80 listed HTTP endpoints working), Base (15 of 36) and BNB Smart Chain (36 of 47).

For what free endpoints can and cannot do at the plan level, see free RPC endpoints and their real limits and public RPC vs paid RPC. If you want one key that works across 86 chains with the limits published and measured, SwiftNodes has a free tier.

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Dedicated Node vs Shared RPC Endpoint: When You Actually Need One

SwiftNodes — Thu, 24 Sep 2026 05:19:44 +0000

"Dedicated node" is one of the most common things people search for when their RPC starts misbehaving. Usually the real question underneath is: my shared endpoint is rate-limiting me, returning inconsistent answers, or missing a method — do I need my own node?

Sometimes the answer is yes. More often it is "not yet", and the fix costs a fraction of a dedicated node. This post covers what each option actually is, what dedicated nodes cost in 2026 according to the providers' own pages, and the concrete signals that tell you which one you need.

What you are buying in each case

A shared endpoint is a URL in front of a pool of nodes that many customers use. The provider load-balances your requests across that pool, and your plan buys a rate limit (requests per second) and sometimes a monthly volume, not a machine. SwiftNodes is a shared-endpoint provider: every plan is a rate limit across all 86 chains we serve, from 2 requests per second on the free tier to 500 on Pro.

A dedicated node is a node, or a small cluster, that serves only you. You buy the machine's capacity. There is no per-request limit beyond what the hardware can do, and you usually get a say in the configuration: archive or full, which client, which tracing flags, which region.

The difference that matters most is not speed. It is consistency. A shared endpoint gives you whichever healthy node answers. A dedicated node always gives you the same one.

What a shared pool looks like from the client side

This is easy to state and hard to picture, so here is a measurement from our own endpoint. On 2026-09-23 I sent the same kinds of requests to our Cronos endpoint and got two different answers depending on which upstream node served them:

Request	Upstream A	Upstream B
Largest `eth_getLogs` range	10,000 blocks (`maximum [from, to] blocks distance: 10000`)	50,000 blocks (`exceed maximum block range: 50000`)
Oldest available height	`lowest height is 90850001`	`lowest height is 95187533`

Both nodes were healthy. They were simply configured differently, and a pooled endpoint exposes the union of their quirks. For most applications this is invisible: you read the head, send transactions, and query recent logs. For an indexer backfilling months of history, it is the difference between a job that finishes and one that fails every few thousand requests on whichever node has the tighter limit.

The shared-endpoint fix is to code to the strictest node: chunk eth_getLogs at the smaller cap, and assume the shallower history. That is what our Cronos guide recommends. The dedicated-node fix is to own the configuration.

What dedicated nodes cost in 2026

Pricing for dedicated infrastructure is mostly not public. What the providers themselves publish, as of September 2026:

Provider	Dedicated pricing, as published
QuickNode	Dedicated clusters are part of Enterprise: "Custom pricing" (pricing page)
GetBlock	"Public dedicated pricing: Yes, from $1,000" (pricing page)
Chainstack	$199/mo plan + compute from $0.50/hour + storage. Their own examples: Ethereum full node ~$1,279/mo, Zora full ~$445/mo, Celo full ~$767/mo (Chainstack, 2026-09-02)

So a dedicated Ethereum node lands at roughly $1,000–1,300 a month where a price is published, and more when you need archive or several regions. Compare that with shared flat-rate plans, which run from $49 to a few hundred dollars a month. On SwiftNodes, Pro is $249/mo for 500 requests per second on every chain.

That gap is the whole decision. A dedicated node needs to fix a problem worth about $1,000 a month to you.

Four signals that you actually need one

1. You need a method or configuration the shared pool does not offer. Examples: debug_traceTransaction on a chain where the pool has no tracing nodes (our Cronos endpoint returns -32601 for the whole debug_ namespace), full archive state on a chain where the shared nodes prune (Cronos keeps about 100 blocks of state), or a specific client for its custom namespace. Check the provider's method support first. Ours is on the measured method matrix. If the method is not there on any shared plan, a dedicated node is the honest answer.

2. Your sustained load is above the top shared plan. Look at your sustained requests per second, not your peak. If you consistently need several hundred requests per second on one chain, the per-request economics favour your own capacity. Bursts are cheaper to absorb with batching and retries — see JSON-RPC batching and RPC rate limits.

3. You need every response to come from the same node. Backfilling indexers, reconciliation jobs and anything that compares state across consecutive calls suffer when consecutive requests can land on nodes a block apart, or with different pruning. You can engineer around it (pin block numbers in every call, use the smallest shared limits), but past a certain volume a single node is simpler.

4. Compliance or data locality says so. Some teams must know exactly which machine in which jurisdiction served a request. A shared pool cannot promise that. A dedicated node in a named region can.

If none of these apply, you probably do not need a dedicated node yet.

Signals that look like "I need dedicated" but are not

429 errors on a free or public endpoint. That is a rate limit, not a capacity problem. Past 2 requests per second, our free tier answers {"error":"Rate limited","limit":2,"plan":"Free"}. A paid shared plan moves that limit from 2 to 50–500 requests per second for $49–249 a month. See public RPC vs paid RPC.

Occasional stale or lagging responses. Usually one lagging node in a pool the provider should be ejecting. Our health checker compares every upstream's height with the chain's best and stops routing to one that trails by more than 50 blocks (EVM) for two consecutive rounds. Is your RPC node synced? covers how to detect it from the client side.

"My eth_getLogs calls fail." Almost always a range cap. Chunk the range; a dedicated node would have a cap too, just one you set yourself. See eth_getLogs range caps.

Latency. A dedicated node in the wrong region is slower than a shared pool with a node near you. Measure p95 from where your code actually runs before paying for isolation.

The middle option: run your own node

If you need consistency and configuration control but not a vendor-managed machine, running a node yourself is the third choice. The hardware is often cheaper than a managed dedicated node. The operations work (upgrades, disk growth, resyncs, monitoring) is not. We did the full cost comparison in self-hosted node vs RPC provider, and the Ethereum archive numbers are in Ethereum archive node cost.

A common pattern that works well: shared endpoint for everything, plus one self-run or dedicated node for the single job that needs consistency (usually the indexer backfill). You pay dedicated prices for one chain and one workload, not for your whole stack.

The short version

A dedicated node buys you consistency and configuration control, not raw speed. Published 2026 prices put a dedicated Ethereum node at roughly $1,000–1,300 a month (GetBlock from $1,000, Chainstack ~$1,279; QuickNode and others quote privately). Shared flat-rate plans cost $49–249 a month. You need dedicated when a method or history depth is missing from every shared plan, when sustained load exceeds the top shared tier, when consecutive calls must hit the same node, or when compliance requires a named machine. Rate limits, stale nodes, eth_getLogs errors and latency are usually fixed more cheaply without one.

If a shared endpoint covers your case, SwiftNodes serves 86 chains on one key with flat monthly pricing and a free tier at 2 requests per second, enough to test your workload before you decide anything. Get an API key.

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Cronos RPC: A Developer's Guide

SwiftNodes — Thu, 24 Sep 2026 05:17:41 +0000

Cronos is Crypto.com's EVM chain: Solidity contracts, eth_* methods, MetaMask, viem and ethers all work unchanged. Underneath, it is a Cosmos SDK chain with an EVM module, and that shows up in exactly the places where Ethereum habits break: how fast blocks arrive, how much history a node keeps, and what the error messages look like when you ask for something it has already thrown away.

Plenty of documentation still describes Cronos as a 5–6 second chain. Our own chain page said so until this post. The chain I measured today produces a block roughly every 0.42 seconds, which changes how you should poll, index and cache.

Everything below was measured on 2026-09-23 through https://rpc.swiftnodes.io/rpc/cronos. Re-run any of it.

The essentials


Chain ID	`25` (`0x19`); `net_version` also returns `25`
Native token	CRO, 18 decimals
Block time	~0.42 s: 0.410 s over 100 blocks, 0.422 over 1,000, 0.419 over 10,000, 0.421 over 100,000, 0.428 over 1,000,000
Head at time of writing	`95,687,161` (2026-09-23 14:03:29 UTC)
Finality	`latest` = `safe` = `finalized`, in every batched read
Block gas limit	60,000,000
Base fee	375 gwei, flat across the last 11 blocks; `eth_maxPriorityFeePerGas` 3.75 gwei
`eth_getLogs` range	10,000 blocks (about 70 minutes of chain time), and an address is required
Historical state	~100 blocks (under a minute)
`debug_` / `trace_`	Not available (`-32601`)
WebSocket	`eth_subscribe("newHeads")` works
RPC	`https://rpc.swiftnodes.io/rpc/cronos?key=YOUR_API_KEY`

Connecting

Any EVM client works. viem does not need a custom chain definition, because it ships cronos:

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

const client = createPublicClient({
  chain: cronos,
  transport: http("https://rpc.swiftnodes.io/rpc/cronos?key=YOUR_API_KEY"),
});

console.log(await client.getChainId());      // 25
console.log(await client.getBlockNumber());  // 95687161n at time of writing

curl -s -X POST "https://rpc.swiftnodes.io/rpc/cronos?key=YOUR_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

The two token contracts most integrations touch first, both read back with eth_call today:

Token	Address	`decimals()`
WCRO	`0x5C7F8A570d578ED84E63fdFA7b1eE72dEae1AE23`	18
USDC	`0xc21223249CA28397B4B6541dfFaEcC539BfF0c59`	6

USDC's 6 decimals is the usual trap for code that assumes 18 on an EVM chain.

0.42-second blocks change your polling math

At ~0.42 s per block, Cronos produces roughly 205,000 blocks per day. A million blocks is under five days. Three consequences:

Polling eth_blockNumber every second skips blocks. Each poll sees the head move by two or three. That's fine if you only need the tip. If you process every block, fetch ranges (fromBlock → toBlock), not "the next one".
Block-count thresholds from Ethereum are far too short here. "Wait 12 blocks" is five seconds on Cronos. If you express staleness, cache TTLs or confirmation UX in blocks, convert them from seconds first.
Subscriptions beat polling. Over WebSocket, newHeads delivered 10 consecutive heads in 4.4 seconds after subscribing, the first one 675 ms in:

const ws = createPublicClient({
  chain: cronos,
  transport: webSocket("wss://rpc.swiftnodes.io/ws/cronos?key=YOUR_API_KEY"),
});

ws.watchBlocks({
  onBlock: (b) => console.log(b.number, b.transactions.length),
});

Handle reconnects without losing events. At this block rate, a 30-second disconnect is about 70 blocks. The pattern is in WebSocket reconnects without losing events.

Finality: there is nothing to wait for

Cronos uses CometBFT-style consensus, so a committed block is final. I read latest, safe and finalized in a single JSON-RPC batch three times, so all three came from the same instant. They returned the same height every time (95,687,363, then 95,687,365, then 95,687,367).

You can drop reorg handling written for probabilistic chains. Keep a sanity check anyway — the reasoning is in handling chain reorgs in an indexer — but you do not need a confirmation depth.

Gas: flat base fee, near-empty blocks

Over the last 10 blocks, eth_feeHistory returned a base fee of exactly 375 gwei for every block. The highest gasUsedRatio was 0.0083 (0.83% of the 60M gas limit), and several blocks were empty. eth_gasPrice returned 378.75 gwei, which is the base fee plus the 3.75 gwei suggested tip.

Blocks are this empty, so the tip is not buying you anything. A real type-2 transaction I pulled from the chain paid an effective gas price of 375,000,000,001 wei: the base fee plus a 1-wei tip. Basic cost figures:

Operation	Gas (measured)	Cost at 375 gwei
Plain CRO transfer	21,000 (`eth_estimateGas` → `0x5208`)	0.007875 CRO
Sample contract call (from chain)	127,908	~0.048 CRO

If you hard-code gas prices from Ethereum-mainnet habits (a few gwei), your transactions will never be included, because the base fee here is 375 gwei. For the general method, see estimating gas with eth_estimateGas and EIP-1559.

eth_getLogs: 10,000 blocks, address required

I queried USDC Transfer events over growing ranges:

Range (blocks)	Result
100	4 events, 158 ms
1,000	41 events, 359 ms
5,000	217 events, 369 ms
10,000	413 events, 1,016 ms
50,000	`maximum [from, to] blocks distance: 10000`
100,000	`-32701 exceed maximum block range: 50000`

Two different limits came back from two different upstream nodes. Code to the smaller one: 10,000 blocks. On Cronos, that covers about 70 minutes, so backfilling a single day takes about 21 requests and a month about 620. The chunking loop from eth_getLogs range caps applies, with one change: chunk size in blocks has to be sized for a fast chain.

A query with only a topic and no address was refused three times out of three with -32701 and the message "Please specify an address in your request". Wide event scans ("every ERC-20 Transfer on the chain") are not something this endpoint will serve. Filter by contract.

History: plan for a node that forgets

This is the part that will break an Ethereum-shaped indexer. The Cosmos SDK nodes behind this endpoint prune aggressively.

State (balances, eth_call at a past block) lasts about 100 blocks. eth_getBalance at 20 and 50 blocks behind the head succeeded. At about 100 blocks behind, and at every depth from there out to 3,000,000, it failed with:

codespace sdk code 18: invalid request: failed to load state at height 91687369;
version mismatch on immutable IAVL tree; version does not exist.
Version has either been pruned, or is for a future block height

A hundred blocks is about 40 seconds. "Read the balance as of this morning" is not a query this endpoint can answer. If you need historical state, you derive it from events, or you run an archive node. We explain that trade-off in full node vs archive node.

Blocks and logs go back further, but the floor depends on which node answers. One upstream reported its lowest height as 90,850,001, and block 90,850,001 (2026-08-30) came back intact. Another reported 95,187,533, about 500,000 blocks or ~2.4 days behind the head. Design backfills around the shorter window, and treat "not available" as a per-node answer.

Pre-floor blocks return null, not an error. eth_getBlockByNumber for block 1, 1,000,000 and 50,000,000 returned result: null, and so did the earliest tag. Code that treats null as "block does not exist yet" will misreport pruned history as the future.

What works and what doesn't

Method	Result
`eth_call`, `eth_estimateGas`, `eth_feeHistory`, `eth_maxPriorityFeePerGas`	Works
`eth_getBlockReceipts`	Works (all receipts for a block in one call)
`eth_call` with a state-override object	Works (see state overrides)
`txpool_status`	Works (`pending` / `queued`)
`eth_createAccessList`	Works only with `gas` set; without it: `gas must be set when using authorization list`
`debug_traceTransaction`, `debug_traceBlockByNumber`, `trace_transaction`	Not available: `-32601 method does not exist/is not available`
`eth_subscribe("newHeads")` over `wss://`	Works

The eth_createAccessList error is misleading: my call had no authorization list, and passing any gas value (I used 200,000) made it succeed. If your library calls it without gas, add one.

No tracing means no call trees for debugging reverts or tracking internal CRO transfers over RPC. To find out where a transaction failed, re-run it with eth_call at the latest block before state moves on — which, at ~100 blocks of state, is less than a minute.

What this means for your stack

Think in seconds, not blocks. Convert every Ethereum-tuned block count (confirmations, TTLs, backoff) to wall-clock time first. At 0.42 s, ported block numbers are about 30x too short.

Chunk eth_getLogs at 10,000 blocks and always pass an address.

Read state at the head, and derive history from events. A shared endpoint keeps about 40 seconds of state.

Handle null for pruned blocks and expect the floor to change with the node that answers.

Skip confirmation depth, keep a sanity check. Finality is single-block.

The short version

Cronos is EVM chain 25 with ~0.42-second blocks (stable from 100 to 1,000,000-block windows) and single-block finality (latest = safe = finalized). The base fee sits at a flat 375 gwei with blocks under 1% full. eth_getLogs is capped at 10,000 blocks (about 70 minutes) and needs an address. Historical state survives about 100 blocks, block history between ~2.4 and ~24 days depending on the node, and pruned blocks come back as null. There is no debug_/trace_ namespace, eth_createAccessList needs gas, and newHeads subscriptions deliver every block.

https://rpc.swiftnodes.io/rpc/cronos?key=YOUR_API_KEY
wss://rpc.swiftnodes.io/ws/cronos?key=YOUR_API_KEY

The Cronos RPC page shows the live status of these endpoints. One key covers all 86 chains, and the free tier is 2 requests per second — enough to re-run every probe in this post.

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Babylon RPC: A Developer's Guide (bbn-1, 9.6s Blocks, and a Pruning Floor That Moves)

SwiftNodes — Tue, 22 Sep 2026 06:04:23 +0000

Babylon is the chain where Bitcoin holders stake BTC natively — no bridge, no wrapper — to secure proof-of-stake networks, and it is not an EVM chain: no eth_* methods, no numeric chain ID, and a REST/gRPC surface that matters as much as the RPC one. Most integration pain here comes from expecting the EVM habits, and from one thing that genuinely surprised me when I measured it: the pruning floor is not a single number.

Everything below was measured on 2026-09-22 through https://rpc.swiftnodes.io/rpc/babylon and the public LCD, from inside a datacenter so the latency figures are not a residential round trip. Re-run any of it.

The essentials


Network / chain ID	`bbn-1` (a string; there is no numeric chain ID)
Consensus client	CometBFT `0.38.22` (protocol p2p 8, block 11, app 0)
Block time	~9.58 s (stable over 100, 1,000 and 5,000-block windows)
Head at time of writing	`4,580,805`
Active validators	68, of `max_validators: 100`
Unbonding period	1,814,400 s = 21 days
Block limits	`max_bytes` 22,020,096 (~21 MiB), `max_gas` 300,000,000
EVM methods	None. `eth_chainId`, `eth_blockNumber`, `eth_getLogs`, `web3_clientVersion` → `-32601 Method not found`
RPC	`https://rpc.swiftnodes.io/rpc/babylon?key=YOUR_API_KEY`
Also exposed	gRPC and REST/LCD — for Babylon these are not optional extras

Connecting

JSON-RPC 2.0 over POST, method in the body, and note the object params ({"height": "..."}), not Ethereum's array.

curl -s -X POST https://rpc.swiftnodes.io/rpc/babylon?key=YOUR_API_KEY \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"status","params":{}}'

const RPC = "https://rpc.swiftnodes.io/rpc/babylon?key=YOUR_API_KEY";

async function rpc(method, params = {}) {
  const r = await fetch(RPC, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  const j = await r.json();
  if (j.error) throw new Error(`${method}: ${j.error.message} ${j.error.data ?? ""}`.trim());
  return j.result;
}

const s = await rpc("status");
const height = Number(s.sync_info.latest_block_height);   // 4,580,805 at time of writing
const block  = await rpc("block", { height: String(height) });
console.log(block.block.header.chain_id);                  // "bbn-1"

Heights are strings. {"height": 4580805} as a JSON number is rejected, which is the single most common reason a working Ethereum client breaks on a Cosmos chain.

CometBFT's own REST-style paths (GET /status, /block?height=N) do not work through a load-balanced RPC path — POST only. And errors arrive as a JSON-RPC error object with HTTP 200, so a client that only checks the status code will read "no data" instead of "refused".

The 9.6 second block is the design, not a problem

I checked this three ways because a single window has misled me before on a Cosmos chain:

Window	Measured
last 100 blocks	9.62 s
last 1,000 blocks	9.57 s
last 5,000 blocks	9.58 s
whole life (4,580,805 blocks since the April 2025 launch)	~10.0 s

Consistent. Babylon is a slow-block chain on purpose — it is coordinating Bitcoin-signature verification, not racing for throughput. Two consequences worth designing for: do not use "blocks since X" as a proxy for time, and do not copy a 1-second-chain timeout budget. Anything waiting on a Babylon block should budget tens of seconds, and a max_age_num_blocks of 100,000 is roughly 11.3 days of chain history, not a few hours.

What is actually in a Babylon block

The block I sampled at 4,580,800 held 23 transactions, and decoding them gave one message type: MsgAddFinalitySig. That is the chain working — finality providers attesting to the state of consumer chains. Two things follow:

Block "activity" on Babylon is mostly protocol traffic. Counting transactions per block tells you almost nothing about user demand here.
block_results.txs_results is where the useful per-transaction detail lives: each of the 23 txs I sampled reported ordinary Cosmos gas (gas_wanted 126,916 / gas_used 116,127) and 12 events each. And those per-tx events are easy to miss, because the top-level events array on the same response was empty, as were begin_block/end_block — on this chain the events hang off individual results.

Which is the practical version of the same rule: block and block_results are two separate calls. A poller that fetches only block sees 23 transactions and zero events, and concludes — wrongly — that nothing happened.

Also, like every CometBFT 0.38 chain I have measured recently: the header contains no num_txs and no total_txs — 0.38 removed them. Read block.data.txs.length. Code ported from 0.37 gets undefined, which becomes NaN in arithmetic and a silently-empty loop in anything that filters "skip empty blocks".

The pruning floor gave three different answers in six calls

This is the finding to plan around. Requesting block at height 1 six times, alternating between the pool's upstream nodes:

height 1        -> lowest height is 2694820
height 1        -> lowest height is 3017244
height 1000     -> lowest height is 2694820
height 1000     -> lowest height is 2556426
height 1000000  -> lowest height is 3017244
height 1000000  -> lowest height is 2694820

Three distinct floors — 2,556,426, 2,694,820 and 3,017,244 — for the same URL. Each is a different node in the pool, each pruning on its own schedule. Heights at and above ~2.6M resolved fine (2,600,000 → 2026-02-03, 4,000,000 → 2026-07-18); anything older fails with an explicit refusal, which is at least the honest failure mode.

So:

"How far back can I read?" has no stable answer on a pooled RPC. Ask the node at startup — request height 1 and read the error — and treat the highest number you see as the safe floor.
Never cache a historical query's success as proof of retention. One success means one node had it.
Babylon is not addressable as an archive target here (chain_id is null in our own config and no archive flag is set on the HTTP rows), so plan around the ~2.5M+ window, not from genesis. If you need genesis-to-now history, you need an indexer or an archival node you run yourself.

`tx_search` refuses to search

Query	Result
`tx.height=4580802`	113 ms, `total_count=23`
`tx.height>0`	16,095 ms, `Backend node error`
`message.action='/cosmos.bank.v1beta1.MsgSend'`	28,082 ms, `Backend node error`
`tm.event='Tx'`	accepted, `total_count=0`

Exact-height lookup is fast. Ranges and attribute queries burn 16–28 seconds and then error rather than returning a partial answer — the indexer here is not built for them. And tm.event='Tx' is a websocket event query, so through plain HTTP RPC it returns an empty set rather than an error, which is easy to misread as "no transactions match".

If you need "transactions matching X over a period", iterate the heights you care about, or use the LCD's module endpoints. Treat tx_search as a by-height lookup, not a search index.

The LCD is half the API

The RPC gives you blocks and consensus. Babylon's actual domain — BTC staking — is on REST/gRPC, and it answers fast:

# Covenant keys, slashing params, staking thresholds — the BTC-staking rulebook
curl -s https://babylon-rest.publicnode.com/babylon/btcstaking/v1/params

# Unbonding time (21 days) and the 100-validator cap
curl -s https://babylon-rest.publicnode.com/cosmos/staking/v1beta1/params

# Total supply of the base denom; BABY has 6 decimals, so 1 BABY = 1,000,000 ubbn
curl -s 'https://babylon-rest.publicnode.com/cosmos/bank/v1beta1/supply/by_denom?denom=ubbn'

All three returned HTTP 200 in my pass, including the babylon/btcstaking/v1/params path with the covenant public keys that make Babylon's slashing scripts work. If you are building on Babylon staking state, the LCD is the right tool and the RPC is the wrong one — and SwiftNodes carries REST rows alongside RPC for this chain for that reason.

Websocket: what I could and could not verify

I want to be precise here rather than repeat a field in a status page. wss://babylon-rpc.publicnode.com/websocket completed the handshake, answered health, and acknowledged a subscribe to tm.event='NewBlockEvent' — and then delivered no event frames in 40 seconds on a chain that produces a block every ~9.6 seconds, so it should have delivered roughly four. And through our own public path, a WebSocket upgrade on /rpc/babylon currently comes back as a 301 to a docs page rather than a 101.

So: treat Babylon subscriptions as unavailable until proven otherwise, and build on polling at ~10 s intervals. One 40-second sample is not proof of impossibility — but it is enough to stop me recommending a surface I could not get to emit an event.

What this means for your stack

Budget for 9.6-second blocks everywhere: timeouts, staleness thresholds, retry backoff, "how long until final" UX.

Never trust a single pruning measurement. Ask for height 1, take the worst floor you observe, and expect it to differ per call.

Send heights as strings, read errors from the JSON body, and expect no eth_* at all.

Use block_results for events and the LCD for staking state, and treat tx_search as by-height only.

And the reason this is worth reading rather than guessing: every number above came from calling the endpoints, including the one that contradicted itself three times in six calls. SwiftNodes publishes Babylon RPC, gRPC and REST behind one key, and our weekly-measured method support matrix exists because claims that are not measured go stale — Babylon's page is at babylon-rpc.

The short version

Babylon Genesis is CometBFT 0.38.22 on chain bbn-1: ~9.58 s blocks (confirmed across 100/1k/5k windows and the chain's own lifetime average), 68 active validators of a 100 cap, a 21-day unbonding period, ~21 MiB blocks, and no eth_* surface whatsoever. Blocks are mostly MsgAddFinalitySig traffic, so transaction counts are protocol noise rather than demand. tx_search answers exact heights in ~113 ms and fails on ranges after 16–28 s. The header has no num_txs in 0.38, health returns an empty object, and the pruning floor is not one number — six attempts named three different floors (2.55M, 2.69M, 3.02M), because each upstream node prunes on its own schedule. Use the LCD for the BTC-staking state, budget 10 seconds per block, and treat WebSockets as unproven.

https://rpc.swiftnodes.io/rpc/babylon?key=YOUR_API_KEY

One key covers all 86 chains — including the Cosmos-family ones whose surface is nothing like Ethereum's — and the free tier is 2 requests per second, enough to run every probe above and check the pruning floor yourself.

Hyperliquid RPC: A Developer's Guide (Chain 999, 1s Blocks, and a Block Number That Does Nothing)

SwiftNodes — Mon, 21 Sep 2026 07:11:42 +0000

Hyperliquid's EVM is a strange and interesting place to run a node: it finalises blocks about once a second, charges a base fee that never moves, and rejects eth_maxPriorityFeePerGas-style market pricing entirely. But the thing that will actually cost you time is quieter. Ask this endpoint for state at a historical block and it will answer — cheerfully, with an empty error field — using the latest state. There is no archive fallback to save you, because the request never looks like it failed.

Everything below was measured on 2026-09-21 through https://rpc.swiftnodes.io/rpc/hyperliquid. Every claim here is a call you can re-run in a minute; the one that matters most has the exact recipe below.

The essentials


Chain ID	`999` (`0x3e7`) — `net_version` agrees, `web3_clientVersion` reports `hyperliquid evm Mainnet`
Block time	~0.985 s (measured over 600 blocks)
Head at time of writing	`46,479,662`
Gas	`baseFeePerGas` of 100,000,000 wei (0.1 gwei) in every block sampled; `gasLimit` 3,000,000
`eth_maxPriorityFeePerGas`	Returns `0x0` — there is no priority-fee market
Block history	~1.21M blocks (~14 days). Older heights error out
State history	Not honoured — see the section below
WebSocket	None. `eth_subscribe` → `-32601`, no `rpc_ws` on the route
`eth_getLogs`	Capped at 1,000 blocks and a 1 MiB response
Tracing	`debug_traceBlockByNumber`, `trace_`, `txpool_` all `-32601`
HTTP	`https://rpc.swiftnodes.io/rpc/hyperliquid?key=YOUR_API_KEY`

Connecting: the setup

Standard EVM JSON-RPC, and standard clients work — with the caveats below doing the real work.

curl

curl -s -X POST https://rpc.swiftnodes.io/rpc/hyperliquid?key=YOUR_API_KEY \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
# 0x2c5382e  -> 46,479,405

viem

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

export const hyperliquid = {
  ...mainnet,
  id: 999,
  name: 'Hyperliquid',
  rpcUrls: { default: { http: ['https://rpc.swiftnodes.io/rpc/hyperliquid?key=YOUR_API_KEY'] } },
};

const client = createPublicClient({ chain: hyperliquid, transport: http() });
const block = await client.getBlockNumber();

ethers v6

import { JsonRpcProvider } from 'ethers';
const provider = new JsonRpcProvider(
  'https://rpc.swiftnodes.io/rpc/hyperliquid?key=YOUR_API_KEY', 999);
await provider.getNetwork();   // { chainId: 999n, name: 'unknown' }

eth_accounts returns -32601 Method not found rather than an empty array, so anything that probes for unlocked accounts will take an exception rather than a length-0 list.

The block number is decorative

This is the finding worth structuring your code around.

Take a contract that was deployed at block 46,479,401 — 261 blocks, about four minutes, before the head I was reading — and ask for its code at heights before that moment existed:

`eth_getCode` block param	Returned
`46,479,400` (1 block before deploy)	`0x6080604052348015600e575f80fd5b50…` — 342 chars
`46,478,401` (1,000 blocks before)	same 342 chars
`46,379,401` (100,000 blocks before)	same 342 chars
`0x1` (height one)	same 342 chars

A correct node must answer 0x for every height before the deployment, because the account did not exist. It answers with the current bytecode at all four. eth_getBalance and eth_getStorageAt behave the same way, and eth_getBlockReceipts at height 1 errors with invalid block height: 1 — so the node clearly knows block 1 is unavailable and still happily serves you "state" at block 1.

Read that precisely: block-tagged state reads are answered from the latest block. Not pruned-and-erroring, not approximate — silently wrong, and indistinguishable from a correct answer unless you test it.

The probe, so you can run it against any provider you are evaluating:

H=https://rpc.swiftnodes.io/rpc/hyperliquid?key=YOUR_API_KEY
# 1. find a contract deployed recently
R=$(curl -s -X POST $H -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["<recent creation tx hash>"]}' \
  | sed -E 's/.*"contractAddress":"(0x[a-fA-F0-9]{40})".*/\1/')
# 2. ask for its code at height 1
curl -s -X POST $H -H 'Content-Type: application/json' \
  -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_getCode\",\"params\":[\"$R\",\"0x1\"]}"

If step 2 returns anything other than "result":"0x", historical state is not being honoured — no matter what the endpoint advertises, and no matter what a health check that only looks at HTTP status tells you.

Practical consequences:

Never use a historical block tag for a real balance or nonce here. If you need state as of a past block, you need an indexer that recorded it, not this RPC.
Reorg-safe nonce/balance logic that pins blockNumber "for consistency" gets no consistency guarantee — you are reading head under a label.
Indexers built on debug_*/archive traces cannot bootstrap from this endpoint. Event-log indexing is the path that works (see the caps below), because logs are fetched per block range and are block-accurate.

What's different from a mainstream EVM node

No WebSocket at all

There is no ws/wss route for this chain on SwiftNodes, and eth_subscribe over HTTP returns -32601 Method not found. Nothing is half-open: subscriptions simply do not exist here. Poll at ~1 s to track ~1 block per poll, or use an external feed for low-latency updates. Do not assume the absence of a WS error means your subscription is working — check that you ever received a confirmation ID.

A base fee that barely moves

Across eight sampled blocks, baseFeePerGas was 100000000 wei in every one — 0.1 gwei — and gasLimit was pinned at 3,000,000. eth_feeHistory does show slight variation (0x651a00b ≈ 0.106 gwei alongside 0x5f5e100), so the mechanism exists; it is simply clamped to within a few percent and does not respond to demand the way an L1 does. eth_maxPriorityFeePerGas returns 0x0. So EIP-1559 fee estimation is effectively meaningless here: there is no market to estimate. Transactions in the blocks I sampled were type-2 with a user-chosen gasPrice of 1.6 gwei against a maxFeePerGas of 30 gwei, so senders are setting their own ceiling and the near-fixed base fee just gets burned.

The practical rule: hard-code a sane maxFeePerGas, skip fee estimators, and treat eth_gasPrice as a constant rather than a signal.

Block history is about two weeks

oldest readable block   ~45,269,661
head                     46,479,662
retained                  1,209,840 blocks   (~13.9 days at 0.985 s)

Heights older than that fail explicitly, which is the good case:

{"code":-32603,"message":"invalid block height: 1000000"}

earliest is not supported either — it comes back as invalid block height: 0. Anything that expects a canonical earliest tag needs a fallback to a numeric height.

eth_getLogs has two different ceilings

Range	Result
100 blocks	1,055 logs, ~400 ms
300 blocks	`{"code":-32008,"message":"Response is too big","data":"Exceeded max limit of 1048576"}`
1,000 blocks	same `-32008`
5,000 blocks	`{"code":-32602,"message":"query exceeds max block range 1000"}`

Two independent limits, and the byte cap bites first. A 1,000-block window is nominally allowed but fails on any busy stretch, so "1000 blocks" is not the number to design around — the number is whatever fits in 1 MiB, which on Hyperliquid means ~100 blocks during activity. Chunk by 50–100 blocks, and handle -32008 by halving the range rather than surfacing an error. Note also that the two error codes are different for the two causes, so a retry policy keyed on one will miss the other.

Tracing is absent

debug_traceBlockByNumber → does not exist/is not available; trace_replayBlockTransactions and txpool_status → -32601. No simulation-adjacent introspection, no mempool visibility — which fits a chain whose execution is driven by an order book rather than a public mempool. If your stack has a debug_traceTransaction fallback path, it will not fire here.

The transaction object carries an extra field

eth_getBlockByNumber with full transactions returns a blockTimestamp on each tx alongside the standard fields. It is additive, so most clients ignore it; if you decode transactions into a strict schema, allow for the extra key.

Not every upstream behaves the same

This route pools more than one Hyperliquid node. Against a busy eth_getLogs window one answered -32008 Response is too big and another answered -32005 rate limited; the same split showed on debug_traceBlockByNumber. If you are building retry or circuit-breaker logic, key it on the JSON-RPC code rather than assuming one error shape per condition.

What this means for your stack

Test the block tag before trusting it. One eth_getCode on a freshly deployed contract tells you whether an endpoint honours history. On this route it does not.

Design around ~100-block log chunks, and treat "response too big" as a normal control signal, not a failure.

Do not fee-estimate. Fixed 0.1 gwei base fee, priority fee of zero.

Plan without WebSocket or tracing. Poll at ~1 s; accept that mempool and debug surfaces do not exist.

And do not treat a 200 OK on a historical read as proof of anything — that is the entire lesson of this endpoint.

The short version

Hyperliquid's EVM is chain 999, blocks about every 0.985 s, a near-fixed 0.1 gwei base fee with a 3,000,000 gas limit, and no priority-fee market. It has no WebSocket, no debug_*/trace_*/txpool_*, and holds roughly 1.21M blocks (~14 days) of history, erroring cleanly beyond that. eth_getLogs is bounded by both a 1,000-block range and a 1 MiB response, and the byte limit arrives first at about 100 blocks of activity. The important part: block-tagged state reads are answered from the latest block — eth_getCode for a contract deployed seconds ago returns its full bytecode at height 1, so historical balances, nonces and storage slots cannot be recovered here and will not warn you.

For Hyperliquid RPC across load-balanced independent upstreams, grab a free API key and point your client at:

https://rpc.swiftnodes.io/rpc/hyperliquid?key=YOUR_API_KEY

One key covers all 86 chains, and the free tier is 2 requests per second — enough to run the eth_getCode probe above against this and every other endpoint you rely on. That probe takes about ninety seconds and it is the only way to know whether the "archive" node you are paying for is telling you the truth about the past.

Neutron RPC: A Developer's Guide (neutron-1, CometBFT 0.38, No eth_*)

SwiftNodes — Sun, 20 Sep 2026 11:28:01 +0000

Neutron is not an EVM chain, and the RPC reflects that: there is no eth_* surface at all, no numeric chain ID, and the request shape is CometBFT JSON-RPC rather than the Ethereum method set. None of that is surprising once you have read a Cosmos RPC reference — but each of these will break a piece of code you already have, and a few of them will not break it loudly.

Everything below was measured on 2026-09-20 through https://rpc.swiftnodes.io/rpc/neutron, against the same chain from a second independent endpoint for anything I did not want to take on trust. Re-run any of it.

The essentials


Network / chain ID	`neutron-1` (a string — there is no numeric chain ID)
Consensus client	CometBFT `0.38.19` (protocol p2p 8, block 11, app 0)
Block time	~7.0 s measured this week, ~2.05 s over the preceding months — see below
Head at time of writing	`61,612,831`
Validators	11 active, 11 signatures in `last_commit`, `ed25519`
Block limits	`max_bytes` 22,020,096 (~21 MiB), `max_gas` 330,000,000
EVM methods	None. `eth_chainId` → `-32601 Method not found`
HTTP	`https://rpc.swiftnodes.io/rpc/neutron?key=YOUR_API_KEY`
Execution layer	CosmWasm (`wasmvm`) contracts, not the EVM

Connecting: the setup

CometBFT RPC is JSON-RPC 2.0 over POST, with the method name in the body. There are no params arrays in the Ethereum sense — most methods take an object, and many take nothing.

curl

# node + sync state
curl -s -X POST https://rpc.swiftnodes.io/rpc/neutron?key=YOUR_API_KEY \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"status","params":{}}'

# a specific block by height
curl -s -X POST https://rpc.swiftnodes.io/rpc/neutron?key=YOUR_API_KEY \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"block","params":{"height":"61612831"}}'

The one thing to get right early: this path is POST-only. A GET /status — which works against a bare CometBFT node on port 26657 — returns 404 here. Clients built around the Tendermint REST-style paths will need the JSON-RPC-over-POST form instead.

A tiny fetch helper

const RPC = "https://rpc.swiftnodes.io/rpc/neutron?key=YOUR_API_KEY";

async function rpc(method, params = {}) {
  const r = await fetch(RPC, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  const j = await r.json();
  if (j.error) throw new Error(`${method}: ${j.error.message} ${j.error.data ?? ""}`.trim());
  return j.result;
}

const s = await rpc("status");
const height = Number(s.sync_info.latest_block_height);   // 61612831 at time of writing
const block  = await rpc("block", { height: String(height) });
console.log(block.block.header.chain_id);                 // "neutron-1"

Note the explicit error check. CometBFT signals most failures as a JSON-RPC error object with HTTP 200, so a client that only looks at status codes will treat "height is not available" as a successful response with a missing field.

CosmJS users: Tendermint37Client / HttpBatchLink speak this same POST-to-root JSON-RPC, so the endpoint drops in. Verify the version handshake yourself rather than assuming — this node reports CometBFT 0.38.19, and the client you pick has to tolerate that.

What's different from an EVM chain

There is no chain ID number

eth_chainId returns -32601 Method not found, and our own status API reports chainId: null for this chain. The identifier is the string neutron-1, and it lives in status.node_info.network and in every block header. Anything in your code that expects an integer — a switch (chainId) on a config map, a wallet addEthereumChain call, a chain-registry lookup keyed by number — needs a string key here.

Two header fields vanished in CometBFT 0.38

The header I read at block 61,612,809 had exactly these keys:

version, chain_id, height, time, last_block_id, last_commit_hash, data_hash,
validators_hash, next_validators_hash, consensus_hash, app_hash,
last_results_hash, evidence_hash, proposer_address

There is no num_txs and no total_txs — 0.38 removed them. Code that reads header.num_txs gets undefined, which in JavaScript means NaN in arithmetic and a silently empty loop in a "skip empty blocks" filter. The replacement is the transaction list itself: result.block.data.txs.length (the block I sampled contained 1 tx).

`health` returns an empty object

{"jsonrpc":"2.0","id":1,"result":{}}

No is_node_healthy field, from either this route or the upstream directly — so a readiness probe that checks result.is_node_healthy === true will read undefined and fail, and one that checks result.is_node_healthy !== false will pass on a node that is down. Use status.sync_info.catching_up === false instead, and treat a failed status call as unhealthy. status.validator_info also came back null here, so don't build on it either.

Block production is not what the docs say

This is the one I would not have believed without measuring twice.

Window	Measured
last 100,000 blocks (2026-09-12 → 09-20)	7.02 s / block
last 5,000 blocks	7.001 s
last 1,000 blocks	6.995 s
last 200 blocks	6.979 s
block 56,000,000 (2026-05-10) → head	2.05 s / block

Consecutive blocks were 7.40, 1.56, 7.41, 7.72, 7.45, 7.44 s apart — so this is a steady ~7 s cadence with occasional fast blocks, not one slow block skewing an average. I repeated the same measurement against a second, independent RPC and got 6.979 s and 7.001 s for the 200- and 2000-block windows, which rules out anything about the route in between.

Read that as: Neutron's long-run rate is ~2 s, and as of this week it is producing at roughly 7 s. Anything you have tuned against a 2 s assumption — a poll interval, a "stale tip" alert threshold, a timeout budget, a UI's "synced" indicator, an ETA in blocks — is currently wrong by about 3.5×. If you have a fixed-interval poller, make it interval-based rather than block-count-based, and set the stall threshold from a measurement you take today, not from a spec.

History: the floor moves between nodes

This is the part that will bite you in production.

Requesting block at height 1 does not return an empty result — it returns an explicit refusal naming the node's own retention floor:

{"code":-32603,"message":"Internal error",
 "data":"height 1 is not available, lowest height is 55481501"}

Then, minutes later, the same request through the same URL named a different floor: 61317000. And block at 61,317,000 failed while 61,317,001 succeeded.

That is not flakiness in the transport. A pool of independent RPC nodes each prune on their own schedule, so "how far back can I read?" has no single answer on a load-balanced endpoint. Observed floors on this route today spanned 55,481,501 to 61,317,000 — a difference of ~5.8 million blocks, i.e. one node kept months more history than another.

Practical consequences:

A historical read may succeed and then fail on the next identical call. Design for it: retry, and if the query matters, pin it to a specific archival endpoint rather than a pooled one.
Do not infer "archive" from a successful old-block read. One success means one node had it.
?archive=1 is an EVM routing hint on SwiftNodes; it does not apply to CometBFT chains like this one.

For reference, the genesis method reports genesis_time: 2025-11-28T11:42:18Z with initial_height: 1 — which cannot be reconciled with a chain at height 61.6M. Treat the genesis result as a consensus-parameter document (chain ID, validator set, upgrade heights), not as a reliable chain birthday. A third endpoint I probed returned no genesis at all.

The methods you'll actually use

Method	What it gives you	Notes
`status`	network, CometBFT version, head height/time, `catching_up`	your real health check
`block`	header + txs + `last_commit` for one height	`params.height` as a string
`block_results`	events and per-tx results for a height	separate call from `block`
`blockchain`	compact metadata for a height range	cheap way to walk history
`tx`	one transaction by hash, with proof
`tx_search`	find txs by query	see the warning below
`validators`	the set at a height	`total` came back 11
`consensus_params`	block limits, evidence rules, vote-extensions height
`broadcast_tx_sync` / `_async` / `_commit`	submit a tx	`_commit` waits for inclusion
`abci_query`	raw app state (contracts, params, stores)	the Cosmos equivalent of a storage read

block and block_results are two calls. Events — the thing you usually actually want — live in block_results, so a poller that fetches only block sees transactions with no results and reports nothing happened.

tx_search: some queries do not answer

Query	Result
`tx.height=61612805`	129 ms, `total_count=1`
`message.action='/cosmwasm.wasm.v1.MsgExecuteContract'`	17,245 ms, `total_count=47532`
`tx.height>0`	28,066 ms, then `Backend node error`

Exact-height lookups are fast. Attribute searches are served, but slowly and at large result counts, and an unbounded range query does not return at all — it burns ~28 s and then errors. If you need "all txs matching X over a period", iterate strict heights or use an indexer; do not hand tx_search a wide range and wait.

On the dYdX route we also saw a stricter rule — tx.height>0 rejected outright with -32701 "please specify tx.height event with strict equality". Different operators configure the indexer differently, so treat tx_search as capability you must probe per endpoint, not a guarantee of the RPC spec.

WebSocket

wss is available on this chain and our status API reports wsAvailable: true. The subscription handshake is CometBFT's, not Ethereum's: method subscribe with query, e.g. {"jsonrpc":"2.0","id":1,"method":"subscribe","params":{"query":"tm.event='NewBlockEvent'"}}, and events arrive as notifications on that subscription rather than as eth_subscribe IDs. If your code already handles eth_subscribe, this is a rewrite of the subscription layer, not a config change.

What this means for your stack

Check your assumptions about time. ~7 s blocks against a 2 s baseline changes every block-count-derived number in your system: staleness thresholds, retry backoffs, "confirmations", and how long a poll interval can be before you look dead.

Stop reading num_txs. It is gone in 0.38 and its absence is silent. Use data.txs.length.

Treat health as unusable on this surface and gate readiness on status.sync_info.catching_up.

Assume history is partial. Ask the node what its floor is by requesting height 1 and reading the error, and do that at startup rather than discovering it on a user-facing query.

Verify capability by calling it. eth_chainId, tx_search ranges and old-block reads are three places where this chain told the truth only when asked directly. SwiftNodes publishes a weekly-measured method-support matrix for exactly this reason — the EVM half of it is at Method support, and the full chain list is at /chains.

The short version

Neutron speaks CometBFT 0.38.19 JSON-RPC over POST on chain neutron-1, with 11 validators, ~21 MiB blocks and a max_gas of 330,000,000. There is no numeric chain ID and no eth_* surface at all; num_txs and total_txs are gone from the header in 0.38; health returns an empty object so readiness has to come from status; block and block_results are separate calls; wide tx_search queries time out where exact-height ones answer in ~130 ms; and the pruning floor differs between nodes in the same pool (55.48M to 61.32M observed today), so historical reads are not reliable on a pooled endpoint. The number to watch: blocks measured 7.02 s over the last 100k, against a 2.05 s average across the preceding five million — a live 3.5× slowdown, confirmed against a second independent RPC.

For Neutron RPC across load-balanced independent upstreams, with HTTP, gRPC, REST and WebSocket, grab a free API key and point your client at:

https://rpc.swiftnodes.io/rpc/neutron?key=YOUR_API_KEY

One key covers all 86 chains, and the free tier is 2 requests per second — enough to run every probe above, including the block-time windows, and check this week's numbers for yourself.

Arbitrum RPC: A Developer's Guide (Chain ID 42161, ~250ms Blocks, Fake Gas Limit)

SwiftNodes — Sat, 19 Sep 2026 07:13:42 +0000

Arbitrum One is the rollup most Ethereum code runs on unmodified, and that is exactly the problem: it does run, right up until a number stops meaning what your code assumes it means. The block gas limit is a placeholder. The priority fee is zero. safe and finalized move on a scale of minutes, not the seven days everyone associates with optimistic rollups. None of these will throw an error at you — they will just quietly make your dashboards, alerts and fee logic wrong.

Everything below was measured today through https://rpc.swiftnodes.io/rpc/arbitrum, so you can re-run every probe yourself.

The essentials

Chain ID: 42161 (0xa4b1)
Block height at time of writing: ~506,697,453
Block time: ~250 ms (measured 18 blocks in 4 seconds)
Gas token: ETH, 18 decimals
Base fee: ~0.02 gwei (0.020224 gwei measured)
Priority fee: eth_maxPriorityFeePerGas returns 0
Block gas limit: 1,125,899,906,842,624 — that is exactly 2⁵⁰, a sentinel, not capacity
Stack: Nitro, sequencer-ordered, proofs posted to Ethereum
WebSocket: supported, eth_subscribe verified working
Archive state: not served on this route — see Archive access

The latency of the endpoint you pick matters more here than on most chains. At 250 ms blocks, a provider that adds 300 ms of round trip makes you feel every round trip roughly once per block.

Connecting: the setup

curl

# Chain ID — expect 0xa4b1 (42161)
curl -s -X POST https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0xa4b1"}

# Latest block
curl -s -X POST https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

# Fee ceiling — the number you actually want
curl -s -X POST https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x1336750"}   = 0.020145744 gwei

viem

Stating the chain explicitly keeps working on every version, and it puts the field that matters in front of you:

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

const arbitrum = defineChain({
  id: 42161,
  name: 'Arbitrum One',
  nativeCurrency: { name: 'Ether', symbol: 'ETH', decimals: 18 },
  rpcUrls: {
    default: { http: ['https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY'] },
  },
});

const client = createPublicClient({ chain: arbitrum, transport: http() });

const blockNumber = await client.getBlockNumber();
const gasPrice = await client.getGasPrice(); // ~0.02 gwei

ethers v6

import { JsonRpcProvider } from 'ethers';

const provider = new JsonRpcProvider(
  'https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY',
  42161,
);

await provider.getBlockNumber();

What's the same as Ethereum

The eth_* surface is complete and standard: eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_sendRawTransaction, filters, eth_feeHistory, the pending/safe/finalized tags. Solidity contracts, ABIs, viem, ethers, Foundry and Hardhat all work as-is. That compatibility is genuinely excellent and it is why Arbitrum won.

Blocks even carry the fields you expect, which is what makes the next section easy to miss.

What's different from Ethereum

The block gas limit is a sentinel

Fetch a block and read gasLimit:

curl -s -X POST https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1}'

The block I pulled reported gasLimit: 0x4000000000000 — that is 1,125,899,906,842,624, exactly 2⁵⁰ — with gasUsed of 398,374 in the same block. Any calculation of the form "this block is 0.0000354% full" or "I have 1.1 quadrillion gas of headroom" is nonsense. Nitro does not bound blocks the way L1 does; capacity is governed by the sequencer and by a separate per-second gas supply.

Practical consequence: never size a transaction against the block gas limit here. Use eth_estimateGas for the transaction you are sending, and treat the block's gasLimit as decoration. If you run a mempool-style backlog monitor or a "block utilization" alert copied from an L1 dashboard, it is reporting a constant on Arbitrum.

Priority fee is zero, and that is not an error

curl -s -X POST https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_maxPriorityFeePerGas","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x0"}

eth_maxPriorityFeePerGas answers with 0x0. The RPC is not broken — the fee market is not a two-dimensional auction here, so there is no tip component to estimate. Inclusion is the sequencer's decision, not a bidding contest between validators.

Two things follow. The common maxFeePerGas = 2 × baseFee + tip recipe computes 2 × baseFee + 0, which is fine but adds nothing; and "bump the priority fee to unstick a stuck transaction" does not work as an operational lever on this chain. If your retry logic escalates tips, it is burning effort on a parameter the sequencer ignores. Read estimating gas properly for where these heuristics stop transferring.

`safe` and `finalized` are minutes, not days

This is the one that surprises people most. Measured directly:

tag	block	behind head	~time behind
`latest`	506,697,453	0	0 s
`safe`	506,694,431	3,022 blocks	~13 min
`finalized`	506,692,973	4,480 blocks	~19 min

"Optimistic rollup means seven days" describes the challenge window for exiting to L1, not how these block tags advance. They move on a minutes scale, tracking what nodes have confirmed among themselves. So if your code waits for finalized believing it has crossed the dispute window, it is waiting roughly twenty minutes for a guarantee that the tag does not carry.

For value-bearing operations, decide what you actually need. If you need "the sequencer will not reorder this", safe is a reasonable marker. If you need "this is unarguably true on Ethereum", track the Rollup contract's confirmed roots on L1 — a different query entirely. Soft vs hard finality on L2s covers the distinction.

Consensus fields are placeholders

The same block object carries difficulty: 0x1, nonce: 0x0000000000273449, and uncles: []. There is no proof of work and no uncle mechanism; these are fixed or structural values kept so L1-shaped code keeps parsing. It also carries one field L1 blocks do not have: l1BlockNumber, an explicit pointer into Ethereum. That pairing is useful — it is how you tie an Arbitrum block back to L1 context — but do not expect it from tools written against mainnet types.

System addresses answer with `0xfe`

A check written as "does code exist at this address?" behaves oddly. Querying Arbitrum's system addresses returned the single byte 0xfe rather than contract bytecode, while a nearby unused address returned plain 0x. So a naive non-empty-code test reads as "something is deployed here" and gives you nothing to decode. Check the specific address list you care about rather than inferring from code size.

The `arb_*` namespace may not be there

Every Arbitrum-specific method I tried through our endpoint was refused:

{"error":{"code":-32601,"message":"the method arb_getStorageRoot does not exist/is not available"}}

That applies to the arb_* names I probed (arb_getBlockReceipts, arb_getStorageRoot, arb_getChainConfig, arb_getNodeInterfaceVersion, arb_getAddressTable). Availability of this namespace is a provider-by-provider decision, so treat it as absent until you have confirmed it on your own endpoint — and if you are migrating from a provider that exposed it, that migration is where things break, not in the standard eth_* calls. The -32601 shape is covered in JSON-RPC error codes, decoded.

The methods you'll actually use

Task	Method	Arbitrum note
Current height	`eth_blockNumber`	~250 ms blocks; height moves fast
Read contract	`eth_call`	standard
Fee ceiling	`eth_gasPrice`	~0.02 gwei
Tip	`eth_maxPriorityFeePerGas`	returns 0; not a lever
Gas units	`eth_estimateGas`	do not compare to block gasLimit
Events	`eth_getLogs`	bound ranges — range caps
L1 mapping	block `l1BlockNumber`	Arbitrum-specific extra field
Balance	`eth_getBalance`	18 decimals

Nothing exotic; the traps are all in what the numbers mean. The general RPC endpoint primer and the Ethereum reference are the baseline this one is a diff against.

Archive access

Be deliberate here if your workload reads history, because Arbitrum archive is a weak point right now.

A state read at an early block on the default route came back with a provider's own gating message rather than data:

Archive requests require a personal token. Get one at: https://www.allnodes.com

and forcing archive routing with ?archive=1 returned a malformed upstream body instead of a clean error. Two lessons, both general:

Verify archive with a real historical query before you build on it. Ask for eth_getBalance at block 2 and see what comes back. A provider that serves eth_blockNumber beautifully may not be keeping state.
An error's status code can lie about its category. "Archive requests require a personal token" is a billing statement wearing the clothes of an RPC failure. Distinguishing capability limits from transient faults is the whole game in retry design — retry and backoff covers the taxonomy, and full node vs archive node explains why this tier costs what it costs.

Recent-state reads, receipts and logs across recent ranges work normally. If you need deep historical state on Arbitrum, confirm it with your provider explicitly rather than assuming from the word "archive" appearing on a pricing page.

WebSocket subscriptions

Verified end to end on this chain — subscribe, then a real head within about a second:

+414ms   OPEN
+620ms   eth_subscribe -> 0x77888af906b7608f…
+743ms   newHeads notification, block 506,697,680

const ws = new WebSocket('wss://rpc.swiftnodes.io/ws/arbitrum?key=YOUR_API_KEY');
ws.onopen = () => ws.send(JSON.stringify({
  jsonrpc: '2.0', id: 1, method: 'eth_subscribe', params: ['newHeads'],
}));

At 250 ms blocks, treat notifications as a signal to re-read rather than a queue you must not miss — you will drop heads during any reconnect. Surviving WebSocket reconnects without losing events is the pattern, and our Arbitrum WebSocket write-up covers this chain's specific failure modes.

Compared to the L2s around it

	Arbitrum One	Base	Polygon zkEVM	Gnosis Chain
Chain ID	42161	8453	1101	100
Block time	~250 ms	~2 s	~1 s post-batches	~5 s
Block gasLimit	2⁵⁰ sentinel	real limit	real limit	real limit
Priority fee	0	normal	normal	normal
`finalized` behind	~19 min	~1 s	proof-based	~5 min
EVM	Yes	Yes	Yes	Yes

Base shares the sequencer model but not the fee shape or the sentinel limit. The zkEVM columns are in its own guide, and the sequencer concept behind all of these is unpacked in what a sequencer is.

Production considerations

Poll like you mean it. At 250 ms blocks a 12-second poll interval is roughly 48 blocks of blind spot. Either subscribe or shorten the interval, and bound requests with JSON-RPC batching where you need many reads.

Never derive capacity from gasLimit. It is a constant. Estimate per transaction.

Stop escalating tips. They are zero here by design; use eth_gasPrice and a margin.

Re-label what "finalized" means in your own code. If a risk model treats it as the seven-day window, it is 20 minutes of comfort instead of a week of certainty.

Index with confirmations you can defend. Chain reorganisation here is sequencer-level, not PoW-style; handling chain reorgs in indexers is the pattern.

Confirm archive before depending on it, as above, on any chain you choose.

Choosing an Arbitrum RPC endpoint

1. What is its end-to-end latency to you? On a 250 ms chain, the round trip is the whole user experience. Measure it yourself from your own region rather than trusting a marketed number — public versus paid endpoints covers what actually moves once you are past the free tier.

2. What happens when its upstream is behind or rate-limited? A single upstream gives you its outages and its 429s. Failover across independent endpoints is the difference between a blip and an incident, which is the point of routing through a layer that tries several upstreams per request and benches any that fall behind the chain head.

3. Will it tell you the truth about capabilities? The good answer is a measured one. Check eth_getCode on a chain-specific address, try an arb_* method, request a balance at block 2. A provider that admits what it does not serve saves you a production discovery.

The short version

Arbitrum One (chain ID 42161) speaks standard eth_* on ~250 ms blocks, so nearly all Ethereum code and tooling works unchanged. What changes is meaning: the block gasLimit is the sentinel 2⁵⁰ rather than capacity, eth_maxPriorityFeePerGas returns 0 because inclusion is sequenced not auctioned, difficulty and nonce are placeholders, blocks carry an extra l1BlockNumber, arb_* methods may be refused, and safe/finalized sat about 3,022 and 4,480 blocks behind head — roughly 13 and 19 minutes — not the seven-day dispute window. Archive state reads are currently the weak spot on this route, so verify any historical read with a real query.

For Arbitrum RPC with per-request failover across independent upstreams and a working eth_subscribe, grab a free API key and point your app at:

https://rpc.swiftnodes.io/rpc/arbitrum?key=YOUR_API_KEY

One key covers all 75 chains, and the free tier is 2 requests per second — enough to run every probe above, including the finality measurements, while you check the numbers for yourself.

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Ethereum Classic RPC: A Developer's Guide (Chain ID 61, No EIP-1559)

SwiftNodes — Fri, 18 Sep 2026 10:46:14 +0000

Ethereum Classic is the awkward one in the EVM family. It isn't a rollup, isn't a sidechain, and didn't fork off Ethereum's design — it is the original Ethereum chain, continuing the history that the majority of the community abandoned at block 1,920,000 in July 2016. Every block before the fork is literally the same blocks, with the same hashes, on both chains.

For a developer, that shared lineage creates a specific set of assumptions that quietly stop being true. The fee market is the big one: Ethereum Classic never activated EIP-1559, so blocks carry no base fee, and the transaction-fee code you copied from an Ethereum tutorial is solving a problem this chain doesn't have. The other is finality: it's still proof-of-work, so there is no finalized block to wait for.

Everything below is measured through https://rpc.swiftnodes.io/rpc/etc on 2026-09-18, so you can re-run each probe yourself.

The essentials

Chain ID: 61 (0x3d)
Block height at time of writing: 25,367,599 (0x183142f)
Block time: ~13–15 seconds (we measured 3 blocks across 45 seconds)
Gas token: ETC, 18 decimals
Consensus: Proof of work (Etchash)
Fee market: Legacy gasPrice. No EIP-1559 base fee
Reference client: Core Geth — eth_getBlockByNumber is served by CoreGeth/hebeblock/v1.12.20-stable
Gas limit: 8,000,512 per block (0x7a1200)
Archive history: Not available on our endpoints — see Archive access

The block limit is worth noticing: 8,000,512 gas per block, against Ethereum's 36 million. Your largest single transactions need to fit inside that, and a contract that pushes a block-size boundary on Ethereum may behave differently here.

Connecting: the setup

curl

# Chain ID — expect 0x3d (61), not 0x1
curl -s -X POST https://rpc.swiftnodes.io/rpc/etc?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x3d"}

# Latest block
curl -s -X POST https://rpc.swiftnodes.io/rpc/etc?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

# Legacy gas price — this is the fee number you actually use
curl -s -X POST https://rpc.swiftnodes.io/rpc/etc?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x28fa6ae00"}   = 11 gwei

viem

Most tooling has an entry for Ethereum Classic, but the safest portable form is to state the chain explicitly — this works regardless of which version you're on, and it makes the one field that matters (chainId: 61) visible:

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

const classic = defineChain({
  id: 61,
  name: 'Ethereum Classic',
  nativeCurrency: { name: 'ETC', symbol: 'ETC', decimals: 18 },
  rpcUrls: {
    default: { http: ['https://rpc.swiftnodes.io/rpc/etc?key=YOUR_API_KEY'] },
  },
});

const client = createPublicClient({ chain: classic, transport: http() });

const blockNumber = await client.getBlockNumber();
const gasPrice = await client.getGasPrice(); // 11 gwei at time of writing

ethers v6

import { JsonRpcProvider } from 'ethers';

const provider = new JsonRpcProvider(
  'https://rpc.swiftnodes.io/rpc/etc?key=YOUR_API_KEY',
  61, // chainId — pinning it stops the provider silently trusting a mismatched node
);

await provider.getBlockNumber();

Pinning the chainId in ethers is worth the one argument. Because ETC and ETH share a genesis and most of their history, a mislabelled endpoint is easy to mistake for a working one.

What's the same as Ethereum

The RPC surface is standard eth_*. Nothing exotic:

Same methods. eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_sendRawTransaction all behave as documented for Ethereum.
Same ABI and tooling. Solidity compiles and deploys unchanged. Foundry, Hardhat, viem, ethers all work.
Same precompiles, including the bn256 pairings. This is the one I expected to be a problem and it isn't. An empty eth_call to the pairing precompile returns the vacuously-true result on both chains:

# ecPairing (0x08) with empty input -> 0x...01 on both chains
curl -s -X POST https://rpc.swiftnodes.io/rpc/etc?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x0000000000000000000000000000000000000008","input":"0x"},"latest"],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x0000...0001"}

Identical output from /rpc/eth and /rpc/base. Snark-verification libraries and anything leaning on ecadd/ecmul/ecpairing will not be the thing that breaks you here.

Same receipt and log semantics, including logsBloom and uncle handling.

What's different from Ethereum

There is no base fee

Ask for the latest block and count the fields:

curl -s -X POST https://rpc.swiftnodes.io/rpc/etc?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1}'

The returned object includes difficulty, mixHash, nonce, miner, totalDifficulty, sha3Uncles and uncles. It does not include baseFeePerGas. That absence is the whole story:

{ "number": "0x183142f", "gasLimit": "0x7a1200",
  "difficulty": "0x6c54c9424b9f9", "miner": "0x…",
  "mixHash": "0x…", "nonce": "0x…" }
// no baseFeePerGas key at all

The familiar maxFeePerGas = 2 × baseFee + tip recipe has nothing to multiply. Use eth_gasPrice and send a legacy transaction.

`eth_maxPriorityFeePerGas` answers — and that answer is a trap

This one deserves its own warning, because it will not fail loudly:

curl -s -X POST https://rpc.swiftnodes.io/rpc/etc?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_maxPriorityFeePerGas","params":[],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"result":"0x28fa6ae00"}   = 11 gwei

It returns 0x28fa6ae00 — the exact same value as eth_gasPrice. The node is handing back its legacy gas-price suggestion through the 1559 method name. It is not a tip, and it is not a priority fee. Code that calls it, believes the name, and then sets maxFeePerGas to tip * 2 will produce a meaningless fee ceiling on this chain — and the estimation call won't stop you, because eth_estimateGas happily accepts EIP-1559-shaped transaction objects and returns a normal result.

Read the fee from eth_gasPrice. Treat the 1559 methods as absent even though one of them replies.

Finality is probabilistic

Proof of work means uncles, and uncles mean the head block can be superseded. There is no finalized block tag to wait on here, and no challenge window to reason about either — that's an optimistic-rollup concept. Your tool is confirmation count, and it needs to be larger than your reflex Ethereum number because blocks arrive roughly every 13–15 seconds rather than every 12.

For anything holding value, index and display the block you were included in and wait out a reorg, rather than assuming the latest block is durable. The mechanics are identical to any other PoW chain — our guide to handling reorgs in indexers covers the pattern.

Block numbers below 1,920,000 mean two different things

This is a data-modelling bug rather than an RPC bug, and ETC is the only chain where you'll hit it. Because the chains share history, block hashes below the fork are byte-identical. Ask both chains for block 1,919,999 — the last block before the fork:

for c in etc eth; do
  curl -s -X POST https://rpc.swiftnodes.io/rpc/$c?key=YOUR_API_KEY \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1d4bff",false],"id":1}' \
    | python3 -c "import json,sys; print('$c', json.load(sys.stdin)['result']['hash'])"
done

Both return the same hash. Then ask for the next block:

Block	Ethereum Classic	Ethereum
1,919,999	`0xa218e2c611f21232d857e3c8…`	`0xa218e2c611f21232d857e3c8…`	identical
1,920,000	`0x94365e3a8c0b35089c1d1195…`	`0x4985f5ca3d2afbec36529aa9…`	diverged
1,920,001	`0xab7668dfd3bedcf9da505d69…`	`0x87b2bc3f12e3ded808c6d4b9…`	diverged

One block, and the two chains never speak to each other again. The genesis hash is likewise identical (0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3), as is every block up to the split.

So if you store transactions keyed on hash, or block heights without a chain discriminator, pre-fork records from Ethereum and Ethereum Classic will collide. A (chainId, blockNumber) or (chainId, txHash) composite key is the fix. This matters most if you run a multi-chain indexer, an airdrop/claims system, or anything with a transaction allowlist.

The methods you'll actually use

Nothing exotic. The list you'd use on Ethereum, with one substitution in the fee path:

Task	Method	Note for ETC
Current height	`eth_blockNumber`	—
Read a contract	`eth_call`	—
Fee estimate	`eth_gasPrice`	use this, not `eth_maxPriorityFeePerGas`
Gas units	`eth_estimateGas`	works normally
Events	`eth_getLogs`	keep ranges bounded
Receipt	`eth_getTransactionReceipt`	check `status`, expect reorgs
Send	`eth_sendRawTransaction`	legacy `gasPrice` transaction
Balance	`eth_getBalance`	18 decimals

For decoding events and reading balances, the mechanics are unchanged from Ethereum — the balance-reading traps and log decoding both apply exactly as written.

Archive access

Be deliberate about this if your project reads history, because Ethereum Classic is not an archive chain on our service and the failure mode differs by how you ask:

# state from an early block
curl -s -X POST "https://rpc.swiftnodes.io/rpc/etc?key=YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x0000000000000000000000000000000000000001","0x3e8"],"id":1}'
# -> {"jsonrpc":"2.0","id":1,"error":{"code":-32000,
#     "message":"missing trie node 97fb274dbf… state … is not available, not found"}}

# explicitly asking for archive routing
curl -s -X POST "https://rpc.swiftnodes.io/rpc/etc?key=YOUR_API_KEY&archive=1" ...
# -> {"error":"No archive node available for this chain","chain":"etc"}

Recent-state reads — the last stretch of blocks — work as expected. Deep historical state returns missing trie node, because the serving node is not keeping full historical state. Plain eth_getBlockByNumber for old blocks is fine; it's state-at-height (eth_getBalance, eth_getCode, eth_call at an old block) that isn't served.

If your workload is genuinely archive-dependent — backtesting balances, replaying old state, rebuilding historical dashboards — Ethereum Classic is a chain where you should confirm archive availability with a provider before committing. That's a real limitation, not a paperwork one: full node vs archive node explains what each tier costs and why providers draw the line where they do, and reading historical state covers what you can still do without it.

WebSocket subscriptions: verify before you build on them

The public status endpoint lists Ethereum Classic with wsAvailable: true and endpointTypes: ["http","ws"], and the socket does accept a connection:

wss://rpc.swiftnodes.io/ws/etc?key=YOUR_API_KEY

But when we tested it on 2026-09-18, an eth_subscribe to newHeads over that connection opened cleanly and then returned nothing — no subscription ID, no error — while the identical script against /ws/eth came back with a subscription ID immediately. A connection that opens is not the same thing as a subscription that streams.

So: treat WebSocket support on this chain as unverified on your provider, and design the HTTP path first. Polling for heads is genuinely fine at a 13–15 second block time:

let tip = await client.getBlockNumber();

setInterval(async () => {
  const head = await client.getBlockNumber();
  if (head > tip) { tip = head; /* process blocks tip-old..head */ }
}, 4000);

Track the block height you have actually processed rather than the head you last saw, and re-read on each new head. On a PoW chain a head you were told about can still be replaced, so a subscription — where it works — is a signal to re-read, not an append-only stream. Surviving WebSocket reconnects without losing events covers the resync pattern, and it applies equally to a polling loop that has to recover a gap.

Compared to the chains around it

	Ethereum	Ethereum Classic	Polygon zkEVM	Gnosis Chain
Chain ID	1	61	1101	100
Consensus	PoS	PoW (Etchash)	Rollup + PoS	PoS (GPOS)
EIP-1559 fee market	Yes	No	Yes	Yes
`baseFeePerGas` in blocks	Yes	No	Yes	Yes
Block time	~12s	~13–15s	~1s post-batches	~5s
Deterministic finality	Yes	No — probabilistic	Proof-based	~5 min
EVM	Yes	Yes	Yes	Yes

The row that surprises people is fee market, not consensus: you can port a contract to ETC without touching it, but the signing code needs a look. The other surprise is that ETC is not an L2 — no sequencer, no forced-state inclusion, no withdrawal delay. L2 finality concepts don't apply; PoW confirmations do.

Production considerations

Confirmations, not finalized tags. Size your wait for a 13–15 second block time and probabilistic finality. Re-query on reorg.

Pin the chain ID. 61, everywhere it's accepted. Because pre-fork history is shared with Ethereum, a wrongly-configured endpoint can return plausible-looking data instead of an error.

Gas price is a node suggestion. eth_gasPrice returns the node's own policy (11 gwei at time of writing) rather than a market-clearing auction price. Watch your backlog instead of trusting one number — estimating gas properly explains where the Ethereum-style heuristics stop transferring.

eth_getLogs ranges. Bound them, the same as anywhere else — range caps and how they bite.

No archive for this chain. If your roadmap needs historical state on ETC, plan for it specifically rather than discovering it in production.

Errors are the same errors. If something fails, it will most likely look familiar — JSON-RPC error codes decoded is the reference.

Choosing an Ethereum Classic RPC endpoint

Three questions decide it:

1. Do you need historical state? If yes, verify archive support for ETC before you build on it. Many providers advertise archive broadly while a given chain's node is not actually keeping full state.

2. Do you need WebSocket? Don't take the checkbox on a provider's status page as a working subscription — open one and confirm it streams before you design around it.

3. What happens when it's slow? A single upstream makes latency and downtime your problem. Failover across independent endpoints is what keeps a reader alive — which is the point of routing through a layer that tries several upstreams per request and benches any that fall behind the chain head.

The short version

Ethereum Classic (chain ID 61) is a proof-of-work EVM chain sharing its entire history with Ethereum up to block 1,920,000 — so pre-fork block and transaction hashes are identical across both chains and need a chain discriminator in your schema. The RPC surface is standard eth_*, Solidity and viem/ethers work unchanged, and even the bn256 precompiles are present. What is genuinely different: no EIP-1559 (blocks have no baseFeePerGas, and eth_maxPriorityFeePerGas returns the legacy eth_gasPrice value — 11 gwei when measured — so use eth_gasPrice and send legacy transactions), probabilistic finality instead of a finalized block, ~13–15 second blocks under an 8,000,512 gas limit, and no archive state for this chain on our endpoints.

For Ethereum Classic RPC with per-request failover across independent upstreams, grab a free API key and point your app at:

https://rpc.swiftnodes.io/rpc/etc?key=YOUR_API_KEY

One key covers all 75 chains, and the free tier is 2 requests per second — enough to run every probe in this article while you verify the fork boundary for yourself.

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

DEV Community: SwiftNodes

opBNB RPC: A Developer's Guide (Chain ID 204)

The essentials

Four blocks a second

Finality, and the stale-head trap

Fees: the L1 part matters here

State and tracing

If you're coming from BSC or Optimism

The short version

Shibarium RPC: A Developer's Guide (Chain ID 109)

The essentials

BONE is gas, and also a contract

Finality: use finalized, not safe

Logs, history and tracing

Security history you should know

If you're coming from Polygon PoS

The short version

Katana RPC: A Developer's Guide to the DeFi-First L2

The essentials

One block per second

Finality: latest, safe, finalized

Fees: almost all execution, almost no L1

Archive and tracing

Trust model, briefly

The short version

Kusama RPC: A Developer's Guide After the Asset Hub Move

The essentials

Big change: balances moved to Asset Hub

What the relay chain RPC is still for

Follow finalized heads, not new heads

Runtime upgrades change your types

History: 256 blocks of state

New JSON-RPC API: chainHead_v1

The short version

We Tested 945 Public RPC Endpoints. Half Don't Work.

How we tested

Why half of them fail

"Working" is not the same as "usable"

WebSockets are worse than they look

Which endpoints held up

How to pick a public endpoint

Our own endpoint, measured the same way

Dedicated Node vs Shared RPC Endpoint: When You Actually Need One

What you are buying in each case

What a shared pool looks like from the client side

What dedicated nodes cost in 2026

Four signals that you actually need one

Signals that look like "I need dedicated" but are not

The middle option: run your own node

The short version

Cronos RPC: A Developer's Guide

The essentials

Connecting

0.42-second blocks change your polling math

Finality: there is nothing to wait for

Gas: flat base fee, near-empty blocks

eth_getLogs: 10,000 blocks, address required

History: plan for a node that forgets

What works and what doesn't

What this means for your stack

The short version

Babylon RPC: A Developer's Guide (bbn-1, 9.6s Blocks, and a Pruning Floor That Moves)

The essentials

Connecting

The 9.6 second block is the design, not a problem

What is actually in a Babylon block

The pruning floor gave three different answers in six calls

tx_search refuses to search

The LCD is half the API

Websocket: what I could and could not verify

What this means for your stack

The short version

Hyperliquid RPC: A Developer's Guide (Chain 999, 1s Blocks, and a Block Number That Does Nothing)

The essentials

Connecting: the setup

curl

viem

ethers v6

The block number is decorative

What's different from a mainstream EVM node

Finality: use `finalized`, not `safe`

New JSON-RPC API: `chainHead_v1`

`tx_search` refuses to search

`health` returns an empty object

`safe` and `finalized` are minutes, not days

System addresses answer with `0xfe`

The `arb_*` namespace may not be there

`eth_maxPriorityFeePerGas` answers — and that answer is a trap