NexFlow › Library › Celo RPC endpoint guide

Celo RPC endpoint: reading the Celo L2 correctly

Celo kept its chain ID and its address space when it stopped being a standalone Layer 1 and became an Ethereum Layer 2, so most RPC calls still look exactly as they did. Underneath, block timing, finality, fee accounting and even where history lives have changed. This guide pairs a working endpoint with what we actually observed reading it.

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

The endpoint is https://nexflowscan.com/api/rpc/celo. It speaks standard Ethereum JSON-RPC over HTTPS POST, requires no key for baseline reads, and distributes calls across a pool of keyless upstreams that includes Celo's own public forno service. When one upstream falls behind or errors, the relay moves the call to the next.

Celo's documentation now keeps a historical page, About Celo L1, for readers who arrive at material about mechanisms that no longer exist. It records that Celo ran as an independent L1 from April 2020 until March 2025, when it completed its migration to an Ethereum Layer 2 at block 31,056,500. That single block number turns out to matter a great deal for anyone querying history, as the sections below show.

Check the network, then the height

Two calls tell you most of what you need about any new endpoint: which chain it serves and whether it is current. On Celo they look like this.

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

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

0xa4ec decodes to 42220, the same Celo mainnet chain ID wallets have used since 2020 — the L2 migration did not change it, which is why existing wallet configurations kept working. 0x4afed0e is block 78,638,350. The client-version string reported by the node that served our calls was a reth build, a sign that the chain is now run on modern Ethereum-style execution software.

One-second blocks and what finality looks like now

As an L2, blocks are produced by a sequencer and become final only once the data that backs them is settled through Ethereum. The RPC surface reflects that with the standard post-merge block tags, and the gaps between them are the most useful thing to measure.

Block cadence was strikingly regular. Averaged over the last 1,000 blocks and again over the last 10,000, the timestamps were exactly 1.000 second apart. That makes block counts a reliable proxy for time on today's Celo — 60 blocks is a minute — in a way that is not true on chains with irregular production. It also means an indexer polling every second will see a new block on nearly every poll, so budget your request rate accordingly.

The finalized gap is the number to design around. A quarter of an hour is short compared with rollups that wait days for fraud windows or hours for proofs, and it is long enough to matter for any flow that pays out on confirmation. Payment flows that credit balances on latest should be reviewed; most should move to finalized, or to safe with an explicit risk decision.

The history boundary at block 31,056,500

Here is the finding most likely to surprise an indexer. We asked the relay for block 31,056,500 — the first L2 block according to Celo's documentation — and received a full block. Its miner field was a 0x4200… system address, the fee-vault pattern used by OP Stack chains. We then asked for block 31,056,499, the last block of the L1 era, and for block 1. Both came back as null.

A null result is not an error; it is the node saying it has no such block. The upstreams answering on our Celo lane serve L2-era state and blocks, not the pre-migration chain. If your application needs Celo history from 2020 through March 2025 — transaction exports, historical balances, old governance events — you need an archive provider that explicitly retains L1 data, and you should test for it before relying on it. Build that check into your indexer: request a block just below 31,056,500 and fail loudly if the answer is empty.

Paying gas in stablecoins: fee abstraction

Celo's documentation calls fee abstraction one of its core protocol features: users can pay gas in ERC-20 tokens such as USDC, USDT or Mento stablecoins instead of holding CELO. The Fee Abstraction overview stresses that this is built into the protocol at the node level — not a paymaster or relayer. A transaction includes a feeCurrency field set to an approved token or adapter address; the chain calls debitGasFees on that token contract to reserve the maximum cost, executes the transaction, then calls creditGasFees to refund what was unused. Wallets need to support the CIP-64 transaction type to build these transactions.

For RPC users this has two consequences. First, reading a user's CELO balance is not enough to decide whether they can transact; a user holding only USDC may still be able to pay fees. Second, when you parse historical transactions, fees may have been paid in a token, so a fee calculation that assumes CELO will misreport them. Check the transaction type and the fee-currency field before you total up fees.

The native fee market itself follows EIP-1559. In our session the latest block's base fee was 200,000,000,000 wei (200 gwei), eth_gasPrice returned 200,001,000,000 wei, and eth_maxPriorityFeePerGas returned 1,000,000 wei. Those are single dated readings in CELO terms. Because the L2 also pays for data posted to Ethereum, the chain exposes an L1 fee oracle at the OP Stack predeploy address 0x420000000000000000000000000000000000000F; an eth_call to its l1BaseFee() function returned 1,472,619,125 wei, and its version() returned "1.6.0". Wallets that show a fee estimate should include that L1 component.

What the relay will and will not do on Celo

Standard reads all pass: balances, eth_call, logs, blocks, receipts, gas estimation, fee history, filters, and eth_call against system contracts such as the fee oracle above. Signing and node-internal methods do not: eth_sign and txpool_content both returned -32601, "Method not allowed on this relay", and the Celo lane page states that sends and signs are refused on the public lane. MiniPay-style apps and payment backends should sign in their own wallet infrastructure and broadcast through a provider they control.

Our relay, as of 2026-09-27, sells capacity on Celo in three lanes. All three reach the same upstream pool with the same method list.

With one-second blocks, a service that follows the chain tip closely will go through the free allowance fast, and the relay will start returning HTTP 402. That is the moment to take a key — the integration guide covers checkout and headers — or, for an agent that reads Celo only occasionally, to use the x402 lane, where each call carries its own payment and there is no account at all.

Frequently asked