---
eip: 7956
title: Tx Ordering via Block-level Randomness
description: Decreasing MEV attacks by forcing a deterministic transaction ordering via block-level randomness.
author: Aryaethn (@aryaethn)
discussions-to: https://ethereum-magicians.org/t/potential-eip-mev-decrease-by-deterministic-transaction-ordering-via-block-level-randomness/24084
status: Stagnant
type: Standards Track
category: Core
created: 2025-05-24
requires: 7998
---


## Abstract

Proposers and builders can currently permute pending transactions arbitrarily, enabling reorder‑driven MEV.  This EIP introduces a consensus rule that sorts all transactions inside a block by XOR‑ing each transaction hash with fresh slot randomness.  The randomness is unknown until the slot starts, so the order is deterministic once known but unpredictable beforehand.  The mechanism **significantly reduces reorder‑based MEV**; latency‑driven back‑running, censorship, and other classes of MEV remain and should be mitigated through complementary techniques (encrypted mempools, reputation, PBS marketplaces, etc.).

## Motivation

Unrestricted ordering is the key enabler of sandwich and classic front‑running attacks.  Deterministic ordering collapses these vectors to latency racing and information asymmetry.  Clear candidate‑set and bundle semantics preserve fee markets while removing the need for trusted sequencers.  Academic works shows deterministic ordering drives sandwich profits toward zero.

### References

* Julia Ofoegbu, “Maximal Extractable Value (MEV): A Tale As Old As Time,” Medium (2024).

* J. Qian et al., “Deterministic Transaction Ordering Without Trusted Sequencers,” arXiv:2411.03327 v1 (2024).

* “Shutter Network Introduces Plan for First Encrypted Mempool on Ethereum,” GlobeNewswire, 13 Feb 2025.

## Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.


### Slot Randomness `R`

We define our randomness `R` as the `randao_reveal` of the each slot, after [EIP-7998](./eip-7998.md), since this EIP provides slot-by-slot randomness for `randao_reveal` (only predictable for the builder). This provides enough randomness for our purpose of reducing MEV attacks by MEV bots.

```
R = body.randao_reveal[0:32]     : bytes32
```


### Builder Flow

1. **Candidate‑set selection** – Builders **MAY** choose **any subset** of the mempool based on priority fees, side agreements, or policy.  Transactions not chosen are ignored.
2. **Canonical sorting** – Sort the chosen set by primary key `H(tx) ⊕ R` ascending, then secondary key `H(tx)` ascending, in case of collision on the primary key.
3. **Gas‑limit packing** – Append items in order until adding the next would exceed the block gas **limit**.
4. **Bundles (optional cross‑address atomicity)**

* **Definition** – A bundle is a user‑signed list of fully‑signed transactions.  Each `child_tx_rlp` is the canonical **signed** RLP encoding, including signature fields `(v, r, s)`.  The bundle begins with a *fee‑payment* transaction that covers gas and builder tip for the entire bundle.
* **Hashing / sort key** – Treat the bundle as a *virtual transaction* with key `H(concat(child_tx_rlps))`, where:

   * `child_tx_rlps[i]` **MUST** be the exact bytes that will later appear in the block body for that transaction, i.e. the *canonical RLP of the fully‑signed transaction* per [EIP‑2718](./eip-2718) / [EIP‑155](./eip-155) rules (for typed transactions the leading *type byte* and length prefix are included).
   * Implementations **MUST NOT** strip or normalise the signature fields `(v,r,s)`; those 65 bytes are hashed as‑is so every participant derives an identical bundle key.
   * The concatenation order is the author‑declared execution order of the child transactions.
* **Gas accounting** – Bundle gas is the **sum of the `gasLimit` fields** of all child transactions.  Builders use that sum when evaluating step 3.
* **Fit‑or‑skip rule** – If the bundle (fee‑payment + children) would exceed the remaining gas limit, the bundle is skipped atomically.

5. **Fee dynamics** – Priority fees influence membership in the candidate set (step 1) but **never** override the canonical order once a tx or bundle is selected.

Here is a pseudocode for the above flow:

