CEL2 Roadmap Update

CEL2 Roadmap

Celo Community, today I’m excited to unveil our CEL2 roadmap.


Guiding Principles: We are committed to the following principles in our work to deliver CEL2:

  • Seeking early feedback from the community.
  • Establishing an iterative process with a rapid feedback loop.
  • Prioritizing the delivery of tangible results over pursuing perfect solutions.
  • Effectively managing expectations.
  • Mitigating uncertainty in the early stages and deferring actions requiring extensive research to later phases.
  • Minimize upgrades / break as little as possible (e.g. ideally for anyone consuming Forno, no change should be needed for the upgrade)

Boundary Conditions: We are committed to ship an L2 which will fulfill the following conditions (which the Celo network currently already fulfills), as postulated in the original post:

  • Sub-cent transaction fees.
  • Gas fees payable with (select) ERC-20 tokens.
  • 1-block finality.

Public Iterative Process: To deliver on our guiding principles of shipping fast and seeking community feedback early, we plan to launch public testnets early on, even if they might feature only a subset of what will constitute CEL2. We are working in the open, and we think this is particularly helpful as:

  • The community can experiment early on with the L2 and get their hands dirty in code.
  • Experiencing a subset of the most crucial features can yield greater value compared to a later release of the final design.
  • Early feedback from the community can significantly influence key design decisions.
  • The community can prepare early on for the migration process, testing and updating applications well in advance. While cLabs promises to do their best to enable any DApp to work on CEL2 without modifications, it is best for developers to be able to test that behavior early on themselves.


The following is a rough roadmap which consists of the following milestones:

Milestone Overview Status Time estimate
1 L2 Transition Foundations Completed Completed
S Stack Selection WIP ~2 months / Mid-December ‘23
2 L2 with Core Celo Features WIP ~2 months / End of November ‘23
3 Celo Rollup ~2 months
4 Data Availability Layer ~1-3 months (high uncertainty)
5 Decentralized Sequencer Further ~2-4 months
6 Pre-Mainnet Further ~2-3 months
7 Mainnet

The further we progress in this roadmap, the harder it is to give relevant time estimates of when a milestone will be finished. Our expectation is that we can launch the mainnet by the end of 2024. Let’s briefly go through each milestone, covering what they encompass and the decisions that need to be made at each step.

Milestone 1: L2 Transition Foundations

The primary objective of this milestone is to build the infrastructure needed to iterate on the L2 development project and continue the process (started prior to the Gingerbread hard fork) of reviewing the design and implementation of Celo-specific features, and planning how to revise or refactor them for the future architecture.


End of September 2023 (finished)


*Only engineering deliverables are listed in this section here and below - other relevant items (e.g., research, communication) are not represented.

  1. Design Documentation: Design discussions around changes needed for key Celo-specific features.
  2. Testnet: Exploratory engineer testnet based on OP stack, which is anchored on the Sepolia testnet.
  3. Celo Token-Duality: Just as in the Celo blockchain, CELO behaves both as a native and as an ERC20 token (i.e., native & ERC20 transfers possible, balance showing for native and ERC20). This means, CELO can be used for gas payments on the L2, but more work is needed to make CELO a fully native token (see Milestone 2). This is the only Celo-specific adaptation of the initial testnet.
  4. Documentation: Initial documentation on how to use the testnet.
  5. Block explorer: A simple block explorer to graphically investigate the testnet.
  6. Faucet: A faucet enabling the community to get funds to test and deploy on the testnet.

Milestone S: Stack Selection

In parallel to Milestone 1, cLabs has been conducting research and evaluating the L2 stack technology under development across the web3 ecosystem – including (in alphabetical order) Arbitrum, Lina, OP Stack, Polygon, and ZKSync. While cLabs’ initial proposal for Celo to become an Ethereum L2 included a design outline based on OP Stack, using EigenDA for data availability, the space continues to advance fast, and Polygon and ZKSync have both directly engaged the Celo community on the forum.

Most of this roadmap document has been written in a stack-agnostic way, as far as possible, but executing on this plan depends on coming to a firm decision as soon as feasible. cLabs proposes to use the work set out below to help the community arrive at a decision on the L2 stack that can enable development to proceed.


Mid November 2023 - Publish draft decision framework for community consultation.
Late November 2023 - General consensus on decision framework, and forum discussions and community calls on stack options.
Early December 2023 - General consensus on preferred stack.
Mid December 2023 - Confirm stack selection via temperature check governance vote.


  1. Draft Decision Framework: a forum post outlining the criteria that cLabs feels should be evaluated, and how, as inputs into the decision around the L2 stack.
  2. Preferred Stack (Community Deliverable): ratification by the community of key technology stack choices for the Celo L2.

