Jito explained: bundles, tips, and how MEV works on Solana

This guide covers how MEV works structurally on Solana, what Jito provides at each layer, and how to plug into that infrastructure with real tooling.

TL;DR

By mid-2026, the Jito-Solana client runs on more than 95% of active stake, and Jito tips account for over 60% of all priority-fee volume on the network. Most developers building on Solana encounter MEV before they understand it. Jito is the dominant MEV infrastructure layer on Solana.

For builders, Jito exposes four operational surfaces:

• Jito-Solana: modified validator client running on ~95%+ of staked SOL
• Block Engine: off-chain auction system for MEV-maximizing transaction bundles
• Bundles: groups of 1–5 transactions executed atomically with tip-based ordering
• ShredStream: direct shred delivery from Jito-connected validators for sub-slot latency

The typical MEV flow: searcher detects opportunity → assembles bundle → submits to block engine with tip → block engine runs auction → winning bundle lands atomically in validator block.

Prerequisites

Before working through this guide, it is recommended to go through:

• Types of nodes on Solana
• Basic DeFi primitives

MEV on Solana

MEV (Maximal Extractable Value) is the value captured by influencing the order, insertion, or exclusion of transactions within a block. On Solana, this surfaces as arbitrage across AMMs (like Raydium or Orca), liquidations on lending protocols (like Project 0 (ex-Marginfi) or Kamino), and back-runs after large swaps.

Solana’s architecture makes MEV structurally different from Ethereum:

	Solana	Ethereum
Block time	~400ms	~12s
Mempool	Shared gossip network	Public mempool
Ordering control	Leader-based	Builder/proposer separation
MEV layer	Jito Block Engine	MEV-Boost relays
Atomic execution	Bundles (max 5 txns)	Bundles (flashbots-style)

On Solana, a leader validator controls block ordering for their assigned slot. Jito extends this by running an off-chain auction layer, the block engine, that determines the highest-value bundle ordering before passing it to the validator. The validator earns tips, the searcher gets guaranteed execution order.

What is Jito?

Jito Labs builds and maintains high-performance MEV infrastructure for Solana. The system operates across four components:

1. Jito-Solana: a modified fork of the Agave validator client
2. Block Engine: the off-chain auction and bundle routing service
3. Bundle API: the JSON-RPC and gRPC interface for searchers
4. ShredStream: low-latency shred delivery for downstream consumers

Each component is independently useful. Together, they form the production MEV stack for Solana.

Jito Architecture

• Validators run Jito-Solana, a modified Agave client. This client connects to the Jito Block Engine and accepts profitable bundle submissions in addition to normal transactions.
• Searchers, dApps, and Telegram bots connect to the block engine and submit transactions and bundles over gRPC or JSON-RPC.
• The block engine simulates submitted bundles, runs parallel auctions at 50ms ticks, and determines the highest-value combination to pass to the validator.
• The validator executes the winning bundles atomically and collects the tips.
• Tip revenue flows back to validators and their stakers, including JitoSOL liquid staking holders.

Block Engine endpoint: https://mainnet.block-engine.jito.wtf

To route to a specific region, specify the desired region:

Region	Endpoint
New York	https://ny.mainnet.block-engine.jito.wtf
Amsterdam	https://amsterdam.mainnet.block-engine.jito.wtf
Frankfurt	https://frankfurt.mainnet.block-engine.jito.wtf
Tokyo	https://tokyo.mainnet.block-engine.jito.wtf
Salt Lake City	https://slc.mainnet.block-engine.jito.wtf

For the full list of regions: https://docs.jito.wtf/lowlatencytxnsend/#api

⚠️ Pick the endpoint geographically closest to your submission infrastructure. Latency between your searcher and the block engine directly affects auction competitiveness.

Searcher Scan visualizing 345 active searchers, 1,000 recent bundles, 1.4K SOL in tips, and the distribution of whale and retail bundle activity across the network.

Bundles

Standard transactions submitted via gossip are visible to other network participants before they land. A searcher running an arbitrage between Raydium and Orca needs to ensure that their two-leg trade executes in order, without any transaction slipping between the legs. Bundles guarantee this.