```
//---------------------------------------------------------------------
// Inputs
//---------------------------------------------------------------------
// mempool          : All pending txs & user-signed bundles visible to the builder
// R                : 32-byte slot randomness supplied by randao_reveal
// BLOCK_GAS_LIMIT  : Max gas allowed in the block

//---------------------------------------------------------------------
// Helper functions
//---------------------------------------------------------------------
function HASH(obj)           → bytes32       // Keccak-256 of the byte sequence
function PRIMARY_KEY(h, R)   → bytes32       // h XOR R (bit-wise)

function bundleGas(bundle):                      // sum of gasLimit of children
    total ← 0
    for childTx in bundle.children:
        total ← total + childTx.gasLimit
    return total

//---------------------------------------------------------------------
// 0. Candidate-set selection  (builder policy / side deals / fee filter)
//---------------------------------------------------------------------
candidates ← pickSubsetFrom(mempool)            //  ANY subset is allowed

//---------------------------------------------------------------------
// 1. Compute canonical keys & gas cost for every candidate
//---------------------------------------------------------------------
for item in candidates:
    if item.type == "single_tx":
        item.gasCost  ← item.gasLimit
        baseHash      ← HASH(item.RLP)          // canonical signed RLP (EIP-2718)
    else if item.type == "bundle":
        concatRlps    ← CONCAT(item.child_rlps) // fee-tx + children in author order
        item.gasCost  ← bundleGas(item)
        baseHash      ← HASH(concatRlps)

    item.primaryKey   ← PRIMARY_KEY(baseHash, R)
    item.secondaryKey ← baseHash

//---------------------------------------------------------------------
// 2. Canonical sorting  (primaryKey asc, then secondaryKey asc)
//---------------------------------------------------------------------
sort(candidates, by = (primaryKey ASC, secondaryKey ASC))

//---------------------------------------------------------------------
// 3. Gas-limit packing with fit-or-skip for bundles
//---------------------------------------------------------------------
blockList ← empty list
gasUsed   ← 0

for item in candidates:
    if gasUsed + item.gasCost > BLOCK_GAS_LIMIT:
        continue               // skip whole tx or bundle atomically
    append(blockList, item)
    gasUsed ← gasUsed + item.gasCost

//---------------------------------------------------------------------
// 4. Output — assemble block body & header field
//---------------------------------------------------------------------
block.randomness          ← R               // bytes16 in the payload header
block.txOrderingVersion   ← 1
block.body                ← flatten(blockList)   // bundles explode into children
return block
```

### Consensus Rule

A block is **invalid** if the executed list deviates from the canonical order derived from its `randomness` and the included transactions/bundles.  Verification is objective; fork‑choice remains unchanged.

### Performance

Sorting ≤ 1 500 transactions remains `O(n log n)` (< 1 ms), on today's hardware.

### Deployment 

#### Added Parameters

* `randomness`: Specified in the specification.
* `txOrderingVersion = 1` flag: To be compatible with the existing consensus rule and adding compatibility for future rules if needed.

#### Fork Parameters

* `ORDERING_FORK_EPOCH`: Beacon‑chain epoch at which execution clients start to recognise the new fields `randomness` and `txOrderingVersion`.
* `ORDERING_TRANSITION_EPOCHS` window activate the rule: 64 epochs (~13.6 h). Length of the transition window during which blocks with either ordering version are accepted.

Both parameters are constants in the fork config and may be tuned during test‑net experiments.

#### Activation Flow

1. Consensus‑layer upgrade —  Beacon‑chain fork at `ORDERING_FORK_EPOCH` activates **`EL‑VRF‑exposure`** (companion EIP) and begins populating the `vrf_output_proposer` field.  Execution clients receiving the `ExecutePayload` after this epoch expect a non‑zero `randomness` field.

2. Execution‑layer handshake —  Builders and proposers include the new `randomness` and `txOrderingVersion` fields in Engine API `engine_newPayloadV3` calls.  Legacy nodes that have not upgraded will reject the payload, causing a natural chain split and economic incentive to upgrade.

