Fee-blind ordering
Frost’s consensus layer orders transactions and executes them FIFO. It does not
read fees, cannot compare them, and offers no way to pay for position. The
EIP-1559 base fee is the entire fee market; eth_maxPriorityFeePerGas returns
zero.
It falls out of the architecture
Section titled “It falls out of the architecture”This is worth stating first, because it changes how much you should trust it. Fee-blindness here is not a policy that a builder implements and could stop implementing. It is a consequence of where ordering happens.
The consensus layer orders opaque bytes. It does not run the EVM, does not decode transactions, and has no notion of what any of them pay. By the time anything in the system can read a fee field, the order is already fixed and committed.
A builder cannot sort by fee because there is no builder, and nothing in the path that decides order can see a fee to sort by.
What it eliminates
Section titled “What it eliminates”Priority-fee auctions. There is no bid to win, so there is no top-of-block to buy.
Sandwich attacks by fee bidding. The canonical sandwich requires placing one transaction immediately before a target and another immediately after, which requires purchasing both positions. Neither is for sale.
Fee-based censorship. You cannot outbid a transaction into oblivion, because outbidding does nothing.
Fee spirals under congestion. When blocks fill, the base fee rises for everyone according to a fixed rule. There is no auction dynamic where users bid against each other for scarce position.
What it does not eliminate
Section titled “What it does not eliminate”Being honest about this matters more than the list above, because “MEV-resistant” is often claimed far beyond what a mechanism delivers.
Ordering still exists. Someone who observes a transaction and submits their own quickly may still land ahead of it, because arriving earlier is exactly what determines position. Fee-blind ordering removes the auction; it does not remove the race. Low-latency infrastructure and proximity to validators still confer advantage.
Validators still see transactions before they are committed. A validator observing the incoming stream learns about transactions before the rest of the network does. Fee-blindness does not encrypt the mempool.
Application-level extractable value is untouched. A DEX design that lets an observer profit from a pending trade still does, if they can act on it. The chain has removed one mechanism for acting; it has not removed the opportunity.
Nothing prevents out-of-band payment. Fee-blindness means the protocol does not sell position. It cannot prevent someone from arranging that privately with a validator, and a chain claiming otherwise would be overstating what consensus rules can do.
The honest summary: Frost removes the in-protocol market for position. That is a meaningful structural change, and it is not the same as eliminating MEV.
Why choose this
Section titled “Why choose this”Two reasons.
Simplicity where it counts. The consensus layer does not have to understand transactions at all. A layer that cannot decode a transaction cannot be manipulated through what a transaction contains, and it is much easier to reason about a component whose input is opaque bytes.
Fee-bidding does not fit the workload. Post-quantum transactions are calldata-dominated, and blocks fill by bytes as much as by computation. A priority auction on top of that mostly redistributes value to whoever runs the fastest infrastructure, without improving how the scarce resource is allocated.
What this means for users
Section titled “What this means for users”Set maxPriorityFeePerGas to zero. A tip is not rejected, but it buys nothing —
no position, no inclusion priority, no latency — so paying one is a straight
loss.
Set maxFeePerGas high enough to cover the base fee for as long as you want the
transaction to remain valid. That is the only fee decision there is.
Most tooling reads eth_maxPriorityFeePerGas and therefore does the right thing
automatically. Tooling with a hardcoded tip does not.
See also
Section titled “See also”- Fees and ordering — the practical view.
- Consensus and the Engine API — why ordering happens where it does.