Comet Asset Extension Migration Audit

Summary

Timeline: From 2025-01-13 To 2025-01-27

Total Issues: 5 (0 resolved)

Medium Severity Issues: 1 (0 resolved)

Low Severity Issues: 4 (0 resolved)

Scope

We audited the migration scripts in the compound-finance/comet repository at commit 5fe26a2, part of pull request #904.

In scope were the following files:

deployments
├─ arbitrum/usdc/migrations/1735299626_update_comet_to_support_more_collaterals.ts
├─ arbitrum/usdc/migrations/1735299626_update_comet_to_support_more_collaterals.ts
├─ arbitrum/usdc.e/migrations/1735299634_update_comet_to_support_more_collaterals.ts
├─ arbitrum/usdt/migrations/1735299656_update_comet_to_support_more_collaterals.ts
├─ arbitrum/weth/migrations/1735299663_update_comet_to_support_more_collaterals.ts
├─ base/aero/migrations/1735299703_update_comet_to_support_more_collaterals.ts
├─ base/usdbc/migrations/1735299714_update_comet_to_support_more_collaterals.ts
├─ base/usdc/migrations/1735299718_update_comet_to_support_more_collaterals.ts
├─ base/weth/migrations/1735299723_update_comet_to_support_more_collaterals.ts
├─ mainnet/usdc/migrations/1735299739_update_comet_to_support_more_collaterals.ts
├─ mainnet/usds/migrations/1735299744_update_comet_to_support_more_collaterals.ts
├─ mainnet/usdt/migrations/1735299748_update_comet_to_support_more_collaterals.ts
├─ mainnet/weth/migrations/1735299752_update_comet_to_support_more_collaterals.ts
├─ mainnet/wsteth/migrations/1735299760_update_comet_to_support_more_collaterals.ts
├─ mantle/usde/migrations/1735299778_update_comet_to_support_more_collaterals.ts
├─ optimism/usdc/migrations/1735299799_update_comet_to_support_more_collaterals.ts
├─ optimism/usdt/migrations/1735299805_update_comet_to_support_more_collaterals.ts
├─ optimism/weth/migrations/1735299811_update_comet_to_support_more_collaterals.ts
├─ polygon/usdc/migrations/1735299827_update_comet_to_support_more_collaterals.ts
├─ polygon/usdt/migrations/1735299832_update_comet_to_support_more_collaterals.ts
└─ scroll/usdc/migrations/1735299855_update_comet_to_support_more_collaterals.ts

System Overview

This report outlines the findings from OpenZeppelin’s review of the migration scripts for all Compound collateral assets. Specifically these migration scripts create proposals that if enacted, will update the existing markets with the new Comet Asset Extension functionality.

Compound plans to update all Comet Markets across all networks to support the newly audited Comet Asset Extension contracts. This upgrade will enable Compound’s Comet Markets to support up to 24 collateral assets in each market, an increase from the previous limit of 15.

As part of this migration, Compound will deploy three new primary smart contracts:

  • AssetListFactory: Responsible for deploying a new asset list.
  • CometExtAssetList: A new version of the CometExt contract, which will include a variable pointing to the address of the AssetListFactory contract.
  • CometFactoryWithExtendedAssetList: A new Comet factory contract that facilitates the deployment of new Comet Markets capable of supporting an asset list of 24 collaterals.

Once these new contracts are deployed, the migration script will execute the following key actions:

  1. Call the Configurator.setFactory() function to update the Comet factory address of each Comet Market.

  2. Call the Configurator.setExtensionDelegate() function to assign the new CometExt implementation to the Comet Market.

  3. Call the CometAdmin.deployAndUpgradeTo() function to deploy a new Comet Market and upgrade the implementation of the Comet proxy.

Migration Review

We reviewed the Comet Asset Extension migration across all networks. During this process, we analyzed the following aspects:

  1. Migration Call Sequence: The migration follows the expected sequence, updating the Comet Factory and CometExt to the new implementation.

  2. Contract Address Consistency: We verified the addresses of all relevant contracts, including Governor, Configurator, CometProxyAdmin, L2 contracts, and all Comet Markets, against the migration plan. This ensured that all addresses were accurate and aligned with expectations.

  3. Code Integrity Check: The deployed code for each new contract was compared to the previously audited versions to ensure that no unauthorized modifications were introduced. This step was critical for confirming that no new vulnerabilities were inadvertently introduced during deployment.

  4. Deployment Validation: For each contract deployed on the network, we verified the constructor arguments and initializer parameters to ensure proper initialization as expected.

  5. Simulation Testing: We tested simulations of the migrations to verify the functionality and expected behavior of the contracts. These simulations ensured that:

    • Contracts invoked by the migration script were executed in the correct order.
    • The contracts functioned as intended.
    • The submitted proposals were consistent and correctly configured.

