Lack of sequencer uptime checks can lead to dutch auctions executing at bad prices or failing #18
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
🤖_33_group
AI based duplicate group recommendation
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/code-423n4/2024-07-reserve/blob/825e5a98a8c94a7b4458b3b359a507edb9e662ba/contracts/plugins/trading/DutchTrade.sol#L199-L205
Vulnerability details
Proof of Concept
First, per the readMe, protocol is to be deployed on multiple chains, optimistic L2s included, see https://github.com/code-423n4/2024-07-reserve/blob/825e5a98a8c94a7b4458b3b359a507edb9e662ba/README.md#L140
The protocol implements Dutch auction trades via DutchTrade.sol. The auction mechanism is designed with a specific price decay structure over time: see the docs for a short map on how these auctions should work.
However, the contract does not include any checks for sequencer uptime. This can be problematic because network outages and reorgs happen quite often with optimistic L2s.
Now to place bids we have https://github.com/code-423n4/2024-07-reserve/blob/825e5a98a8c94a7b4458b3b359a507edb9e662ba/contracts/plugins/trading/DutchTrade.sol#L199-L205
Take a look at the
_price()
function, which calculates the auction price based on the current timestamp:Now, if there's a sequencer downtime, which we should agree the likelihood to be substantial considering the various chains protocol is to deploy to the timestamp used for price calculation could be significantly off, leading to incorrect pricing.
Impact
Auctions could execute at unfavorable prices if there's a significant delay between when a bid is submitted and when it's processed due to sequencer downtime, even worse these auctions could fail entirely if they end during a period of sequencer downtime, as no bids would be able to be placed.
Since "sequencer downtime" can be seen as a twin window to
reorg
issues, would be key to note that sincecreate2
is not being used for these deployments of the auctions then we have issues where users might bid on the wrong auction due to a swap of the addresses since the reorg could switch addresses for 2 different auctions. Another subtle scenario is say a user would like to mint right after theRToken
was deployed, a reorg might cause for the deployment of a different RToken and trap the users' funds in it.Tool used
Recommended Mitigation Steps
Consider implementing a check for sequencer uptime using Chainlink's L2 Sequencer Uptime Feed. This can be used to ensure that the sequencer was online during the entire duration of an auction and then add a mechanism to extend or restart auctions if there was significant sequencer downtime during the auction period, and for the switch in address case, using
create2
should sort this out.Assessed type
Context
The text was updated successfully, but these errors were encountered: