MEV Auction. Private order flow with a rebate clients can verify

Our work

We developed the transaction-routing and auction middleware for MEV Auction. The work covered privacy-limited searcher hints, bid commitments, execution-linked rebates and reconciliation across builder responses and chain reorganisations.

A signed transaction still has to reach a block. During that interval its route determines who can inspect the order and act on the information before execution. For an institutional trading desk this makes transaction submission part of execution quality. MEV Auction addresses that interval through private ingestion, a controlled order flow auction and a settlement record that clients can reconcile against the chain.

The project is B2B middleware between the institution's signing infrastructure and Ethereum block production. Clients retain their keys and construct their own transactions. The system controls routing and auction participation rather than trading strategy or account ownership. Two engineering conflicts shape the design. Searchers need enough information to bid on a backrun without receiving the full order. The resulting rebate also needs to remain connected to execution when a block is reorganised or a builder retains a signed transaction.

Competition needed what privacy was meant to withhold

An order flow auction lets searchers compete for the opportunity to execute after an originating trade. That backrun may capture an arbitrage opportunity created by the trade and return part of its value to the originator. Giving searchers the complete signed transaction would expose the same sensitive details the private route is intended to protect. Withholding every detail would leave them unable to identify an opportunity. We made disclosure an explicit part of the order model rather than an informal agreement with auction participants.

The engine normalises each order into three information classes. Approved hints identify relevant contracts, function selectors or pools. Sealed fields contain exact amounts, slippage bounds and sensitive identity information. Internal fields include signatures and the complete executable payload. Searchers receive only the selected hints and contribute their own backrun bundles. The engine retains responsibility for constructing the ordered submission. An auction participant does not receive the originator's signed transaction as material it can assemble or redistribute through the auction interface.

Candidate backruns are simulated against the projected state after the originating transaction. Eligibility checks reject submissions that violate the required ordering, invalidate the originating execution or fail their payment obligation. The engine therefore controls both the disclosure surface and the permitted contribution to the bundle. This constrains the searcher's role without claiming that all external actors lose the ability to exploit order information. The operator sees cleartext during processing and selected builders receive it for block assembly. Those remain separate trust boundaries.

Account abstraction added more information to protect

The ingestion model supports native signed transactions and ERC-4337 UserOperations. Native flow preserves the original signed artifact. Account-abstraction flow first passes through a private bundler that validates the signature, time restrictions, prefund and any Paymaster requirements before constructing an EntryPoint envelope. Both paths then enter a common auction pipeline. For UserOperations the sensitive intent is nested inside account calldata, so inspecting only the outer EntryPoint call would not produce a useful or safe disclosure policy.

The engine decodes the inner target and selector while keeping the inner arguments, signature and Paymaster context out of the searcher-facing payload. A per-order salted handle replaces the smart account's raw sender address. This avoids publishing a stable account identifier in the hints that participants could directly link across auctions. It does not create anonymity after settlement. The included transaction and EntryPoint events remain public, and analysis of that public history remains possible.

Gas metadata can also reveal the shape of an operation even when its arguments are hidden. The design uses standard gas brackets to make those hints less precise. Bracketed execution limits are part of the operation agreed before final signing; the privacy setting does not remove its gas requirement. Coarser limits also affect prefund requirements, so this privacy setting has an operational cost. The design treats it as a client configuration decision rather than hiding it behind a claim of free privacy.

A correct payout required a checkable auction result

Returning a percentage of an operator-reported clearing price would leave the most important number inside the operator's system. MEV Auction therefore links accepted bids to a committed bid set. Each acknowledged bid receives a signed receipt containing its commitment and order context. The engine records acknowledged bids with their eligibility status and commits the set before builder submission. Ineligible bids remain in the acknowledged bid record.

This separates two disputes. A bidder can challenge the omission of an acknowledged bid using its receipt and the committed set. A disagreement about eligibility instead requires examination of the simulation and the state against which it ran. These are different evidence problems and need different resolution paths. The architecture provides an operator bond for demonstrable violations alongside searcher collateral, rather than making participants bear obligations that the operator itself does not share.