Milestone 2: L2 with Core Celo Features

With this milestone cLabs plans to deliver the main differentiating features of the Celo blockchain early in the process, postponing the implementation of features that depend on 3rd-party entities to later stages.


End of November 2023 (in progress)


  1. Ultragreen Money: Use the FeeHandler contract to allocate the base gas fee to different purposes. Notably, 80% of gas fees are burned, and 20% used for carbon offsets.
  2. CELO as the Native Token: Bridging ETH from L1 will go to a WETH ERC20 contract on L2 instead of creating a native L2 token like in Optimism. Gas fees on L2 (that include L1 fees denominated in ETH) will be denominated in CELO*. *ETH/CELO exchange rate will not be included in the scope of the milestone as well as precisely calculated data fees.
  3. Gas Payment with ERC-20 Tokens: The Celo blockchain maintains a governable list of ERC-20 tokens that can be used for gas payments. This enhances user experience and simplifies the use of stable tokens (e.g., users of Opera MiniPay only ever hold stablecoins and never need to acquire CELO or other tokens to pay for gas). For this stage of the testnet, we enable a predefined list of ERC-20 tokens* as currencies for gas payments. *This list is not governable, as all governance issues are delayed to Milestone 6.

Milestone 3: Celo Rollup

The objective for this milestone is to have a 100% Celo-compatible rollup. Per cLabs’ existing proposal design, this would be a version of OP that fully implements the Celo protocol but does not include certain modifications to the current L2 implementation, such as offchain DA and a decentralized sequencer. This rollup would not include consensus related features like validator elections, epoch rewards, and Celo’s random beacon.

As outlined in the original proposal, our primary objective with this design is to continue providing great UX for Celo users and developers. One of the key features of Celo is its 1-block finality and the absence of reorgs. We are planning to retain 1-block finality by reading deposited transactions only from finalized L1 blocks to minimize the effect of reorgs on Ethereum.

A good chunk of this milestone we’re planning to dedicate to getting more experience with migrating the state and getting clarity around the exact way we want to handle historical events as it might have a significant impact on infrastructure providers.


~2 months


  1. 1-block Finality: An implementation that provides 1-block finality with a centralized sequencer.
  2. Initial Celo State Migration: Try importing state data from the existing Celo L1 chain. Note that we plan to regularly update the state, which will help us gain practical experience with the tools and address any potential challenges that may arise during the process of migrating the state from Celo to CEL2.
  3. Iterative Celo State Migration: Establish a process of regular state updates.
  4. Full Celo Feature Migration: In this milestone we will implement all other Celo features* that were missing in Milestone 2. *This does not include consensus related features.
  • Governable Block Size.
  • Migrate/remove fractionMulExp precompile.
  • Governance (as it is today, an updated version of it is postponed till Milestone 6).


  1. How historical (pre-CEL2) events will be handled.
  2. What changes in the infrastructure layer will be needed to process pre-existing data (e.g. events).

Milestone 4: Data Availability Layer

Maintaining low gas fees represents a central objective for the proposed design. In our initial proposal, we explored off-chain data availability solutions like EigenDA as a means to achieve this goal without imposing substantial increases in Celo’s transaction fees. Data availability layer is a critical component in the efficiency of an L2 ecosystem, and, at this stage, it’s necessary to ensure that these associated costs do not significantly affect Celo’s transaction fees.

Delaying this milestone allows us the opportunity to do the required research and make a well-informed decision regarding the most appropriate solution for the data availability layer. Our aim is to thoroughly assess all potential options, including EigenDA, a custom DA layer and proto-danksharding, before committing to a specific technology. Furthermore, the decision made at this stage will have a considerable influence on the final design of the decentralized sequencer. Consequently, it makes sense for us to segregate these two steps and gather valuable insights from the process.

Again, even though at this step the testnet will still be using a centralized sequencer, we still can introduce protective mechanisms that will then be inherited in the final decentralized design.


~2 months Timeline is dependent on availability of DA solutions still in active development, e.g EigenDA testnet launch.


  1. Design documentation for the DA layer.
  2. Data availability layer that allows for sub-cent TX fees.
  3. A mechanism verifying data availability and penalizing for withholding it.
  4. Mechanism to charge “data availability fees”. OP stack charges a fixed fee to the user for DA; we need to adapt this mechanism to our DA solution.


  1. Which DA layer technology to use. Relevant questions are:
  • speed of delivery
  • costs (as in fees or for implementation)
  • security
  • solutions that might be relevant by the time we face this decision: Celestia, EigenDA, Proto-Danksharding.

Milestone 5: Decentralized Sequencer

