Optimism Market Admin Migration Review

[jbass-oz]

Summary

Timeline: From 2024-11-11 To 2024-11-12

Total Issues: 0 (0 resolved)

Scope

We reviewed the calldata generated by the Optimism migration script in PR#1 at the 607ce91 commit.

Migration review

We reviewed the Market Admin migration for the Optimism network. During the migration review, we analyzed the following aspects:

1. Migration Call Sequence: The migration follows the expected sequence, updating the Configurator to the new implementation and all Comet market contracts on Optimism to operate under the new CometProxyAdmin.

2. Contract Address Consistency: Each contract’s address, including CometProxyAdmin, Configurator, MarketAdminPermissionChecker, MarketUpdateTimelock, and MarketUpdateProposer, was verified against the migration plan to ensure the addresses were correct and consistent with our expectations.

3. Code Integrity Check: We compared the deployed code for each new contract with the previously audited version to ensure no unauthorized changes were introduced. This step was crucial to confirm that no new vulnerabilities were inadvertently introduced during deployment.

4. Contract State Configuration: The initial state of each newly deployed contract was reviewed to ensure correct setup according to the migration plan. This included verifying that the ownership, permissions, and specific configuration variables such as marketAdmin, pauseGuardian, and proposalGuardian were set appropriately. We also verified that the ownership of the deployed contracts are correctly transferred to the current Timelock, making it impossible for further changes to state before the Market Admin governance path is live.

5. Simulated Testing: To verify contract functionality and expected behavior, we conducted simulated tests. These simulations checked that the contracts, specifically MarketUpdateProposer and MarketUpdateTimelock, responded accurately to proposals, affirming that the governance changes were working as designed.

After this comprehensive analysis, we confirm that the migration on the Optimism network executes as expected, with all contract addresses, permissions, and state configurations matching the pre-audited specifications. The deployment aligns with the intended security model, with no discrepancies or issues identified.

Privileged Multisig Accounts

Two privileged accounts using Safe multisig wallets were configured to interact with the MarketUpdateProposer and MarketAdminPermissionChecker contracts:

• Guardian Account: Set as the pauseGuardian in MarketAdminPermissionChecker which can cut off the access of the marketAdmin to the protocol, also set as proposalGuardian within the MarketUpdateProposer which allows the guardian wallet to cancel any proposals sent by the marketAdmin. The Safe multisig wallet for this account, at address 0x3fFd6c073a4ba24a113B18C8F373569640916A45, operates with a threshold of 4 out of 7 owners:

  • 0x2C96F0403eabC1F11FE737566dEDB183A019763B
  • 0xd04e545c665741cd99d1B9D9CD96396F0f8166FB
  • 0xC3AaE58Ab81663872dd36d73613eb295b167F546
  • 0xDD659911EcBD4458db07Ee7cDdeC79bf8F859AbC
  • 0x7e4A8391C728fEd9069B2962699AB416628B19Fa
  • 0x2B384212EDc04Ae8bB41738D05BA20E33277bf33
  • 0x54A37d93E57c5DA659F508069Cf65A381b61E189

• MarketAdmin Account: Defined within MarketUpdateProposer, this account has privileges to submit new proposals to the MarketUpdateProposer. The Safe multisig wallet for this account, at address 0x7e14050080306cd36b47DE61ce604b3a1EC70c4e, operates with a threshold of 2 out of the following 4 owners:

  • 0xDD659911EcBD4458db07Ee7cDdeC79bf8F859AbC
  • 0xda32C5AEE8Fc5C51Ed9a99f5608c33f435F740B4
  • 0x1D8e0b8F4CEd9262C9ac0c0870BF8B45D74ad9D9
  • 0x47526FDDBA0A5a7ef001FaaD4836b771B3e92522

The security model depends on the integrity and reliability of these multisig wallets, assuming that these addresses belong to independent and trustworthy entities with aligned interests in maintaining the security and stability of the Compound ecosystem. In case these two addresses collude against the protocol, they can harm the protocol through misconfiguration of the markets (e.g. reducing collateral factor can lead to liquidation of valid positions).

The protocol’s monitoring should begin immediately. If the marketAdmin submits a proposal before the new governance path is live, they could execute it as soon as the path becomes active, effectively bypassing the built-in timelock delay on the market admin path. Therefore, the community should start monitoring the market admin’s actions right away.

Conclusion

Our team at OpenZeppelin has reviewed the migration scripts and confirmed they are functioning correctly, with the contracts deployed successfully and correctly initialized. We strongly encourage the community to begin monitoring the market admin immediately, as they can start submitting proposals to the market admin timelock right away.