Relevant smart contracts:
The Oracle Module is in charge with ingesting and pushing price feed updates into the system. It has three core components: a medianizer that accepts data points from whitelisted addresses or calls multiple oracle networks, an
FSM (Feed Security Module) that introduces a delay to prices coming from the medianizer and an
OracleRelayer that divides the price data by the
redemptionPrice and then divides the result again by the collateralization ratio (of the asset whose price is submitted) before pushing the final output in the
SAFEEngine. The module may also be used to provide price feed data for the system's feedback mechanism or other contracts meant to autonomously set system parameters.
DSValue is a simplified version of a medianizer. It is used for testing the oracle infrastructure. The contract creator can specify which addresses are allowed to update the price feed inside the contract.
OSM (named via acronym from Oracle Security Module) ensures that new price values propagated from the medianizers are not taken up by the system until a specified delay has passed.
DSM (named via acronym from Dampened Security Module) is an
OSM-like contract that limits the maximum price change between two consecutive price feed updates.
FsmGovernanceInterface is an abstraction meant to help governance
OracleRelayer is the glue between the
OSM and the core system (
SAFEEngine). It divides every price feed by the latest
redemptionPrice and then divides the output again by the collateralization ratio before saving the final result. The relayer will, in fact, store two different prices for each collateral type: a
safetyPrice used only when SAFE users want to generate debt and a
liquidationPrice used when someone calls
LiquidationEngine.liquidateSAFE. The relayer is also in charge with storing the
redemptionPrice and updating it using the
ChainlinkPriceFeedMedianizer provide fresh price feeds for every token used in the system. The major difference between the two is that the governance led version maintains a whitelist of price feed contracts which are authorized (and incentivized) by token holders to push prices into the system whereas the Chainlink version does not depend on GEB's governance to function properly (apart from instances where token holders need to point to an upgraded version of the Chainlink aggregator).
OracleRelayer - A bug would most likely result in the collateral prices not being updated anymore or in the
redemptionPrice being set to an unusually high or low value.
GovernanceLedPriceFeedMedianizer - there is no way to prevent a majority of the oracles to come together and sign a price of zero. This would result in the price being invalid and would return false on
ChainlinkPriceFeedMedianizer - governance may need to change the aggregator address in case there is an upgrade on the Chainlink infrastructure. Failure to do so will result in the price feed not being updated anymore and the need for settlement in case a solution is not found in a short period of time.
OSM - governance can change the
priceSource address to a malicious contract or to a source that does not adhere to the correct interface (that should otherwise contain
getResultWithValidity). Governance may also call
DSM - can suffer from the same attacks as the
FsmGovernanceInterface - governance can maliciously stop one or more
In the long run, governance can completely remove control over the
OracleRelayer, provided that three conditions are met:
Governance does not plan to add any more collateral types in the future.
The team that deployed the system thoroughly tested its feedback mechanism, both in simulated and in live environments.
OracleRelayer is in the Level 1 Gov Minimization category. Governance will need to retain long term control over
FSMs and medianizers because they are integrated with external components that can always change.