Deterministic transaction execution ordering using only the transactions (no external randomness, no bundles)

EIPs
,
1

Hi everyone,

I’d like to propose a simple, fully self-contained mechanism to remove most order-based MEV (sandwiches, front-running, etc.) by fixing the execution order of transactions inside each block in a deterministic way.

This proposal is possible to implement in two parts: first as an advisory opt-in default behavior, and then as a consensus change.

Why this is needed

EIP-7956 [DRAFT] (“Tx Ordering via Block-level Randomness”) is currently stagnant and depends on another unfinished EIP for exposing fresh RANDAO/VRF-style randomness per slot. Even if that dependency were resolved, a builder who wins consecutive blocks (which is common under MEV-heavy conditions) can predict the randomness and grind exact transaction ordering.

This proposal avoids those issues entirely: it uses only data already present in the block—specifically the new transactions themselves—and requires no new transaction formats, no bundles, and no external randomness.

Core idea

Once a builder chooses the set of transactions for a block, the execution order becomes immediately fixed.

Specification (high level):

  1. Sort transactions TX_SORTED = t.sort(_.txid)

  2. Get sorting seed from the full transactions seed = keccak256(concatenated TX_SORTED)

  3. Put transactions in nonce order by sender (tiebreak with txid) TX_NONCE_SENDER_ORDER = t.sort(_.txid).sort(_.nonce).sort(_.sender)

  4. Get final sender list FINAL_SENDERS = t.sort(seed).map(_.sender)

  5. Get final transaction list `FINAL_TX = FINAL_SENDERS.forEach(sender -> TX_NONCE_SENDER_ORDER.popFirst(_.sender = sender))

The block is only valid if the resulting state root matches execution in exactly this canonical order.

This guarantees:

  • Per-sender nonce order is maintained.
  • The builder still chooses which transactions to include.
  • Once the set is chosen, the interleaving order is fixed.

Opt-in:

We can accept this proposal now as a recommended transaction ordering. And it can be implemented starting now in the clients published by Ethereum Foundation. Then we can can start to recognize non-canonical-order blocks. And then later we can separately consider a hard-fork to disallow any blocks other than this canonical ordering.

Advantages over EIP-7956

  • No dependency on unfinished randomness EIPs.
  • No reliance on slot-level randomness that a consecutive-block proposer can predict/grind.
  • Extremely simple — only uses keccak256 (native) and data already in the block body.
  • No need for bundles or new transaction types.

Trade-offs we accept

  • A single address can spam many transactions to increase likelihood they will have the first and last transaction. This is disincentivized with the same anti-spam cost everybody has (i.e. paying gas).
  • Grinding remains possible, to influence n bits of entropy in the block requires 2^n transaction inclusion rerolls. This multiplies the effort of each MEV ordering activity inside a block.

Questions for the community

  • Any edge cases I missed around reorgs, blob transactions, or system transactions (e.g. deposits)?
  • Is this two-part (recommended and then hard-fork) novel approach to changing consensus rules a good idea or a bad idea?

I believe this is one of the simplest viable ways to meaningfully reduce harmful reorder MEV without adding complexity or external dependencies.

Looking forward to your thoughts!