Celo for Ethereum Developers

Overview of the similarities and differences between the Celo and Ethereum blockchains.

For a general overview of the Celo network and architecture, see the Celo Overview page.

Celo’s relationship to Ethereum

Celo is an Ethereum Layer 2 solution. Since the migration, Celo is an OP stack based L2 on top of Ethereum, extending it by adding fee abstraction, 1-second blocks and a range of local stablecoins. Ethereum’s L2 landscape is becoming a melting pot of philosophies and Celo adds a values-driven, inclusivity-focused layer to that mix, enriching Ethereum’s pluralistic fabric. In terms of programmability, Celo is similar to Ethereum. Both networks run the Ethereum Virtual Machine (EVM) to support smart contract functionality. This means that all programming languages, developer tooling and standards that target the EVM are relevant for both Celo and Ethereum. Developers building on Celo can write smart contracts in Solidity, and take advantage of smart contract standards that have already been developed for Ethereum.

The ERC-20 token standard

The ERC20 token standard is a standard API for tokens within smart contracts. This standard interface allows any tokens to be re-used by different applications. The ERC20 token standard is blockchain agnostic, so ERC20 tokens can be implemented on any blockchain. The standard includes the optional functions

function name() public view returns (string)
function symbol() public view returns (string)
function decimals() public view returns (uint8)

and the required functions

function totalSupply() public view returns (uint256)
function balanceOf(address _owner) public view returns (uint256 balance)
function transfer(address _to, uint256 _value) public returns (bool success)
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
function approve(address _spender, uint256 _value) public returns (bool success)
function allowance(address _owner, address _spender) public view returns (uint256 remaining)

and includes the following events

event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approval(address indexed _owner, address indexed _spender, uint256 _value)

An ERC20 compliant contract must include the required functions and events at minimum. It can include additional functions and events and still be ERC20 compliant.

The Celo native asset and Mento stablecoins

This interface is relevant for two important assets on the Celo network, the Celo native asset (CELO) and Mento stablecoins like USDm (Mento Dollar). CELO was called Celo Gold (cGLD) when the contract was deployed, so you will often see references to Celo Gold in the codebase. CELO and cGLD are the same thing. You can view the CELO implementation here. CELO has an ERC20 interface, so users can interact with CELO via the token standard, but it is important to note that not all CELO transfers are required to go through the token contract. CELO can also be transferred by specifying the value field of a transaction, in the same way that ETH can be transferred in Ethereum. To track every balance-changing operation you therefore need to follow native value transfers as well as ERC-20 Transfer events. See token duality. USDm (Mento Dollar) is implemented solely as a smart contract, so all USDm actions are mediated by the smart contract. You can view the implementation here.

Key differences between Celo and Ethereum

Features exclusive to Celo

Celo allows users to pay transaction fees in cryptoassets other than the native asset. On Ethereum, users must pay transaction fees in Ether. For example, users can send USDm, and then pay any transaction fees in USDm as well.
Celo posts transaction data to EigenDA for data availability. Blocks are produced every second, against ~12 seconds on Ethereum. Finality follows the Ethereum L1 — see finality for what a given confirmation depth actually guarantees.

Things to watch out for

As previously mentioned, CELO transfers are not required to happen via the ERC20 interface. A user’s CELO balance may change without any interaction with the CELO contract, as they may transfer CELO natively.
Celo supports a broad range of Ethereum-compatible transaction types to ensure seamless integration with existing Ethereum tooling. In addition to standard Ethereum tx types like legacy (type 0), EIP-2930 (type 1), and EIP-1559 (type 2), Celo also supports OP Stack-specific deposited transactions (type 126) and introduces its own Celo-native tx type (type 123) to enable features like Fee Abstraction. While most Ethereum transactions work out of the box on Celo, developers can also take advantage of extended functionality such as paying gas fees in ERC-20 tokens. For a more detailed overview, check out the full breakdown of supported transaction types.

Mnemonic seed phrases can derive different accounts depending on the key derivation path used. While Ethereum wallets typically use the path m/44'/60'/0'/0, Celo defines its own path as m/44'/52752'/0'/0. Despite this, most Celo wallets—including Valora—default to the Ethereum derivation path, except in the case of some legacy accounts. Ledger Wallet, when used with the Celo Ledger app, strictly uses the Celo path. Tools like the Celo CLI and the Celo Ledger app, however, offer flexibility and allow users to specify either path explicitly.
The Valora wallet uses two types of accounts: externally owned accounts and meta-transaction wallets. There are important consequences for wallet developers and dapp developers building on Celo as Valora is one of the main interfaces for Celo users. You can find more information about Valora accounts here.

Deploying Ethereum contracts to Celo

Celo runs the EVM which means that smart contracts written for Ethereum can easily be deployed to Celo, the main difference being that you just need to connect to a Celo node instead of an Ethereum node. You can connect to your own Celo node or to a Celo node service provider like Quicknode.

Protocol differences

OPCODES & Block headers

With the move to an L2, Celo now supports the same OPCODES and Block headers as Ethereum.

Precompiled contracts

Celo includes all of the Ethereum precompiled contracts and adds a few of its own. The current list is in core/vm/celo_contracts.go in celo-org/op-geth.

Core contract calls

Celo runs some protocol logic in core contracts rather than in the client — epoch rewards and validator elections among them. If you index Celo, read those contracts rather than assuming every state change arrives as a normal transaction.

Node management APIs

You can find the full list of RPC API endpoints in this file.

Overview

Nodes

Contracts

Wallets

Explorers

Indexers

Oracles

Dev Environments

Libraries & SDKs

Contract Verification

Celo for Ethereum Developers

Celo’s relationship to Ethereum

The ERC-20 token standard

The Celo native asset and Mento stablecoins

Key differences between Celo and Ethereum

Features exclusive to Celo

Things to watch out for

Deploying Ethereum contracts to Celo

Protocol differences

OPCODES & Block headers

Precompiled contracts

Core contract calls

Node management APIs

​Celo’s relationship to Ethereum

​The ERC-20 token standard

​The Celo native asset and Mento stablecoins

​Key differences between Celo and Ethereum

​Features exclusive to Celo

​Things to watch out for

​Deploying Ethereum contracts to Celo

​Protocol differences

​OPCODES & Block headers

​Precompiled contracts

​Core contract calls

​Node management APIs

Celo’s relationship to Ethereum

The ERC-20 token standard

The Celo native asset and Mento stablecoins

Key differences between Celo and Ethereum

Features exclusive to Celo

Things to watch out for

Deploying Ethereum contracts to Celo

Protocol differences

OPCODES & Block headers

Precompiled contracts

Core contract calls

Node management APIs