EIP-8046: Uniform price auction over inclusion lists

EIPs EIPs core
1

Discussion topic for EIP-8046; PR; Web.

Description

Ensure IL transactions that offer a higher ranking fee than competing transactions are included in the block. Burn the marginal ranking fee.

Relevant resources

Thanks to Francesco D’Amato for feedback.

Abstract

This EIP proposes a uniform price auction over inclusion lists (UPIL), which ranks transactions by their offered ranking fee per gas. When the block is full, no transaction is allowed to displace an inclusion-list (IL) transaction that passes regular inclusion criteria and offers a higher ranking fee per gas. All included transactions pay a uniform inclusion price, equal to the highest ranking fee offered by any valid IL transaction excluded from the block, and this fee is burned. UPIL achieves strong censorship resistance by not allowing builders to circumvent propagated ILs when the block is full. This is particularly valuable for time-sensitive transactions and promotes fairness while preventing cheap block-stuffing under a multidimensional fee market. UPIL is specified to run on top of FOCIL (EIP-7805), but can be deployed on top of any IL mechanism.

1 Like
2

this could be used to stop MEV attacks?

3

It does not prevent MEV.

4

Does FOCIL/FOCILR take OFAC into consideration?

5

Thanks for the proposal — FOCILR feels like a meaningful evolution of FOCIL, especially for maintaining censorship-resistant inclusion guarantees under multi-resource congestion.

What I particularly appreciate is the combination of:

  • Explicit ranking_fee_per_gas → expresses inclusion urgency directly
  • Uniform marginal ranking fee → removes value extraction incentives for block stuffing
  • Ordered IL enforcement → strengthens the credible commitment in congested conditions

To help the ecosystem align around adopting this, I believe two areas could use more elaboration:

:one: Tooling / UX implications
Wallets, explorers, and simulation tools need clear guidance to prevent confusing situations where users overpay ranking fees or fail inclusion despite high gas settings. A recommended “ranking fee bidding” strategy or baseline heuristics would be very useful.

:two: Builder / includer implementation paths
As FOCILR introduces new ordering constraints, having more detail on how block builders should efficiently incorporate ranked IL during block construction can help avoid accidental centralization pressure.

If the EIP includes these operational considerations (or links to reference implementations), it would be easier for client teams and infra providers to commit to rolling this into their roadmaps — and the proposal’s benefits to censorship-resistance would be much clearer to the broader community.

Overall, I support the direction and would love to see more concrete benchmarks and UX guidelines as next steps.