Order flow auction
MEV Blocker's order flow auction protects user transactions from frontrunning and sandwich attacks—the worst types of MEV—by sending transactions to a private mempool of trusted searchers. These searchers then capture any backrunning opportunities left by user transactions and give up to 90% of their value back to the users.
- MEV protection - Public mempool transactions are vulnerable to MEV attacks like frontrunning and sandwich attacks, causing millions in weekly losses. MEV Blocker's private pool protects you from these type of attacks.
- MEV rebates - MEV Blocker lets searchers bid to backrun transactions, returning 90% as user rebates and using 10% to reward builders and validators, reclaiming value and enabling wallet and dapp revenue.
- Faster transaction inclusion - MEV Blocker bypasses the public Ethereum mempool, forwarding transactions directly to major builders for quicker inclusion.
By default, MEV Blocker shares transaction information with all permissionlessly connected searchers mixing real transactions with fake transactions. In the majority of instances, spoofing transactions in this way obscures the transaction data from malicious searchers.
MEV Blocker also supports passing transactions to a curated subset of handlers
using the shareSafe=1 query parameter to increase the success outcomes for advanced swaps protocols.
MEV Blocker's transaction flow can be broken down into six main steps. The following image shows a general overview of the flow of a transaction.
1. Builders connect to MEV Blocker and pay fees
Connected builders post a bond and pay weekly dues. Dues are calculated based on realized MEV Blocker value attributable to the MEV Blocker transaction flow.
For details, see:
2. Order flow originators connect to MEV Blocker RPC endpoints
Order flow originators can submit transactions via public endpoints without an API key or third-party permission.
3. MEV Blocker private mempool action-hiding transactions from searchers
MEV Blocker RPC shares the transaction (without signature) with a permissioned or permissionless set of searchers (depending on the endpoint). It enhances security by mixing real and AI-generated fake transactions together.
Depending on the type of transaction, additional details may be hidden:
- In the case of swaps, MEV Blocker removes some sensitive information (such as slippage tolerance) from the transaction, preventing sandwich attacks.
- If the transaction is unlikely to receive a backrun, MEV Blocker doesn't share it with searchers at all.
In a permissionless environment, searchers can't be prevented from misusing shared data, so fake transactions add uncertainty to the data. Since searchers can't distinguish real from fake, they risk acting on transactions that may never reach the chain, discouraging frontrunning attempts.
3.1. Transactions get forwarded to MEV Blocker connected searchers and builders
Transactions are shared with searchers for backrunning and sent directly to builders for the fastest inclusion.
4. Searchers provide backrunning bids for the flow
After receiving the orders, searchers proceed to crunch their numbers and give their bundles back to MEV Blocker. Searchers are competing for the most profitable option and if they spot a backrun opportunity (real or fake), they submit a bundle to MEV Blocker RPC.
The searcher that provides the bundle with the highest rebate value for users gets selected as the winner (NOT the searcher that pays the highest fee to the validator).
5. Searcher bundles get forwarded to builders to be included in the next block
In this step, the MEV Blocker system gathers all the searcher bundles, discards those containing fake transactions, and attaches the user signatures back to the transactions.
In order to have their bundles forwarded to builders, searchers bid an arbitrary amount denominated in ETH. In theory, searchers have an internal valuation of the bundle's backrun value that is larger than their bid—otherwise they wouldn't bid at all.
Once the builder has selected a searcher bundle bid, they are obligated to refund 90% of that bid's value to the user and use the remaining 10% to pay the validator/proposer.
6. MEV Blocker transactions assembly
MEV Blocker discards bundles with fake transactions, forwarding only real ones. It also re-adds the transaction signature, preventing searchers from bypassing the system and ensuring MEV rebates reach users. The builder selects the bundle with the highest kickback to the user for onchain inclusion.
7. Builders receive transactions and bundles
Builders receive individual transactions and bundles from MEV Blocker. Per OFA rules, they must replace any bundle with a higher-paying one during block-building. They also execute a transaction that pays 90% of the backrun value to the user. Unlike per-transaction fee models, MEV Blocker bills builders based on realized MEV Blocker value, not on per-transaction fees.
If the highest paying bundle no longer simulates correctly on the top of the block (for example, because the submitted transaction route is no longer available), a lower paying bid can still be included. This ensures that users get the highest possible reward without delayed execution (it's also possible for a user to get multiple refunds in a single block).
8. Transaction inclusion onchain
Builders execute the user transaction, backruns, and MEV refund, which is automatically sent to tx.origin or the designated address.
This ensures users and order flow providers receive 100% of the refund, with MEV Blocker taking no cut.
9. Final: MEV Blocker gas rebates for order flow originators
MEV Blocker provides gas rebates to order flow providers by redistributing 90% of builder fees that are attributable to the order flow originator.