# Used orders or revoked token authorizations can cause `withdrawAuction` and `depositAuction` to fail

A market maker can front-run Opyn's auction by marking their order nonce used or revoking token approval, reverting the whole withdrawAuction/depositAuction batch.

- Payout: Contest reward
- Severity: medium
- Program: Opyn
- Credited: indijanc
- Disclosed: 2022-11-22
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-11-opyn-judging/issues/60
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-11-opyn%3AM-4
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:race-window technique:source-review vuln:business-logic vuln:dos

**Target:** CrabNetting.sol auction settlement (withdrawAuction/depositAuction)
**Root cause:** Auction loops process every order and revert on any single failure; _useNonce() reverts if a nonce is already used and token transfers revert if approval/balance was revoked, so one bad order aborts the entire auction.
**Steps:**
1. Owner submits `withdrawAuction()`/`depositAuction()` containing market maker orders.
2. Market maker front-runs by calling `setNonceTrue()` (or `checkOrder()`) to mark their order nonce used.
3. Alternatively revoke ERC20 approval to CrabNetting or move required tokens out of the trading account.
4. Auction loop hits `_useNonce()` revert or failed `transferFrom`, reverting the whole transaction.
5. Repeat each auction to grief settlement indefinitely.
**How found:** Code review of auction loops and _useNonce(): noticed a single order failure reverts the whole batch, then identified user-controllable preconditions (nonce, approval, balance) that can be changed before submission.
**Exploitation:** Attacker with a pending order watches the mempool for the owner's auction tx, front-runs with setNonceTrue() or an approval revocation so the order's nonce check or token transfer reverts, causing the entire auction to fail; repeated to block auctions.
**Insight:** In batch settlement loops, any per-item check that reverts (nonce reuse, allowance, balance) is a griefing vector since one bad item kills the batch; look for state a counterparty can mutate between signing and execution.
