Searcher-Builder Interface: How MEV Auctions Work in 2026
The searcher-builder interface MEV landscape of 2026 has evolved far beyond the simple PBS of 2023. Today, searchers interact with a diverse ecosystem of specialized builders through standardized APIs, submitting complex bundles of transactions that are validated against encrypted state and header commitments before any block is finalized.
This guide provides an advanced, detailed look at how MEV auctions work in 2026, covering the full lifecycle: from order flow auctions that allocate exclusive user transactions to searchers, through bundle construction and submission, to header-based verification that ensures builders cannot cheat. We examine real protocols like Flashbots MEV-Share, Titan Builder, and beaverbuild, and explain the trust models that make this system viable at scale.
- The searcher-builder interface enables direct, trustless bundle submissions through header-based verification.
- Order flow auctions have become the primary source of high-value MEV, shifting profits back to users.
- Inclusion lists enforce censorship resistance and force builders to respect proposer preferences.
- SUAVE and similar cross-domain platforms expand searcher opportunities beyond single-chain MEV.
- Privacy-preserving tools (zk-bundles, TEEs) are essential for protecting bundle content from builders.
- The 2026 interface is multi-builder and multi-relay, requiring searchers to manage complex submission strategies.
What Is the Searcher-Builder Interface in 2026?
The searcher-builder interface is the standardized communication channel through which MEV searchers submit transaction bundles to block builders. Unlike the monolithic PBS of earlier years, the 2026 interface is modular, supporting multiple submission mechanisms (gRPC, WebSocket, and even on-chain via SUAVE) and incorporating verifiable delay functions (VDFs) to prevent front-running of bundle orders.
Key components include:
- Bundle Submission API – typical endpoints for sendBundle, checkBundleStatus.
- Header Commitments – builders publish block headers (including state root and transaction root) before revealing the full block, enabling searcher verification.
- Order Flow Integration – searchers receive exclusive order flow from wallets through OFA protocols like Flashbots Protect.
Real-world example: A searcher using Flashbots MEV-Share can opt-in to share partial order flow with builders, receiving a cut of the MEV while allowing builders to optimise block construction.
How Searchers Submit Bundles to Builders
Submission in 2026 follows a three-phase process: preparation, auction, and settlement. First, the searcher assembles a bundle of transactions, typically including at least one arbitrage or liquidation opportunity alongside filler txs (e.g., backrunning order flow). The bundle is signed with the searcher’s identity key and includes a gas price bid expressed in Gwei per gas.
Phase two: the bundle is sent to one or more builders via the searcher-builder interface. Builders run internal auction rounds every ~200ms, competing to include the bundle alongside other bundles and user transactions. The builder selects the most profitable combination while respecting inclusion lists.
Phase three: the winning builder produces a block, signs a header, and broadcasts it. Only after the searcher verifies the header does the builder publish the full block, including the bundle. This prevents builders from copying and replaying bundle content.
Key tools include the bundle-submission APIs exposed by builders such as Titan and beaverbuild, and the Flashbots bundle-submission API.
Header-Based Verification: Trustless Block Delivery
Header-based verification is the cornerstone of trust in the searcher-builder interface. In 2026, builders cannot simply claim they will include a bundle; they must prove it via header commitments.
The protocol works as follows:
- Builder constructs a block containing the promised bundles.
- Builder computes the block header (hash of previous block, state root, transaction root, etc.).
- Builder signs the header and sends it to the searcher (or a relay) as a commitment.
- Searcher verifies that the header’s transaction root is consistent with the expected inclusion of their bundle. This can be done locally using Merkle proofs.
- Only after verification does the builder release the full block body.
This mechanism eliminates the need for a trusted third party (like an external relay) for bundle delivery, though many searchers still use relays for aggregation. The Ethereum beacon chain's inclusion of blob headers also allows verification of L2 bundles. Tools like SUAVE’s Preconfirmation API extend this to cross-chain commitments.
The Role of Order Flow Auctions (OFAs)
Order flow auctions (OFAs) are the mechanism by which users’ transactions are allocated to searchers before entering the public mempool. In 2026, OFA has become the primary source of MEV for sophisticated searchers, as it allows exclusive access to high-value transactions like large swaps or liquidations.
Typical OFA flow:
- User signs a transaction via an integrated wallet (e.g., Rabby, Metamask with OFA plugin).
- The wallet sends the signed tx to an order flow aggregator (e.g., Flashbots MEV-Share, Eden Network).
- The aggregator runs a sealed-bid auction among searchers; each searcher bids a portion of their expected MEV back to the user.
- Winning searcher receives the exclusive order flow and incorporates it into a bundle for submission to builders.
The OFA market has matured, with complex bidding strategies involving MEV estimation in zero-knowledge. Searchers must bid fast and accurately, often using ML models to predict arbitrage potential. The result is that users can capture a substantial share of the MEV generated from their own transactions, reducing negative externalities like sandwich attacks.
A Practical Example: Submitting a Sandwich Bundle via Flashbots
Suppose a searcher identifies a large pending swap on a DEX that can be sandwiched. In 2026, the searcher first checks whether the target transaction is available in an OFA channel. If not, they proceed with a classic mempool-based sandwich.
Steps:
- Construct the sandwich bundle: a front-run tx (buy token X), the victim’s swap, and a back-run tx (sell X at higher price). All three must be atomic: bundle inclusion guarantee is essential.
- Estimate gas and profit: compute the profit after gas costs and builder fees (typically 10-20% of MEV).
- Submit to builder via Flashbots API: using bundle signing with a valid fee recipient address. Specify a bid (e.g., 5 Gwei/gas above the current base fee).
- Builder inclusion and header commitment: builder includes the bundle, signs a header, and sends it back. The searcher verifies the header using a local Merkle proof.
- Reveal and settlement: builder publishes the full block, the bundle executes, and the searcher’s fee is automatically transferred to the fee recipient.
If the bundle fails (e.g., due to state changes), the searcher is not charged—only successful inclusions incur fees. This risk-free submission model has made searchers willing to bid aggressively.
Comparison: Traditional PBS (2023) vs. 2026 Searcher-Builder Interface
| Aspect | Traditional PBS (2023) | 2026 Searcher-Builder Interface |
|---|---|---|
| Trust Model | Relay-mediated; trust required in relay to not steal bundles | Trustless via header verification; relay optional |
| Bundle Submission | JSON-RPC over HTTPS; slow, batch-based | gRPC/WebSocket; sub-200ms rounds |
| Order Flow Access | Public mempool only | OFA channels with exclusive flow |
| Verification | No header verification; bundles revealed fully to relay | Header commitments with Merkle proofs |
| MEV Sharing | Only through mev-geth | Native OFA profit sharing with users |
| Builder Diversity | Flashbots dominant | Multiple builders: Titan, beaverbuild, rsync, plus protocol-owned builders |
Inclusion Lists and Censorship Resistance
Inclusion lists are a critical feature of the 2026 searcher-builder interface. An inclusion list (IL) is a set of transactions that a proposer (validator) can force a builder to include, preventing censorship of certain txs (e.g., simple ETH transfers or DeFi operations). Searchers can also submit bundles to inclusion lists, ensuring their critical transactions cannot be excluded by builders who may front-run them.
The protocol works via two-stage block production: proposers first publish an inclusion list, then builders construct blocks around it. Searchers interacting with builders must ensure their bundles do not conflict with the IL; otherwise, the builder must drop the bundle.
Tools like Builder Bundles with IL Compliance have emerged, allowing searchers to query the current IL of a proposer before submitting. This adds complexity but dramatically improves censorship resistance for bundles that include user transactions from order flow auctions.
Trust Assumptions: Relays, Builders, and Searchers
Despite header-based verification, the searcher-builder interface still relies on several trust assumptions:
- Builder honesty: builders could attempt to simulate a searcher's bundle locally to extract the MEV themselves. Header commitments mitigate this by committing to the bundle inclusion before revealing details, but a builder might still attempt to reconstruct the bundle from non-verifiable state differences.
- Relay integrity: many searchers use relays to aggregate builders. Relays must not collude with builders to steal bundles. In 2026, most relays are permissionless and use cryptographic order-fairness tools (e.g., Fair Sequencing from Flashbots).
- Searcher privacy: bundles contain sensitive information. Searchers use zk-proofs (e.g., via Beaver) to prove a bundle is valid without revealing its contents until after inclusion.
- MEV-Boost fork choice: the beacon chain still uses MEV-Boost to connect proposers with builders, but 2026 has added “honest builder proofs” that allow validators to penalize builders who renege on header commitments.
The overall trust model has shifted from “trust the relay” to “trust the cryptographic commitments and slashing conditions.”
Advanced Strategies: Cross-Domain MEV and SUAVE
The searcher-builder interface is expanding to cover multiple domains. SUAVE (Single Unifying Auction for Value Expression) is a flagship example: it is designed as a shared mempool and execution environment where searchers can submit bundles that span Ethereum L1, L2s, and even Solana (via wormhole bridges).
In 2026, searchers use SUAVE’s confidential compute environment to run order flow auctions and bundle construction inside trusted execution environments (TEEs). This enables:
- Cross-domain arbitrage: bundling a swap on Uniswap (Ethereum) with an opposite swap on Aerodrome (Base) in a single bundle using SUAVE preconfirmation.
- Multi-builder competition: builders from different domains bid on a single bundle, optimizing for finality and fee.
- Privacy-preserving MEV: bundles are never seen in plaintext by any builder; only the execution result is revealed.
SUAVE-based order flow aggregators aim to let searchers bid on order flow from multiple chains simultaneously, increasing the profit surface.
Key Protocols and Tools in 2026
Several protocols define the searcher-builder interface landscape:
- Flashbots MEV-Share: a leading OFA platform, allowing searchers to bid for order flow. Supports partial confidential sharing.
- Titan Builder: a major Ethereum block builder with support for inclusion lists.
- beaverbuild: one of the largest Ethereum block builders by market share.
- SUAVE: a cross-domain execution environment developed by Flashbots.
Searchers interact with these via client libraries and each builder's documented submission API.
Common mistakes to avoid
- Assuming bundle inclusion is guaranteed even if the state changes between submission and block production; always set a high gas limit and use revert protection.
- Ignoring inclusion lists: submitting a bundle that conflicts with the current proposal's IL will cause the builder to reject it, wasting gas.
- Over-relying on a single builder; the 2026 market demands multi-builder submission to ensure inclusion and competitive pricing.
- Neglecting to verify header commitments locally; trusting a relay to perform verification can lead to stolen bundles.
- Basing gas bids on static formulas; dynamic gas estimation using recent block data and auction state is essential.
- Failing to sanitize order flow from OFAs: exclusive flow may be poisoned with sandwich bait; always simulate before building bundles.
Frequently asked questions
How does a searcher choose which builder to submit a bundle to?
Searchers typically submit to multiple builders simultaneously via a relay to maximize inclusion probability. They evaluate builders based on historical inclusion rates, gas price thresholds, reputation for not stealing bundles, and support for inclusion lists. Tools like Flashbots' Builder Scorecard provide real-time metrics.
What is the difference between an order flow auction (OFA) and the traditional public mempool?
Traditonal mempool broadcasts transactions openly, allowing any searcher to front-run or sandwich. OFA channels give exclusive access to a transaction to a single searcher who wins an auction, preventing those negative externalities and returning a portion of MEV to the user. OFA channels now route a growing share of DEX order flow.
Can searchers trust builders with their bundles under header-based verification?
Header-based verification significantly reduces trust: the builder commits to including the bundle before knowing its full content (due to encryption or partial blinding). However, advanced builders might still attempt to extract MEV through state inference. To mitigate this, searchers use privacy-preserving submission that reveals only simulation results.
What role does SUAVE play in cross-domain MEV auctions?
SUAVE provides a unified execution environment where searchers can submit bundles that span multiple blockchains. It uses a combination of TEEs and preconfirmation signals to coordinate inclusion across domains. Searchers can bid once for a bundle that settles on Ethereum L1 and an L2 simultaneously, reducing complexity and capital requirements.
Related reading
Track the entities behind the concepts
DeFi Intel maps 11,000+ protocols, tokens and companies to a typed knowledge graph — with live data, incidents and regulation.