Oracle Sanity Checks
Last updated
Last updated
The Oracle contract implements a number of "sanity checks" to ensure that data being reported by the off-chain Oracle services is correct and reasonable. This helps protect the protocol in the unlikely case of an oracle reporting issue or Oracle compromise.
Sanity checks are tests that the reported data is reasonable within some bounds. The bounds are based on some assumptions about the network and are therefore adjustable as needed. Sanity checks include:
The total Consensus layer balance increase is not too high or too low — e.g., we expect a reward rate of around 5%, so the gains must not deviate from this too much.
The total consensus loss (if applicable) does not go beyond a certain % of protocol value. For example, in the case of slashing/penalties, the total loss is not greater than 0.1% of the protocol.
If the sanity checks fail, the protocol is automatically paused for the report to be reviewed.
Oracle Contract: 0x8735049F496727f824Cc0f2B174d826f5c408192
maxConsensusLayerGainPerBlockPPT()
190250 parts per trillion
Assume 7200 slots per day, 365 slots per year = 2628000 slots per year. Assume 5% expected yield per Year = 19025 PPT. Sanity bound 10x expected = 190259 PPT.
minConsensusLayerGainPerBlockPPT()
1903 parts per trillion
Assume 7200 slots per day, 365 slots per year = 2628000 slots per year. Assume 5% expected yield per Year = 19025 PPT. Sanity bound 0.1x expected = 1903 PPT.
maxConsensusLayerLossPPM()
1000 parts per million, 0.1%
The maximum consensus layer loss (in part-per-million, i.e. in units of 1e-6). This value doesn't scale with time and represents a total loss over a given period, remaining independent of the blocks. It encapsulates scenarios such as a single substantial slashing event or concurrent off-chain Oracle service downtime with validators incurring attestation penalties.