Optimism Comet Deployment Assessment
Updated April 10, 2024
Initially we reviewed pull request Deploy Compound III on Optimism by dmitriy-bergman-works · Pull Request #833 · compound-finance/comet · GitHub of the compound-finance/comet repository at commit b329070
. This was a set of deployment and migration scripts that deployed Comet USDC and USDT on the Optimism network. After the first review of the scripts, with new changes after the initial stage of the audit, the scope was reduced to only USDC scripts on commit 2abd324, the changes can be found here.
In scope were the following files:
deployments
└── optimism
├── usdc
│ ├── configuration.json
│ ├── deploy.ts
│ └── migrations
│ └── 1707394874_configurate_and_ens.ts
└── usdt
├── configuration.json
├── deploy.ts
└── migrations
└── 1707399040_configurate_and_ens.ts
Low Severity
Outdated verification of state changes
Changes of the migration script up to commit 874052
contain code changes including:
- Setting
baseSupplySpeed
andbaseBorrowSpeed
to zero. - Setting
supplyCap
for all collateral assets to zero. - Removing
wstETH
as collateral form the USDC Comet.
However, these changes are not reflected in the verify
function. Consider the following changes:
- Change the expected values of
baseTrackingBorrowSpeed
andbaseTrackingSupplySpeed
to zero. - Change the expected
supplyCap
values to zero. - Remove
wstETH
from the list of expected changes.
Notes & Additional Information
Inaccurate Proposal Description
The description of the proposal states that there will be an emission of 5 COMP/day for both borrowing and lending on the upcoming USDC market. However, in recent changes to the migration script, the baseSupplySpeed
and baseBorrowSpeed
were set to zero.
Consider adapting the proposal description to reflect recent changes.
Update: Resolved in commit 05a1f00
Conclusion
In this audit, our initial focus was on the deployment of Compound V3 USDC and USDT markets on Optimism. After the first phase of the audit, the OpenZeppelin team concluded that under normal conditions, the contracts are likely to be deployed successfully without issues. However, it is important to highlight a concern regarding the initialization of the BridgeReceiver contract which was also noted in a previous audit: this contract can be initialized by any address. Although the BridgeReceiver is deployed and initialized within the same script, these actions occur in different transaction contexts which can be modified by the block proposer. This means that verifying the deployment after the script is run is also important. In such scenarios where the contract is initialized by an unexpected address, we recommend restarting the deployment process in a more secure and controlled environment.
Later on, the scope was reduced to only include the USDC market. Our team at OpenZeppelin has carefully reviewed the new changes to the deployment scripts and is confident that the initial deployment of the contracts will proceed without issue. However, the verify function fails to check the appropriate values, leading to failure in the verifying step of the deployed contract.
To sum up, the scripts are fundamentally correct, and the deployment process is expected to go through successfully while minor fixes need to be implemented.