2. Transition window —  For `ORDERING_TRANSITION_EPOCHS` after `ORDERING_FORK_EPOCH`, clients accept:

  * Version 0 blocks —  `txOrderingVersion` == 0; no randomness; legacy ordering.

  * Version 1 blocks —  `txOrderingVersion` == 1; valid randomness; canonical ordering enforced. During this period proposers are encouraged (but not forced) to adopt version 1 so that fee markets and MEV supply chains have time to adjust.

4. Finalisation —  At `ORDERING_FORK_EPOCH` + `ORDERING_TRANSITION_EPOCHS` the consensus rule changes: blocks MUST set `txOrderingVersion == 1` and pass canonical‑order validation.  A version‑0 block after this point is treated as invalid and will not be considered by fork‑choice.


## Rationale

### Why randomness‑driven ordering?

* Objective & Verifiable –  Using a function of on‑chain randomness (R) and a transaction’s own hash gives every validator an identical, cheap check on order validity.

* Unpredictable Until Slot Start –  The XOR of slot‑level RANDAO and the proposer’s VRF output ensures that neither users nor builders can know the final sort key before the slot begins, closing the classic front‑run window.

* Minimal Surface Area –  A single 16‑byte field in the execution payload plus a hash operation keeps consensus changes small and auditable.

### Why XOR as the mixing function?

* XOR is associative, fast, and requires no extra cryptographic assumptions beyond SHA‑2 already used for H(tx).

* Any bias in one entropy component (e.g., RANDAO) is negated unless the attacker also controls the VRF output.

### Why allow builders to curate the candidate set first?

* Preserves fee‑market incentives: high‑tip transactions still rise to the top of inclusion competition.

* Avoids forced inclusion of low‑value spam that could bloat blocks if the entire mempool were blindly sorted.

### Why a secondary key H(tx) for tie‑breaking?

* Guarantees total order with negligible extra cost.

* Leverages a value already known to every node; no extra field is needed.

### Why optional bundles instead of implicit nonce‑chain folding?

* Cross‑address atomicity (e.g., borrower + lender tx pair) cannot be expressed via nonce order alone.

* Requiring an explicit fee‑payment transaction embeds pricing for the externality a bundle imposes on ordering neutrality.

### Why the "fit‑or‑skip" bundle rule?

* Ensures all clients compute the same gas impact, preventing divergent execution.

* Avoids partial bundle execution, which would undermine user intent.

### Why the version flag + transition window?

* Prevents accidental consensus splits by giving node operators a grace period.

* Mirrors previous successful hard forks (e.g., London’s BASE_FEE activation sequence).


## Backwards Compatibility

* **Old nodes** —  Execution clients that ignore the new fields will treat version‑1 blocks as malformed and fork away.  The short transition window gives operators time to upgrade.
* **Light clients** —  No additional work; they track headers chosen by upgraded full nodes.


## Security Considerations

### Randomness Bias & RANDAO Manipulation

* *Single‑validator bias* – A block proposer can not change its `randao_reveal` output after EIP-7998, only predictable to him.

* *Coalition bias* – Multiple consecutive‑slot proposers could attempt to influence RANDAO by withholding signatures, but the protocol already slashes equivocation and missed attestations.  The cost rises exponentially with coalition size, and the added VRF entropy further randomizes `R`.

* *Forkable bias* – Re‑org attempts longer than depth 1 must overcome the usual consensus finality thresholds.  Because `R` is embedded in the execution payload, any fork conflicts are objectively detectable by all nodes.

Conclusion: Collusion attacks are economically unattractive; the mixed entropy from RANDAO and VRF provides strong unpredictability guarantees.

### Hash Grinding

New signatures are required only when `calldata` changes, but attacks must begin **after** block is built.  Propagation delays and inclusion fees sharply limit profitable grinding to high‑value trades.

### Tie Collisions

Secondary key `H(tx)` guarantees total order; collision probability (`2^{-256}`) is negligible.

### Bundle Gas Consistency

Explicit summation rule ensures every client computes identical gas usage for bundles, preventing divergent validation.

### Residual MEV Vectors

* *Back‑running & latency* – Persist.

* *Builder discretion* – Builders may censor or selectively include transactions while forming the candidate set; exactly like the current status of Ethereum.


## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).