cLabs Proposal for Celo to transition to an Ethereum L2

Thrilled to see this proposal published. As a member of the Celo ecosystem for years, the last time I was this excited was for the Donut hardfork that improved interoperability with Ethereum and other L1s (among other upgrades).

Fully in support of bring Celo closer to Ethereum, and longer-term making it the de-facto L2 for real-world web3 applications!


Great proposal. Celo team once again leads on innovation. An exciting and logical step for Celo.
I’m sure the colab with Ethereuem will help speed up achieveing Celo’s goals!


Hello all,

As a Prezenti grantee and Celo Camp builder this is the right step forward. Transition to a L2 based on OP stack will bring more alignment towards the development of Celo in direct correlation with Ethereum and its fastest growing projects and protocols (who knows - maybe it opens more doors for Celo). Alcancía’s Celo bags support this proposal.

Best :cowboy_hat_face:


This reads like a well-thought-out proposal and change. Toucan is in favor and supports this!


Amazing, and excited to see this! Would love to see the Celo ecosystem come closer to Ethereum.

Some technical questions/feedback:

  1. In the diagram, shouldn’t it be the proposers that sends a block to the validator set? Generally in PBFT-style consensus, the proposer moves first.

  2. Would the data submitted to Ethereum contain the signatures, or a SNARK of the signatures, or just the DA certificate?

    Making it include either the signatures or a SNARK, and making an L1 contract actually verify it, has a lot of benefits because then assets issued outside Celo (whether ethereum or an L2) can be bridged to Celo in a way with the maximum possible guarantees of a validium: even if the DA mechanism is broken, the worst that a malicious Celo validator set could do is freeze everyone’s funds by making a block with missing data; they would not be able to steal funds.

    On the other hand, if the SNARK (Plumo proofs?) live outside of Ethereum, then a bridge would not have that security guarantee, unless of course the bridge itself demands a full recursive proof. If bridging happens much less frequently than block submission, then maybe that would be ok.

  3. On “never reverting” as an objective. One of the challenges of that is that Ethereum itself can revert, and even post-SSF in extreme cases: during an inactivity leak the finality mechanism would not run and the chain would run on LMD GHOST.

    A particular risk in that situation is: what if someone deposits assets issued on Ethereum into Celo, but then Ethereum reverts, reverting the deposit, but those assets still exist on Celo.

    I see two solutions:

    • Abandon the “never revert” objective, and instead have a design where a Celo block header points to the most recent Ethereum block that it accepts deposits from, so Celo would revert in lockstep with Ethereum (this would happen only in extreme cases of inactivity leak + network instability, so users would know ahead of time that Ethereum is in an extreme mode that it is recovering from)
    • Only accept deposits from finalized blocks. In this case, if Ethereum enters an inactivity leak stage, Celo would just not accept deposits until the inactivity leak ends (this has happened once in Ethereum history so far, and lasted less than an hour, but in the worst case it could last several weeks)

    Personally, my opinion is that ideally all networks would embrace publishing revertable blocks in situations where finality stops working, because giving users partial information about what is likely to be included is better than giving users no information at all. But I understand that this is technically difficult to implement if the chain is not built for it already, and would not wish extra technical challenges on the Celo community that it’s not able to handle given its ongoing hard work in many other areas. Hence the second option sounds better?



Can we know more about the strengths that Celo can have compared to other existing Ethereum L2 chains?

Welcome to the Celo forum @vbuterin! I and I’m sure everyone here appreciates your detailed feedback and questions! Here are some thoughts/responses to your points:

  1. With regards to your proposer question, this is great feedback. We should update this diagram to differentiate between the BFT-Proposer, the OP-Stack Proposer, and OP-Stack Batcher. This is a little confusing because the term proposer is now overloaded and we tried to simplify the diagram a little.

  2. This is an active topic of research right now. It is possible to not have to include and verify the SNARK proof and/or BFT signatures, and just have L2 full nodes verify this data when deriving L2 blocks from the L1/DA. This would be the most L1 gas efficient, but then would require traditional optimistic fraud proofs and a 1 week withdrawal period for bridging assets out.

    On the other hand, we are working on a Halo2 proof that can prove Plumo proofs and have them be verified efficiently on Ethereum. This would simplify L2 block derivation and allow L1 smart contracts to read what blocks the sequencers are signing off on, which could be used for fast withdrawals (via a light client bridge) while the OP Stack works on fraud proofs. What’s great is that even if the cost of verifying these proofs ends up being too high to verify on every L2 block, we could use them in an optimistic manner.

    If we misinterpreted your question, let us know.

  3. This is a great discussion point. Given the types of use cases on Celo today, our thinking right now is to do exactly what you are proposing in your second suggestion (only accepting deposits from finalized blocks). This certainly carries some tradeoffs and we are continuing to do research on the impact on this. There might be other solutions that we are missing and so your feedback and guidance is helpful. Would love to find some more time to discuss this further.

