Proposal #353 Review - Compound Reserves Vault Proposal 1

OpenZeppelin, in its role as Security Partner to Compound DAO, reviewed Proposal #353 for security issues.

Summary

Total Issues: 1 (0 resolved)

Low Severity Issues: 1 (0 resolved)

Scope

Following the review of Compound Proposal #348, OpenZeppelin has completed the assessment of Proposal #353, which represents part 1 of 2 of the updated proposal.

System Overview

Proposal #348 proposes leveraging the DAO’s USDC and DAI reserves to generate yield in lending markets using the Compound Reserves Aera Vault. The goal is to maximize the DAO treasury’s revenue, as outlined in the Compound Community Forum Proposal.

During the review of Proposal #348, OpenZeppelin identified that the C3PO oracle contracts listed in the AeraVaultRegistry did not have verified source code. Specifically, the C3PO cUSDCv3 oracle and C3PO cWETHv3 oracle contracts were unverified.

This lack of verification was due to a bug in the version of the Solidity compiler used to compile the contract. The bug, related to the use of the via-ir flag, produced bytecode differences that prevented verification on Etherscan. Following discussions with the Gauntlet team, the proposal was canceled as a precautionary measure.

As a result of the cancellation of Proposal #348, two new proposals have been prepared to address the contract verification bug. Since Compound’s Governor limits proposals to 10 actions, two separate proposals are needed to update the AeraVault and deploy the assets.

This review encompasses the first of the two new proposals, Proposal #353. This proposal is similar to Proposal #348 with one key difference; instead of adding the C3PO cWETHv3 oracle, the unverified C3PO cUSDCv3 oracle will be removed from the registry. Both C3PO oracles will be added in the subsequent proposal.

Security Model and Trust Assumptions

The AeraVaultV2 contract has two privileged roles:

The guardian is authorized to act on behalf of the vault’s owner within constraints defined as a list of permitted sighashes registered in the AeraVaultHooks module. One of these sighashes corresponds to UniswapV3 Router’s exactInputSingle function, which could allow a potentially malicious guardian to transfer vault assets to an arbitrary account by setting the recipient parameter in a swap operation.

The AeraVaultV2 does not validate the parameter values of allowed functions; however, it enforces, on a per transaction basis, that daily losses do not exceed 3% of the vault balance.

It is assumed that the guardian of the AeraVaultV2 will act in alignment with the interests of the owner and refrain from any malicious actions. The guardian is expected to maintain this trustworthy behavior, ensuring the security and integrity of the vault.

Low Severity

Unnecessary Target Sighashes in AeraVaultHooks

Although the C3PO oracles for cUSDCv3 and cWETHv3 have been temporarily removed from the AeraVaultHooks, the contract still retains the function signatures (sighashes) related to supplying and withdrawing from those Comets.

Consider removing the sighashes for the cUSDCv3 and cWETHv3 from the AeraVaultHooks contract to prevent the usage of the vault funds in those Comet markets, until the corresponding C3PO oracles are reintroduced in the next proposal.

Conclusion

The issue identified in Proposal #353 poses minimal risk and will be resolved in a subsequent proposal. The unnecessary sighashes will be needed when the oracles are reintroduced but would require one or more scarce proposal actions to remove now and add back later. The trust assumptions for this Aera vault remain the same as those for the Compound Vendor Payment Vault. Despite these concerns, the proposal has been correctly crafted and adheres to all current recommendations.

1 Like