At this stage we introduce the final piece of the design - decentralized sequencing. There are quite some choices to be made. We want to invest some time into optimizing Celo’s BFT algorithm or replacing it with a new consensus protocol such as HotStuff 2 or Narwhal+Bullshark and adjusting the validators incentives to match their updated role in the system.

Proxy nodes have been an invaluable part of the validator setup, helping with uptime and providing additional security for validators. They allow the validator to run within a private network, and to communicate to the rest of the Celo network via the proxy. It’s a unique feature of the Celo blockchain and with the migration to L2, this piece of infrastructure now needs to be re-evaluated.


~ 2-4 months


  1. New/updated consensus implementation.
  2. Migrate Random Beacon solution.
  3. A more standard implementation for proxies or alternative DoS protection measures.
  4. Updated Celo stats website.
  5. Finalize the new validator setup and update technical specifications.
  6. Draft proposal to update validator rewards based on their role in the L2.


  1. Replacement of the Celo Istanbul consensus:
  • Tendermint
  • HotStuff 2
  • Narwhal
  1. What to do with epoch snark data and ultra-light clients in general.

Milestone 6: Pre-Mainnet

This marks a significant milestone, achieved through our previous steps’ diligent efforts. At this point, we have a testnet that incorporates the key characteristics of the eventual final design, although certain features, like Governance, had been postponed till a later stage. Now it is a good time to come back to them, perform a final cleanup and address various tasks that have been deferred.


~ 2-3 months


  1. Design and implement new governance, figuring out the split between execution layer-level governance and high-level protocol governance.
  2. Updated documentation.
  3. Document and publish the final migration plan.
  4. Extensive testing.
  5. Make sure that major infrastructure providers keep working after the upgrade.
  6. Communication with the community and providing help with the migration.

Milestone 7: Mainnet

This marks the end of the project as we launch a fully fledged mainnet :tada:

Your involvement is greatly appreciated, and we eagerly anticipate your feedback!

Valentin, cLabs


Thanks @valentin for sharing this detailed and easy to understand roadmap. This seems like the right approach! Excited about the future ahead.


Hey Valentin, thanks for sharing the roadmap and more importantly thanks for seeking feedback from the Celo community. To be very clear, I strongly support Celo’s transition to an L2 on Ethereum. However, I have some concerns regarding the roadmap.

First, the next milestone should focus on eliminating the biggest risk/unknown in the whole project - Data Availability Layer research, before tackling other tasks/milestones. The highest selling point or competitive advantage that Celo would offer is “sub-cent transaction fees”, which is critical to payment apps like Celo-Opera MiniPay (and other Dapps). Based on my knowledge, the DA layer cost accounts about 80% of the total tx cost. However, DA layer is delayed and high uncertainty. Are we 100% sure there will be a 3rd party DA solution that can meet the requirement of “sub-cent transaction fees”? Especially during the bull market where the price of payment token, for example ETH, can be 10x and hence the cost will be 10x? If no 3rd party solution can meet the requirement of “sub-cent transaction fees”, what’s the plan B? All resources could be wasted if there is NO DA layer solution that meet the requirement of “sub-cent transaction fees”, agree?

