NexFlow › Library › Mode Network RPC endpoint guide

Mode Network RPC endpoint: an OP Stack chain, read carefully

Mode is a small Ethereum L2 built on the OP Stack, which means that if you have read Optimism or Base over RPC, most of your code already works. The gaps are in the details — which fee number to trust, how far behind the tip "finalized" really sits, and one standard method that returns a misleading answer. Here is a tested endpoint and what we learned using it.

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

The endpoint for Mode Network is https://nexflowscan.com/api/rpc/mode. Send a standard JSON-RPC POST; baseline reads need no key. Behind the URL, the relay keeps a short list of keyless upstreams — among them the mainnet.mode.network RPC that Mode's own Network Details page publishes — and retries the next one when a provider errors or trails the tip.

Mode's documentation describes the chain as powered by the OP Stack in collaboration with Optimism, and as a contributor to Optimism's Superchain. For you, as the one writing the client, that lineage is the most useful fact about Mode: its system contracts, block tags and fee components follow the OP Stack's conventions, so the OP Stack's documentation and tooling apply almost unchanged.

Verify the chain in two calls

Before a Mode endpoint touches production code, prove that it serves chain 34443 and that its view of the tip is current.

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

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

The hex 0x868b is 34443, which Mode's Network Details page lists as the mainnet chain ID alongside ETH as the currency symbol, explorer.mode.network as the explorer, and bridge.mode.network as the bridge. 0x2b17ad8 is block 45,185,752. The client-version string of the node that answered was a Conduit build of op-reth, which suggests the node was operated by a rollup-as-a-service provider — a common arrangement for OP Stack chains of Mode's size.

Block cadence and the three tags that matter

Mode produces a block every two seconds, and our measurements confirmed it: timestamps were exactly 2.000 seconds apart averaged over the last 1,000 blocks and over the last 10,000. An OP Stack sequencer builds blocks on a fixed clock even when they are nearly empty — the latest block we fetched carried a single transaction, the system deposit that every OP Stack block begins with.

The interesting numbers are the gaps between tags. On OP Stack chains latest is the sequencer's unsafe head, safe is derived from batch data already posted to Ethereum, and finalized is safe data whose Ethereum block has itself finalized.

A quarter-hour safe lag is longer than on the busiest OP Stack chains, and most likely follows from economics rather than a fault: a low-traffic chain tends to post batches to Ethereum less often to keep data costs down, so the safe head advances in bigger, less frequent jumps. If you run a service that waits for safe, expect it to move in steps rather than smoothly, and do not alert on a single long gap.

Fees: the method that lies and the oracle that doesn't

An OP Stack transaction pays an L2 execution fee and an L1 data fee. The L2 part is ordinary EIP-1559. In our session the latest block's base fee was 252 wei, and eth_maxPriorityFeePerGas suggested 1,000,000 wei. Those are single dated reads, not an average, and on a quiet L2 they sit close to the floor.

The L1 part is where a careless client goes wrong. We called the standard eth_blobBaseFee method on Mode and got 0x1 — one wei. That is the L2's own blob base fee, which is meaningless because the L2 does not carry blobs. It is not what Mode pays Ethereum to post its data. Code that plugs that value into an L1 cost estimate will report fees near zero.

The number you want lives in the OP Stack's gas price oracle predeploy at 0x420000000000000000000000000000000000000F. Through our relay, on 2026-09-27:

Those oracle values track Ethereum's execution base fee and blob base fee as seen by the chain. Wallets built on viem or ethers with OP Stack extensions call this contract for you; hand-rolled fee logic should call it too, or accept that its estimates will be low.

Method scope on the Mode lane

The relay forwards the Ethereum reads that Mode applications use: eth_call against contracts including OP Stack predeploys, eth_getLogs, block and receipt lookups with all standard tags, eth_estimateGas, eth_feeHistory, filters and identity methods. It refuses signing and node-internal calls — eth_sign and txpool_content both returned -32601, "Method not allowed on this relay" — and the Mode lane page states that sends and signs are refused on the public lane. Keep signing inside the wallet or backend that holds the key, and broadcast through a provider you control.

If your product spans several Superchain networks, the relay's value is a single URL pattern across them: swap the path segment and the same client code reads another OP Stack chain. The RPC index lists which ones we route.

Five mistakes we see in Mode integrations

Copying the chain ID from a testnet config. Mode's test network has its own ID. Assert 0x868b at startup and refuse to run if the endpoint disagrees.

Estimating fees from the L2 base fee alone. At a few hundred wei, the execution fee is a rounding error next to the L1 data component. A fee display built only from eth_gasPrice will be wrong in the direction that surprises users.

Trusting eth_blobBaseFee. As shown above, it describes the L2, not Ethereum. Use the oracle.

Alerting on safe-head stalls. On a quiet chain the safe head can sit still for many minutes and then jump. Alert on the finalized head falling far behind — an hour or more beyond what you normally see — instead.

Unbounded log queries. Two-second blocks add up to more than 43,000 blocks a day. Page eth_getLogs in fixed block windows and keep each response small enough that a single upstream can answer it inside your timeout.

Free, keyed, or pay-per-call

Our relay, as of 2026-09-27, prices Mode access in three lanes over the same upstreams:

A batch of 25 items costs 25 against the per-minute allowance, so batching helps latency more than quota. When the free window is used up, the relay responds with HTTP 402, which your client can treat as a clean signal to switch lanes.

For a Mode indexer or a trading backend that follows every block, the flat $25 key is the predictable option; the integration guide explains how to buy and send it. For an agent that reads Mode only when a task calls for it, the x402 lane lets it pay per request with no account.

Frequently asked