Inconsistency in auctionEndTime handling
Summary
auctionEndTime is handled inconsistently.
Vulnerability Details
At block.timestamp == auctionEndTime, one can end the auction, bid and unbid. Bid and unbid can be performed even after the auction is ended.
Since the price of the sale is fixed on ending the auction, user's who like the price can first withdraw their tokens and lower the price and then invoke the end function followed by adding their bids and then buying the entire auction tokens. This will cause future user's to not receive any assets and hence effectively loose their points. An attacker can also first bid with large amounts so that others don't bid and then perform the above sequence to steal all the auction assets at a very low price
Impact
Attackers can effectively steal auction tokens and user's can loose their points
Tools Used
Recommendations
Make auction ending possible only if block.timestamp > auctionEndTime
Lead Judging Commences
Users can bid in the same block when the actionEnd could be called (`block.timestamp==actionEndTime`), depending on the order of txs in block they could lose funds
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.
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.