# Orders from other market makers can be invalidated

Opyn CrabNetting checkOrder() consumes order nonces, letting anyone front-run and invalidate market makers' presigned orders, griefing auctions into failure.

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

**Target:** CrabNetting.sol checkOrder()/withdrawAuction()/depositAuction()
**Root cause:** checkOrder() calls _useNonce() which marks the order nonce as used, so a read-only verification path mutates state and consumes the nonce.
**Steps:**
1. Observe checkOrder() at CrabNetting.sol#L447-L476 calls _useNonce() (L756-L759).
2. Monitor mempool for a market maker's order submitted to withdrawAuction()/depositAuction().
3. Front-run by calling `checkOrder(order)` with the same order/nonce.
4. Nonce is marked used; the victim's auction call reverts on nonce reuse.
**How found:** Code review of checkOrder() revealed it invokes _useNonce(), a state-mutating nonce consumer, in what should be a verification-only path shared with auction functions.
**Exploitation:** Attacker watches mempool for presigned orders headed to withdrawAuction()/depositAuction(), front-runs with checkOrder() on the same order to burn its nonce, causing the auction transaction to fail.
**Insight:** Look for verification/view-intended functions that call nonce-consuming or state-mutating helpers; any permissionless caller can then burn nonces to grief order-based flows.