MEV Protection Strategies for Solana Developers - Featured image

View image

Blockchain

MEV Protection Strategies for Solana Developers

BUILDERZ

January 12, 2026

5 min read

In this guide

The decisions and working steps ahead.

5 min read

What You'll Learn

TL;DR

Prerequisites

MEV Protection Strategies for Solana Developers

**Category:** Development/Security | **Audience:** Intermediate to Advanced

**Reading Time:** 18 minutes | **Author:** Builderz Team

**Verified Packages:** jito-ts@4.2.1, @solana/web3.js@1.98.4

What You'll Learn

Maximum Extractable Value (MEV) attacks on Solana have extracted between $370-500 million over the past 16 months, with sandwich attacks accounting for the majority. This guide teaches developers how to protect user transactions using Jito bundles, leader-aware routing, and smart contract defenses. By the end, you'll implement multiple MEV protection layers in your Solana applications.

Key Takeaways:

Understand how MEV attacks work on Solana's architecture
Implement Jito bundle protection with tips
Use leader-aware routing to avoid malicious validators
Build contract-level sandwich resistance
Identify and block high-risk validators

TL;DR

MEV on Solana has evolved from external bots to validator-coordinated attacks:

**Scale**: $370-500M extracted over 16 months, 529,000+ SOL from sandwiches alone
**Problem**: 93% of sandwich attacks are "wide" multi-slot attacks evading detection
**Solution 1**: Jito bundles with tips (~$0.04 minimum for protection)
**Solution 2**: Leader-aware routing avoiding malicious validators
**Solution 3**: Contract-level TWAP + commit-reveal patterns

Code exampletypescript

// Quick protection: Add Jito anti-frontrun marker
const JITO_MARKER = new PublicKey('jitodontfrontXXXXXXXXXXXXXXXXXXXXX...');
transaction.add(
  SystemProgram.transfer({
    fromPubkey: payer,
    toPubkey: JITO_MARKER,
    lamports: 0, // Zero-lamport transfer as marker
  })
);

Prerequisites

Before implementing MEV protection, ensure you understand:

**Solana transaction lifecycle** and blockhash handling
**Validator leader schedule** and slot mechanics
**DeFi basics**: slippage, liquidity, AMM mechanics
**TypeScript/Rust** for implementation

Code examplebash

# Install Jito SDK
npm install jito-ts @solana/web3.js

Understanding MEV on Solana

What Makes Solana Different

Unlike Ethereum's mempool-based MEV, Solana's continuous block production creates different attack vectors:

| Factor | Ethereum | Solana |
|--------|----------|--------|
| Mempool | Public, visible | No global mempool |
| Block Time | 12 seconds | 400ms slots |
| MEV Source | Mempool scanning | Leader slot control |
| Attack Window | Seconds | Milliseconds |

On Solana, the current leader (validator) has full control over transaction ordering within their slot. Over 95% of active stake runs the Jito validator client, which enables atomic bundles.

Types of MEV Attacks

1. Sandwich Attacks

The attacker detects your swap, front-runs with a buy order (raising price), lets your trade execute at worse price, then back-runs with a sell order.

Code exampletypescript

Timeline:
1. You submit: Swap 100 SOL -> USDC
2. Attacker front-runs: Buy large amount, price increases
3. Your trade executes: Get fewer USDC than expected
4. Attacker back-runs: Sell at higher price, profit from your slippage

According to 2025 research, wide (multi-slot) sandwiches now account for 93% of all sandwich attacks, extracting over 529,000 SOL in the past year.

2. Arbitrage

Not inherently harmful, but affects your trade execution price. Arbitrageurs balance prices across DEXs, often after your trade creates an imbalance.

3. Liquidations

In lending protocols, MEV searchers race to liquidate undercollateralized positions for profit.

**Builderz Insight**: Across our 32+ deployed projects, DeFi applications without MEV protection see 3-5% higher slippage costs for users. Protection is essential for competitive products.

Strategy 1: Jito Bundle Protection

Jito is the dominant MEV infrastructure on Solana, with bundles processed by 95%+ of stake.

How Jito Bundles Work

Bundles are atomic transaction groups that either all succeed or all fail. By including your transaction in a bundle with a tip, you get:

**Privacy**: Transaction not broadcast publicly until included
**Atomicity**: All-or-nothing execution
**Priority**: Tips ensure fast inclusion

Basic Jito Implementation

Code exampletypescript

import { Connection, Keypair, Transaction, PublicKey } from '@solana/web3.js';
import { searcherClient } from 'jito-ts/dist/sdk/block-engine/searcher';
import { Bundle } from 'jito-ts/dist/sdk/block-engine/types';

const JITO_BLOCK_ENGINE = 'mainnet.block-engine.jito.wtf';
const JITO_AUTH_KEYPAIR = Keypair.generate(); // Your auth keypair

