Unpacking MEV on Solana: Challenges, Threats, and Developer Defenses

Solana doesn't operate like Ethereum, and that reshapes the entire game of MEV. In this blog, we break down how front-running and back-running work on Solana, the technical constraints that make it harder to pull off, and what strategies (both legitimate and malicious) are evolving. If you're building on Solana, this is your crash course on MEV risks, defenses, and the invisible games validators and searchers might be playing.

Why Front-Running Is Harder on Solana

Front-running on Solana is significantly less accessible than on Ethereum. Here's why:

• No public mempool: Pending transactions are not visible
• Timestamp constraints: Wallets include a recentBlockhash field in each transaction, which limits its validity to roughly the last 150 blocks. This effectively acts as a Time-To-Live (TTL), meaning the transaction will automatically expire if not included quickly.
• Continuous block building: Transactions are streamed into blocks. Even high-priority fee txs arriving later can be included after lower-fee ones.
• Parallel transaction threads: Validators process transactions in parallel, meaning priority fees don't guarantee ordering.

Jito once offered pending transaction visibility for MEV searchers, but discontinued it after community pushback. Some private pools still exist, but access is limited.

How MEV Still Happens in Solana

MEV-Capable Actors

1. Trading Bots (e.g., BonkBot, Unibot on Telegram)

These bots allow users to trade volatile or newly listed assets directly through messaging apps. Since the bot controls transaction construction and signing, it can sandwich or front-run user trades for its own gain.

2. RPC Providers

RPC operators see user transactions before they hit the blockchain. This gives them an informational edge, allowing them to front-run transactions. If an RPC provider is also a validator, they're even better positioned to capitalize on MEV opportunities.

3. Validators

Validators with a large enough stake could become block leaders. With full view of all incoming transactions during their slot, a validator could theoretically reorder or censor transactions to capture MEV.

MEV Techniques

1. Optimistic Transactions

A spam-based technique where searchers send many transactions that only succeed if certain profitable conditions are met. Even if 90%+ of transactions fail, the few that succeed can justify the cost.

2. Searcher Colocation with Validators

By locating in the same datacenter as validators, searchers reduce latency and boost their chances of landing profitable transactions faster than the competition.

3. Validator Colocation with Centralized Exchanges (CEXs)

Validators positioned near CEX infrastructure can monitor off-chain prices and land trades that exploit arbitrage gaps.

Jito's Role in Leveling the Field

Jito, now halted, helped counter MEV centralization by making the mempool more accessible to all searchers. This reduced spam and made optimistic strategies less necessary. Instead of relying on randomness, searchers could build valid, profitable bundles, distributing MEV more fairly.

Developer Defenses: Protecting Solana Programs from MEV

Sandwich Attacks (front/back-running)

The two widely deployed solutions to protect swaps against sandwich attacks are slippage protection and validity timestamp.

• Slippage protection reverts if the resulting amount from the swap diverges too much from the expected value
• Validity timestamp prevents validators from withholding the transaction for too long

pub fn swap_tokens_protected(
    ctx: Context<SwapTokens>,
    amount_in: u64,
    min_amount_out: u64,  // Slippage protection
    max_timestamp: i64    // Timestamp protection
) -> Result<()> {
    let current_time = Clock::get()?.unix_timestamp;
    require!(
        current_time <= max_timestamp,
        ErrorCode::TransactionExpired
    );

    let pool = &mut ctx.accounts.pool;
    let amount_out = perform_swap(pool, amount_in)?;
    require!(
        amount_out >= min_amount_out,
        ErrorCode::SlippageExceeded
    );
    Ok(())
}

Initialization Front-Running

If an attacker can deploy your Configuration account before you and sets an address they control as the admin, they effectively hijack your protocol.

A simple safeguard is to require that the signer's pubkey during initialization matches the program's upgrade_authority, automatically set at runtime to the deployer's pubkey:

#[derive(Accounts)]
pub struct SetInitialAdmin<'info> {
    #[account(init, payer = authority, seeds = [b"admin"], bump)]
    pub admin_settings: Account<'info, AdminSettings>,
    #[account(mut)]
    pub authority: Signer<'info>,
    #[account(constraint = program.programdata_address()? == Some(program_data.key()))]
    pub program: Program<'info, MyProgram>,
    #[account(constraint = program_data.upgrade_authority_address == Some(authority.key()))]
    pub program_data: Account<'info, ProgramData>,
    pub system_program: Program<'info, System>,
}

Oracle Manipulation

MEV bots can manipulate on-chain oracles (like AMM-based TWAPs) in the same block as an exploit. Defenses include:

• Using time-weighted average prices (TWAPs) over multiple blocks
• Setting maximum price deviation limits
• Using off-chain oracles like Pyth or Switchboard for critical price feeds

General Best Practices

• Implement commit-reveal schemes for operations where the exact inputs should be hidden until execution
• Use deadline/expiry parameters on all user-facing transactions
• Monitor for sandwich patterns in your protocol's transaction history
• Avoid relying on block timestamps as the sole source of randomness or timing

MEV on Solana is real, but it's also controllable. Most of the effective defenses come down to good protocol design rather than complex cryptographic solutions. Build with these patterns from day one.