Once again, we love this feedback. Excited to continue the conversation with you and others in the Ethereum and Celo communities :raised_hands:




Can we know more about the strengths that Celo can have compared to other existing Ethereum L2 chains?

I would say the main strengths are the key differentiators listed at the start of @matt’s post:

  • Decentralized sequencer powered by Celo’s existing validator set running Byzantine Fault Tolerance consensus.
  • Off-chain data availability layer, powered by EigenLayer and EigenDA, operated by Ethereum node operators, and protected by restaked ETH. EigenDA brings the design of danksharding to Ethereum early, enabling Celo to maintain its low fees.
  • A design that retains Celo’s 1-block finality.

Most L2s today do not operate decentralized sequencers. It is difficult for them to achieve sub 1 cent transaction fees, and they do not offer 1-block finality.


Great idea!

there is just one problem with the OP:

Off-chain data availability layer, powered by EigenLayer and EigenDA, operated by Ethereum node operators, and protected by restaked ETH. EigenDA brings the design of danksharding to Ethereum early, enabling Celo to maintain its low fees.

EigenDA is not actually protected by restaked ETH, because that is not possible. Due to the non-attributability of data withholding, it is not possible to slash the EigenDA validators’ restaked ETH for withholding data, therefore it cannot be described as “protected by restaked ETH”, and it is a very far from bringing “the design of danksharding to Ethereum early”. Since the rollup will be based on OP stack (optimistic rollup), it relies on the DA committee for safety of funds. Please be aware of the serious risks to safety of users funds involved in this setup!


I guess building up on @mariano’s post, regarding on what the final decision regarding these parameters ends up being, I guess a key takeaway is that Celo remains fully sovereign in how it chooses to set them up (as well as Celo being the native gas currency).


The fact that Solana is faster doesn’t really mean much in this context. For Celo, they key is high economic security behind the L1 blocks. In that regard, Ethereum heavily outperforms Solana. Uptime is also an important factor, with Ethereum having an outstanding track record.

Also, EVM compatibility makes interpretability more trivial. The same tooling works on Ethereum and on Celo with minimal modifications, that is not the case with Solana.


I tend to like the second option, as having instant one-block finality is a key feature of Celo and a lot of assumptions got built around it, it simplifies a lot of use-cases. I think that worst case is acceptable, giving that Ethereum provides more economic security and that’s the tradeoff.

I think this is a move in the right direction.

Previously I saw a tension where Celo sort of competed with Ethereum, while in practice the use cases are very complementary:

  • Ethereum as a settlement layer for the internet, with mostly institucional txs.
  • Celo, as a mobile-first, user-centric ecosystem.

I think this proposal aligns incentives really well: using Celo means that the Ethereum ecosystem also gets bigger, which could differentiate from other L1s and bring more folks to the community. It also ensures for developers that Celo is a safe place for their Dapp the want to move out of Ethereum.

I would like this proposal to invite folks to the Ethereum ecosystem to innovate on Celo. Celo has a history of pioneering UX and has the opportunity to move much faster than Ethereum. The parties required for an Ethereum upgrade are just too many for breaking changes to be tested and iterated fast enough. Many Account Abstraction proposals could be developed and tested on Celo before rolling them back to Ethereum, increasing the speed of iteration and innovation.

At the end of the day, I think what differentiates one network from another it is its community, as technology can be forked away and TVL can very easily move (as we have seen after DeFi summer ended). The Celo community has a strong focus one ReFi, projects with positive impact in the real word and real use caes. That is, in my opinion, it’s because the Celo Community made it clear that it will make everything possible to have affordable tx fees and that the most vulnerable users should be protected, all while having a positive impact on the planet. This is not the case in Ethereum, where many people have had funds locked due high tx fees, or whole Dapps had been pushed away, at the benefit of having a very decentralized and secure chain.

