mStable relies on accurate prices in a number of places across the system:
Calculation of mAsset Redemption Fee
Pricing strategy during re-collateralisation auction (Phase 2)
The Oracle in Phase 1 of the protocol is purposefully centralised - this non-critical pricing data is retrieved, validated and signed off-chain before being sent in to the on-chain Oracle. Prices remain valid for up to 12 hours before they are deemed to be too stale for use.
In scenario 3 above, it is absolutely critical that the prices are accurate, as they will be used to determine the starting and reserve prices for the OpenIPO Reverse Dutch auction during re-collateralisation. With this in mind, we view relying on a price feed, however decentralised, to be unnecessarily careless.
In this instance, we employ governors to do a manual price validation. They must supply current prices of both the mAsset and MTA when they cast their vote in the ARE proposal. In order for a vote to be accepted, the price must lie within 5% of the price currently emitted from our Oracle.
In an ideal world, our pricing data would come from a completely secure, accurate and reliable on-chain provider, like a high volume/frequency DEX, or shared data pool. There are emerging solutions to this requirement, but currently these solutions do not exist in maturity.
We have purposefully left our Oracle module upgradable and intend to move towards a more decentralised implementation as it becomes available. Phase 1.1 sees us welcome in a number of external data contributors through the first Module upgrade, while Phase 2 sees the possibility of joining a shared pool, like that of Compound or Maker's Open Oracle system, or leveraging existing implementations like that of Chainlink.