Optics Recovery Mode

Would appear that Anna owns it: anna — Mirror

She also made the commit you referenced and reported the 1s timelock bug 24 days ago.

It would appear that Anna (the person who made the commit you linked) is also the owner of the address: anna — Mirror (used this account to also acquire $PARTY as you mentioned)

This makes sense when reading the Github issue Anna also created 24 days ago: recoveryTimelock mis-configured · Issue #918 · celo-org/optics-monorepo · GitHub

1 Like

Thank you for sharing what you found. That does clarify things a lot. So Anna is also a core Celo contributor, and is the person who originally discovered and reported this 1-second misconfiguration with recoveryTimelock.

On a more broad note, while it’s nice to have an answer to that question, to be honest I’m still confused about this entire situation. I don’t understand where any malicious action comes into play.

The nature of these transactions seems unclear, but so does their connection to James Prestwich in any negative way. I might be overlooking something; if that is the case then please correct me.

As a new user of Celo I’m somewhat disappointed in the tone of the announcement. It comes off as a strong accusation and seems unwarranted by the surrounding context. I understand that Celo insiders likely have a more comprehensive understanding of this situation than any public observer. But I think it’s important to consider the potential negative impact of that tone when it comes to observers’ perceptions of Celo.


On what basis do you believe funds are not at risk, even though ownership of the bridge is now under unknown ownership outside of Celo/cLabs control? Unless Celo knows additional info about the bridge owner, it seems like the responsible course of action would be to evacuate funds from the current bridge and migrate to a new one.


Community Update #1 11/23/2021, Optics Recovery Mode

Hi all, I’m Eric from the cLabs Dev Rel team. Yesterday we held a community call with the CEO of cLabs, Tim Moreton. In our conversation, the team committed to:

  • Record and publish the AMA video. The video has been published and is available here on YouTube.
  • Update the language on the Optics Bridge. The new language highlights that Optics Bridge is currently in Recovery mode. The bridge is operational. Users may bridge their tokens as they choose.
  • Share a contract audit with the community. We are working to release it and hope to do so shortly.

Also, here are a few notes to address some questions that have come up:

The cLabs Optics team is currently staffed by more than 10 people, including several engineers, a handful of folks from the early team, and people like me and others helping the community on Discord and forum. (Heads up the forum has a profanity bot that deletes posts automatically. If your post is removed, please revise and submit again.)

The bridge is operational and tokens bridged to and from Celo, Polygon and Ethereum are operational. The Optics Bridge process takes a minimum of 4 hours to complete. If your transaction has not been completed after this time, please visit the #bridge-support channel on Optics Discord.

For those asking what to do with your funds, please know that we are working to provide you with more guidance beyond what we said above, and will share additional thoughts in the next 24 hours at the latest.

Finally, we are putting together an incident report over the coming days as we continue to discover new facts

Thanks for your patience.


Optics v2 Announcement

After sharing yesterday’s Optics v2 proposal in the #community-owned-optics channel on Discord and receiving feedback from the broader community in the AMA zoom call and Discord, we are seeing support for a new instance of Optics alongside a migration plan that will allow users to safely move their funds from the current Optics instance.

First and foremost, we’re focused on launching Optics v2 in a thoughtful and secure manner that maximizes trust and confidence in the new bridge. Given this goal, it will take a few days to stand up the new instance and properly audit it with the community.

Migration Plan

Since launching the new bridge will take some time, we are making recommendations for what people should do today to keep their funds safe until they are ready to migrate to the new bridge. We recommend that users perform the following actions as soon as possible:

  • For large holders not impacted by the cost of gas on Ethereum, we suggest using the current instance of Optics (v1) to move your funds back to Ethereum and then back to Celo using the newly deployed Optics v2 at a later time once it is launched.
  • For smaller holders not looking to be impacted by the price of gas on Ethereum, there are numerous non-optics assets that are not affected (e.g. cUSD, cEUR, cETH, cBTC) that we recommend trading into, and back to the Optics v2 assets once they are live.

Launch Plan

Based on the community feedback we’ve received so far, we are planning to move forward with the following:

