# Bidder Funds Can Become Unrecoverable Due to 1 second Overlap in participateToAuction() and claimAuction()

A bidder can bid at the exact auction end timestamp after claimAuction() runs, leaving their ETH permanently trapped with no refund path.

- Payout: Contest reward
- Severity: medium
- Program: NextGen
- Credited: HChang26
- Disclosed: 2024-01-08
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-10-nextgen-findings/issues/175
- Library page: https://bugbountylibrary.com/r/c4%3A2023-10-nextgen%3AM-10
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** AuctionDemo.sol auction contract (participateToAuction/claimAuction)
**Root cause:** participateToAuction() uses block.timestamp <= auctionEndTime while claimAuction() uses block.timestamp >= auctionEndTime, so both are valid at the exact end timestamp; a bid placed after claimAuction() is never refunded.
**Steps:**
1. Auction ends at timestamp T; winner calls `claimAuction(tokenid)` at block.timestamp == T, setting auctionClaim=true and refunding all existing bids.
2. Another bidder calls `participateToAuction(tokenid)` in the same second T with `msg.value > highestBid`; require passes since block.timestamp <= endTime and auctionStatus true.
3. New bid is pushed to auctionInfoData but claimAuction already ran; auctionClaim is true so claimAuction cannot run again.
4. cancelBid()/cancelAllBids() revert after auction end, so the new bidder's ETH is stuck in AuctionDemo.sol with no rescue.
**How found:** Code reading of the boundary conditions: noticed participateToAuction uses <= endTime while claimAuction uses >= endTime, giving a shared valid timestamp; then checked that cancel functions revert post-auction, confirming no recovery path.
**Exploitation:** Bidder submits a bid in the exact end-timestamp block after the winner's claimAuction transaction; funds are locked irrecoverably. Requires block.timestamp exactly equal to auction end (12s multiples post-merge).
**Insight:** When two functions gate on the same timestamp with inclusive comparisons on opposite sides (<= vs >=), the boundary instant is valid for both — check ordering-dependent state flags (like auctionClaim) for funds that can be deposited after settlement with no refund path.