Root + Impact

Description

• Normal behavior: In a fair auction, on‑chain bids are accepted in the order they are mined. Honest bidders expect that once they submit a valid bid, that bid will be the current highest bid unless someone later outbids them by paying a legitimately higher amount. Auctions should not be trivially manipulable by watchers who observe pending transactions and submit competing transactions to change ordering for profit.

• Issue: The market exposes classic on‑chain auction state (bid amounts, buy‑now purchases) in the public mempool and accepts the first valid on‑chain transaction that arrives. Because placeBid immediately updates the highest bid and there is a short extension window for last‑minute bids, bots or miners can front‑run legitimate bidders or repeatedly place last‑second bids (sniping) to gain advantage or keep an auction alive. The code’s rolling 15‑minute extension and immediate acceptance of on‑chain bids create a favorable environment for these attacks.

Risk

Likelihood:

• Bots and MEV searchers continuously monitor mempools on public blockchains; they will observe pending placeBid / buy‑now transactions and submit higher‑priority transactions to take priority (this happens for every visible bid submission).

• Auctions with active last‑minute bidding patterns will repeatedly trigger the rolling extension logic, creating many opportunities for sniping and extension abuse.

Impact:

• Buy‑Now front‑run: A legitimate buyer attempting to buyNow can have their purchase preempted by a frontrunner who places an identical or slightly higher transaction with higher gas; the frontrunner gets the NFT.

• Bid sniping & griefing: Attackers place last‑second bids (or many small last‑second bids) to win auctions cheaply or keep auctions from finishing (increased gas costs and potential indefinite extension).

• Market fairness degradation: Honest bidders pay more gas, lose auctions unexpectedly, and lose trust in the marketplace; sellers may get worse outcomes or prolonged auctions.

Proof of Concept

1. Buy‑Now frontrun: A user submits a transaction placeBid{value = buyNowPrice} to purchase immediately. A watcher sees this pending transaction in the mempool and quickly resubmits an equivalent transaction (or one with slightly higher msg.value if >= is allowed) with a higher gas price. The miner includes the frontrunner’s transaction first; the frontrunner becomes the buyer. The original buyer’s transaction either reverts (NFT no longer available) or loses.

2. Classic outbid front‑run: A user submits a bid X that would become the highest. A bot observes the pending tx and issues a higher bid X' (just enough to be valid) with higher gas so miners include it first. The bot wins, and the honest bidder’s transaction is included later but is no longer highest (or even rejected depending on timing).

3. Bid sniping / rolling‑extension abuse: When auctions extend by a short window (15 minutes) if bids arrive near the deadline, an attacker can repeatedly submit last‑second bids to reset the clock or snipe with high‑priority transactions, ensuring they capture the auction at the last moment or force repeated bidding rounds. Over many auctions this creates a profitable and disruptive bot strategy.

Recommended Mitigation

Commit–reveal / Sealed bids

• Move to a two‑phase model (commit phase where hashed bids are submitted, then a reveal phase). This removes bid amounts from the mempool during the commit phase and prevents observers from reacting to pending bid values.

Off‑chain signed bids + on‑chain settlement (orderbook/relayer)

Accept bids signed off‑chain (EIP‑712) and only settle at execution. Relayers submit them atomically; mempool keeps only the settlement call, not the bid value.

Fixed auction window after first bid (no unbounded rolling)

• Keep your design choice to start only after the first bid, but use a fixed duration (e.g., 3 days) rather than unbounded rolling extensions. Alternatively, cap the number of extensions or the total extended time.

Increase extension granularity or restrict last‑minute actions

• If you want some protection against sniping, implement a single small extension (e.g., + N minutes) but cap the number of extensions (e.g., max 3 extensions). This prevents indefinite extension abuse.