Chainlink sequencer feed may sometimes return a startedAt value of 0, potentially fooling the contract into believing the sequencer is active when its not.
In KeeperProxy.sol, the _validatePrice function is put in place to assert if the sequencer on an L2 is running but these checks are not implemented correctly. Chainlink docs say that sequencer feed can return a 0 value for startedAt if it is called during an "invalid round".
startedAt: This timestamp indicates when the sequencer changed status. This timestamp returns 0 if a round is invalid. When the sequencer comes back up after an outage, wait for the GRACE_PERIOD_TIME to pass before accepting answers from the data feed. Subtract startedAt from block.timestamp and revert the request if the result is less than the GRACE_PERIOD_TIME.
An "invalid round" is occurs when there's a problem updating the sequencer's status, possibly due to network issues or problems with data from oracles, and is shown by a startedAt time of 0 and answer is 0.
Inadequate checks to confirm the correct status of the sequencer fee in KeeperProxy.sol will cause _validatePrice to not revert even when the sequencer uptime feed is not updated or is called in an invalid round. This defeats the purpose of the uptime feed check as well causing that the protocol risks working with stale prices.
Manual Review
Include checks to revert if startedAt == 0
startedAt is only 0 when contract is not initialized on Arbitrum, but it is already initialized on Arbitrum. startedAt is sufficient for the protocol, it does not need roundID. Current documentation of Chainlink does not have this sentence: “This timestamp returns `0` if a round is invalid.“
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.