The configured auction rule determines the clearing payment. Under first-price clearing it is the highest eligible payment. Under second-price clearing it follows the second-highest eligible payment. The revealed bid data and commitment identify the inputs to that calculation. Neither calculation establishes that the operator attracted every possible bidder or acknowledged every incoming network request. The proof covers the committed set, while signed receipts create accountability for acknowledged bids missing from that set.

The originator's refund coefficient is fixed at ingestion. The rebate is calculated from that coefficient and the clearing payment rather than fitted retrospectively to an amount the operator chose to pay. We used Q64.64 fixed-point arithmetic so client reconciliation can reproduce the contract calculation, including rounding. A rebate exists only when an eligible opportunity attracts a paying bid. Private routing does not itself imply that every transaction earns a return.

Two commitments: the bundle did not exist at ingestion

An ingestion receipt can commit to an order and its disclosure policy, but it cannot yet identify a winning backrun or an assembled bundle. We split attestation into two phases. The first commitment binds the submitted order, sealed-field digest, exact hint set, chain context and refund coefficient. It gives the client a record of what entered the auction before the result was known.

The routing commitment comes after clearing and before submission. It links back to ingestion and adds the ordered bundle hash, target builder set, target block, clearing payment and bid-set root. Both phases are included in externally anchored batches with client inclusion proofs. This makes the retained records comparable with a public commitment history instead of relying only on copies supplied by the operator. The records retain the association between orders, attempts and commitments for inspection. A Merkle inclusion proof establishes inclusion of a record, not the truth of every claim represented by that record.

The client reconciliation path checks several distinct artifacts.

• The original order and committed disclosure policy.
• The signed attestations and anchor proofs.
• The acknowledged bid set and clearing rule.
• The submitted ordering and canonical execution.
• The refund coefficient and on-chain payment.

These records provide evidence about submission, auction accounting and settlement. They do not prove that no one leaked cleartext through a separate channel. Nor does failing to observe a transaction in a monitored mempool prove that it was never disclosed anywhere. Keeping this boundary explicit prevents a useful audit mechanism from becoming an unsupported claim of complete information privacy.

Private routing becomes more accountable when clients can reconstruct what was disclosed, how the auction cleared and whether the promised rebate reached them. MEV Auction connects those stages through commitments and settlement records while keeping operator visibility and builder behaviour visible as remaining trust assumptions.

Conflict two: keeping execution and rebate together

For native signed transactions the engine assembles the originating transaction, winning backrun and refund into an ordered bundle. This preserves the client's existing target contract and avoids placing a platform router in the asset path. The refund is part of the intended bundle execution. However, the relationship exists at the bundle layer. It is not encoded inside the originating transaction itself.

A reorganisation exposes that distinction. If the original block disappears a builder that retained the signed transaction may attempt to include it on the new chain without the separate refund. The transaction nonce prevents duplicate execution but does not require another transaction to accompany it. Re-simulation and resubmission can support recovery, yet they cannot make the native transaction enforce a dependency it never signed. Clients needing stronger coupling therefore use a different settlement path.

The Settlement Wrapper makes the rebate part of the originating execution frame. The winning searcher funds order-specific escrow before execution. The wrapper verifies the settlement context, obtains the authorised input, executes the inner trade, checks the realised output and pays the agreed rebate within the same transaction. Failure of a required step reverts the frame. If the escrow disappears in a reorganisation the wrapped trade cannot execute successfully without the required funding. This moves the coupling from a builder submission convention into the contract call the originator authorised.

The wrapper route changes the integration and approval surface. Its design uses bounded Permit2 authorisation for the settlement and exact target allowances that are reset after execution. This is narrower than granting an arbitrary standing allowance to a trading router. The distinction also matters to the custody description. Native flow submits the client's signed transaction without inserting the platform wrapper into its asset path. Wrapped flow moves assets through contract execution and uses searcher-funded escrow, but does not create an operator-maintained rebate balance awaiting a later withdrawal. Contract and authorisation risks remain part of that choice.

