mev-analysis

name	mev-analysis
description	MEV exposure assessment, sandwich attack detection, and protection strategies for Solana DEX trading

MEV Analysis for Solana DEX Trading

Maximal Extractable Value (MEV) is the profit that validators and searchers can extract by reordering, inserting, or censoring transactions within a block. On Solana DEXes, MEV primarily manifests as sandwich attacks against swaps, cross-DEX arbitrage, and liquidation extraction. This skill covers detection, estimation, and protection strategies.

What Is MEV on Solana?

MEV occurs when someone with transaction ordering power profits at other traders' expense. On Solana, the MEV supply chain works as follows:

1. You submit a swap through an RPC endpoint
2. Searchers observe your transaction (via RPC forwarding, block engine access, or leader TPU sniffing)
3. Searcher constructs a profitable bundle (e.g., sandwich your swap)
4. Bundle submitted to Jito block engine with a tip to the validator
5. Validator includes the bundle in the block, earning the tip
6. You receive worse execution; the searcher profits the difference

How Solana MEV Differs from Ethereum

Aspect	Ethereum	Solana
Block time	12 seconds	~400ms slots
Mempool	Public mempool	No mempool (but tx visible in transit)
Ordering	Proposer-builder separation (PBS)	Jito block engine (~85%+ validators)
Bundle system	Flashbots bundles	Jito bundles with tips
MEV cost	Gas priority fees	Jito tips (SOL)
Latency pressure	Moderate	Extreme (sub-100ms decisions)

Key Solana-specific factors:

• No public mempool: Transactions flow RPC → TPU → Leader, but searchers tap into this flow via Jito's block engine and modified validators
• Known leader schedule: The leader (block producer) schedule is known ~2 epochs ahead, letting searchers target specific leaders
• Jito dominance: ~85%+ of validators run the Jito-modified client, making Jito bundles the primary MEV vector
• Speed: 400ms slots mean MEV bots must operate in microseconds, favoring co-located infrastructure

MEV Types on Solana

1. Sandwich Attacks

The most common MEV attack against retail traders.

Mechanics:

1. Attacker sees your pending swap: Buy 10 SOL worth of TOKEN_X
2. Front-run:  Attacker buys TOKEN_X first  → price rises
3. Your swap:  You buy TOKEN_X at higher price → worse execution
4. Back-run:   Attacker sells TOKEN_X         → profits the difference

Your loss = price impact from front-run + attacker's profit margin Attacker profit = your_loss - jito_tip - transaction_fees

Risk factors:

• Trade size: Larger trades = more profitable to sandwich
• Token liquidity: Illiquid tokens = easier price manipulation
• Slippage setting: Wide slippage = more room for the attacker
• Pool type: CPMM pools more vulnerable than CLMM pools at concentrated ranges

2. Arbitrage (Cross-DEX)

Searchers capture price discrepancies between DEXes.

Pool A: TOKEN_X = 1.00 USDC
Pool B: TOKEN_X = 1.02 USDC
→ Buy on A, sell on B, profit 0.02 USDC per token (minus fees)

This is generally beneficial to the market — it equalizes prices across venues. However, your trade may trigger the arbitrage opportunity that the searcher captures.

3. Liquidation Extraction

When DeFi positions (Solend, Marginfi, Kamino) become undercollateralized, searchers race to liquidate them and claim the liquidation bonus (typically 5-10%).

4. JIT (Just-In-Time) Liquidity

Searchers add concentrated liquidity to a CLMM pool just before a large swap and remove it immediately after, earning swap fees without sustained impermanent loss exposure. This is a sophisticated MEV form that can actually improve execution for the swapper.

5. Back-Running

Trading immediately after a large swap that moved the price, capturing the reversion. Less harmful than sandwiching because it does not worsen your execution — it profits from the market response to your trade.

Estimating MEV Exposure

Estimate your MEV risk before executing a trade:

import httpx

def estimate_mev_risk(
    trade_size_sol: float,
    pool_liquidity_usd: float,
    slippage_bps: int,
    token_daily_volume_usd: float,
) -> dict:
    """Estimate sandwich attack profitability for a given trade.

    Returns risk assessment with estimated cost and recommendations.
    """
    # Trade as percentage of pool liquidity
    sol_price = 150.0  # approximate; fetch live price in production
    trade_usd = trade_size_sol * sol_price
    trade_pct_of_pool = (trade_usd / pool_liquidity_usd) * 100

    # Estimated price impact from constant-product AMM
    # price_impact ≈ trade_size / pool_liquidity (simplified)
    price_impact_bps = int(trade_pct_of_pool * 100)

    # Sandwich profitability: attacker captures portion of slippage headroom
    # Rough model: sandwich_profit ≈ 0.5 * slippage_headroom * trade_size
    slippage_headroom_bps = slippage_bps - price_impact_bps
    if slippage_headroom_bps < 0:
        slippage_headroom_bps = 0

    sandwich_profit_usd = (slippage_headroom_bps / 10000) * trade_usd * 0.5
    jito_tip_cost = 0.001 * sol_price  # ~0.001 SOL typical tip
    tx_fees = 0.000015 * sol_price * 2  # two transactions for sandwich

    net_mev_profit = sandwich_profit_usd - jito_tip_cost - tx_fees
    is_profitable_to_sandwich = net_mev_profit > 0.10  # $0.10 minimum

    # Volume ratio indicates MEV bot attention level
    volume_ratio = trade_usd / max(token_daily_volume_usd, 1)

    risk_level = "LOW"
     is_profitable_to_sandwich  trade_pct_of_pool > :
        risk_level = 
     is_profitable_to_sandwich  trade_pct_of_pool > :
        risk_level = 

     {
        : risk_level,
        : (trade_pct_of_pool, ),
        : price_impact_bps,
        : slippage_headroom_bps,
        : ((net_mev_profit, ), ),
        : is_profitable_to_sandwich,
        : _get_recommendations(
            risk_level, trade_size_sol, slippage_bps, trade_pct_of_pool
        ),
    }


 () -> []:
    
    recs = []
     risk_level == :
        recs.append()
        recs.append()
     trade_pct_of_pool > :
        n_splits = (, (trade_pct_of_pool))
        recs.append()
     slippage_bps > :
        recs.append()
     risk_level  (, ):
        recs.append()
      recs:
        recs.append()
     recs

