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

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

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.

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

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

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.