• Max 5 transactions per bundle
• Executed sequentially in the specified order
• Atomically, all succeed or all fail
• Compete against other bundles via tip auctions at the block engine
• Minimum tip: 1,000 lamports per bundle

If any transaction in the bundle fails or is invalidated, the entire bundle reverts — no partial execution.

The block engine runs parallel auctions at 50ms ticks. Bundles with intersecting account lock patterns (write-write or read-write on the same account) compete in the same auction. Bundles that touch completely separate accounts run in independent auctions, parallelism is exploited where possible. Within a single auction, bundles are ordered by tip-per-compute-unit efficiency.

Bundle usage has become a core part of Solana’s execution layer, with billions of bundles flowing through the block engine over the past year.

Submitting a bundle:

Endpoint: POST https://mainnet.block-engine.jito.wtf/api/v1/bundles

curl https://mainnet.block-engine.jito.wtf:443/api/v1/bundles -X POST -H "Content-Type: application/json" -d '
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "sendBundle",
  "params": [
    [
      "AT2AqtlokikUWgGNnSX5xrmdvBjSaiIPxvFz6zc5Abn5Z0CPFW5GO+Y3rXceLnqLgQFnGw0yTk3NtJdFNsbrwwQBAAIEsXPDJ9cMVbpFQYClVM7PGLh8JOfCD6E2vz5VNmBCF+p4Uhyxec67hYm1VqLV7JTSSYaC/fm7KvWtZOSRzEFT2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABUpTWpkpIQZNJOhxYNo4fHw1td28kruB5B+oQEEFRI1i3Wzl2VfewCI8oYXParnP78725sKFzYheTEn8v865YQIDABhqaXRvIGJ1bmRsZSAwOiBqaXRvIHRlc3QCAgABDAIAAACghgEAAAAAAA=="
    ],
    {
      "encoding": "base64"
    }
  ]
}'

Jito implements a sandwich detection mechanism at the block engine level. When a bundle matches the pattern of a known sandwich (a buy transaction before a victim transaction and a sell transaction after it), the block engine rejects it. This is enforced at the infrastructure level — the block engine will discard bundles that match sandwich patterns, protecting users submitting through Jito-enabled paths.

Check out this example bundle using the protection.

Tips

Tips are the economic signal inside the Jito system. A tip is a SOL transfer from the searcher’s wallet to one of eight Jito tip accounts. The validator receives this tip in exchange for including your bundle at its specified position in the block.

Retrieve current tip accounts:

curl https://mainnet.block-engine.jito.wtf/api/v1/getTipAccounts -X POST -H "Content-Type: application/json" -d '
{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getTipAccounts",
    "params": []
}
'

This returns a list of eight accounts. Include a SOL transfer to any one of them as the final transaction in your bundle.

Tip sizing:

• Minimum tip: 1,000 lamports
• During high competition (active token launches, major liquidation events): tip floors rise substantially
• Query current tip market via REST: https://bundles.jito.wtf/api/v1/bundles/tip_floor
• WebSocket tip stream: wss://bundles.jito.wtf/api/v1/bundles/tip_stream

The tips volume showing over 1.1 million SOL paid through Jito auctions, with clear spikes during periods of elevated MEV activity in the last year.

Tip vs. priority fee:

These two mechanisms are distinct and both apply to bundles:

	Priority Fee	Jito Tip
What it pays	Solana base fee layer	Jito Block Engine auction
Recipient	Validators (base protocol)	Jito validator + stakers
Required for	Base transaction inclusion	Bundle ordering priority
Minimum	Dynamic (compute units × fee rate)	1,000 lamports

A bundle requires both a valid priority fee on its transactions and a tip to a Jito tip account. Omitting the priority fee risks base-layer rejection; under-tipping on the Jito side means lower auction priority.

Validators running the Jito client receive tips in exchange for including the bundle at the right position in the block. Because Jito also operates a liquid staking pool on top of this validator network, a portion of those tips flows back to ordinary stakers who have deposited SOL through the protocol. The TipRouter NCN (Node Consensus Network) decentralizes this distribution further, routing 6% of MEV tips to JitoSOL stakers and JTO governance token holders.

