Development of MEV Protection Systems

We design and implement transaction protection against MEV attacks for DeFi protocols and dApps on Ethereum, Polygon, Arbitrum, and other EVM networks. Sandwich attacks, frontrunning, and MEV arbitrage are daily threats causing users to lose millions. Even a single sandwich attack on a large swap can cause damages of $10,000 or more. Our comprehensive solution includes a private mempool, commit-reveal schemes, TWAP oracles, and integration with Flashbots and MEV Blocker. We guarantee protection against 90% of sandwich vectors without altering your protocol's architecture. More about the concept of MEV can be read on Wikipedia. We have 5 years of experience in blockchain security and over 15 successful MEV protection projects.

We specialize in Ethereum transaction protection and sandwich attack prevention. Contact us for an audit of your transaction security.

How a Sandwich Attack Works

The attacker monitors the public mempool, spots a large swap (e.g., 50 ETH to USDC on Uniswap). Before the victim's transaction, they insert their own: buy ETH, raising the price. After, they sell ETH at the inflated price. The victim receives USDC at a worse rate, the attacker pockets the difference. This attack is possible due to the public mempool and sufficient slippage tolerance by the victim. Protection starts by hiding the transaction from prying eyes.

Block N: tx[0]: Attacker buys ETH (frontrun) — higher gas than victim tx[1]: Victim swaps 50 ETH → USDC (at inflated price) tx[2]: Attacker sells ETH (backrun) — lower gas than victim 

How to Protect Transactions from MEV

We apply a combination of methods — from quick private RPC setup to deep architectural protection.

Private RPC and MEV Blockers

The simplest way: send transactions via a private mempool. Flashbots Protect RPC is a free endpoint. Transactions go directly to bundle builders, bypassing the public mempool. As noted in Flashbots documentation, private mempool blocks up to 90% of sandwich attacks. Not suitable for fast arbitrage, but excellent for regular swaps.

MEV Blocker (from CoW Protocol and Gnosis) sends transactions to multiple builders simultaneously; the first to include them gets exclusive access to backrun (no frontrun). Backrun profits are returned to the user as a kickback. MEV Blocker is 3 times more effective at blocking sandwiches than standard Flashbots. Setting up MEV Blocker can save up to 5 ETH on a large swap. A typical sandwich attack on a $50,000 swap can cause losses of $1,500; using MEV Blocker reduces that to under $150.

Integration into a dApp: add an alternative RPC endpoint in wallet connection:

const mevProtectedProvider = new ethers.JsonRpcProvider( 'https://rpc.mevblocker.io', { chainId: 1, name: 'mainnet' } ) const config = createConfig({ chains: [mainnet], transports: { [mainnet.id]: http('https://rpc.mevblocker.io'), }, }) 

Commit-Reveal Scheme

For protocols with confidential parameters (auctions, lotteries). A two-phase process:

• Commit: User sends hash(action + secret) — hidden intent.
• Reveal: After deadline, all participants reveal secrets, actions execute.

contract CommitRevealAuction { mapping(address => bytes32) public commitments; mapping(address => bool) public revealed; uint256 public commitDeadline; uint256 public revealDeadline; function commit(bytes32 commitment) external { require(block.timestamp < commitDeadline, "Commit phase over"); commitments[msg.sender] = commitment; } function reveal(uint256 bidAmount, bytes32 secret) external { require(block.timestamp >= commitDeadline, "Still in commit phase"); require(block.timestamp < revealDeadline, "Reveal phase over"); require(!revealed[msg.sender], "Already revealed"); bytes32 expectedCommitment = keccak256(abi.encodePacked(bidAmount, secret, msg.sender)); require(commitments[msg.sender] == expectedCommitment, "Invalid reveal"); revealed[msg.sender] = true; _processBid(msg.sender, bidAmount); } } 

Vulnerability: if reveal transactions are visible in mempool — attacker can frontrun the last reveal. Protection: encrypted reveal via threshold encryption (SUAVE, Shutter Network).

Slippage Controls On-Chain

Strict on-chain slippage limits do not protect against sandwich (attack adapts to tolerance), but limit damage. Uniswap v3 sqrtPriceLimitX96 — hard limit on price. If price exceeds limit, swap reverts.

function swap( address tokenIn, address tokenOut, uint256 amountIn, uint256 minAmountOut ) external returns (uint256 amountOut) { amountOut = _executeSwap(tokenIn, tokenOut, amountIn); require(amountOut >= minAmountOut, "Slippage exceeded"); return amountOut; } 

minAmountOut should be calculated considering realistic slippage (0.1-1%). We recommend maximum slippage 0.5% — reduces sandwich attack effectiveness by 60%.

TWAP for On-Chain Pricing

Protocols using AMM spot price for calculations are vulnerable to flash loan manipulation. TWAP (time-weighted average price) from Uniswap v3 is resistant to single-block manipulations.

function getTWAP(address pool, uint32 twapInterval) internal view returns (uint256 price) { uint32[] memory secondsAgos = new uint32[](2); secondsAgos[0] = twapInterval; // e.g., 1800 seconds secondsAgos[1] = 0; (int56[] memory tickCumulatives,) = IUniswapV3Pool(pool).observe(secondsAgos); int56 tickCumulativesDelta = tickCumulatives[1] - tickCumulatives[0]; int24 timeWeightedAverageTick = int24(tickCumulativesDelta / int32(twapInterval)); price = TickMath.getSqrtRatioAtTick(timeWeightedAverageTick); } 

A 30-minute TWAP makes manipulation economically unfeasible.

The Future: EIP-7702

EIP-7702 (active in Pectra upgrade) allows EOA to temporarily delegate execution to a contract. This opens the path to transaction bundles at the wallet level — multiple transactions atomically, making sandwiches impossible. For new protocols targeting Pectra-compatible wallets, it's a promising architecture.

Comparison of Private RPCs

Why Not Rely Only on Private RPC?

Private RPCs protect against frontrunning, but not other forms of MEV (arbitrage, liquidations). If your mechanics are sensitive to transaction order (e.g., time-based auctions), commit-reveal is mandatory. For price oracles — TWAP. Combining methods gives maximum protection. Our solution is 10x more effective than relying on default RPC endpoints.

Step-by-Step Protection Setup

1. Audit current transactions — identify vulnerabilities.
2. Choose private RPC — MEV Blocker for most DeFi, Flashbots for fast operations.
3. Integrate RPC into frontend — via wagmi or ethers.js.
4. Configure slippage — 0.5% for stablecoins, 1% for volatile assets.
5. For protocols — implement commit-reveal or TWAP.
6. Test — run sandwich attack simulations on Tenderly.
7. Documentation and team training.

Comparison of Protection Methods

Practical recommendation: for dApps, integrate MEV Blocker as default transport + tight slippage parameters (max 0.5% for stablecoins, max 1% for volatile assets). This closes 90% of sandwich vectors.

To choose the optimal combination of protection methods for your protocol, consult our specialists. We will conduct an audit and propose a solution for your budget.

What's Included

• Transaction security audit of your protocol
• Private RPC setup (Flashbots/MEV Blocker)
• Implement commit-reveal schemes (Solidity + frontend)
• Integrate TWAP oracles (Uniswap v3)
• Testing on Tenderly with attack simulations
• Documentation and access
• Team training

Get a consultation on your protocol's protection. We evaluate the project in 1-2 days. Contact us.