Submitted by ladboy233, also found by 0x73696d616f
In the Api3OracleReader.sol, the code assumes tha the timestamp returned from oracle is always in the past.
Note the check:
If timestamp is greater than block.timestamp, the transaction will revert and block oracle lookup on APi3OracleReader.sol.
The relayer on api3 side can update both oracle price timestamp and value.
Let us go over how the price is updated in Api3 code:
The function readDataFeedWithID basically just read the data from struct _dataFeeds[beaconId], in this function
When the relayer updates the oracle data, first we are calling processBeaconUpdate.
Note that is a modifier onlyValidateTimestamp.
The check ensures that only when the timstamp is from more than 1 hour, the update reverts.
What does this mean?
The timestamp of an oracle can be set to the future within an hour, the relayer does not have to be malicious, it is a normal part of updating data.
Suppose the current timestamp is 10000
1 hour = 3600 seconds
If the relayer set timestamp to 12000, the price update will go through
But the code:
Will revert when current timestamp is 10001.
10001 - 12000 will revert in underflow.
If the oracle timestamp comes from the future, the code should consider it not stale.
Can change the code to:
fez-init (INIT) confirmed
