Transaction Bundle

What Is a Transaction Bundle?

A transaction bundle is an ordered group of signed transactions that a searcher submits to a block builder as a single atomic package. The builder either includes every transaction in the bundle in the exact specified order, or excludes the bundle entirely. There is no partial execution: if any transaction in the bundle reverts (unless explicitly marked as allowed to revert), the whole bundle is dropped.

Bundles emerged from the need to guarantee transaction ordering on blockchains where validators (or miners, pre-merge) control which transactions appear in a block and in what sequence. Before bundles existed, searchers had to compete in public gas auctions to try to get their transactions positioned correctly, a process that congested the network and leaked strategy information. The Flashbots project introduced the bundle abstraction in 2021 as part of mev-geth, creating a private marketplace between searchers and block producers. After Ethereum's transition to proof-of-stake, the bundle pipeline evolved into the proposer-builder separation (PBS) architecture used today.

How It Works

The bundle lifecycle involves four distinct actors: the searcher who constructs the bundle, the relay that transmits it, the builder who assembles the block, and the proposer who signs the final block.

1. A searcher monitors blockchain state (pending transactions in the mempool, on-chain contract state, oracle price feeds) to identify a profitable MEV opportunity
2. The searcher constructs a bundle containing the exact sequence of transactions needed to capture that opportunity, signs each transaction, and submits the bundle to a block builder through a private channel
3. The builder receives bundles from many searchers, simulates each one to verify profitability and validity, then assembles the most profitable block possible by combining bundles with regular transactions from the public mempool
4. The builder submits the assembled block to a relay, which verifies the block and forwards the block header (with a payment bid) to the current slot's proposer
5. The proposer selects the most profitable block header, signs it, and the relay releases the full block for propagation across the network

This pipeline keeps bundle contents hidden from the public mempool at every stage. The proposer never sees individual bundle transactions: they only see the total payment offered by the builder. This prevents the proposer from stealing MEV by reordering or copying bundle strategies.

Bundle Submission Format

Searchers submit bundles via JSON-RPC endpoints exposed by builders or relays. The Flashbots relay, for example, accepts bundles through the eth_sendBundle method. A bundle payload contains the signed transactions, a target block number, and optional timing constraints:

{
  "jsonrpc": "2.0",
  "method": "eth_sendBundle",
  "params": [
    {
      "txs": [
        "0x02f8...",   // signed tx 1 (e.g., front-run)
        "0x02f8...",   // signed tx 2 (e.g., victim tx)
        "0x02f8..."    // signed tx 3 (e.g., back-run)
      ],
      "blockNumber": "0x1234567",
      "minTimestamp": 0,
      "maxTimestamp": 1700000000,
      "revertingTxHashes": [
        "0xabc..."
      ]
    }
  ]
}

The txs array contains raw signed transactions in the exact order they must execute. The blockNumber field targets a specific block: if the bundle is not included in that block, it expires. The revertingTxHashes field lists transactions that are allowed to revert without invalidating the entire bundle. The Flashbots relay enforces limits of 100 transactions per bundle and a maximum payload size of 300,000 bytes.

Bundle Simulation

Before including a bundle in a block, builders simulate it against the current chain state. Simulation verifies that transactions execute successfully, calculates the MEV profit (the difference between gas costs and extracted value), and checks that the searcher's payment to the builder is valid. Bundles that fail simulation or are unprofitable are discarded. Builders run simulations continuously as new bundles arrive and chain state changes.

Use Cases

DEX Arbitrage

The most common use of bundles is capturing price discrepancies across decentralized exchanges. When the price of a token differs between two AMM pools, a searcher constructs a bundle that buys on the cheaper pool and sells on the more expensive one. The bundle guarantees both trades execute atomically: the searcher either captures the spread or pays nothing.

Liquidations