Deploy Optics V2: Upon final testing and internal verification, we will publish the deploy config and work together with the community to explain it and have it checked and verified against the deployed onchain state. This config will include a 2 week timelock for entering recovery mode and an initial community-owned multisig controlling both the Governor and Recovery Manager.

Governance and Recovery Manager via Community Multisig: Before going live, we will assemble and agree as a community on a set of entities/projects to act as signers for the multisig. To get the deployment started, we have put together the following initial list but plan to amend this based on community feedback:

  • Moola Market (DeFi Dapp)
  • Mobius (DeFi Dapp)
  • Ubeswap (DeFi Dapp)
  • CeloWallet.app (Wallet)
  • cLabs (Core Development)
  • Censusworks (Validator)
  • Celo Foundation

Code Audit Released: An audit of the Optics code was completed previously and can now be viewed here.

Additional Planned Improvements

In addition to the above improvements around deployment and governance, Optics v2 will include a number of new features and enhancements which will be rolled out in the following weeks after launch:

Migration Page

We plan to release a migration page that will make it easier for people to move their assets between the two instances, but users do not need to wait for the migration GUI’s completion per the Migration Plan above.

Additionally, we are investigating creating additional pools, e.g. WETH (Optics v1) <> WETH (Optics v2) that would allow users to directly trade legacy optics assets for Optics v2 assets. We invite any parties interested in arbitraging these pools (and taking on any associated Optics v1 risk) to do so by sending assets over both bridges to maintain price parity.

Bridge Gas Refund

There is a CGP Proposal being discussed to automatically refund users for gas when sending funds towards Celo using a bridge. If passed, this proposal will make it easier and cheaper for users to bridge funds to Celo using future bridges.

Recovery Manager Timelock UI Notification

If the recovery manager activates recovery mode, it will take 2 weeks before it is enabled, and UIs will be modified to show a warning to users.

Faster and More Security

We’re reducing the window before which funds are made available from 3 hrs to 30 mins. This means faster bridging. At the same time, we are working hard to enable the community to run Watcher Agents to further increase the security of the bridge (see the Optics design). We don’t have an exact timeline for this but stay tuned! Over time, there are other changes we plan to make with the community to strengthen the security of the system too.

Avalanche Support

Based on popular demand, Optics v2 will be deployed on the Avalanche C-Chain as well as Ethereum, Celo and Polygon, so that after testing, we can support bridging of AVAX and other assets.

Final Thoughts

We appreciate the community’s feedback and participation in what have been some difficult conversations over the past few days. There are definitely lessons we have learned from this situation, and we will continue to look closely at what went wrong, and why. To that end, we plan on issuing a full incident report as soon as possible.

Now we are focused on this next chapter for Optics, and want to thank you for helping us get there. The team came up with a swift solution under difficult circumstances and I want to personally thank everyone involved for their efforts.


What about the current v1 bridge multi-sig?
Did Anna give back control of that multi-sig or is that still in limbo?

And as for “We invite all parties interested in arbitraging these pools to do so by sending assets over both bridges to maintain price parity.”, any funds sent over the v1 bridge is still vulnerable until control of the multi-sig is back in the org’s control right? Not necessarily a zero-risk arb there.

Good point. Let me update the post to mention that risk.

1 Like

Is it possible to find a full list of affected tokens, so we can be totally sure we’re out of risk? I’ve been reading about this topic on discord and here and I couldn’t find it.

I used the bridge to transfer some ETH from celo to polygon, and it worked, but its weird, i see that the WETH token contract on polygon is this one:

but the right one used on dApps is this:

Something to worry about?? i see there are transfers using that contract from 65 days ago, but i dont see how i can transform the WETH to the real one!

call it a bug. Optics is in beta for a reason. They shall fix this in Optics V2. For now you can bridge it back to Celo, then swap it to cUSD.

The audit report was released Oct 8th. A comment is right there. No one in Optics team bothered to read audit report I assume, but Option V2 will have this issue fixed?