ShredStream

ShredStream is Jito’s low-latency block data delivery service. To understand what it does, let’s understand how Solana actually moves block data across the network.

When a Solana leader validator produces a block, it splits the block data into small packets called shreds. These shreds propagate through the Turbine protocol, a tree-based broadcast network, to reach other validators and RPC nodes. A node receiving shreds via standard Turbine sits multiple hops away from the producing validator. Each hop adds time.

ShredStream short-circuits this entirely. It streams shreds directly from Jito-connected validators to ShredStream subscribers without waiting for the Turbine fanout to reach them. The practical effect is hundreds of milliseconds of saved latency on incoming block data.

For competitive MEV, this is the margin between detecting an opportunity within the current slot and detecting it in the next one.

Use cases:

• HFT bots that need to react to chain state inside a slot
• MEV searchers monitoring on-chain state for triggers
• RPC operators serving latency-sensitive applications (DEX aggregators, trading frontends)
• Any infrastructure needing the freshest possible chain state

Setup:

ShredStream runs via a proxy that subscribes to Jito-connected validators. The proxy handles the direct shred delivery and exposes the data locally.

Run via Docker with host networking recommended for lowest latency:

docker run -d \
  --network host \
  jitolabs/shredstream-proxy:latest \
  --block-engine-url https://mainnet.block-engine.jito.wtf \
  --auth-keypair /path/to/keypair.json \
  --desired-regions amsterdam,ny \
  --dest-ip-ports 0.0.0.0:8001

View logs with docker logs -f jito-shredstream-proxy

The full setup guide, including native binary and firewall configuration, is available at docs.jito.wtf/lowlatencytxnfeed.

If you prefer not to run your own proxy, ShredStream is already included: Chainstack’s Solana Global Nodes include Jito ShredStream by default. In 2026, ShredStream has become standard for any infrastructure provider serving latency-sensitive customers, often wired in by default through the Yellowstone Geyser plugin.

Chainstack pairs ShredStream with the Yellowstone gRPC Geyser plugin for structured real-time Solana data streaming: account updates, transaction confirmations, and slot notifications over gRPC, with ShredStream providing the sub-slot delivery path.

For RPC access, Chainstack’s Global Nodes for Solana are geo-balanced across regions and include ShredStream integration, making them suitable as the RPC layer for MEV-adjacent infrastructure without operating your own validator.

BAM

BAM is the latest infrastructure milestone from the Jito ecosystem. Built on top of the existing Jito stack, BAM introduces TEE (Trusted Execution Environment)-based transaction sequencing using AMD SEV-SNP, separating transaction ordering from block validation entirely.

Over 50% of Solana validators now run BAM. pic.twitter.com/GuB03fbONB

— Jito (@jito_sol) June 5, 2026

BAM implements transaction sequencing through Trusted Execution Environments, enabling programmable block construction via custom plugins. The system operates through BAM Nodes that privately sequence transactions using hardware-based secure enclaves, and BAM Validators that execute the ordered transactions. The ordering is cryptographically attested at every step.

The plugin framework opens an entirely new design space for application builders. Apps gain direct control over their transaction sequencing. Oracles can update instantly when needed. Orders can be cancelled without spamming the network. Developers can define application-specific ordering logic as BAM plugins, supporting use cases like priority cancellations for options protocols, synchronized oracle updates, and time-sensitive execution primitives.

BAM also introduces a new value layer across the Jito network. All Jito fees, both BAM and block engine, route to the DAO Treasury. Plugin adoption directly benefits the Jito DAO. Validators, developers, and stakers each have a defined earning path within the system.

This section is a light introduction to BAM and what it brings to the Jito ecosystem. For a deeper dive into the architecture, plugin development, and validator onboarding, visit bam.dev.

Jito builder tools

Developers building on Solana do not always need bundles. Whether to use them depends on the application.

Bundles are useful when:

• Multiple transactions require atomic execution
• Liquidations must execute in order
• Arbitrage depends on deterministic settlement
• Trading strategies compete during congestion