Lending protocols like Aave and Compound allow anyone to liquidate undercollateralized positions for a reward. When a position becomes eligible for liquidation (typically because the collateral's price has dropped below the required ratio), multiple searchers race to execute the liquidation. Bundles let a searcher package the liquidation transaction with a swap to immediately sell the received collateral, locking in profit atomically.

Sandwich Attacks

A sandwich attack is one of the more controversial uses of bundles. The searcher constructs a three-transaction bundle:

1. A front-run trade that buys the same token the victim is about to swap, pushing the price up
2. The victim's own pending swap transaction, which now executes at a worse price due to the front-run
3. A back-run trade that sells the token acquired in step one at the inflated price, capturing the difference as profit

The bundle's atomicity guarantee is critical here: if the victim's transaction reverts (for example, because slippage protection triggers), the entire bundle fails and the searcher pays no gas. The searcher detects the victim's transaction in the public mempool, wraps it with their own trades, and submits the bundle privately to a builder.

Backrunning

Not all bundle strategies are extractive. Backrunning places a transaction immediately after a large trade to capture the arbitrage opportunity it creates, without affecting the original trader's execution price. For example, when a large swap moves a pool's price away from the global market price, a backrunner can rebalance the pool and pocket the difference. This form of MEV is generally considered beneficial because it improves price efficiency across markets.

The Private Order Flow Debate

Transaction bundles are central to a broader debate about private order flow and its impact on blockchain fairness. The shift toward private submission channels has created what some researchers call a parallel transaction supply chain, where a growing share of transactions never enters the public mempool.

Arguments for Private Bundles

• They protect users from front-running by keeping pending transactions hidden from adversarial searchers scanning the public mempool
• They reduce network congestion by eliminating priority gas auctions (PGAs), where competing searchers would spam high-gas transactions to win ordering
• They create an efficient market for block space, where builders compete on merit rather than on who can spam the fastest

Arguments Against Private Bundles

• They concentrate power in a small number of high-performance builders who can process bundles fastest, undermining decentralization
• They require users to trust the private channel operator not to exploit or censor their transactions: this trust model is difficult to verify at scale
• They enable harmful MEV strategies like sandwich attacks that extract value from regular users, with the builder effectively facilitating the attack
• They reduce mempool transparency, making it harder to detect censorship or analyze network health

This tension is sometimes described using the dark forest metaphor: the public mempool is a hostile environment where any visible transaction can be exploited, driving users toward private channels that introduce their own centralization risks. The Ethereum research community is actively exploring solutions like encrypted mempools and enshrined PBS (ePBS) to address these trade-offs at the protocol level. For a deeper analysis of how PBS shapes validator economics, see the research article on Ethereum MEV, PBS, and validator economics.

Risks and Considerations

Builder Centralization

The bundle pipeline has concentrated block building among a small number of sophisticated builders. Over 90% of Ethereum blocks are now produced through MEV-Boost, and a handful of builders consistently win the majority of block auctions. This concentration creates censorship risks: if dominant builders decide (or are compelled) to exclude certain transactions, users have limited recourse.

Failed Bundle Costs

While bundles that fail simulation cost the searcher nothing in gas, building the infrastructure to detect opportunities, simulate bundles, and submit them at scale requires significant investment in low-latency systems and blockchain state indexing. The competitive landscape favors well-capitalized searchers with co-located infrastructure, raising barriers to entry.

Cross-Domain Bundles

As MEV strategies span multiple chains and layers, searchers increasingly need to coordinate bundles across different execution environments. Cross-domain MEV introduces additional risks because atomicity guarantees do not extend across chains: a bundle on Ethereum may succeed while the corresponding transaction on an L2 or another chain fails, leaving the searcher exposed.

Regulatory Uncertainty

The legality of MEV extraction through bundles remains an open question in most jurisdictions. Sandwich attacks, in particular, bear structural similarities to front-running in traditional finance, which is illegal in many markets. As regulators develop frameworks for blockchain markets, bundle-based MEV strategies may face increased scrutiny.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.