Line 164-180 Function
recoveryManager = _recoveryManager (governance/GovernanceRouter.sol#173)
code sets recoveryManager without emitting an event which is difficult to track offchain.
Emit an event for critical parameter changes.

Might I recommend renaming the redeployment of Optics V2?


Hi Thawin, if you want that specific wETH on Polygon, you would need to bridge “wETH (Optics)” from Celo to Ethereum network, and then use the Polygon bridge to bridged to the Polygon network. If you have more questions or need help, the team is on discord. #bridges-support

[updated] Thanks @yeet @rq-crypto for flagging.

1 Like

This is not a good answer. Optics bridge shall manage this issue automatically(swap from wETH(Optics) to wETH(PoS)) or block it. Think what if WETH bridged by Celo to Ether is an unique token just like this wETH(Pos)? It will be a disaster. It feels that Optics team has no product manager, just a bunch of wild developers not knowing the need of an average user.
Another thing is that Optics bridge shall automatically unwrap WETH to ETH in Ether chain, because most users starts with ETH, not WETH. And most exchanges only recognize ETH. I assume a lot of users will have issue when bridging back WETH from celo to exchange address, because it will not show up.

Bridges don’t work like this. The PoS weth is from Polygon Proof of Stake Bridge. The underlying weth is held on ethereum in a contract optics bridge has no control over.
Even weth bridged via Polygon Plasma bridge is not interchangeable with weth bridged via PoS bridge.

Where tokens are minted or burned bridging is non trivial.
If you want to “swap” tokens across chains use liquidity bridges like xpollinate and always check which token you are getting on the other side, as there will likely be several, though won’t be liquidity for all them on exchanges.

Thanks for the explanation. We know bridging is tough, especially multi-chain bridging, which is why there is a team running Optics. Optics must have been working hard to make sure cross-chain validation is solid, however, I do not think it’s hard to establish a principal for cross-chain swaps. For each token in a specific chain, there should only have one path in-and-out, which is what an average user expect. And in Celo, there should be only one token, not multiple versions of wrappers. And Optics manages the technical details. In the case of wETH(Optics) to Polygon, why bridge protocol could not perform wrapper swap automatically, but leave the details to the users? Is internal swap hard to maintain? I think it’s hard, but doable. The bridge itself can manage token balance of contract address on various chains, and transfer between them cross-chain automatically using chain-specific bridge when contracts balances are off(every chain has native bridge with Ether). The Optics bridge itself is nothing more than a central clearing facility, with one branch per chain. If it works out, the multi-chain bridge itself can become a major application area of Celo network, as everyone is looking to pay for fast and reliable cross-chain transfers.

Thank y’all for your patience and kindness

I always have and always will fiercely protect users’ safety and security. Based on everything I know, I do not believe there is a security threat to users’ funds or to the bridge.

If you have not yet, please read this ticket: recoveryTimelock mis-configured · Issue #918 · celo-org/optics-monorepo · GitHub

I’ve had to retain lawyers to protect my rights. Im hopeful that I’ll be able to share more info soon :heart:

  • Anna

Anna, thank you for posting here. I am glad we are aligned: we all want to be sure the funds in the bridge are secure. We see that the biggest tension causing anxiety is the lack of transparency about who controls the recovery manager. How can we move Optics out of Recovery mode and the recovery manager to a known multisig as proposed in V2?


It’s great that bridge V2 will learn from the mistake and build on stronger governance. I think one thing should not get lost there, is that Optics has been performing well this week under heavy load. This is a actually a good sign and it might have a great potential as cross-chain bridges among strong competitions already from allbridge/Anyswap/RelayBridge. Bridge V2 can be more reliable, DAO governed, faster, but it needs to be more convenient to use. And that will make it stand out - because most users do not want to deal with bridging mass. Just get out of dev team habit and think of three things -(1) use the same contract address cross multiple chains to avoid confusion, (2) do not call cUSD as WcUSD in Ether chain, and look at how UST did it, (3) have only one wrapped edition per token per chain as long as the asset is passed through Optics bridge - it can be optics contract, it can be native assets(USDC) or established asset, like wETH on Polygon. Deliver user the end asset, and charge them if necessary

1 Like