Development of an MEV-Protected Order Execution System

Every transaction in a public mempool is visible to all: bots instantly analyze it and place their orders ahead or behind, eroding your profit. According to Flashbots, over $1 billion has been extracted via MEV in recent years. Our system solves this at the architecture level: the order is hidden until included in a block. We specialize in developing secure solutions for DeFi protocols and traders, guaranteeing maximum protection against MEV attacks.

What problems we solve

Frontrunning. A bot sees your limit buy order, buys cheaper before you, and sells to you at a higher price. Losses — up to 5% of the trade amount on liquid pairs. Sandwich attack. The bot buys before you, you buy at an inflated price, the bot sells after. In low-liquidity pools, the loss can reach 20%. Attacks on arbitrage. Competitors copy your strategy and intercept profits. Our protection guarantees exclusive execution.

How does frontrunning protection work?

The system uses a commit-reveal protocol: the user sends a hash of the order (commit), which is stored in a smart contract. Then, in the same block, a reveal transaction with the actual parameters is sent. The contract verifies the match and executes the order. Between commit and reveal, one block passes — the bot cannot insert its transaction. The key element is a private mempool via Flashbots. Transactions are sent directly to validators and included in the block without public dissemination. We use a bundle mechanism: commit and reveal go as a single atomic package. Inclusion guarantee — 100% with a correct bundle.

Why is it important to use a private mempool?

A public mempool is an open order book. A private mempool (Flashbots, MEV-Share) hides the contents until inclusion in a block. Statistics: using private mempools reduces MEV losses by 90%. For networks without Flashbots (e.g., BNB Chain), we deploy our own relay infrastructure based on known validators. An alternative is encrypted mempools (Shutter Network, Swarm).

Comparison of protection methods

System architecture

Commit-reveal smart contract

// SPDX-License-Identifier: MIT pragma solidity 0.8.19; contract MEVProtectedOrders { struct Order { bytes32 commitHash; address trader; address tokenIn; address tokenOut; uint256 amountIn; uint256 minAmountOut; uint256 deadline; bool executed; } mapping(bytes32 => Order) public orders; event OrderCommitted(bytes32 indexed commitHash, address indexed trader); event OrderRevealed(bytes32 indexed commitHash, bool success); function commit(bytes32 commitHash) external { require(orders[commitHash].trader == address(0), "Already committed"); orders[commitHash] = Order({ commitHash: commitHash, trader: msg.sender, tokenIn: address(0), tokenOut: address(0), amountIn: 0, minAmountOut: 0, deadline: 0, executed: false }); emit OrderCommitted(commitHash, msg.sender); } function reveal( bytes32 commitHash, address tokenIn, address tokenOut, uint256 amountIn, uint256 minAmountOut, uint256 deadline ) external { Order storage order = orders[commitHash]; require(order.trader == msg.sender, "Not owner"); require(!order.executed, "Already executed"); require(block.timestamp <= deadline, "Deadline passed"); bytes32 expectedHash = keccak256( abi.encodePacked( msg.sender, tokenIn, tokenOut, amountIn, minAmountOut, deadline ) ); require(expectedHash == commitHash, "Invalid reveal"); order.tokenIn = tokenIn; order.tokenOut = tokenOut; order.amountIn = amountIn; order.minAmountOut = minAmountOut; order.deadline = deadline; // execution via DEX (e.g., Uniswap V3) _executeSwap(order); order.executed = true; emit OrderRevealed(commitHash, true); } function _executeSwap(Order memory order) internal { // swap logic with slippage protection } } 

Backend service for creating bundles

import { FlashbotsBundleProvider } from '@flashbots/ethers-provider-bundle'; import { ethers } from 'ethers'; class MEVBundleBuilder { private flashbotsProvider: FlashbotsBundleProvider; private contract: ethers.Contract; constructor(signer: ethers.Wallet, provider: ethers.Provider, contractAddress: string) { this.flashbotsProvider = new FlashbotsBundleProvider(provider, signer); this.contract = new ethers.Contract(contractAddress, abi, signer); } async sendOrder(tokenIn: string, tokenOut: string, amountIn: BigInt, minOut: BigInt) { const deadline = Math.floor(Date.now() / 1000) + 60; // 1 minute const commitHash = ethers.keccak256( ethers.AbiCoder.defaultAbiCoder().encode( ['address', 'address', 'address', 'uint256', 'uint256', 'uint256'], [this.signer.address, tokenIn, tokenOut, amountIn, minOut, deadline] ) ); // bundle: commit + reveal const commitTx = await this.contract.commit.populateTransaction(commitHash); const revealTx = await this.contract.reveal.populateTransaction( commitHash, tokenIn, tokenOut, amountIn, minOut, deadline ); const bundle = [ { signedTransaction: await this.signer.sendTransaction(commitTx) }, { signedTransaction: await this.signer.sendTransaction(revealTx) } ]; const result = await this.flashbotsProvider.sendBundle(bundle, targetBlockNumber); return result; } } 

Case study: protecting an arbitrage bot on Uniswap V3

One of our clients ran arbitrage between USDC/WETH pools on Uniswap and Sushiswap. Due to frontrunning, competing bots intercepted up to 60% of profitable opportunities. After integrating commit-reveal with Flashbots, the success rate of transactions increased from 40% to 95%. The average margin per trade increased by 30% due to the elimination of sandwich attacks. The system handles up to 500 orders per minute with a delay of less than 2 seconds.

What security guarantees do we provide?

With proper configuration of our system, we guarantee the absence of frontrunning and sandwich attacks. Each project undergoes smart contract auditing, load testing, and real-time monitoring. We provide an audit report and runbook for operations. For incidents — 24/7 support. Our experience — over 6 years in DeFi, dozens of successful integrations.

Process of work

What is included in development

• Source code of smart contracts under MIT license
• Integration with selected DEXs and networks
• Setup of Flashbots relay or custom relay
• Test documentation and audit report
• Team training and runbook for operations
• Execution monitoring and alerts (Telegram, PagerDuty)
• Support for 2 weeks after deployment

Typical mistakes when implementing MEV protection

• Using untrusted relay servers. Only Flashbots or your own validator.
• Too short deadline — the transaction might not enter the target block. Optimal: 1-2 minutes.
• Data leakage in the commit event. The hash must be irreversible.
• Ignoring cross-chain MEV. If the order executes on multiple networks, unified protection is needed.

We have over 6 years of experience in DeFi and have developed dozens of secure systems for traders and protocols. We guarantee no MEV losses if our recommendations are followed. Contact us to discuss your project — we'll share the details.