Normally, a buyer can purchase listed assets by calling the OrderBook::buyOrder function. However, MEV bots can scan the buyOrder transaction from the mempool and front-run it, resulting in:
The original buyer’s transaction reverting.
The bot successfully buying the asset.
The buyer missing out despite having the required funds.
Reason 1: buyOrder can be front-run easily if sent through public RPC or non-private mempool.
Reason 2: No commit-reveal or protection from external frontrunning built into OrderBook.
Impact 1: Buyer is unable to buy the asset even with correct conditions.
Impact 2: Critical functionality of the OrderBook is broken — users cannot reliably fulfill orders.
Impact 3: Trust in the decentralized marketplace degrades due to frontrunning exploits.
The MevBotAttack contract simulates a bot that front-runs legitimate buyers by quickly calling buyOrder on an active order.
Add this test to your TestOrderBook.t.sol file:
✅ test_MevAttackOnBuyer - Front-running Buyer
Use private RPC providers like Flashbots RPC to protect user intent from public mempool visibility.
Consider adding:
Commit-reveal schemes for critical actions like buyOrder().
Access control or reservation windows (e.g., "soft-lock" orders for 1 block).
Slippage protection, where user sets a max token amount or block deadline.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.