async function sendProtectedTransaction(
  connection: Connection,
  transaction: Transaction,
  signer: Keypair,
  tipLamports: number = 50000 // ~$0.04 minimum recommended
): Promise<string> {
  // Connect to Jito block engine
  const client = searcherClient(JITO_BLOCK_ENGINE, JITO_AUTH_KEYPAIR);

  // Get Jito tip accounts (rotates for load balancing)
  const tipAccounts = await client.getTipAccounts();
  const tipAccount = new PublicKey(
    tipAccounts[Math.floor(Math.random() * tipAccounts.length)]
  );

  // Add tip instruction
  const tipInstruction = SystemProgram.transfer({
    fromPubkey: signer.publicKey,
    toPubkey: tipAccount,
    lamports: tipLamports,
  });

  transaction.add(tipInstruction);

  // Get fresh blockhash
  const { blockhash } = await connection.getLatestBlockhash();
  transaction.recentBlockhash = blockhash;
  transaction.feePayer = signer.publicKey;
  transaction.sign(signer);

  // Create and send bundle
  const bundle = new Bundle([transaction], 5); // 5 = max transactions

  const result = await client.sendBundle(bundle);
  console.log('Bundle sent:', result);

  return result;
}

Jito Anti-Frontrun Marker

Jito provides a special marker address that signals "do not front-run":

Code exampletypescript

// Add to any instruction in your transaction
const JITO_ANTI_FRONTRUN = new PublicKey(
  'jitodontfrontfMQAMxGjKNBCWFUmPqEqRY7XpG1UVK'
);

// Include in transaction as a key (not necessarily a transfer)
const markerInstruction = new TransactionInstruction({
  keys: [
    { pubkey: JITO_ANTI_FRONTRUN, isSigner: false, isWritable: false },
  ],
  programId: SystemProgram.programId,
  data: Buffer.from([]), // No-op
});

transaction.add(markerInstruction);

This marker tells Jito relays to enforce do-not-front-run rules for your transaction.

Strategy 2: Leader-Aware Routing

Not all validators are equal. Some have abnormally high sandwich rates, indicating they enable or participate in MEV extraction.

Identifying High-Risk Validators

Tools like sandwiched.me track validator sandwich rates. Validators with rates above 5-10% should be avoided.

Code exampletypescript

// Example high-risk validator detection
interface ValidatorRisk {
  identity: string;
  sandwichRate: number;
  totalSlots: number;
  isTrusted: boolean;
}

const HIGH_RISK_VALIDATORS = new Set([
  // Populate from sandwiched.me or similar sources
  'HighRiskValidator1PublicKey...',
  'HighRiskValidator2PublicKey...',
]);

function isValidatorTrusted(validatorPubkey: string): boolean {
  return !HIGH_RISK_VALIDATORS.has(validatorPubkey);
}

Leader Schedule Checking

Code exampletypescript

import { Connection } from '@solana/web3.js';

async function getUpcomingLeaders(
  connection: Connection,
  slotsAhead: number = 10
): Promise<string[]> {
  const currentSlot = await connection.getSlot();
  const leaderSchedule = await connection.getLeaderSchedule();

  if (!leaderSchedule) {
    throw new Error('Leader schedule not available');
  }

  const leaders: string[] = [];
  const startSlot = currentSlot % 432000; // Slots per epoch

  for (let i = 0; i < slotsAhead; i++) {
    const slotIndex = (startSlot + i) % 432000;

    for (const [validator, slots] of Object.entries(leaderSchedule)) {
      if (slots.includes(slotIndex)) {
        leaders.push(validator);
        break;
      }
    }
  }

  return leaders;
}

async function waitForTrustedLeader(
  connection: Connection,
  maxWaitSlots: number = 20
): Promise<void> {
  for (let i = 0; i < maxWaitSlots; i++) {
    const leaders = await getUpcomingLeaders(connection, 4);
    const nextLeader = leaders[0];

    if (isValidatorTrusted(nextLeader)) {
      console.log(`Trusted leader ${nextLeader} in next slot`);
      return;
    }

    console.log(`Waiting for trusted leader (current: ${nextLeader})`);
    await new Promise(resolve => setTimeout(resolve, 400)); // ~1 slot
  }

  console.warn('No trusted leader found within wait limit');
}

Multi-Path Routing

For critical transactions, use multiple routing paths:

Code exampletypescript

interface RoutingConfig {
  jito: boolean;
  paladin: boolean;
  directRpc: boolean;
}

async function sendWithMultiPath(
  transaction: Transaction,
  signer: Keypair,
  config: RoutingConfig = { jito: true, paladin: true, directRpc: false }
): Promise<string[]> {
  const results: Promise<string>[] = [];

  if (config.jito) {
    results.push(sendViaJito(transaction, signer));
  }

  if (config.paladin) {
    results.push(sendViaPaladin(transaction, signer));
  }

  if (config.directRpc) {
    // Only to trusted validators
    results.push(sendToTrustedValidator(transaction, signer));
  }

  // Return first successful result
  return Promise.all(results);
}

Strategy 3: Yellowstone Shield (Validator Allowlists)

Yellowstone Shield is an on-chain program for managing validator allowlists and blocklists.

How Shield Works

Define allowlist/blocklist of validator identities on-chain
Transactions reference the Shield policy
RPCs check current leader against policy
Transactions only sent when leader passes policy

Code exampletypescript

// Conceptual Shield integration
import { ShieldClient, PolicyType } from '@yellowstone/shield';

const shield = new ShieldClient(connection);

// Create allowlist policy
const policyAddress = await shield.createPolicy({
  type: PolicyType.Allowlist,
  validators: [
    'TrustedValidator1...',
    'TrustedValidator2...',
    'TrustedValidator3...',
  ],
});