Inclusion needed a deadline matching block construction

We bounded auction collection and routing by the builder submission window. Budgeting against a whole Ethereum slot would overstate the time available. The architecture subtracts the builder's seal margin, relay deadline and network round-trip time to estimate the usable window. Bid collection, simulation and clearing all consume part of that window. For orders where a few milliseconds determine the opportunity, the system includes a private path that skips the auction rather than pretending the collection interval has no cost.

Routing uses moving estimates of builder latency, variance and acknowledgement health. When a builder degrades the engine can promote another approved route during the submission window. Sending to several builders improves route diversity but exposes cleartext to more parties. Clients can therefore cap the submission set. The system does not treat the inclusion-optimal builder count as automatically appropriate for every confidentiality policy.

Public fallback is another explicit choice. Strict-private orders expire rather than being broadcast publicly to force inclusion. Deadline-based and immediate fallback modes permit different behaviour when selected by the client. The recorded disclosure policy controls fallback during congestion. A strict-private order may remain unincluded under censorship or repeated private-route failure. The system reports that outcome instead of promising that private routing always matches public-path latency.

Recovery had to preserve the original agreement

After a reorganisation the projected state that supported a bid may no longer exist. The engine tracks canonical block ancestry, identifies affected orders and re-simulates them against the new head. A replacement routing attestation connects the new attempt to the original commitment and the reorganisation evidence. The backrun, target block or clearing result may change because the state changed. The order's disclosure policy and committed refund coefficient cannot become unrelated new values under the cover of a retry.

Fee escalation is bounded by the client's cap and deadline. When changing the native transaction's fee fields requires a new signature, that authorisation remains with the client's signing path. The routing service does not gain permission to rewrite a signed artifact. This preserves the distinction between preparing a new submission attempt and authorising a new transaction. It also prevents recovery logic from quietly changing the custody model established at ingestion.

Searchers and the operator face different accountability paths depending on the evidence. A receipted bid omitted from a committed set is a specific proof problem. Suspected information probing or collusion is an inference that may require a challenge period and arbitration. Searcher bonds remain exposed during an unbonding delay so withdrawal does not immediately remove collateral from an unresolved dispute. Hash-chained interaction records support review without turning every suspicious pattern into an automatic penalty.

Integration: precise failures and chain-specific capabilities

The private RPC surface lets a client retain its transaction construction and key management. Native submission can fit into an existing provider configuration, while wrapper-mediated execution requires deliberate calldata and authorisation changes. UserOperation flow uses the private bundler path. Treating all three as the same endpoint substitution would hide the settlement decision that affects both gas and protection under reorganisation.

Error categories distinguish an expired submission window, a reverting simulation, an unmet slippage bound and a screening rejection. Expensive exploit screening runs in a worker pool separate from routing, with compute and wall-clock limits on each request. A screening timeout follows the client's configured fail mode and is either rejected or explicitly flagged. Successful simulation remains an observation about the simulated state. The wrapper applies its output check at execution; a successful simulation does not replace that check.

The architecture also keeps routing capability separate from the client API. Ethereum builder competition supports the full order flow auction model described here. Each chain adapter records its available private-routing and native-sequencing capabilities. A shared interface cannot establish identical ordering power or rebate opportunities across networks. Capability and settlement mode therefore belong in the integration contract rather than being inferred from the fact that an endpoint accepts an order.

The operator can access cleartext during processing. Disclosure controls limit what searchers and builders receive, while commitments and receipts make auction participation reviewable. Those controls do not provide enclave-based confidentiality from the operator.

The implementation gives a trading desk a choice of disclosure policy, builder exposure, fallback behaviour and settlement path before submission. After execution, the same records connect the order to the auction, chain outcome, gas cost and rebate. A missed inclusion or failed settlement remains visible alongside successful execution.