Advanced

Anti-MEV Protection

Every transaction sent through BoltTx is protected from MEV attacks by default. No configuration needed.

Built-in for All Plans

Anti-MEV protection is included in every BoltTx plan — from Starter to Whale. There are no additional fees, no opt-in flags, and no extra configuration required. When you send a transaction through BoltTx, it is automatically shielded from frontrunning, sandwich attacks, and other forms of MEV extraction.

Enabled by Default

The anti_mev option defaults to true on all send endpoints. You can explicitly set it to false if you want to opt out, but we strongly recommend keeping it enabled.

How It Works

BoltTx uses a private transaction delivery channel that keeps your transaction payload out of public mempools and searcher feeds until it lands on-chain.

Private Delivery

Transactions travel through BoltTx's private delivery pipeline over encrypted channels. They are never rebroadcast to public subscription feeds where searchers look for opportunities.

Zero Inspection

We don't analyze your transaction contents to look for MEV opportunities. Your payload is treated as an opaque blob — no copy-trading, no front-running.

Optimized Routing

Our routing engine continuously selects the fastest available delivery path, minimizing the time between submission and on-chain inclusion.

Tip-Based Fair Ordering

Transactions are ordered purely by the tip you set — higher tip means higher priority. No hidden fees, no preferential treatment, no reordering. The signed bytes you send are the bytes that land on-chain.

Types of MEV Attacks Prevented

Attack Type	Description	Protection
Frontrunning	Bots detect your trade and execute the same trade before you	Protected
Sandwich Attack	Bots place orders before and after your trade to profit from price impact	Protected

Best Practices

•Anti-MEV is always on — every transaction BoltTx delivers, from a simple SOL transfer to a multi-hop swap, is protected by our private delivery pipeline. There is nothing to toggle.
•Still use reasonable slippage tolerance — Anti-MEV protection prevents frontrunning and sandwich attacks, but it is not a substitute for proper slippage settings against normal market volatility.

Optional Enhancement: Jito Sandwich Mitigation

BoltTx's private delivery already prevents the common frontrunning and sandwich paths. For defense-in-depth against attacks that route through Jito bundles, you can additionally mark your transaction with Jito's native "don't front-run" flag — a zero-cost, zero-latency hint that Jito's block engine enforces at the bundle level.

How it works

Add any valid Solana public key that starts with jitodontfront to any instruction in your transaction. The account does not need to exist on-chain, but it must still be a structurally valid pubkey (base58-decodable, 32 bytes) — you cannot use arbitrary bytes.

Jito's block engine will reject any bundle containing this transaction unless the transaction sits at position 0. Frontrunners physically cannot insert a transaction in front of yours.

JavaScript example

import { PublicKey } from "@solana/web3.js";

// Any valid Solana pubkey starting with "jitodontfront" works.
// The key does NOT need to exist on-chain.
const dontFrontKey = new PublicKey(
  "jitodontfront111111111111111111111111111111"
);

// Canonical pattern: attach the key as a read-only, non-signer
// account meta on an instruction you already have (e.g. your swap).
// No extra instruction is needed — this saves bytes and CUs.
yourSwapIx.keys.push({
  pubkey: dontFrontKey,
  isSigner: false,
  isWritable: false,
});

// ...then build, sign, and submit the transaction as usual.

Important scope: the jitodontfront rule is enforced exclusively by Jito's block engine. A transaction only gains this protection when it reaches Jito — either through Jito's sendTransaction endpoint (mainnet.block-engine.jito.wtf/api/v1/transactions) or inside a bundle via sendBundle. A transaction delivered only through BoltTx bypasses Jito's pipeline entirely and receives no jitodontfront enforcement. If you want both BoltTx's landing speed and Jito's sandwich mitigation, the recommended pattern is to fan the same signed transaction out to both paths in parallel (see the Durable Nonce page for how to do this safely). The feature is mainnet/testnet only — it has no effect on devnet or localhost — and Jito notes it is a mitigation, not a guarantee against every variation of sandwich ordering.

Official best practices

•Mark the dontfront account as read-only (isWritable: false). Writable works, but read-only optimizes landing speed.
•Use a unique prefix variant per application (e.g. jitodontfront11111111111111111111111xxxxyyyy). Jito accepts any valid pubkey starting with jitodontfront, and a unique variant lets you distinguish your app's usage in on-chain data.
•The dontfront account may be sourced through an Address Lookup Table. Tip accounts, however, must NOT go through an ALT.