Why perfect fairness in transaction ordering is impossible

Blockchain consensus today rests on two pillars: consistency and liveness. Consistency means all nodes eventually agree on the same transaction sequence. Liveness means the system keeps processing new transactions. Neither one addresses whether that final order is actually fair.

In public blockchains, ordering has direct economic consequences. Validators, block builders, and sequencers can exploit their position to extract value through front-running, back-running, and sandwiching — collectively known as maximal extractable value (MEV). Because block proposers have unilateral control over ordering, no protocol rule inherently stops them.

Transaction order-fairness has been proposed as a third consensus property. A fair protocol would prevent any participant from systematically biasing order beyond what network conditions and protocol rules dictate. But even this seemingly intuitive idea hits a hard wall.

The problem starts with asynchrony. In a distributed system, there’s no global clock. Each node sees messages at different times, so there’s no universally agreed-upon “arrival order.” Without that, you can’t enforce first-come-first-served fairness — ever.

Then there’s the Condorcet paradox from voting theory. Even when each node has a consistent view, the group can end up with a circular preference: most nodes see transaction A before B, B before C, but C before A. No single ordering satisfies the majority across all pairs.

Practical systems therefore adopt weaker guarantees. Hedera’s hashgraph, for instance, uses a DAG structure with median timestamps and virtual voting to approach fairness for causally linked events, though concurrent events can still hit the Condorcet problem.

The takeaway: perfect receive-order-fairness is structurally impossible in asynchronous networks. The best protocols can do is limit how much power block proposers have to reorder transactions — moving closer to fairness without ever fully reaching it.