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:
owner
: set to the Compound Timelock.guardian
: an unverified trusted contract known to be controlled by the Gauntlet team.
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.