Second, the plan should address the questions raised by @Ross on [token utility, revenue generation, and revenue allocation](cLabs Proposal for Celo to transition to an Ethereum L2 - #57 by Ross). Without these, the Celo L2 may not be sustainable, agree?

I think depending on the result of the DA layer research, there could be an elegant solution that addresses both concerns. Anyway, just my 2 cents here. Thanks again for all the work cLabs team has done so far!

1 Like

Hi cLabs team!

Is execution client diversity on the roadmap?

Thanks for your thoughtful response, @hhe!

I agree on the concerns that you raised, both are very important. As I outlined above, only engineering deliverables are listed in the roadmap. We’ve started Data Availability research already but since it’s very early stage realistically when we get to the implementation that would be Milestone 4.


Hi @kamikazechaser!
Although we would want to address the topic of execution client diversity, it’s a long-term goal for us, in the short term we want to focus on delivering one.

1 Like

Do you have the results? If so, can you share? My point is that if the research results shows NO DA solution can meet the requirement for “sub-cent transaction fees” and only after milestone 4, we draw the conclusion, then effort for milestone 1/2/3 could be wasted and the project won’t achieve its design goal. Hence we need to eliminate this risk/unknown ASAP.

Hey @valentin - excited to see where your discussions on decentralized sequencing go! I’m with Espresso Systems, and we’re building a shared sequencing/interoperability layer for Ethereum rollups. We’d be excited to think through this and contribute to your research.

Regarding your point on “optimizing Celo’s BFT algorithm or replacing it with a new consensus protocol such as HotStuff 2 or Narwhal+Bullshark” - we have developed our own implementation of HotStuff called HotShot. Here’s a link to the paper and supporting blog post.

Regarding Data Availability, how are you all prioritizing the balance between speed of delivery and security? We’ve built our own data availability solution, Tiramisu (complimentary to HotShot) to balance these tradeoffs. In optimistic cases, it leverages a CDN for super efficient availability of data, but uses a fall back network akin to Danksharding to provide Ethereum-level security guarantees and efficient access to data in pessimistic cases.

Also, I’m wondering how the community is thinking about shared sequencing? I’ve seen that conversations around potential rollup stacks have emerged, and am wondering how the Celo community thinks about the future of rollup interoperability (independent of stack).

Since we’ve invested a significant amount of resources into building out our own implementation of HotStuff, and a supporting DA layer, we’d be more than happy to host a call with the Celo community to outline our design choices, and answer any questions around these items.

Congrats on releasing the roadmap!


@hhe, the trouble with DA research is that there’s nothing very concrete to look at. Dencun (which includes proto-danksharding) hasn’t been delivered, EigenDA doesn’t have a testnet, and I believe Espresso’s Tiramisu isn’t in testnet quite yet, either.

This will look very different in even a few months / half a year.

Dencun lands in testnet likely this year, on mainnet early 2024. EigenDA and Tiramisu are motoring towards testnets.

As for the concern of wasted effort, I am not concerned reading the milestone. The options on the table are native (EIP-4844 aka proto-danksharding); EigenDA; other 3rd party like Espresso Tiramisu; home-grown.

That last one is important. It says “if none of the existing DA options do what we need, we can build our own”. The only way that fails is if it’s technically impossible to deliver a DA layer with the desired properties, at all.

3rd party solutions also have an incentive to be feasible. If the research shows they’re not quite up to snuff, I’d be shocked if there wasn’t iteration to their designs.


Welcome @ian-espresso to the forum! We’re excited to have you here and looking forward to having a conversation about ways to work together.

I can’t speak for the whole community, but I’m personally excited about the prospect of shared sequencing for the whole Ethereum ecosystem. The obvious challenge is prioritization so it’s great to see you posting early here so we can put our heads together to see if there is a way to work together to accelerate the CEL2 transition.


Welcome Espresso Systems! I’ve been following your team’s work for a while and as a validator I am very interested in learning more about how we might be able to use your stack for decentralized sequencing.


Hey @mariano! Totally understand the challenge with numerous priorities here. For a first step, I’d recommend a joint R&D call between the Celo community and the Espresso team to dive deeper into decentralized, shared sequencing landscape.

Since the DA layer + sequencer milestones are 3-6 months out, we could do an initial chat early December time frame if the community is open to that. I can jump in the Discord to coordinate scheduling there.


Hey @ian-espresso - thanks so much for making this post; there seems to be a lot of synergy worth exploring.

I think most of the community doesn’t have a strong vision or preference yet for the future of roll-up interoperability. Are there any resources you recommend to help people better understand the options and trade-offs of potential interoperability designs?

I would love to join a potential call and learn from your design choices to understand better trade-offs and why you landed on a specific vision. Is this something we can schedule for maybe a week after DevConnect?


Hey @LuukDAO - here’s a document that outlines our view on how shared sequencing can improve cross-rollup interop.

The tl;dr is that in a shared sequencing layer, transactions from multiple rollups are included within rollup blocks. For cross-rollup transactions, shared sequencing can guarantee atomic inclusion, and with PBS, honest builders can guarantee atomic execution. This provides greater guarantees to users that cross-rollup transactions will be executed. HotShot provides pre-confirmations within 2-3 blocks, this can be nearly instantaneous under best case network conditions.

Additionally, the user can check the rollup server, state update proof, or wait for the transaction to be certified by the L1. Cross-rollup bridging can also be done in a capital efficient manner with minimal latency, because there is no longer the need for multiple sources of trust. Instead, all chains share a single source of consensus and don’t risk independent state reorgs.

This is something our team has given a lot of thought over the last few months, and we’ll be releasing some more content on cross-rollup interop in the coming weeks.

Regarding the call, that timing works on our end! Would it be best to DM you here or on Discord to coordinate? We’re also at DevConnect and would love to see you guys while in Istanbul.

1 Like

Is the timeline for the stack selection being pushed back/delayed? What’s going on with that?


we will share more information about the stack selection aspect soon!


Stack selection framework proposal is now posted here:

To answer @Bigga 's question:

Is the timeline for the stack selection being pushed back/delayed?

We’re running about 2 weeks behind the schedule in Milestone S above – mainly because of a ton of great community building and 8 talks at DevConnect, and some work on the EigenDA testnet pulled in from M3 that @hhe will be interested in - more info shortly.


Stack selection delayed again?


Just posted about that: