Lack of Proper Handling for Timestamp Matching Auction End in `FjordAuction`
Summary
The FjordAuction contract, which governs token auctions using FjordPoints, currently does not handle the specific case where block.timestamp == auctionEndTime. This results in users being unable to perform any actions—neither ending the auction nor placing or withdrawing bids—at the precise moment the auction ends. This behavior leaves the auction in a frozen state at this critical time, resulting in a lack of clarity about what should happen when the auction duration ends exactly.
Vulnerability Details
In the current implementation of the FjordAuction contract, the functions auctionEnd, bid, and unbid perform checks based on block.timestamp compared to auctionEndTime. The logic only checks if the current block’s timestamp is strictly less than or greater than auctionEndTime. However, it does not explicitly handle the equal (=) case, leading to a situation where the auction’s state is unclear.
As a result, no actions can be taken at the exact auctionEndTime, and the auction remains in a frozen state until the next block is mined. This gap in functionality disrupts the auction’s flow.
Impact
When block.timestamp == auctionEndTime, the auction is left in a frozen state where users cannot end the auction, place new bids, or withdraw existing bids. This creates a gap in functionality and can frustrate participants who expect the auction to proceed smoothly.
Tools Used
Manual Code Review
Recommendations
To resolve this issue, handle the block.timestamp == auctionEndTime condition explicitly within the auctionEnd function. By allowing actions to proceed normally until the auction ends, and handling the exact moment of auctionEndTime within the auctionEnd function, you ensure a smooth transition and proper closure of the auction.
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.
Appeal created
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.