NexFlow › Library › Fantom RPC endpoint guide

Fantom RPC endpoint: how to read Opera in 2026

Fantom Opera is still running and still answering JSON-RPC, but it is no longer where the ecosystem's activity lives — the Fantom documentation says Opera migrated to a new chain called Sonic in December 2024. If you maintain a wallet, an indexer, an accounting export or a historical dashboard that touches Opera, this guide covers a working endpoint and the quirks we hit reading it.

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

The endpoint: https://nexflowscan.com/api/rpc/fantom. It accepts standard Ethereum JSON-RPC over HTTPS POST, needs no key for baseline reads, and routes each call through the keyless upstream providers the relay keeps in its pool for Opera. On this chain that pool is smaller than on our busier networks — two public upstreams at the time of writing — which is worth knowing if you are deciding how much redundancy to build on your side.

Who still needs Opera reads? More people than the migration headline suggests. Tax and accounting tools reconstruct historical transfers. Holders who never moved check balances before migrating FTM. Auditors and researchers query old contract state. Protocols that wound down on Opera still have users asking what they hold. All of that is read traffic, and all of it needs an endpoint that answers correctly.

Confirm you are on Opera

Opera and Sonic are different chains with different chain IDs, and it is easy to paste the wrong URL. The chain-ID call settles it in one round trip; the block-number call confirms the node behind the relay is live.

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

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

0xfa is 250, Fantom Opera's chain ID. 0x75bc68d is block 123,455,117. Here is the telling detail: earlier in the same session, block 123,455,113 carried a timestamp of 19:53:51 UTC, and at 20:04:12 UTC the latest block was 123,455,142. That is 29 blocks in a little over ten minutes, roughly one every 21 seconds. It is not a stalled node — the height kept moving — it is what a quiet chain looks like when blocks are produced in response to activity rather than on a fixed clock.

Why Opera's block timing looks strange

The Fantom documentation's Consensus page describes Opera as using a proof-of-stake, DAG-based asynchronous Byzantine fault tolerant mechanism, and cites the Lachesis paper for the technical detail. Each validator batches incoming transactions into event blocks in its own local DAG; those events are exchanged and ordered, and the final blocks you see through RPC are the result. The docs note that event-block generation is internal and not visible to end users.

The consequence for a client is that "block time" is not a constant you can plan around. We measured it two ways on 2026-09-27: the most recent 1,000 blocks averaged 9.2 seconds apart, while the most recent 10,000 averaged 3.97 seconds. The shorter window was slower, which is what you would expect if activity has been tapering. Any code that converts a block count into wall-clock time on Opera — "wait 20 blocks", "look back one day's worth of blocks" — will be wrong in a way that drifts. Use block timestamps instead: fetch the block with eth_getBlockByNumber and read its timestamp field.

The same documentation, on its Build on Opera overview, says Opera provides fast transaction finality, typically within one second. A block that the network has produced is, for practical purposes, final; there is no long probabilistic tail like on proof-of-work chains, and no multi-hour settlement window like on a rollup.

The block-tag trap: safe and finalized fail

Many modern EVM libraries default to asking for the safe or finalized block when they want reorg-resistant data. On Opera, through our relay, those tags do not work. Our requests for eth_getBlockByNumber with "safe" and with "finalized" both returned the upstream error "invalid argument 0: hex string without 0x prefix" — the node treats the tag as a malformed block number.

If your stack is a multi-chain indexer that uses one code path for every network, add an Opera exception: pin reads to explicit block numbers, which also makes them reproducible. Historical and accounting workloads benefit from that anyway, because a report built at block N can be rebuilt and checked at block N later.

FTM fees, and what the numbers look like now

The Fantom documentation's Transaction Fees page states that every transaction on Opera requires a fee paid in FTM, the chain's native token, and gives the current split: 5% burned, 10% to the Ecosystem Vault, 15% to Gas Monetization, and 70% to validators. None of that changes how you estimate gas through RPC, but it explains where fees go if you are writing documentation for users.

What our reads returned on 2026-09-27: the latest block's base fee was 1,000,000,000 wei (1 gwei), eth_gasPrice answered 1,025,003,000 wei, and eth_maxPriorityFeePerGas answered 25,002,000 wei. Those are one-session readings, not averages, and they will change. The same block header reported a gas limit of 281,474,976,710,655 — a placeholder maximum, not a capacity figure — so do not build block-fullness metrics from it.

Estimate every transaction with eth_estimateGas rather than reusing limits from another chain. For balance checks, remember that FTM on Opera is the native balance returned by eth_getBalance; the Sonic chain's token is a separate asset on a separate network, and a balance on one does not appear on the other.

Relay scope on Opera

The relay forwards the Ethereum read methods that historical and wallet workloads depend on: eth_getBalance, eth_call, eth_getLogs, block and transaction lookups, receipts, eth_estimateGas, eth_feeHistory and filters. The client-version string we received identified a third-party gateway, which is expected: the relay's job is routing across providers, not running every node itself.

Signing and node-internal methods are refused. eth_sign and txpool_content returned -32601, "Method not allowed on this relay", and the Fantom lane page states that sends and signs are refused on the public lane. For an Opera wallet that still needs to move funds — to migrate them, for instance — sign in the wallet and broadcast through a provider you control.

Large eth_getLogs ranges deserve care on any chain, and on Opera the block numbers are large and the history is long. Page through history in bounded windows and keep each batch well inside the lane's limits; a single enormous log query is more likely to time out upstream than to return.

Lanes and pricing for Opera reads

Our relay, as of 2026-09-27, offers the same three lanes on Fantom as on every other chain it serves:

Opera workloads tend to be bursty: a tax export that pulls years of history at once, then nothing for a month. For that pattern the x402 lane can make more sense than the flat key — you pay only for the calls in the burst, with no account to maintain. The x402 RPC page explains how the 402 challenge and payment header work. For an always-on service, such as a wallet backend that still supports Opera balances, the flat key described on the integration page is simpler to budget.

Whichever lane you pick, batch items count individually against the per-minute allowance, and the free lane answers HTTP 402 when its window is used up — a clear signal to switch lanes rather than a silent failure.

Frequently asked