Fee-blind ordering

On Frost a priority fee buys nothing. eth_maxPriorityFeePerGas returns zero, the EIP-1559 base fee is the whole fee market, and a transaction’s position in a block is fixed by consensus before anything in the system has read what it pays. This page explains where that property comes from, by contrasting how Ethereum and Frost each decide the order of transactions.

How Ethereum orders a block

Ethereum divides time into 12-second slots and assigns each slot to one validator, chosen pseudo-randomly in advance. For that slot the proposer has sole authority over the block: which transactions it contains, and in what order. Nothing in the protocol constrains those choices beyond validity.

Because the proposer can read every transaction’s fee fields, and because the priority fee is paid to the proposer, the natural strategy is to sort by what each transaction pays. In practice almost every proposer outsources this through MEV-Boost: specialised builders assemble complete blocks, bid for the right to have theirs proposed, and win by extracting the most value from the ordering. The priority fee is a bid for position in that auction, and anyone can place one.

That is the mechanism behind the familiar attacks. A sandwich needs one transaction placed immediately before a target and another immediately after — two positions, both purchased. Frontrunning is buying the position ahead of a transaction the attacker has seen in the mempool. Fee-based censorship is outbidding a transaction until it never fits. All three depend on a single party controlling the order and being willing to sell it.

How Frost orders a block

Frost’s consensus layer is Mysticeti, a DAG-based Byzantine fault tolerant protocol taken from the Sui codebase. It differs from Ethereum’s model in three places, and each removes a piece of the machinery above.

Every validator proposes, every round. There is no slot leader. Consensus proceeds in rounds, and in each round every validator broadcasts a block containing the transactions it has received, together with references to the blocks it has seen from other validators in the previous round — at least two-thirds of the committee by stake. The result is a directed acyclic graph that all honest validators converge on. A transaction enters the DAG through whichever validator’s ingress accepted it, in that validator’s next block. No single validator decides what the network as a whole includes.

The order is computed from the graph, not chosen. Each round has a designated leader block, taken from a schedule. Its only role is to anchor a commit: once enough blocks in the following rounds support it — a pattern every validator reads off its own copy of the DAG, with no further round of voting — the leader and its entire causal history commit together: every not-yet-committed block it references, directly or transitively. That set of blocks is then linearised by one fixed rule: sort by round, then by validator index. Transactions inside a block keep the order their proposer listed them in. The leader does not choose the order of the blocks it anchors, and its own block sorts by the same rule as everyone else’s.

Consensus never reads a fee. To the consensus layer a transaction is an opaque byte string. It does not decode the payload, does not run the EVM, and has no field to sort by. Fee-blindness is therefore not a policy that validators follow and could stop following; it is the absence of the information a policy would need.

Once consensus commits an ordered list, the execution layer’s job is to reproduce it. The driver hands the committed list to the execution layer over a forced-transaction profile of the Engine API, the execution layer refuses to build a block from its own mempool, and the transactions execute in the committed order — first in, first out. There is no point in the pipeline at which a fee could move a position.

The two pages behind this are Consensus and blocks, on what the DAG does, and Consensus and the Engine API, on why the execution layer is not allowed to choose.

Side by side

	Ethereum	Frost
Who proposes	One validator per 12-second slot	Every validator, every round
Who orders	The proposer — in practice a builder it sells the slot to	A fixed rule over the DAG: round, then validator index
Can the orderer read fees?	Yes	No; consensus sees opaque bytes
Does a priority fee buy position?	Yes; it is the bid	No; eth_maxPriorityFeePerGas returns 0
Can a block be reorganised after inclusion?	Until finality, roughly 13 minutes later	No; committed is final
Fee market	Base fee plus priority-fee auction	Base fee only

What it does not remove

Being precise about the limits matters, because “MEV-resistant” is often claimed well beyond what a mechanism delivers.

Ordering still exists, so a race still exists: a transaction that reaches a validator earlier lands earlier, and low-latency infrastructure still helps. Validators still see transactions before they are committed; fee-blindness encrypts nothing. Application-level extractable value is untouched: a DEX design that lets an observer profit from a pending trade still does, if the observer can act in time. And no consensus rule prevents someone from arranging position out of band with a validator.

What Frost removes is the in-protocol market for position — the auction, and the single seller who runs it. The Design section’s Fee-blind ordering page treats these limits in more depth.

For users

Set maxPriorityFeePerGas to zero. A tip is not rejected, and it is charged: the post-quantum transfer in block 132,306 used as the worked example on the Post-quantum accounts page paid a 1 gwei tip on top of an 8 wei base fee, and received nothing for it. Set maxFeePerGas high enough to cover the base fee for as long as the transaction should stay valid. That is the only fee decision there is.

Most tooling reads eth_maxPriorityFeePerGas and does the right thing automatically; the Frost SDKs default the tip to zero explicitly. Tooling with a hardcoded tip pays it for nothing.

Next

• Fees and ordering — the practical view: base fee behaviour, gas limits, and paying for someone else.
• Consensus and blocks — the DAG, block cadence, finality, and post-quantum block signatures.
• Fee-blind ordering — what it eliminates and what it deliberately does not.