NexFlow › Library › Gnosis RPC endpoint guide

Gnosis Chain RPC endpoint: a practical guide for builders

Gnosis Chain looks like a small Ethereum — same client software family, same JSON-RPC, a beacon-style proof-of-stake consensus — with two differences that matter to anyone reading it programmatically: blocks every five seconds, and a stablecoin as the gas token. Here is a working endpoint, the responses it gave us, and how to read the chain correctly.

7 min read · updated 2026-09-27 · infra guide, not financial advice

The endpoint is https://nexflowscan.com/api/rpc/gnosis. Send it a JSON-RPC POST and you get an answer from one of several keyless upstream providers the relay health-checks; if one falls behind or errors, the next one takes the call. There is no key to obtain for baseline reads and no account to create.

Gnosis Chain grew out of the xDai chain and still uses xDai as the unit you pay fees in, while GNO is the token validators stake to secure consensus. That split — a dollar-denominated fee token and a separate staking token — is unusual among EVM networks, and it shapes how you should think about gas estimates, balance displays and fee alerts.

Two requests that prove the endpoint works

Whenever you add a new RPC URL to a project, run a chain-ID check first and a block-height read second. The first proves you reached the right network; the second proves the node behind it is live and syncing.

curl -s -X POST https://nexflowscan.com/api/rpc/gnosis \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
# {"jsonrpc":"2.0","result":"0x64","id":1}

curl -s -X POST https://nexflowscan.com/api/rpc/gnosis \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
# {"jsonrpc":"2.0","result":"0x2e39a7f","id":1}

0x64 is decimal 100, the Gnosis Chain mainnet ID. 0x2e39a7f is block 48,470,655, which is where the chain stood when we ran the call on 2026-09-27. The Chiado testnet uses a different ID, 10200, so a response of 0x27d8 means you are pointed at the test network rather than mainnet — an easy mistake to make when copying URLs between environment files.

What the official specifications tell your code

The Gnosis documentation keeps a short Gnosis Specifications page that is worth bookmarking. It lists a block speed of 5 seconds, a block size of 17M gas units, xDai as the fee token, GNO as the consensus token, and chain ID 100 (hex 0x64), with Chiado at 10200 (hex 0x27D8). It also names the current Ethereum-aligned fork patchset, which is how you know which opcodes and transaction types the chain accepts.

We checked those figures against live data instead of taking them on faith. Over the most recent 1,000 blocks, timestamps averaged 5.055 seconds apart; over 10,000 blocks, 5.091 seconds — close to the documented five, with the small excess coming from occasional missed slots, which is normal on a proof-of-stake chain. The latest block header we read showed a gas limit of 16,966,653, matching the documented 17M.

Why this matters in practice: a five-second chain produces roughly twelve blocks a minute. If your indexer polls every second, four out of five polls return nothing new. Polling every few seconds, or subscribing through a filter and draining it with eth_getFilterChanges, uses far less of your rate budget for the same freshness.

Safe and finalized on Gnosis Chain

Because Gnosis uses beacon-chain style consensus, the safe and finalized block tags carry the same meaning they do on post-merge Ethereum: safe is a block the consensus layer considers unlikely to be reorganized, and finalized is one that validators have irreversibly checkpointed. The difference from Ethereum is speed — the shorter slot time brings finalization much closer to the tip.

Those gaps come from a single read and will move around, but the order of magnitude is the useful part: waiting for finality on Gnosis costs you a few minutes, not the quarter-hour you would budget on Ethereum. For a payment flow that credits user balances, that is short enough that there is rarely a good reason to settle on latest.

Gas priced in xDai — and priced in wei

On most EVM chains a gas fee is a small amount of a volatile token. On Gnosis it is a small amount of xDai, a token designed to track the US dollar. That makes fees easy to reason about, but it also means the raw numbers are strikingly small. In our session, the latest block's base fee was 10 wei, eth_gasPrice returned 0xc (12 wei), and eth_maxPriorityFeePerGas returned 0xb (11 wei).

Those values will not stay fixed; base fee rises with demand under the same EIP-1559 rules Ethereum uses. What they reveal is a common bug: code that formats fees in gwei and rounds to two decimals shows "0.00" on Gnosis and can make a working estimate look broken. Format in wei, or scale your display to the value.

The other habit to break is assuming the gas token and the staking token are the same thing. A wallet that is empty of xDai cannot pay for a transaction on Gnosis Chain even if it holds GNO. When you build an onboarding check — "does this address have enough to transact?" — query the native balance with eth_getBalance, which returns xDai, not a GNO token balance.

What passes through the relay, and what stops at it

The Gnosis lane forwards the Ethereum read methods applications actually use: eth_call for contract reads, eth_getLogs for events, block and receipt lookups, eth_estimateGas, eth_feeHistory, filters, and the net_ and web3_ identity calls. Requests are spread across a ladder of keyless upstreams, including the RPC that the Gnosis ecosystem itself publishes, so a single provider's bad afternoon does not become yours.

It deliberately does not act as a signer or a node console. We sent eth_sign and txpool_content and both came back with -32601, "Method not allowed on this relay". The lane page is explicit that sends and signs are refused on the public lane. Keep private keys in the wallet or service that owns them, sign there, and broadcast through a provider you have a relationship with.

A relay also adds a hop. If you ever need to know which node produced a particular answer — during a dispute, or while debugging an inconsistent read — call a single provider directly for that investigation. For day-to-day reads, the fallback ladder is what you want.

Choosing a lane for Gnosis traffic

Our relay, as of 2026-09-27, prices the Gnosis endpoint in three lanes. They share the same method set and upstream pool; what changes is throughput and how you pay.

Every item in a batch counts separately against the per-minute budget, so batching saves round trips, not quota. On the free lane, once the 50-call allowance is exhausted the relay replies with HTTP 402 — a clear signal, not a silent throttle.

For a service that watches Gnosis continuously — a Safe transaction monitor, a prediction-market indexer, a payments backend — the flat key is the natural fit. The checkout endpoint returns USDC payment addresses; after paying you claim a key and send it as a header. The integration page covers the details.

For autonomous agents the x402 lane skips accounts entirely: the first unpaid call returns a 402 challenge naming the price and the settlement networks, the client pays, and the retried call is served. The mechanics are on the x402 RPC page.

Frequently asked