CELO

Celo: An Ethereum Layer 2 Built Around Stablecoin Payments and Flexible Gas

Celo has moved from its original independent proof-of-stake chain design to an OP Stack-based Ethereum Layer 2. Its distinctive features now include stablecoin fee payment, a Celo-specific execution client, on-chain governance, and a token whose role spans gas, voting, and network economics.

From independent chain to Ethereum Layer 2

Celo Mainnet migrated to an Ethereum Layer 2 architecture on March 26, 2025. The network now uses the OP Stack while retaining Celo-specific protocol features. Ethereum serves as the settlement layer, Celo executes EVM-compatible transactions, and transaction data is documented as using EigenDA for data availability. The published network specification describes one-second blocks, a 30 million gas limit, and a 25 Gwei base-fee floor.

The migration preserved Celo’s historical state while changing the software and security model around it. This matters for users and developers: Celo remains EVM-compatible, but it is no longer best understood as a conventional standalone Layer 1. Its practical dependencies now include Ethereum settlement, the OP Stack, the data-availability system, bridge contracts, and Celo’s own execution and proof infrastructure.

How the network is assembled

Celo’s documented architecture separates execution, sequencing, data availability, and settlement. The sequencer collects transactions, executes them into L2 blocks, and submits data or commitments for settlement on Ethereum. Full nodes maintain L2 state and interact with Ethereum infrastructure to read and verify rollup information. This modular design can improve throughput and user experience, but it also means that operational failures in any major layer can affect the chain even if the Celo smart contracts themselves continue to function.

The official Celo Rust repository currently describes two relevant components: celo-reth, an execution client for running the network, and Celo-specific fault-proof programs that execute and verify the rollup state transition. The repository also identifies two protocol extensions that distinguish Celo from a stock OP Stack chain: fee abstraction and token duality, in which native CELO and its ERC-20 representation share one balance through a transfer precompile.

Fee abstraction is the clearest user-facing feature

Celo allows users to pay transaction fees with approved ERC-20 assets instead of holding CELO for gas. The documentation lists assets such as USDC, USDT, USDm, and other approved currencies. A transaction specifies the chosen fee currency, and protocol-level logic debits the maximum fee before execution, refunds unused gas, and distributes the fee according to the network’s rules. This is implemented at the node and transaction-protocol level rather than through a separate relayer or paymaster.

The feature is useful for payment applications and users who primarily hold stablecoins, but it is not unrestricted. Fee currencies are controlled by a governance-managed allowlist, and some assets use adapter contracts rather than their ordinary token address. Non-CELO fee transactions also have additional gas overhead. As a result, the convenience depends on the continued availability, configuration, and liquidity of approved fee assets.

What CELO does

CELO remains the network’s native asset and can be used to pay transaction fees, although fee abstraction reduces the need for every user to hold it for that purpose. CELO also retains a governance role. Celo’s governance documentation describes a process in which holders lock CELO, participate in proposal voting, and can delegate voting power. Proposals move through queue, approval, referendum, and execution stages, with quorum and approval requirements determined by the governance system.

The token’s security role requires more careful qualification after the L2 migration. Older Celo documentation describes locked CELO voting for validator groups in a proof-of-stake system, while the L2 architecture identifies a sequencer as replacing the traditional validator role for block production. A December 2024 governance discussion said the L2 would initially launch with a centralized sequencer and that decentralized sequencing was planned for a later release. This creates an important distinction between CELO’s continuing governance function and the network’s current sequencing arrangement.

Governance and upgrade control

Celo uses on-chain governance to approve protocol changes, treasury actions, and other network decisions. The formal process requires a proposal deposit, queue management, approval review, referendum voting, and execution. The documentation says all CELO holders can vote once a proposal reaches the referendum stage, while locked CELO and delegation affect voting power. Successful proposals can be executed by anyone after the required conditions are met.

Governance is therefore part of Celo’s operating infrastructure, not merely a community forum. It can affect fee-currency eligibility, token economics, treasury use, validator or sequencing arrangements, and upgrades. Readers should distinguish between a forum proposal, an approved on-chain governance action, and a change that has actually been executed on Mainnet; those are separate stages with different evidentiary value.

Practical dependencies and open questions

Celo’s current design combines several external and internal dependencies: Ethereum settlement, the OP Stack, EigenDA as documented for data availability, the sequencer, bridge and rollup contracts, approved fee currencies, and Celo-specific client and fault-proof software. A failure or governance change in one component can alter transaction availability, withdrawal behavior, fee payment, or the economic role of CELO. The official code also shows that Celo maintains a customized implementation rather than simply deploying an unmodified OP Stack chain.

The principal unresolved issue is how Celo’s long-term validator and sequencing model will develop. The transition plan acknowledged an initial centralized sequencer, while the public architecture and code continue to evolve. Celo’s governance and documentation also contain material written for both the former proof-of-stake Layer 1 and the newer Layer 2. Users, developers, and token holders should therefore verify the current network configuration, contract addresses, fee-currency allowlist, bridge status, and governance decisions before relying on older instructions.

Key takeaways

• Celo is now an OP Stack-based Ethereum Layer 2 rather than a conventional standalone Layer 1.
• Its main user-facing differentiator is protocol-level fee abstraction, allowing approved ERC-20 assets to pay gas.
• CELO remains relevant for native fees, governance, and network economics, but its sequencing role changed after the L2 migration.
• Celo uses customized execution and fault-proof software, including Celo-specific support for fee abstraction and token duality.
• The network depends on Ethereum settlement, data availability infrastructure, sequencing, bridges, governance, and approved fee currencies.

Risks and open questions

• Sequencer concentration is a material architectural risk while decentralized sequencing remains a future objective rather than a completed property in the cited transition plan.
• Celo’s security and availability depend on Ethereum, the OP Stack, data-availability infrastructure, bridge contracts, and Celo-specific client and proof software.
• Governance can change fee-currency eligibility, treasury policy, token economics, and other protocol parameters; proposal discussions are not equivalent to executed changes.
• The continuing role of CELO in validator incentives and sequencing is not fully captured by older proof-of-stake documentation, which should be read alongside post-migration L2 materials.
• Approved stablecoins and other fee currencies introduce issuer, liquidity, contract, and allowlist dependencies.
• Documentation spans both the former Celo Layer 1 and the current Layer 2, so older operational instructions and security assumptions may be stale.