MEV without the noise

MEV is the value a block producer can capture by choosing which transactions go into a block and in what order: arbitrage, liquidations, sandwiching a user's swap. Any ordering choice is worth something to someone. The question for an operator is who makes that choice and whether it can be checked.

Ethereum: proposers outsource the block

On Ethereum most proposers run MEV-Boost. The validator does not build its own block. Builders assemble blocks and bid for inclusion, relays pass the bids along, and the proposer signs the header of the highest bid without seeing its contents first.

This separates the validator from the ordering, but it moves trust elsewhere:

• Relays can withhold a payload after the proposer signs, which costs the proposer the slot.
• Relays differ in policy. Some filter transactions from sanctioned addresses, some do not. The relays a validator enables decide which blocks it can propose.
• A small number of builders produce most blocks, so ordering power is concentrated even when the validator set is not.

An operator on Ethereum should publish which relays it uses and why. That is the part delegators can actually verify.

Cosmos: ordering belongs to the application

In Cosmos SDK chains the picture is different. Since ABCI++ (CometBFT 0.38 and SDK 0.47 onward), PrepareProposal lets the application define how the proposer builds a block, and ProcessProposal lets every other validator reject a block that does not follow those rules.

That means ordering policy is a property of the chain, decided in code and through governance, not something each validator chooses privately. Examples include lane-based block building, in-protocol auctions for top-of-block space, and Osmosis ProtoRev, where backrun arbitrage is done by the protocol and the profit goes to the community pool instead of a searcher.

If a validator runs a modified binary to reorder transactions, other validators can reject its proposals when the chain enforces ordering in ProcessProposal. Where the chain does not enforce it, a modified proposer can still get away with it, which is why the enforcement matters more than promises.

Our position

• We run the binary the chain releases, built from tagged source, with no patches to mempool or proposal logic.
• No private order flow, no side deals with searchers, no sandwiching.
• Where a chain adopts an ordering mechanism through governance, we run it as specified.
• When we vote on such proposals, we look at two things: whether the revenue goes to stakers or the community pool rather than a third party, and whether the rules are enforced by other validators rather than trusted.

"MEV aware" on this site means exactly that: we know how blocks are built on each chain we validate, and we do not change it for our own benefit.