// Send with policy enforcement
await shield.sendWithPolicy(transaction, signer, policyAddress);

Benefits

**On-chain enforcement**: Policies verifiable by anyone
**Community curation**: Share trusted validator lists
**Automatic routing**: RPC handles leader checking

Strategy 4: Contract-Level Defenses

For the strongest protection, implement defenses at the smart contract level.

Commit-Reveal Pattern

Split transactions into two phases to hide trade details:

Code examplerust

// Anchor program with commit-reveal
use anchor_lang::prelude::*;

#[program]
pub mod protected_swap {
    use super::*;

    pub fn commit(ctx: Context<Commit>, commitment_hash: [u8; 32]) -> Result<()> {
        let commitment = &mut ctx.accounts.commitment;
        commitment.hash = commitment_hash;
        commitment.owner = ctx.accounts.user.key();
        commitment.slot = Clock::get()?.slot;
        commitment.revealed = false;
        Ok(())
    }

    pub fn reveal_and_swap(
        ctx: Context<RevealAndSwap>,
        amount: u64,
        min_output: u64,
        nonce: [u8; 32],
    ) -> Result<()> {
        let commitment = &ctx.accounts.commitment;

        // Verify commitment
        let expected_hash = hash_commitment(amount, min_output, &nonce);
        require!(commitment.hash == expected_hash, ErrorCode::InvalidReveal);

        // Ensure minimum delay (e.g., 2 slots)
        let current_slot = Clock::get()?.slot;
        require!(
            current_slot >= commitment.slot + 2,
            ErrorCode::RevealTooEarly
        );

        // Execute swap with verified parameters
        execute_swap(ctx, amount, min_output)?;

        Ok(())
    }
}

fn hash_commitment(amount: u64, min_output: u64, nonce: &[u8; 32]) -> [u8; 32] {
    let mut data = Vec::new();
    data.extend_from_slice(&amount.to_le_bytes());
    data.extend_from_slice(&min_output.to_le_bytes());
    data.extend_from_slice(nonce);
    anchor_lang::solana_program::hash::hash(&data).to_bytes()
}

TWAP Oracle Checks

Use time-weighted average prices to detect manipulation:

Code examplerust

pub fn check_twap_deviation(
    current_price: u64,
    twap_price: u64,
    max_deviation_bps: u64,
) -> Result<()> {
    let deviation = if current_price > twap_price {
        (current_price - twap_price) * 10000 / twap_price
    } else {
        (twap_price - current_price) * 10000 / twap_price
    };

    require!(
        deviation <= max_deviation_bps,
        ErrorCode::PriceDeviationTooHigh
    );

    Ok(())
}

// In swap function
pub fn protected_swap(ctx: Context<Swap>, amount: u64) -> Result<()> {
    let current_price = get_current_price(&ctx.accounts.pool)?;
    let twap_price = get_twap_price(&ctx.accounts.oracle, 5)?; // 5-slot TWAP

    // Reject if price deviates more than 1% from TWAP
    check_twap_deviation(current_price, twap_price, 100)?;

    // Proceed with swap
    execute_swap(ctx, amount)
}

Strategy 5: Transaction Simulation

Always simulate before sending to detect manipulation:

Code exampletypescript

async function simulateWithMEVDetection(
  connection: Connection,
  transaction: Transaction,
  expectedOutput: number,
  maxSlippageBps: number = 50
): Promise<{ safe: boolean; actualOutput: number }> {
  const simulation = await connection.simulateTransaction(transaction);

  if (simulation.value.err) {
    throw new Error(`Simulation failed: ${JSON.stringify(simulation.value.err)}`);
  }

  // Parse expected output from logs (implementation depends on program)
  const actualOutput = parseOutputFromLogs(simulation.value.logs);

  const slippage = Math.abs(expectedOutput - actualOutput) / expectedOutput * 10000;

  return {
    safe: slippage <= maxSlippageBps,
    actualOutput,
  };
}

// Usage
const simulation = await simulateWithMEVDetection(
  connection,
  swapTransaction,
  expectedUsdcOutput,
  50 // 0.5% max slippage
);

if (!simulation.safe) {
  console.warn('Potential MEV detected, aborting transaction');
  return;
}

Complete Protection Stack

Combine all strategies for maximum protection:

Code exampletypescript

import { Connection, Keypair, Transaction } from '@solana/web3.js';

interface ProtectionConfig {
  useJito: boolean;
  jitoTipLamports: number;
  waitForTrustedLeader: boolean;
  maxLeaderWaitSlots: number;
  simulateFirst: boolean;
  maxSlippageBps: number;
}

const DEFAULT_CONFIG: ProtectionConfig = {
  useJito: true,
  jitoTipLamports: 50000, // ~$0.04
  waitForTrustedLeader: true,
  maxLeaderWaitSlots: 20,
  simulateFirst: true,
  maxSlippageBps: 50, // 0.5%
};

