Insurance for MEV and Sandwich Attack Losses

Detailed Instructions

Begin by exporting your wallet's transaction history for a significant period (e.g., last 6-12 months) using a block explorer API or portfolio tracker. The goal is to identify transactions where MEV extraction occurred. Filter for failed transactions, unusually high gas fees, or transactions with a significant slippage tolerance that was fully consumed.

• Sub-step 1: Use a service like EigenPhi, Flashbots MEV-Explore, or a private RPC with eth_getBlockByNumber to detect if your past transactions were part of a sandwiched bundle.
• Sub-step 2: For each identified incident, calculate the value extracted by comparing your executed price to the pool's price before and after your transaction in the same block.
• Sub-step 3: Aggregate the total loss value and frequency. This establishes a baseline Annual Loss Expectancy (ALE).

javascriptCopy
// Example query to Flashbots MEV-Share for a specific tx hash
const response = await fetch('https://mev-share.flashbots.net/api/v1/bundle/0x...');
const data = await response.json();
// Check for 'sandwiched_tx' flag and profit details

Tip: Focus on high-value DeFi interactions like large liquidity provision deposits/withdrawals, token swaps on DEXs, and collateral management actions, as these are prime targets.

Detailed Instructions

Not all activities carry equal risk. Create a profile by categorizing your common transaction types. Frontrunning susceptibility is highest for transactions that are predictable and move markets. Assess the time-sensitivity and profitability signal your actions emit to searchers.

• Sub-step 1: List your common actions: e.g., weekly DCA swap, yield harvesting, lending collateral adjustments, or NFT mint participation.
• Sub-step 2: Assign a risk tier (Low/Medium/High) to each. High-risk actions include large, one-off swaps on low-liquidity pools or participating in competitive, gas-auctioned mints.
• Sub-step 3: Estimate the average transaction size (in USD) and frequency for each category. This defines your exposure profile.

Tip: Using private transaction services like Flashbots RPC or Taichi Network for high-risk actions can reduce frequency of attacks, which may lower your insurance premium.

Detailed Instructions

This step focuses on single-loss exposure, not frequency. Identify the largest transaction you would reasonably execute. For a swap, the maximum loss is often the full approved slippage tolerance. For complex interactions like leveraged position liquidation, it can be the entire position value.

• Sub-step 1: Review the maximum transaction parameters you set: e.g., a 5% slippage tolerance on a $100,000 swap implies a Potential Maximum Loss (PML) of $5,000.
• Sub-step 2: For liquidity provision, calculate the impermanent loss plus fees that could be extracted via a well-timed sandwich around your deposit/withdrawal.
• Sub-step 3: Consider cross-transaction attacks, where a series of your dependent transactions (e.g., approve then swap) are exploited. The PML could be the sum of all linked actions.

solidityCopy
// When approving a token for a DEX router, an unlimited approval creates higher PML.
// A better practice is to approve only the exact amount needed for the imminent transaction.
IERC20(token).approve(router, amount); // Specific amount
// vs
IERC20(token).approve(router, type(uint256).max); // Unlimited - Higher Risk

Tip: Your PML sets the upper bound for the coverage limit you should seek in an insurance policy.

Detailed Instructions

Document the MEV mitigation strategies you already employ. The goal is to identify the residual risk that remains and is suitable for insurance. Insurance should cover losses that slip through your technical defenses.

• Sub-step 1: List your active protections: e.g., using Flashbots Protect, 1inch Fusion, CowSwap with fee=0, or setting tight slippage (e.g., 0.3%).
• Sub-step 2: For each, note its failure modes. Private mempools can have reliability issues; DEX aggregators may not support all assets.
• Sub-step 3: Quantify the coverage gap. For instance, if you use a protected service for 80% of your volume, the remaining 20% of high-value transactions on unprotected venues represent your primary insurable exposure.

Tip: Insurance is most cost-effective for covering the tail-risk scenarios where your primary mitigations fail, not for replacing them.

Detailed Instructions

Translate your risk assessment into concrete policy parameters. The key variables are coverage limit, deductible, and premium. Use your calculated PML and ALE to inform these values.

• Sub-step 1: Set a coverage limit slightly above your PML for a single transaction category (e.g., $5,500 for swaps).
• Sub-step 2: Choose a deductible (per-claim). A higher deductible lowers premiums but should be below your average loss event size from Step 1.
• Sub-step 3: Determine your premium tolerance. As a benchmark, traditional insurance often costs 1-10% of the covered limit per year. For nascent on-chain insurance, expect higher rates.
• Sub-step 4: Specify covered activities. Be precise: e.g., "Uniswap V3 swaps on Ethereum mainnet exceeding $10k value, using standard router."

Tip: Start with a pilot coverage for your highest-risk, most quantifiable activity (e.g., large DEX swaps) before expanding to more complex DeFi interactions.

Detailed Instructions

Begin by analyzing your typical transaction behavior and wallet activity. Identify if you are a high-frequency trader, a long-term holder making occasional large swaps, or a protocol interacting with DeFi. Estimate the maximum probable loss (MPL) for a single transaction based on your average trade size and the typical slippage or MEV extraction observed on your target DEXs like Uniswap V3. Consider the coverage period—whether you need per-transaction protection or a policy for a batch of transactions over a set timeframe. This assessment dictates the premium you will pay and the policy structure you should seek.

• Sub-step 1: Review your last 50 transactions on a block explorer to identify patterns in DEX usage, token pairs, and amounts.
• Sub-step 2: Use MEV monitoring tools like EigenPhi or Flashbots Explorer to check the historical sandwich attack prevalence for your common trading pairs.
• Sub-step 3: Calculate a realistic worst-case loss scenario, e.g., a 2% price impact on a $10,000 swap equals a $200 potential loss per transaction.

javascriptCopy
// Example risk calculation logic
const avgTradeSize = 10000; // USD
const estimatedMaxSlippage = 0.02; // 2%
const potentialLossPerTx = avgTradeSize * estimatedMaxSlippage; // $200

Tip: For complex DeFi strategies involving multiple steps, model the MEV risk at each interaction point, as attacks can occur on any liquidity pool.

Detailed Instructions

Research and select a provider specializing in MEV protection, such as an on-chain insurance marketplace or a dedicated protocol like Sherlock or Nexus Mutual (for specific contract coverage). Scrutinize the policy wording for exclusions, the claims process, and the coverage trigger—typically a verifiable on-chain event proving a sandwich attack. You will need to configure key parameters: the insured amount (e.g., 1 ETH), the coverage duration (e.g., 24 hours for a trading session), and the premium, which is often a percentage of the sum insured paid to liquidity providers or stakers. Ensure the provider's smart contracts are audited and have a proven track record.

• Sub-step 1: Compare providers based on capital backing, claim dispute resolution (e.g., Kleros jury), and historical payouts.
• Sub-step 2: Connect your wallet (like MetaMask) to the provider's dApp and navigate to the policy creation interface.
• Sub-step 3: Input your desired coverage amount, duration, and review the dynamically calculated premium quote.

solidityCopy
// Simplified view of a policy struct in a smart contract
struct Policy {
    address policyholder;
    uint256 coverageAmount;
    uint256 premiumPaid;
    uint256 startBlock;
    uint256 endBlock;
    bool active;
}

Tip: For high-value coverage, consider splitting it across multiple providers to diversify counterparty risk.

Detailed Instructions

Once your policy is active and funded, you can execute transactions. The key is to generate and preserve immutable proof of your intended trade and its exploited outcome. Use a MEV-protected RPC like Flashbots Protect or a private transaction relay to submit your transactions, which can prevent frontrunning but not all sandwich attacks. For every covered swap, record the transaction hash, the block number, the exact input and output amounts you expected based on the quoted price, and the actual executed amounts. This data is crucial for proving the negative slippage caused by an attacker's surrounding transactions.

• Sub-step 1: Before sending a trade, note the quoted price from the DEX aggregator (e.g., 1 ETH = 3500 DAI) and your minimum acceptable output.
• Sub-step 2: Submit the transaction through your configured, protected endpoint.
• Sub-step 3: After confirmation, immediately save the transaction receipt and compare the actual execution price to your quoted price.

bashCopy
# Example command to fetch transaction details for proof
cast tx <TX_HASH> --rpc-url $MAINNET_RPC

Tip: Maintain a local log or use a dedicated service like OpenZeppelin Defender to automate the recording of transaction metadata for all covered activities.

Detailed Instructions

If you detect a loss exceeding your tolerance and covered by your policy, you must file a claim within the protocol's stipulated timeframe. Gather your pre-recorded proof: the policy ID, the victim transaction hash, and the attacker's sandwiching transactions identified via MEV explorers. You will need to demonstrate the causal link—showing that the attacker's transactions in the same block directly caused your worse execution. Submit this bundle to the insurance protocol's claims smart contract or interface. The claim will typically enter a challenge period where underwriters or a decentralized jury can audit the evidence.

• Sub-step 1: Use a block explorer like Etherscan to identify the transactions placed before and after yours in the same block, noting the attacker's address.
• Sub-step 2: Compile a report showing the price impact calculation: (Expected Output - Actual Output).
• Sub-step 3: Call the submitClaim(uint256 policyId, bytes calldata proof) function on the insurance contract.

solidityCopy
// Example interface for a claim submission function
interface IMEVInsurance {
    function submitClaim(
        uint256 _policyId,
        bytes calldata _transactionProof
    ) external returns (uint256 claimId);
}

Tip: Be prepared to participate in a dispute resolution forum to defend your claim if it is challenged by liquidity providers.

Detailed Instructions

Continuously monitor the state of your active policies and any filed claims. Use the provider's dApp or query their smart contracts directly to check the remaining coverage period and the claim status (e.g., Pending, Approved, Denied). If a claim is approved, the payout—usually in the form of stablecoins or the insured asset—will be sent to your address. For ongoing protection, establish a process for policy renewal. Before a policy expires, reassess your risk profile. You may need to adjust the coverage amount based on changing portfolio size or market volatility. Set reminders to renew coverage manually or, if supported, authorize automated renewals using smart contract allowances, ensuring you are never unprotected during critical operations.

• Sub-step 1: Weekly, check your active policy's endBlock against the current block number.
• Sub-step 2: For pending claims, monitor the governance or jury portal for updates and requests for additional information.
• Sub-step 3: To renew, navigate back to the policy creation, update parameters if needed, and approve a new premium payment.

javascriptCopy
// Querying a policy's status via a contract call
const policy = await insuranceContract.policies(policyId);
const isActive = policy.endBlock > await ethers.provider.getBlockNumber();

Tip: Consider using a wallet automation tool to trigger a policy renewal transaction when the endBlock is within 100 blocks, preventing any lapse in coverage.