Standard transactions are often sufficient for:

• Wallet transfers
• NFT applications
• Consumer applications
• General-purpose protocol interactions

Understanding this distinction helps teams choose the right execution path. When bundles are the right choice, the tools below provide everything needed to integrate them into any stack.

Jito SDKs

• jito-py-json-rpc: Python SDK for interacting with the Jito Block Engine. Send transactions, submit bundles, and query tip accounts directly from Python applications.
• jito-js-json-rpc: JavaScript and TypeScript SDK for Node.js and browser environments, covering bundle submission, status polling, and tip account management.
• jito-rust-json-rpc: Rust SDK for high-performance MEV workflows. Designed for latency-sensitive searcher infrastructure built in Rust.
• jito-go-json-rpc: Go SDK for the Jito Block Engine API, covering the same bundle and transaction endpoints as the other language clients.

Jito Resources

• docs.jito.wtf: Official Jito documentation covering bundles, tips, ShredStream setup, and rate limits.
• explorer.jito.wtf: Live MEV explorer with bundle history, tip distributions, and slot-level analytics.
• Tip floor REST API: Current tip floor data for calibrating bundle bids.
• Block Engine global endpoint: Primary bundle submission endpoint.
• ShredStream setup: Proxy setup guide for sub-slot block data delivery.

RPC and Geyser

• Solana Global Nodes with ShredStream: Geo-balanced Solana RPC with Jito ShredStream included by default.
• Yellowstone gRPC Geyser plugin: Real-time account, transaction, and slot streaming over gRPC for latency-sensitive data pipelines.
• Solana MEV protection: Documentation covering MEV protection strategies on Solana.
• Solana trading infrastructure 2026: Overview of the full Solana trading stack for production systems.
• Improve Solana RPC latency with ShredStream: Guide on reducing RPC latency using ShredStream integration.
• Start for free: Get a Solana RPC node with ShredStream included.

Ecosystem

• Jito Explorer: Bundle and tip analytics across the Jito network.
• BAM: TEE-based programmable block sequencing built on the Jito stack.
• Raydium: AMM and primary arbitrage surface on Solana.
• Orca: Whirlpool-based AMM, high tip-auction volume.
• Project 0: Lending protocol, active liquidation competition via Jito bundles.
• Kamino Finance: Yield and lending, liquidation-relevant for MEV searchers.
• Drift Protocol: Perpetuals DEX and BAM validator partner.

Conclusion

With over 95% of Solana’s staked SOL flowing through Jito-client validators, the block engine and its bundle auction are the production path for any strategy requiring execution guarantees. The architecture is layered and each piece has a distinct function. For builders in 2026, the practical checklist is:

• Use Jito bundles for any multi-transaction strategy requiring atomic execution
• Set priority fees on transactions and tips on your bundles, both are required
• Integrate ShredStream or use an RPC provider with ShredStream baked in (e.g. Chainstack’s Global Nodes) to minimize reaction latency

The infrastructure is mature, the tooling is well-documented, and the adoption numbers confirm that operating outside this stack means competing at a structural disadvantage on every high-value transaction.

Reliable Solana RPC node infrastructure

Getting started with Solana on Chainstack is fast and straightforward. Developers can deploy a reliable Solana node within seconds through an intuitive Console — no complex setup or hardware management required. 

Chainstack provides low-latency Solana RPC access and real-time gRPC data streaming via Yellowstone Geyser Plugin, ensuring seamless connectivity for building, testing, and scaling DeFi, analytics, and trading applications. With Solana low-latency endpoints powered by global infrastructure, you can achieve lightning-fast response times and consistent performance across regions. 

Start for free, connect your app to a reliable Solana RPC endpoint, and experience how easy it is to build and scale on Solana with Chainstack – one of the best RPC providers.

FAQ

Additional Reading

• Solana trading infrastructure 2026: MEV, nodes, latency
• Solana node types: validator, RPC, and trader nodes
• How to improve Solana RPC latency with ShredStream
• Solana: estimate priority fees with getRecentPrioritizationFees