MEV Protection Strategies

Strategy 1: Tight Slippage Settings

Set slippageBps as low as feasible. Sandwich profit is bounded by your slippage tolerance.

Token Liquidity	Recommended Slippage
> $5M pool	50 bps (0.5%)
$1M - $5M pool	100 bps (1%)
$100K - $1M pool	150-200 bps
< $100K pool	200-500 bps (high risk)

Trade-off: Too-tight slippage causes failed transactions, costing you fees with no execution.

Strategy 2: Jito Bundles

Submit your swap as a Jito bundle with a priority tip:

import httpx

JITO_BLOCK_ENGINE = "https://mainnet.block-engine.jito.wtf"

async def submit_jito_bundle(
    signed_transactions: list[str],
    tip_lamports: int = 1_000_000,  # 0.001 SOL
) -> str:
    """Submit a transaction bundle to Jito block engine.

    Args:
        signed_transactions: Base64-encoded signed transactions.
        tip_lamports: Tip amount in lamports (1 SOL = 1e9 lamports).

    Returns:
        Bundle ID for tracking.
    """
    async with httpx.AsyncClient() as client:
        resp = await client.post(
            f"{JITO_BLOCK_ENGINE}/api/v1/bundles",
            json={
                "jsonrpc": "2.0",
                "id": 1,
                "method": "sendBundle",
                "params": [signed_transactions],
            },
            timeout=10.0,
        )
        resp.raise_for_status()
        result = resp.json()
        return result.get("result", "")

Tip guidelines:

• Normal priority: 0.0001 - 0.001 SOL
• High priority: 0.001 - 0.01 SOL
• Urgent (volatile market): 0.01 - 0.05 SOL

Strategy 3: Private/Protected RPCs

Send transactions through endpoints that do not expose them to searchers:

• Jito bundles (described above)
• Helius priority fee API with staked connections
• QuickNode private transaction submission
• Direct TPU forwarding (requires infrastructure)

Strategy 4: Trade Splitting

For large trades (> 1% of pool liquidity), split execution:

def compute_split_plan(
    total_sol: float,
    pool_liquidity_usd: float,
    sol_price: float = 150.0,
    max_pct_per_trade: float = 0.5,
) -> list[dict]:
    """Compute a trade splitting plan to minimize MEV exposure."""
    total_usd = total_sol * sol_price
    trade_pct = (total_usd / pool_liquidity_usd) * 100

    if trade_pct <= max_pct_per_trade:
        return [{"sol_amount": total_sol, "delay_seconds": 0}]

    n_splits = max(2, int(trade_pct / max_pct_per_trade) + 1)
    per_trade = total_sol / n_splits
    delay = 30  # seconds between trades

    return [
        {"sol_amount": round(per_trade, 4), "delay_seconds": i * delay}
        for i in range(n_splits)
    ]

Strategy 5: Jupiter MEV Protection

Jupiter v6 includes built-in MEV protection features:

• Dynamic slippage: Automatically adjusts slippage to minimize sandwich window
• Priority fee estimation: Sets appropriate compute unit price
• Transaction landing optimization: Retry logic with increasing priority

Enable via Jupiter API:

params = {
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": token_mint,
    "amount": str(amount_lamports),
    "slippageBps": "50",
    "dynamicSlippage": "true",        # Auto-adjust slippage
    "prioritizationFeeLamports": "auto",  # Auto priority fee
}

Detecting Sandwich Attacks

After a trade, check whether you were sandwiched:

1. Fetch your transaction and identify the slot
2. Fetch all transactions in that slot involving the same token
3. Look for the pattern:
   • Transaction A: Buy TOKEN_X (before your tx in slot ordering)
   • Your transaction: Buy TOKEN_X (worse price than expected)
   • Transaction B: Sell TOKEN_X (after your tx, same signer as A)
4. Verify: Signer of A and B is the same wallet (the attacker)
5. Estimate cost: Difference between your expected and actual execution price

See scripts/sandwich_detector.py for a working implementation.

Known MEV indicators:

• Transaction signer has thousands of transactions per day
• Same-slot buy-then-sell of the same token around your swap
• Signer interacts with Jito tip program frequently
• Wallet has no token holdings (just in-and-out)

Integration with Other Skills

• slippage-modeling: Use slippage estimates to set protective limits
• liquidity-analysis: Pool liquidity determines MEV vulnerability
• jupiter-api: Jupiter's MEV protection features and swap execution
• solana-onchain: On-chain transaction analysis for sandwich detection
• helius-api: Transaction parsing and historical analysis

Files

References

• references/solana_mev_mechanics.md — Solana block production, Jito block engine, MEV supply chain, and transaction flow paths
• references/protection_strategies.md — Detailed protection strategies with implementation guidance, cost-benefit analysis, and decision matrix

Scripts

• scripts/sandwich_detector.py — Detects sandwich attacks around a given transaction signature using on-chain data
• scripts/mev_risk_estimator.py — Estimates MEV exposure for a planned trade based on token liquidity, trade size, and slippage settings