The DSC protocol does not check the L2 Sequencer's uptime. If the protocol is deployed on L2 chains and the Sequencer goes down, the DSC protocol could consume stale price data, leading to exploitations.
The DSC protocol is assumed to support every EVM chain (confirmed by the client), including L2 chains such as Arbitrum, Optimism, and Metis.
On the Arbitrum chain, for example, the so-called Sequencer
is used for submitting batches of L2 transactions to the L1 chain. In case of Sequencer
downtime, Chainlink will not be able to feed the fresh price data to the L2 chain. Therefore, the price data consumed by the DSC protocol could become stale.
However, an attacker can still manually submit their L2 messages via L1 into the delayed Inbox of the L2 network. Then, an attacker can execute their L2 messages through the Inbox's forceInclusion()
. In this way, an attacker can execute L2 transactions to exploit the DSC protocol that is consuming the stale price data. For more info, please refer to this Chainlink's docs.
I noticed that the staleCheckLatestRoundData()
does not check the Sequencer
's uptime status. Therefore, the function could return stale price data.
Even if the Sequencer
goes down, the DSC protocol still allows users/attackers to execute its functions, such as mintDsc()
, burnDsc()
, redeemCollateral()
, and liquidate()
. However, the protocol could consume the stale price data unconsciously, leading to exploitations. This could result in the disruption of the protocol.
Manual Review
I recommend executing the revertIfSequencerInActive()
in the staleCheckLatestRoundData()
, as shown below. Specifically, the revertIfSequencerInActive()
will revert if the Sequencer
goes down and make sure that the grace period has passed after the Sequencer
is back up.
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.