I would like to also make a note about using ETH (or other tokens for that matter) as gas tokens on Celo. After CIP-52 gets implemented in the next hardfork, all tx fees will eventually get converted to Celo on-chain and then burned (or donated to a Green Fund). So this alternative currencies (including Mento ones) are intermediary currencies rather than native gas tokens.


Acting as facilitator for a second, this proposal can be split into two key pieces:

  1. Making Celo part of a wider Ethereum ecosystem.
  2. How would (1) be achieved technically and what compromises are off the table (block finality, fees, etc).

I would suggest focusing on (1) for now and then opening an ongoing research and discussion line for (2), in case there’s consensus to support (1).

1 Like

I love this proposal, and am very happy to see it put forward. I believe the incentive alignment, technical alignment, and social/community alignment here makes sense on so many levels.


Thanks to restakinglover for the question that lets us address the underlying trust model of EigenDA.

There are three distinct ways to analyze the security of blockchain systems:

  1. Byzantine fault tolerance: Assume some fraction are honest (and follow the protocol exactly) and some are malicious (and can deviate arbitrarily).
  2. Equilibrium model: Analyzes the economic incentives of each node assuming there are enough distinct parties.
  3. Pure cryptoeconomic model: Assumes all stake is held by the same node and models the cost of economic corruption.

EigenDA is built on ETH restaking via EigenLayer and uses erasure codes with a configurable coding ratio which can be set by the rollup.

  1. BFT model: EigenDA is safe as long as >x fraction of nodes are honest (x can be 10% to 50% depending on coding rate), i.e., data can be retrieved.
  2. Equilibrium model: As long as collusion size is smaller than (1-x), storing and serving data is a Nash equilibrium.
    2a. Storing being NE is ensured by proof-of-custody which slashes ETH of nodes that do not store the data
    2b. Serving being NE is ensured because data is dispersed across various nodes, inducing a competitive market to serve
  3. Cryptoeconomic model: As long as the data is available (or equivalently, as long as >x fraction is honest), the ETH staked by any node that doesnt custody data will be slashed
    3a. EigenDA does not have unconditional cryptoeconomic safety, which is that if all nodes withhold data, then ETH will not be slashed, as proof of custody requires someone to trigger it and that party needs to know the data.

EigenDA builds on two distinct models of trust: non-collusion which comes from decentralization and economic trust which comes from (re)staking. The core idea is that EigenDA can borrow both decentralization and economic trust from Ethereum.

Further safety comes from CELO staking: the proposed architecture uses CELO stakers as part of decentralized sequencing and fast confirmation: hence there is additional redundancy in data availability. Thus the results above can be strengthened as follows:

  1. BFT model: EigenDA is safe as long as >x fraction of EigenDA nodes are honest (x can be 10% to 50% depending on coding rate) OR majority of CELO stakers honest.

  2. Equilibrium model: As long as EigenDA collusion size is smaller than (1-x) OR CELO collusion is sub-majority, storing and serving data is a Nash equilibrium.

  3. Cryptoeconomic model: As long as the data is available (or equivalently, as long as >x fraction of EigenDA is honest OR majority CELO stakers honest), the ETH staked by any node that doesnt custody data will be slashed
    3a. In addition, whenever DA safety fails, CELO stakers can be unconditionally slashed (by forking the CELO chain).

Overall this system improves the DA safety significantly via integrating decentralization and economics of two distinct communities. Reiterating, CELO+EigenDA builds on two distinct models of trust: non-collusion which comes from decentralization of CELO stakers and EigenLayer restakers and economic trust which comes from EigenLayer restaking and CELO staking.


Read through is a good upgrade


Great move for builders in both the Celo and Ethereum communities!


Brilliant step ahead for both Celo and Ethereum!

The GoodDollar community is watching it closely as the protocol’s reserve is on Ethereum and the Universal Basic Income distribution/usage is happening on Celo. Simplifying liquidity sharing between Celo and Ethereum is key to ensure that the protocol can continue to mint and distribute UBI.

Maintaining low gas fees is a must. We’ve seen >150k p2p micro transactions between GoodDollar holders since our expansion to Celo in May, and we want to make sure people can still send and receive money, no matter the amount.

Ahead, with prosperity for all.


How does this decision impact Celo’s roadmap goal of becoming the fastest L1 EVM chain? This was also listed in Celo’s press release just weeks prior to this L2 switch announcement(gingerbread hard fork announcement), so some clarity on Celo being the fastest (as far as EVM compatibility goes) and where the company is at with that, and the Mysten labs collaboration would be much appreciated.