If a user places a bid in the auction at block.timestamp == auctionEndTime
, someone else can frontrun the bid()
transaction by calling auctionEnd()
first, resulting in the user losing their points.
Consider the following scenario:
A user calls the FjordAuction.bid
function (placing a bid in the auction when block.timestamp == auctionEndTime
).
A frontrunner detects the transaction in the mempool and sends an auctionEnd()
transaction faster.
As a result, the user's transaction is successfully processed, but the bid is placed in an already ended auction.
This issue occurs due to an incorrect check of whether the auction has ended.
The user ends up losing all their points as a result of the issue
Manual review
The AuctionNotYetEnded
check needs to be updated as follows
The protocol doesn't properly treat the `block.timestamp == auctionEndTime` case. Impact: High - There are at least two possible impacts here: 1. By chance, user bids could land in a block after the `auctionEnd()` is called, not including them in the multiplier calculation, leading to a situation where there are insufficient funds to pay everyone's claim; 2. By malice, where someone can use a script to call `auctionEnd()` + `bid(totalBids)` + `claimTokens()`, effectively depriving all good faith bidders from tokens. Likelihood: Low – The chances of getting a `block.timestamp == auctionEndTime` are pretty slim, but it’s definitely possible.
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.