thedavidmeister
commented
2 days ago This is two parts
- constructor validation
It actually doesn't matter if oracles are deployed with bad config, what matters is that the version that is referenced by a deployed ERC20PriceOracleReceiptVault is correctly deployed.
If a 0 base or quote were actually used, i think that would cause _price to error when solidity attempts to deserialize calls to a non-contract address into uint256 values, which in practise means no tokens could be minted based on the oracle output anyway, so nothing would happen and we'd just have to redeploy.
Pragmatically, Cyclo is being deployed by a foundry script from an automated CI process, so it's not manual, and the script actually creates both the quote and base inline with the combined oracle, so there's no way a real deployment using the deploy actions on github could actually reference a 0 address.
https://github.com/cyclofinance/cyclo.sol/blob/main/script/Deploy.sol#L54
- Assuming 18 decimals
Any oracle implementing IPriceOracleV2 that is not 18 decimals is non conformant to that interface, so should be considered a corrupt oracle anyway. This means that it is the implementation's job as an oracle to first normalize everything to 18 decimals before returning a value for price.
https://github.com/gildlab/ethgild/blob/main/src/interface/IPriceOracleV2.sol#L11
/// Simplified interface into a price oracle.
/// The intention is that some more complex oracle interface is wrapped/adapted
/// by a contract that implements `IPriceOracleV2` to produce a single final
/// price value. A price is defined as the best possible ratio between two assets
/// for the purpose of a liquid trade.
///
/// Prices from an `IPriceOracleV2` MUST be:
/// - The latest available data/value
/// - Fresh enough or revert if only too-stale data is available
/// - Represented as `uint256` values or error (e.g. disallow negative values)
/// - 18 decimal fixed point values representing a ratio (price) between "base"
/// and "quote" token.
/// - A positive integer, `0` prices are disallowed.
/// - Valid according to the upstream oracle or revert for any other reason the
/// price is suspect or unusable.
///
/// By normalising all ratios to 18 decimal fixed point at their source we
/// simplify downstream math that derives prices by combining several
/// real price quotes.
///
/// If for any reason the underlying oracle cannot produce an appropriate
/// answer it MUST error rather than return inappropriate values. The ability
/// to do so MAY be limited by upstream providers.
The TwoPriceOracleV2 contract's constructor does not validate that the base and quote parameters are non-zero. Additionally, there is no validation to ensure that the oracles' decimals are consistent, which is crucial for accurate price calculations. This can lead to incorrect contract initialization and potential calculation errors if invalid parameters are provided.