OpenZeppelin, in its role as Security Partner to the Compound DAO, audited the proposed changes to the v2 Price Oracle contract.
Summary
July 8-12, 2024
Total Issues: 1 (1 resolved)
Notes & Additional Information: 1 (1 resolved)
Scope
We audited the smartcontractkit/open-oracle repository at commit 48c123d with a focus on the differences since our last audit.
In scope were the following files:
contracts
└── PriceOracle
└── PriceOracle.sol
System Overview
Compound stands as a prominent lending platform that enables liquidity providers to deposit their funds and earn interest, while simultaneously offering borrowers the opportunity to secure loans against collateral. Although the community is gradually transitioning to Compound V3 (Comet), Compound V2 continues to be actively utilized. From the start, Compound V3 has been using Chainlink price feeds.
In contrast, Compound V2 employs an anchoring system, which rejects price feeds from Chainlink oracles if there is a significant difference from the recent Time-Weighted Average Price (TWAP), potentially leading to price inaccuracies and delays during periods of market volatility. The price oracle under review in this audit is designed to replace the anchoring system in Compound V2, addressing these price update issues.
Security Model and Trust Assumptions
The PriceOracle contract is administered by an owner address responsible for adding various price feeds as configurations. These configurations can be utilized by third parties, such as Compound V2, to retrieve the prices of different assets. The contracts are specifically designed to output prices in a format that the Comptroller expects.
The contract owner is a trusted entity and is expected to provide accurate information to the system. Each configuration can either supply prices from a price feed or a fixed price set by the admin. The fixed price must be correctly provided by the admin in the manner expected by the Comptroller.
Notes & Additional Information
Precision loss for assets with large decimals value
In the getUnderlyingPrice function, the precision of the outcome relies on the difference of 36 - config.underlyingAssetDecimals. When config.underlyingAssetDecimals approaches 36 or exceeds it, the outcome will have low-precision decimals, potentially leading to inaccurate prices. However, since this is the required format by the Comptroller, the oracle might need to avoid adding such assets to its configuration.
Consider checking underlyingAssetDecimals of assets when adding them to the oracle and require a minimum precision amount for the reported prices. For example, if the required minimum precision is 6 decimals, the condition underlyingAssetDecimals <= 36-6 should hold true for all assets.
Update: Resolved in commit 4c3bf6c.
Conclusion
In the previous audit, we confirmed that the PriceOracle contract was functioning correctly. In this audit, we have reviewed the new changes and can confirm that the PriceOracle contract continues to operate as expected, with state transitions being correctly managed by the contract. Provided the admin supplies accurate information, the PriceOracle contract can correctly forward the prices from the designated feeds to the Comptroller contract in the expected format.