async function sendProtectedSwap(
  connection: Connection,
  transaction: Transaction,
  signer: Keypair,
  expectedOutput: number,
  config: ProtectionConfig = DEFAULT_CONFIG
): Promise<string> {
  // Step 1: Simulate
  if (config.simulateFirst) {
    const sim = await simulateWithMEVDetection(
      connection,
      transaction,
      expectedOutput,
      config.maxSlippageBps
    );

    if (!sim.safe) {
      throw new Error('MEV risk detected in simulation');
    }
  }

  // Step 2: Wait for trusted leader
  if (config.waitForTrustedLeader) {
    await waitForTrustedLeader(connection, config.maxLeaderWaitSlots);
  }

  // Step 3: Send via Jito with tip
  if (config.useJito) {
    return sendProtectedTransaction(
      connection,
      transaction,
      signer,
      config.jitoTipLamports
    );
  }

  // Fallback: Direct send (less protected)
  const signature = await connection.sendTransaction(transaction, [signer]);
  return signature;
}

Common Pitfalls

Insufficient Tips

Problem: Bundle not included because tip is too low.

Code exampletypescript

// WRONG - Tip too low during high demand
const tipLamports = 1000; // ~$0.001

// CORRECT - Dynamic tip based on network conditions
const tipLamports = await calculateOptimalTip(connection); // Usually 50k-500k

Stale Blockhash

Problem: Transaction expires before trusted leader slot.

Code exampletypescript

// Solution: Refresh blockhash if waiting for leader
if (waitedSlots > 50) {
  const { blockhash } = await connection.getLatestBlockhash();
  transaction.recentBlockhash = blockhash;
}

Trusting All Jito Validators

Problem: Some Jito validators still participate in sandwiching.

Code exampletypescript

// Solution: Maintain blocklist of known bad actors
const BLOCKED_VALIDATORS = await fetchBlockedValidators();

Ignoring Simulation Results

Problem: Sending transactions that will fail or have poor execution.

Code exampletypescript

// Always check simulation before sending
const simResult = await connection.simulateTransaction(transaction);
if (simResult.value.err) {
  throw new Error('Simulation failed - do not send');
}

Monitoring & Analytics

Track MEV protection effectiveness:

Code exampletypescript

interface MEVMetrics {
  transactionHash: string;
  expectedOutput: number;
  actualOutput: number;
  slippageBps: number;
  jitoTipPaid: number;
  leaderAtExecution: string;
  wasSandwiched: boolean;
}

async function logMEVMetrics(
  signature: string,
  expectedOutput: number,
  jitoTip: number
): Promise<MEVMetrics> {
  const tx = await connection.getTransaction(signature, {
    maxSupportedTransactionVersion: 0,
  });

  const actualOutput = parseActualOutput(tx);
  const slippageBps = ((expectedOutput - actualOutput) / expectedOutput) * 10000;

  // Check for sandwich indicators
  const wasSandwiched = await checkForSandwich(signature);

  const metrics: MEVMetrics = {
    transactionHash: signature,
    expectedOutput,
    actualOutput,
    slippageBps,
    jitoTipPaid: jitoTip,
    leaderAtExecution: tx?.slot ? await getLeaderForSlot(tx.slot) : 'unknown',
    wasSandwiched,
  };

  // Log to analytics
  await sendToAnalytics(metrics);

  return metrics;
}

Next Steps & Resources

Stay Updated

MEV tactics evolve constantly. Follow these resources:

[Jito Labs Documentation](https://docs.jito.wtf/)
[sandwiched.me](https://sandwiched.me) - Validator risk tracking
[bloXroute Solana API](https://bloxroute.com/solana/) - Multi-path routing

[Jupiter Token Swap Tutorial](/blog/jupiter-token-swap-tutorial) - Swap implementation basics
[Solana Development Services](/services) - MEV-protected DeFi development

Official Resources

[Jito GitHub](https://github.com/jito-labs)
[Solana MEV Documentation](https://solana.com/developers/guides/advanced/mev)
[Yellowstone Shield](https://github.com/rpcpool/yellowstone-grpc)

Summary

MEV protection on Solana requires a multi-layered approach:

**Jito Bundles**: Atomic execution with tips (~$0.04+)
**Leader Awareness**: Avoid high-risk validators
**Shield/Allowlists**: On-chain validator policies
**Contract Defenses**: Commit-reveal, TWAP checks
**Simulation**: Pre-flight MEV detection

With $370-500M extracted by MEV over 16 months, protection is no longer optional for production DeFi applications. Implement these strategies to protect your users and maintain competitive execution quality.

Built with expertise from Builderz - 32+ Solana projects with battle-tested MEV protection strategies.

Continue reading

Blockchain

View image

Blockchain

MEV Protection Strategies for Solana Developers

BUILDERZ

January 12, 2026

5 min read

In this guide

The decisions and working steps ahead.

5 min read

What You'll Learn

TL;DR

Prerequisites

MEV Protection Strategies for Solana Developers

**Category:** Development/Security | **Audience:** Intermediate to Advanced

**Reading Time:** 18 minutes | **Author:** Builderz Team

**Verified Packages:** jito-ts@4.2.1, @solana/web3.js@1.98.4

What You'll Learn

Key Takeaways:

Understand how MEV attacks work on Solana's architecture
Implement Jito bundle protection with tips
Use leader-aware routing to avoid malicious validators
Build contract-level sandwich resistance
Identify and block high-risk validators

TL;DR

MEV on Solana has evolved from external bots to validator-coordinated attacks:

**Scale**: $370-500M extracted over 16 months, 529,000+ SOL from sandwiches alone
**Problem**: 93% of sandwich attacks are "wide" multi-slot attacks evading detection
**Solution 1**: Jito bundles with tips (~$0.04 minimum for protection)
**Solution 2**: Leader-aware routing avoiding malicious validators
**Solution 3**: Contract-level TWAP + commit-reveal patterns

Code exampletypescript

// Quick protection: Add Jito anti-frontrun marker
const JITO_MARKER = new PublicKey('jitodontfrontXXXXXXXXXXXXXXXXXXXXX...');
transaction.add(
  SystemProgram.transfer({
    fromPubkey: payer,
    toPubkey: JITO_MARKER,
    lamports: 0, // Zero-lamport transfer as marker
  })
);

Prerequisites

Before implementing MEV protection, ensure you understand:

**Solana transaction lifecycle** and blockhash handling
**Validator leader schedule** and slot mechanics
**DeFi basics**: slippage, liquidity, AMM mechanics
**TypeScript/Rust** for implementation

Code examplebash

# Install Jito SDK
npm install jito-ts @solana/web3.js

Understanding MEV on Solana

What Makes Solana Different

Unlike Ethereum's mempool-based MEV, Solana's continuous block production creates different attack vectors:

On Solana, the current leader (validator) has full control over transaction ordering within their slot. Over 95% of active stake runs the Jito validator client, which enables atomic bundles.

Types of MEV Attacks

1. Sandwich Attacks

The attacker detects your swap, front-runs with a buy order (raising price), lets your trade execute at worse price, then back-runs with a sell order.

Code exampletypescript

Timeline:
1. You submit: Swap 100 SOL -> USDC
2. Attacker front-runs: Buy large amount, price increases
3. Your trade executes: Get fewer USDC than expected
4. Attacker back-runs: Sell at higher price, profit from your slippage

According to 2025 research, wide (multi-slot) sandwiches now account for 93% of all sandwich attacks, extracting over 529,000 SOL in the past year.

2. Arbitrage

Not inherently harmful, but affects your trade execution price. Arbitrageurs balance prices across DEXs, often after your trade creates an imbalance.

3. Liquidations

In lending protocols, MEV searchers race to liquidate undercollateralized positions for profit.

**Builderz Insight**: Across our 32+ deployed projects, DeFi applications without MEV protection see 3-5% higher slippage costs for users. Protection is essential for competitive products.

Strategy 1: Jito Bundle Protection

Jito is the dominant MEV infrastructure on Solana, with bundles processed by 95%+ of stake.

How Jito Bundles Work

Bundles are atomic transaction groups that either all succeed or all fail. By including your transaction in a bundle with a tip, you get:

**Privacy**: Transaction not broadcast publicly until included
**Atomicity**: All-or-nothing execution
**Priority**: Tips ensure fast inclusion

Basic Jito Implementation

Code exampletypescript

import { Connection, Keypair, Transaction, PublicKey } from '@solana/web3.js';
import { searcherClient } from 'jito-ts/dist/sdk/block-engine/searcher';
import { Bundle } from 'jito-ts/dist/sdk/block-engine/types';

const JITO_BLOCK_ENGINE = 'mainnet.block-engine.jito.wtf';
const JITO_AUTH_KEYPAIR = Keypair.generate(); // Your auth keypair

async function sendProtectedTransaction(
  connection: Connection,
  transaction: Transaction,
  signer: Keypair,
  tipLamports: number = 50000 // ~$0.04 minimum recommended
): Promise<string> {
  // Connect to Jito block engine
  const client = searcherClient(JITO_BLOCK_ENGINE, JITO_AUTH_KEYPAIR);

  // Get Jito tip accounts (rotates for load balancing)
  const tipAccounts = await client.getTipAccounts();
  const tipAccount = new PublicKey(
    tipAccounts[Math.floor(Math.random() * tipAccounts.length)]
  );

  // Add tip instruction
  const tipInstruction = SystemProgram.transfer({
    fromPubkey: signer.publicKey,
    toPubkey: tipAccount,
    lamports: tipLamports,
  });

  transaction.add(tipInstruction);

  // Get fresh blockhash
  const { blockhash } = await connection.getLatestBlockhash();
  transaction.recentBlockhash = blockhash;
  transaction.feePayer = signer.publicKey;
  transaction.sign(signer);

  // Create and send bundle
  const bundle = new Bundle([transaction], 5); // 5 = max transactions

  const result = await client.sendBundle(bundle);
  console.log('Bundle sent:', result);

  return result;
}

Jito Anti-Frontrun Marker

Jito provides a special marker address that signals "do not front-run":

Code exampletypescript

// Add to any instruction in your transaction
const JITO_ANTI_FRONTRUN = new PublicKey(
  'jitodontfrontfMQAMxGjKNBCWFUmPqEqRY7XpG1UVK'
);

// Include in transaction as a key (not necessarily a transfer)
const markerInstruction = new TransactionInstruction({
  keys: [
    { pubkey: JITO_ANTI_FRONTRUN, isSigner: false, isWritable: false },
  ],
  programId: SystemProgram.programId,
  data: Buffer.from([]), // No-op
});

transaction.add(markerInstruction);

This marker tells Jito relays to enforce do-not-front-run rules for your transaction.

Strategy 2: Leader-Aware Routing

Not all validators are equal. Some have abnormally high sandwich rates, indicating they enable or participate in MEV extraction.

Identifying High-Risk Validators

Tools like sandwiched.me track validator sandwich rates. Validators with rates above 5-10% should be avoided.

Code exampletypescript

// Example high-risk validator detection
interface ValidatorRisk {
  identity: string;
  sandwichRate: number;
  totalSlots: number;
  isTrusted: boolean;
}

const HIGH_RISK_VALIDATORS = new Set([
  // Populate from sandwiched.me or similar sources
  'HighRiskValidator1PublicKey...',
  'HighRiskValidator2PublicKey...',
]);

function isValidatorTrusted(validatorPubkey: string): boolean {
  return !HIGH_RISK_VALIDATORS.has(validatorPubkey);
}

Leader Schedule Checking

Code exampletypescript

import { Connection } from '@solana/web3.js';

async function getUpcomingLeaders(
  connection: Connection,
  slotsAhead: number = 10
): Promise<string[]> {
  const currentSlot = await connection.getSlot();
  const leaderSchedule = await connection.getLeaderSchedule();

  if (!leaderSchedule) {
    throw new Error('Leader schedule not available');
  }

  const leaders: string[] = [];
  const startSlot = currentSlot % 432000; // Slots per epoch

  for (let i = 0; i < slotsAhead; i++) {
    const slotIndex = (startSlot + i) % 432000;

    for (const [validator, slots] of Object.entries(leaderSchedule)) {
      if (slots.includes(slotIndex)) {
        leaders.push(validator);
        break;
      }
    }
  }

  return leaders;
}

async function waitForTrustedLeader(
  connection: Connection,
  maxWaitSlots: number = 20
): Promise<void> {
  for (let i = 0; i < maxWaitSlots; i++) {
    const leaders = await getUpcomingLeaders(connection, 4);
    const nextLeader = leaders[0];

    if (isValidatorTrusted(nextLeader)) {
      console.log(`Trusted leader ${nextLeader} in next slot`);
      return;
    }

    console.log(`Waiting for trusted leader (current: ${nextLeader})`);
    await new Promise(resolve => setTimeout(resolve, 400)); // ~1 slot
  }

  console.warn('No trusted leader found within wait limit');
}

Multi-Path Routing

For critical transactions, use multiple routing paths:

Code exampletypescript

interface RoutingConfig {
  jito: boolean;
  paladin: boolean;
  directRpc: boolean;
}

async function sendWithMultiPath(
  transaction: Transaction,
  signer: Keypair,
  config: RoutingConfig = { jito: true, paladin: true, directRpc: false }
): Promise<string[]> {
  const results: Promise<string>[] = [];

  if (config.jito) {
    results.push(sendViaJito(transaction, signer));
  }

  if (config.paladin) {
    results.push(sendViaPaladin(transaction, signer));
  }

  if (config.directRpc) {
    // Only to trusted validators
    results.push(sendToTrustedValidator(transaction, signer));
  }

  // Return first successful result
  return Promise.all(results);
}

Strategy 3: Yellowstone Shield (Validator Allowlists)

Yellowstone Shield is an on-chain program for managing validator allowlists and blocklists.

How Shield Works

Define allowlist/blocklist of validator identities on-chain
Transactions reference the Shield policy
RPCs check current leader against policy
Transactions only sent when leader passes policy

Code exampletypescript

// Conceptual Shield integration
import { ShieldClient, PolicyType } from '@yellowstone/shield';

const shield = new ShieldClient(connection);

// Create allowlist policy
const policyAddress = await shield.createPolicy({
  type: PolicyType.Allowlist,
  validators: [
    'TrustedValidator1...',
    'TrustedValidator2...',
    'TrustedValidator3...',
  ],
});

// Send with policy enforcement
await shield.sendWithPolicy(transaction, signer, policyAddress);

Benefits

**On-chain enforcement**: Policies verifiable by anyone
**Community curation**: Share trusted validator lists
**Automatic routing**: RPC handles leader checking

Strategy 4: Contract-Level Defenses

For the strongest protection, implement defenses at the smart contract level.

Commit-Reveal Pattern

Split transactions into two phases to hide trade details:

Code examplerust

// Anchor program with commit-reveal
use anchor_lang::prelude::*;

#[program]
pub mod protected_swap {
    use super::*;

    pub fn commit(ctx: Context<Commit>, commitment_hash: [u8; 32]) -> Result<()> {
        let commitment = &mut ctx.accounts.commitment;
        commitment.hash = commitment_hash;
        commitment.owner = ctx.accounts.user.key();
        commitment.slot = Clock::get()?.slot;
        commitment.revealed = false;
        Ok(())
    }

    pub fn reveal_and_swap(
        ctx: Context<RevealAndSwap>,
        amount: u64,
        min_output: u64,
        nonce: [u8; 32],
    ) -> Result<()> {
        let commitment = &ctx.accounts.commitment;

        // Verify commitment
        let expected_hash = hash_commitment(amount, min_output, &nonce);
        require!(commitment.hash == expected_hash, ErrorCode::InvalidReveal);

        // Ensure minimum delay (e.g., 2 slots)
        let current_slot = Clock::get()?.slot;
        require!(
            current_slot >= commitment.slot + 2,
            ErrorCode::RevealTooEarly
        );

        // Execute swap with verified parameters
        execute_swap(ctx, amount, min_output)?;

        Ok(())
    }
}

fn hash_commitment(amount: u64, min_output: u64, nonce: &[u8; 32]) -> [u8; 32] {
    let mut data = Vec::new();
    data.extend_from_slice(&amount.to_le_bytes());
    data.extend_from_slice(&min_output.to_le_bytes());
    data.extend_from_slice(nonce);
    anchor_lang::solana_program::hash::hash(&data).to_bytes()
}

TWAP Oracle Checks

Use time-weighted average prices to detect manipulation:

Code examplerust

pub fn check_twap_deviation(
    current_price: u64,
    twap_price: u64,
    max_deviation_bps: u64,
) -> Result<()> {
    let deviation = if current_price > twap_price {
        (current_price - twap_price) * 10000 / twap_price
    } else {
        (twap_price - current_price) * 10000 / twap_price
    };

    require!(
        deviation <= max_deviation_bps,
        ErrorCode::PriceDeviationTooHigh
    );

    Ok(())
}

// In swap function
pub fn protected_swap(ctx: Context<Swap>, amount: u64) -> Result<()> {
    let current_price = get_current_price(&ctx.accounts.pool)?;
    let twap_price = get_twap_price(&ctx.accounts.oracle, 5)?; // 5-slot TWAP

    // Reject if price deviates more than 1% from TWAP
    check_twap_deviation(current_price, twap_price, 100)?;

    // Proceed with swap
    execute_swap(ctx, amount)
}

Strategy 5: Transaction Simulation

Always simulate before sending to detect manipulation:

Code exampletypescript

async function simulateWithMEVDetection(
  connection: Connection,
  transaction: Transaction,
  expectedOutput: number,
  maxSlippageBps: number = 50
): Promise<{ safe: boolean; actualOutput: number }> {
  const simulation = await connection.simulateTransaction(transaction);

  if (simulation.value.err) {
    throw new Error(`Simulation failed: ${JSON.stringify(simulation.value.err)}`);
  }

  // Parse expected output from logs (implementation depends on program)
  const actualOutput = parseOutputFromLogs(simulation.value.logs);

  const slippage = Math.abs(expectedOutput - actualOutput) / expectedOutput * 10000;

  return {
    safe: slippage <= maxSlippageBps,
    actualOutput,
  };
}

// Usage
const simulation = await simulateWithMEVDetection(
  connection,
  swapTransaction,
  expectedUsdcOutput,
  50 // 0.5% max slippage
);

if (!simulation.safe) {
  console.warn('Potential MEV detected, aborting transaction');
  return;
}

Complete Protection Stack

Combine all strategies for maximum protection:

Code exampletypescript

import { Connection, Keypair, Transaction } from '@solana/web3.js';

interface ProtectionConfig {
  useJito: boolean;
  jitoTipLamports: number;
  waitForTrustedLeader: boolean;
  maxLeaderWaitSlots: number;
  simulateFirst: boolean;
  maxSlippageBps: number;
}

const DEFAULT_CONFIG: ProtectionConfig = {
  useJito: true,
  jitoTipLamports: 50000, // ~$0.04
  waitForTrustedLeader: true,
  maxLeaderWaitSlots: 20,
  simulateFirst: true,
  maxSlippageBps: 50, // 0.5%
};

async function sendProtectedSwap(
  connection: Connection,
  transaction: Transaction,
  signer: Keypair,
  expectedOutput: number,
  config: ProtectionConfig = DEFAULT_CONFIG
): Promise<string> {
  // Step 1: Simulate
  if (config.simulateFirst) {
    const sim = await simulateWithMEVDetection(
      connection,
      transaction,
      expectedOutput,
      config.maxSlippageBps
    );

    if (!sim.safe) {
      throw new Error('MEV risk detected in simulation');
    }
  }

  // Step 2: Wait for trusted leader
  if (config.waitForTrustedLeader) {
    await waitForTrustedLeader(connection, config.maxLeaderWaitSlots);
  }

  // Step 3: Send via Jito with tip
  if (config.useJito) {
    return sendProtectedTransaction(
      connection,
      transaction,
      signer,
      config.jitoTipLamports
    );
  }

  // Fallback: Direct send (less protected)
  const signature = await connection.sendTransaction(transaction, [signer]);
  return signature;
}

Common Pitfalls

Insufficient Tips

Problem: Bundle not included because tip is too low.

Code exampletypescript

// WRONG - Tip too low during high demand
const tipLamports = 1000; // ~$0.001

// CORRECT - Dynamic tip based on network conditions
const tipLamports = await calculateOptimalTip(connection); // Usually 50k-500k

Stale Blockhash

Problem: Transaction expires before trusted leader slot.

Code exampletypescript

// Solution: Refresh blockhash if waiting for leader
if (waitedSlots > 50) {
  const { blockhash } = await connection.getLatestBlockhash();
  transaction.recentBlockhash = blockhash;
}

Trusting All Jito Validators

Problem: Some Jito validators still participate in sandwiching.

Code exampletypescript

// Solution: Maintain blocklist of known bad actors
const BLOCKED_VALIDATORS = await fetchBlockedValidators();

Ignoring Simulation Results

Problem: Sending transactions that will fail or have poor execution.

Code exampletypescript

// Always check simulation before sending
const simResult = await connection.simulateTransaction(transaction);
if (simResult.value.err) {
  throw new Error('Simulation failed - do not send');
}

Monitoring & Analytics

Track MEV protection effectiveness:

Code exampletypescript

interface MEVMetrics {
  transactionHash: string;
  expectedOutput: number;
  actualOutput: number;
  slippageBps: number;
  jitoTipPaid: number;
  leaderAtExecution: string;
  wasSandwiched: boolean;
}

async function logMEVMetrics(
  signature: string,
  expectedOutput: number,
  jitoTip: number
): Promise<MEVMetrics> {
  const tx = await connection.getTransaction(signature, {
    maxSupportedTransactionVersion: 0,
  });

  const actualOutput = parseActualOutput(tx);
  const slippageBps = ((expectedOutput - actualOutput) / expectedOutput) * 10000;

  // Check for sandwich indicators
  const wasSandwiched = await checkForSandwich(signature);

  const metrics: MEVMetrics = {
    transactionHash: signature,
    expectedOutput,
    actualOutput,
    slippageBps,
    jitoTipPaid: jitoTip,
    leaderAtExecution: tx?.slot ? await getLeaderForSlot(tx.slot) : 'unknown',
    wasSandwiched,
  };

  // Log to analytics
  await sendToAnalytics(metrics);

  return metrics;
}

Next Steps & Resources

Stay Updated

MEV tactics evolve constantly. Follow these resources:

[Jito Labs Documentation](https://docs.jito.wtf/)
[sandwiched.me](https://sandwiched.me) - Validator risk tracking
[bloXroute Solana API](https://bloxroute.com/solana/) - Multi-path routing

[Jupiter Token Swap Tutorial](/blog/jupiter-token-swap-tutorial) - Swap implementation basics
[Solana Development Services](/services) - MEV-protected DeFi development

Official Resources

[Jito GitHub](https://github.com/jito-labs)
[Solana MEV Documentation](https://solana.com/developers/guides/advanced/mev)
[Yellowstone Shield](https://github.com/rpcpool/yellowstone-grpc)

Summary

MEV protection on Solana requires a multi-layered approach:

**Jito Bundles**: Atomic execution with tips (~$0.04+)
**Leader Awareness**: Avoid high-risk validators
**Shield/Allowlists**: On-chain validator policies
**Contract Defenses**: Commit-reveal, TWAP checks
**Simulation**: Pre-flight MEV detection

Built with expertise from Builderz - 32+ Solana projects with battle-tested MEV protection strategies.

Continue reading

Blockchain

Solana RPC Guide: Reads, Subscriptions, and Production Setup

BUILDERZJul 21, 2026

Blockchain

SPL Token Guide: Mints, Accounts, ATAs, and Authorities

BUILDERZJul 21, 2026

Blockchain

Solana Transaction Guide: Instructions, Fees, and Confirmation

BUILDERZJul 21, 2026

MEV Protection Strategies for Solana Developers

In this guide

MEV Protection Strategies for Solana Developers

What You'll Learn

TL;DR

Prerequisites

Understanding MEV on Solana

What Makes Solana Different

Types of MEV Attacks

1. Sandwich Attacks

2. Arbitrage

3. Liquidations

Strategy 1: Jito Bundle Protection

How Jito Bundles Work

Basic Jito Implementation

Jito Anti-Frontrun Marker

Strategy 2: Leader-Aware Routing

Identifying High-Risk Validators

Leader Schedule Checking

Multi-Path Routing

Strategy 3: Yellowstone Shield (Validator Allowlists)

How Shield Works

Benefits

Strategy 4: Contract-Level Defenses

Commit-Reveal Pattern

TWAP Oracle Checks

Strategy 5: Transaction Simulation

Complete Protection Stack

Common Pitfalls

Insufficient Tips

Stale Blockhash

Trusting All Jito Validators

Ignoring Simulation Results

Monitoring & Analytics

Next Steps & Resources

Stay Updated

Related Builderz Content

Official Resources

Summary

Continue reading

Solana RPC Guide: Reads, Subscriptions, and Production Setup

SPL Token Guide: Mints, Accounts, ATAs, and Authorities

Solana Transaction Guide: Instructions, Fees, and Confirmation

Have a blocked Solana or AI system?

MEV Protection Strategies for Solana Developers

In this guide

MEV Protection Strategies for Solana Developers

What You'll Learn

TL;DR

Prerequisites

Understanding MEV on Solana

What Makes Solana Different

Types of MEV Attacks

1. Sandwich Attacks

2. Arbitrage

3. Liquidations

Strategy 1: Jito Bundle Protection

How Jito Bundles Work

Basic Jito Implementation

Jito Anti-Frontrun Marker

Strategy 2: Leader-Aware Routing

Identifying High-Risk Validators

Leader Schedule Checking

Multi-Path Routing

Strategy 3: Yellowstone Shield (Validator Allowlists)

How Shield Works

Benefits

Strategy 4: Contract-Level Defenses

Commit-Reveal Pattern

TWAP Oracle Checks

Strategy 5: Transaction Simulation

Complete Protection Stack

Common Pitfalls

Insufficient Tips

Stale Blockhash

Trusting All Jito Validators

Ignoring Simulation Results

Monitoring & Analytics

Next Steps & Resources

Stay Updated