Optics v2 deployment complete! Please help verify the deployment

The Optics v2 deployment has been completed!

We’re focused on launching Optics v2 in a thoughtful and secure manner that maximizes trust and confidence in the new bridge.

Before it is considered live, we encourage members of the community to audit the deployment. To that end, we’re sharing details of the deployment here for anyone interested in reviewing.

We hope we can reach general consensus on this by Monday 29th 12pm EDT so the community can declare v2 live later that day.

Understanding the Optics v2 bridge deployment

This PR contains configuration for the deployment and the deployment outputs including contract addresses.

The new Optics v2 bridge deployment adds support for Avalanche C-Chain. It also reduces the window before which funds are made available from 3 hrs to 30 mins, making for a faster bridging experience for users.

This config includes a 2 week timelock for entering recovery mode and an initial community-owned 4 of 7 multisig controlling both the Governor and Recovery Manager.

Multisigs have been deployed for each network, each with the same membership composed of a diverse set of community members. In alphabetical order, they are:

  • Celo Foundation: 0xa725898D6F73C512f803B564A89DFbd96cF298EC
  • Celo Wallet: 0xeE2b1e23e71052860C14f69E84AAF78478606D63
  • Censusworks: 0x7519Db53B63d72721470319A5F4462D587Bb3008
  • cLabs: 0xd85DC9A21378EF738A248236E970c2e0be89C9c2
  • Mobius: 0x63c079444e07D82d33399DE7D56d6E48740494c7
  • Moola: 0x7d7cd2ED526F99D05A05a93CCf42C1ADdBe78552
  • Ubeswap: 0xFCcD3516d6BB62b009088aDae1E349430dDF6e77

The multisigs are deployed at the following addresses:

  • Celo: 0x070c2843402Aa0637ae0F2E2edf601aAB5E72509 (Celo Safe)
  • Ethereum: 0x2bb2a5a724170357cb691841f40d26a950d8c33d (Gnosis Safe)
  • Polygon: 0x8A1405C70c8a45177b5ac71b1d22779272E5d48b (Gnosis Safe)
  • Avalanche: 0x8a11d528d12ea09ccbf86e21B7813812b53a6900 (Pangolin Safe)

The Governance domain is Celo, so the Celo multisig address is used for both Optics governance and the recovery manager for the Celo chain.

Suggested verification steps

Should you want to gain confidence that the bridge has been correctly deployed and is under community-own governance, we recommend the following steps:

Check the configuration in the PR matches the state of the deployed contracts. You will want to look up the governance proxy addresses from the config for each network and verify the following:

  • governor() is set to 0x00...00 for all networks but Celo where it is set to the Celo multisig
  • recoveryManager() is set to the multisig address above for each network
  • recoveryTimelock() is set to 14 days (1209600 secs) for each network

You can verify some of this data using block explorers that support read calls on proxy contracts (e.g. etherscan). If you can’t find a tool that you can use to easily inspect contract state, consider the following web3playground.io code (connect Metamask and select the correct network first):

async function main() {

// TODO: Set this to the governance proxy address for each network (from
// deployment config PR). This must match the network you are connected
// to via Metamask.

const governanceRouterAddress = "<GOVERNANCE_PROXY_ADDRESS>"

const recoveryManagerSig = web3.eth.abi.encodeFunctionSignature("recoveryManager()")
const recoveryManager = await web3.eth.call({ to: governanceRouterAddress, data: recoveryManagerSig })
console.log(recoveryManager)

const governorSig = web3.eth.abi.encodeFunctionSignature("governor()")
const governor = await web3.eth.call({ to: governanceRouterAddress, data: governorSig })
console.log(governor)

const recoveryTimelockSig = web3.eth.abi.encodeFunctionSignature("recoveryTimelock()")
const recoveryTimelock = await web3.eth.call({ to: governanceRouterAddress, data: recoveryTimelockSig })
console.log(parseInt(recoveryTimelock, 16))
}

Additionally, you may want to verify that the keyholders are the same for each multisig on each network and match the list above, and the threshold required for a change is 4. You can do so by importing the multisig contract address into each of the following multisig services:

An audit of the Optics smart contract code was completed previously and can now be viewed here. The issues raised there were considered low severity, and will be addressed in a future upgrade to the contracts.

Optics has several UIs and each of them will be allowing users to work with both the Optics v1 bridge and the new Optics v2 bridge during the transition period.

We welcome your help. Please send questions, suggestions for further verification steps, and any feedback here or in the discussion on #community-owned-optics on Optics Discord.

7 Likes

will Sushi increase its reward once V2 is completed, it’s only half of what it was before

hey @tim from security/trust perspective it would be great if you can verify all the deployed contracts. Just because contract is usable through a gnosis safe UI doesn’t mean it is an unmodified/unaltered gnosis safe contract.

If you want to do things right, it would be best if all deployed contracts are fully source verified on all platforms (including Multisigs)

1 Like

Also I just took a quick look at the PR and Celo contracts, and none of the contracts deployed on Celo seem to be verified on explorer/sourcify.

How do you expect community members to verify/check anything if contracts aren’t source code verified?

@thezviad you are right that source verification is critical. Not entirely sure why Sourcify hasn’t picked up the Celo multisig, but if you look at the creator of GnosisSafeProxy (0x070c2843402Aa0637ae0F2E2edf601aAB5E72509) - Celo Explorer, it is GnosisSafeProxyFactory (0xC22834581EbC8527d974F8a1c97E1bEA4EF910BC) - Celo Explorer which is the Factory, whose source is verified and also is referenced by the gnosis team here Celo deployment by rmeissner · Pull Request #18 · gnosis/safe-deployments · GitHub

Re: Celo contracts not being verified, the tooling unfortunately hasn’t made it easy to verify them on non-Etherscan explorers, so we are still in the process of manually verifying

EDIT: I just verified a few more contracts. I noticed that Blockscout will imply that a contract wasn’t source verified, but when you click on the Code tab, it will actually show up.

EDIT 2: I was able to source verify the Celo multisig GnosisSafeProxy (0x070c2843402Aa0637ae0F2E2edf601aAB5E72509) - Celo Explorer

2 Likes

:+1: makes sense. Would be nice if somehow Multisig got verified too since it would allow other tools to parse its transactions, but at least from security perspective this seems fine.