Celo RPC: The L2 Where You Pay Gas in Stablecoins

Celo has a feature most EVM chains don't: you can pay gas in stablecoins. A user with only cUSD in their wallet can transact without ever holding the native token — the fee is charged in the ERC-20 they already have. For a mobile-first payments network, that's the whole point, and it's the thing that most changes how you build here. Celo is also unusual in another way: it migrated from a standalone Layer 1 to an Ethereum L2 in 2025, keeping the same chain ID through the transition. It's standard EVM either way — chain ID 42220, ordinary eth_*, viem/ethers unchanged — but two Celo-specific facts shape the work. Here's the map.

The essentials

Celo mainnet is chain ID 42220, and as of March 2025 it's an OP Stack Layer 2 on Ethereum:

• CELO is the native gas token (18 decimals) — but not the only fee token (see below).
• ~1-second blocks — down from ~5s on the old L1, after the L2 migration.
• OP Stack + EigenDA — Celo runs Optimism's stack but posts data to EigenDA for data availability rather than Ethereum blobs.
• EVM-compatible — Solidity, ABIs, and standard tooling work directly.

Connecting is standard EVM:

import { createPublicClient, http } from "viem";
import { celo } from "viem/chains";   // chain ID 42220

const client = createPublicClient({
  chain: celo,
  transport: http("https://rpc.swiftnodes.io/rpc/celo?key=YOUR_API_KEY"),
});
await client.getBlockNumber();   // just works

The standout feature: fee currencies (gas in stablecoins)

On almost every chain, gas is paid in the native token — you must hold ETH, or CELO, or whatever, to move anything. Celo breaks that assumption with fee abstraction: a transaction can specify a feeCurrency — a whitelisted ERC-20 (like cUSD or cEUR) — and the protocol charges the fee in that token instead of CELO.

Why it matters:

• Onboarding. A user funded with only a stablecoin can transact immediately — no "go acquire the gas token first" step. For payments and emerging-market use cases, that removes the single biggest UX cliff.
• Predictable fees. Denominating fees in a stablecoin means the cost of a transaction doesn't swing with the native token's price.

The developer implication is that gas isn't purely a native-token concern here. If you're building wallet or payment flows, you deal with an extra field: transactions can carry a feeCurrency, and estimating cost means knowing which token the fee is in. Standard eth_estimateGas still returns the gas units (gas estimation basics); the fee-currency layer sits on top, converting that to a charge in the chosen ERC-20. If you use CELO as the fee token, everything behaves like a normal EVM chain — the abstraction is opt-in.

Design fact #2: it's now an OP Stack L2 (with EigenDA)

Celo launched as its own L1 in 2020 and completed its transition to an Ethereum L2 on March 26, 2025 (at block 31,056,500), rebuilt on the OP Stack. Two consequences:

• OP Stack mechanics now apply. A sequencer orders transactions, gas has an L1 data-fee component, and withdrawals to Ethereum pass through the standard optimistic challenge window — the same model we covered on Unichain, Zora, and (as a contrast) the based-rollup Taiko. Finality is L2-soft/L1-hard; see soft vs hard finality.
• Data availability is EigenDA, not Ethereum blobs. Rather than posting rollup data to Ethereum as blobs, Celo uses EigenDA — an external DA layer (conceptually similar to the modular-DA role Celestia plays). It's a cost/scaling choice and mostly invisible from the RPC, but it's why Celo's data-availability story differs from a vanilla OP Stack chain.

The nice part for existing integrations: the chain ID stayed 42220 through the migration, so your RPC endpoint config and chain references didn't need to change — only the underlying architecture did.

One more quirk: CELO token duality

CELO is the native gas token, but it also has an ERC-20 representation — "token duality." You can interact with CELO both as native value (like ETH) and via a standard ERC-20 interface at a well-known address. Most of the time you won't think about it, but if a contract expects an ERC-20 and you're dealing with the native token, that's the mechanism that bridges the two.

What carries over unchanged

Aside from fee currencies and the DA layer, treat Celo as a standard OP Stack EVM chain:

• eth_call, eth_getLogs, eth_getBalance, eth_getTransactionReceipt, eth_sendRawTransaction, eth_subscribe all behave normally.
• Solidity contracts, ABIs, and the viem/ethers/foundry toolchain deploy and run as-is.
• WebSocket subscriptions (newHeads, logs) work; at ~1s blocks, stream rather than poll.

The short version

Celo (chain ID 42220) is now an OP Stack L2 (migrated from L1 in March 2025, using EigenDA for data availability), with ~1-second blocks and standard eth_* — viem/ethers work unchanged. Its two distinctive traits: fee currencies let users pay gas in stablecoins like cUSD instead of CELO (a mobile-first onboarding superpower, and an extra feeCurrency field in payment flows), and it's a rare chain that kept its chain ID through an L1→L2 migration. Build it like an OP Stack chain, and lean on fee abstraction if you're doing payments.

Building mobile payments, stablecoin apps, or ReFi on Celo? A flat-rate Celo RPC endpoint gives you chain 42220 over HTTP and WebSocket alongside 75+ other chains under one key. Grab a free key and point your stack at:

https://rpc.swiftnodes.io/rpc/celo?key=YOUR_API_KEY