Summary

The ChainLink Data Feed Heartbeat parameter is not a constant and static value and could be updated in the future. OracleLib is not taking in consideration this option and if that config value changes it could break the whole protocol flow by reverting when it should not or accepting a price that should be considered stale.

Vulnerability Details

The ChainLink Data Feed for a pair updates the last answer when

• Price changes above a delta X % compared to the previous price

• Y seconds have passed since the last answer

ChainLink can change those X and Y parameters for a data feed. The current implementation of the OracleLib library does not take in consideration and sets the TIMEOUT parameter as a constant value equal to 3 hours (10800 seconds).

These are the current configuration of wETH and wBTC on the ChainLink data feed:

• ETH / USD: deviation threshold: 0.5% | Heartbeat: 3600 seconds (1 hour)

• BTC / USD: deviation threshold: 0.5% | Heartbeat: 3600 seconds (1 hour)

OracleLib.staleCheckLatestRoundData works like this: if the latest answer from the ChainLink Data Feed is older than TIMEOUT (block.timestamp - response.updatedAt) the response is considered stale.

But as we said, ChainLink could change the Heartbeat parameter and this would mean that if there's no price change the Chainlink answer could change faster/slower than what's expected by the OracleLib.

Scenario 1) ChainLink increases Heartbeat to > 10800 seconds. If there is no price change above the deviation threshold the OracleLib will consider the ChainLink response stale even if the response is not stale (for the ChainLink standards)
Scenario 2) ChainLink decreases Heartbeat to 1800 seconds (30 minutes). TIMEOUT is 10800 and it seems to have been calculated as 3x the current CL Heartbeat, so the logic is that a price is stale if it has not changed in 3x Heartbeat. With the updated value of CL Heartbeat, the price should be considered stale if the answer has not been updated after 1.5 hours. This means that, for the current logic of OracleLib a price that should be considered stale is instead accepted and used by the protocol.

Impact

The protocol could

• revert declaring a price stale when in reality the price is not stale

• accept price as non-stale when in reality the price is stale

Tools Used

Manual

Recommendations

The OracleLib TIMEOUT parameter should not be declared constant but should be a variable that can be updated by the DSCEngine owner or by the Governance when needed and based on the specific ChainLink Data Feed Heartbeat value.

• Set the TIMEOUT as non-constant

• Initialize the value of TIMEOUT value based on the ChainLink Heartbeat current value

• Add a setTimeout function callable only by the DSCEngine owner / Governance to update the TIMEOUT when needed