Medium Severity

A Single Comet Extension Is Reused for Multiple Markets

The update_comet_to_support_more_collaterals migration scripts contain the necessary logic to update the Comet Markets across multiple chains to support more collaterals. As part of these scripts, a new Comet Extension contract is deployed using the name and symbol of the previous Comet Extension contract. This pattern is employed in the migrations scripts for Arbitrum, Base, Ethereum Mainnet, Mantle, Optimism, Polygon, and Scroll.

While each script contains updates for multiple markets, it only deploys a single new Comet Extension, which uses the name and symbol for the first Comet Market on the chain and re-uses this same Comet Extension for the remaining markets. Consequently, all the markets on each chain will use the same Comet Extension, which returns the name and symbol of the first upgraded Comet Market.

The migration scripts listed below follow this incorrect pattern:

Consider updating the migration scripts to retrieve data from the correct Comet Extensions for all relevant assets. Currently, a single Comet Extension is re-used for all markets on the same chain, which leads to inconsistencies. Instead, separate Comet Extension contracts should be deployed with the appropriate parameters for each market. These contracts should then be used when calling setExtensionDelegate. This approach ensures that each Comet Market is associated with the correct Comet Extension, preventing potential issues caused by the current pattern of re-using a single Comet Extension across multiple markets.

Low Severity

Inaccurate Proposal Descriptions

For each migration, a proposal description string is submitted to the Governor contract as part of the proposal which enacts the migration. The description provides a brief overview of the proposal and enumerates the actions that the proposal will perform should it pass.

In the migration scripts, multiple instances of incorrect or incomplete proposal descriptions were identified. In particular:

  • Mainnet USDC-USDT-USDS: The order of actions, as described in the proposal description, is different from the order of actions as enacted by the migration script. The proposal description groups the migration actions by asset while the migration script groups the actions by the function called.
  • Mainnet WETH-WSTETH: The proposal description is incomplete.
  • Optimism USDC-USDT-WETH: The description notes that four Comet Markets will be updated, but in reality, there are only three assets that will be migrated.
  • Polygon USDC-USDT: The last sentence of the description mistakenly notes that it upgrades four Comet Markets to a new version, whereas only the USDC and USDT Comet Markets are upgraded.

In addition, it is noted that the final sentences of the proposal descriptions across the codebase describe the actions in an unclear manner; there is no clear distinction between the actions taken.

Consider modifying the proposal descriptions for the migrations so that they correspond to the intended actions proposed.

Incorrect Check in Migration Scripts

Within some reviewed migration scripts, a check is performed to assert that the Comet Extension for the updated Comet Markets has been correctly set to the newly deployed CometExtAssetList contract. However, the scripts only check that the first updated Comet Market’s extensionDelegate function returns the correct Comet Extension address. When checking the remaining Comet Markets, the first Comet Market is checked again.

The issue is present in the following scripts:

Consider correcting the checks to ensure that all the updated Comet Markets are updated to the correct Comet Extension. This can be achieved through checking the correct address is returned from the extensionDelegate function of each Comet Market.

Arbitrum USDCe Market Comet Extension Setup Incorrectly

During the review, it was discovered that the current USDCe Comet Market on Arbitrum points to a Comet Extension which returns the incorrect name and symbol. It returns USDC Compound and cUSDCv3 instead of Compound USDCe and cUSDCev3, respectively.

The issue is that when a new Comet Extension is deployed for the USDCe Comet Market using the migration script, the Comet Extension’s name and symbol constructor arguments are obtained from the current Comet Extension’s on-chain data. This means that the new Comet Extension will be deployed with the incorrect constructor arguments.

Consider specifically supplying the correct values for the USDCe Comet Extension constructor arguments within the appropriate migration script.

Incomplete Verification in Polygon Script

The verify() function in the Polygon USDC script currently only validates the USDC Comet Market by checking its assetList and Comet Extension properties. However, the enact() function also includes migration logic for the USDT Comet Market, which is not being validated in the verify() step.

To ensure comprehensive validation, consider updating the verify() function so that it includes additional checks for the USDT Comet Market. These checks should mirror those applied to the USDC Comet Market, validating both the assetList and extensionDelegate properties to ensure that they have been properly updated during the migration.

Conclusion

Enacting the reviewed migrations will upgrade existing Comet Markets on multiple chains to allow each to support up to 24 collateral assets. We have reviewed the migration scripts which will be used to enact the proposals. The identified issues were not severe, but would have necessitated redeployment if not addressed before execution on-chain.