The ChainlinkUtil contract's sequencerUptimeFeed checks are inadequate. It fails to properly handle "invalid rounds" where startedAt is 0, potentially allowing operations when the sequencer status is uncertain. This oversight could lead to the contract functioning under incorrect assumptions about the L2 sequencer's status, posing risks to the system's reliability and security. The implementation does not fully adhere to Chainlink's recommended practices for sequencer uptime feeds.
The ChainlinkUtil contract has sequencerUptimeFeed checks in place to assert if the sequencer on an L2 is running but these checks are not implemented correctly. The chainlink docs say that sequencerUptimeFeed can return a 0 value for startedAt if it is called during an "invalid round".
Please note that an "invalid round" is described to mean there was 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. Further explanation can be seen as given by an official chainlink engineer as here in the chainlink public discord
This makes the implemented check below in the getPrice() to be useless if its called in an invalid round.
as startedAt will be 0, the arithmetic operation block.timestamp - startedAt will result in a value greater than GRACE_PERIOD_TIME (which is hardcoded to be 3600) i.e block.timestamp = 1719739032, so 1719739032 - 0 = 1719739032 which is bigger than 3600. The code won't revert.
Imagine a case where a round starts, at the beginning startedAt is recorded to be 0, and answer, the initial status is set to be 0. Note that docs say that if answer = 0, sequencer is up, if equals to 1, sequencer is down. But in this case here, answer and startedAt can be 0 initially, till after all data is gotten from oracles and update is confirmed then the values are reset to the correct values that show the correct status of the sequencer.
From these explanations and information, it can be seen that startedAt value is a second value that should be used in the check for if a sequencer is down/up or correctly updated. The checks in getPrice() will allow for sucessfull calls in an invalid round because reverts dont happen if answer == 0 and startedAt == 0 thus defeating the purpose of having a sequencerFeed check to assertain the status of the sequencerFeed on L2 i.e if it is up/down/active or if its status is actually confirmed to be either.
inadequate checks to confirm the correct status of the sequecncer/sequecncerUptimeFeed in ChainlinkUtil. getPrice() will not revert even when the sequcncer uptime feed is not updated or is called in an invalid round.
Manual Review
add a check that reverts if startedAt is returned as 0.
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.