Within the LibOracle#oracleCircuitBreaker()
, there is no validation to check whether or not the retrieved-price would be a stale price (timeStamp > block.timestamp + 2 hours
).
This lead to retrieving a stale price when the LibOracle#oracleCircuitBreaker()
would be called.
Within the LibOracle#oracleCircuitBreaker()
, a fetched-data via Oracle would be checked and the result would be stored into the invalidFetchData
.
And then, if the invalidFetchData
would be True
, it would be reverted like this:
https://github.com/Cyfrin/2023-09-ditto/blob/main/contracts/libraries/LibOracle.sol#L120-L125
According to the "Invalid Fetch Data" in the documentation, it is supposed to be checked whether or not the timeStamp
would be greater than block.timestamp + 2 hours
in order to confirm that the timeStamp
would not be a stale Data like this:
Invalid Fetch Data
The following are checked regarding incoming Chainlink data:
timeStamp > block.timestamp
(Implies Chainlink data is coming from the future)
timeStamp > block.timestamp + 2 hours
(stale Data: Chainlink has not updated a round in over 2 hours)
However, within the LibOracle#oracleCircuitBreaker()
, there is no validation to check whether or not the retrieved-price would be a stale price (timeStamp > block.timestamp + 2 hours
).
This lead to retrieving a stale price when the LibOracle#oracleCircuitBreaker()
would be called.
This lead to retrieving a stale price when the LibOracle#oracleCircuitBreaker()
would be called.
Foundry
Within the LibOracle#oracleCircuitBreaker()
, consider adding the validation to check whether or not the retrieved-price would be a stale price (timeStamp > block.timestamp + 2 hours
) like this:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.