The Impossibility of Perfect Fairness in Transaction Ordering

Why perfect fairness cannot hold in asynchronous networks, and how different blockchains adopt different relaxations to fairness.

Consensus guarantees today, focus on two properties: Consistency and Liveness. Consistency requires that all nodes eventually agree on the same set and sequence of transactions, while liveness ensures the system continues to process new transactions. What they do not address is whether the agreed-upon transaction order totally reflects fairness.

In public blockchains, transaction ordering has direct economic consequences. The order in which transactions execute determines who captures value and who pays the cost, particularly as validators, block builders, or sequencers can exploit their privileged role in block construction for financial gain. This practice is known as maximal extractable value (MEV) and includes the profitable frontrunning, backrunning, and sandwiching of transactions. Prima facie, there is no obvious way to prevent MEV extracting practices because block proposers hold unilateral power over transaction ordering, and no protocol rule inherently constrains how they exercise that power.

To address this, transaction order-fairness has been proposed as a third essential consensus property. A protocol is transaction order-fair if no participant can systematically bias transaction ordering beyond what objective network conditions and protocol rules imply. By limiting how much power a block proposer has to reorder transactions, fair-ordering protocols move blockchains closer to being transparent, predictable, and MEV-resistant.

However, even this intuitive idea of fairness encounters a structural limit. In an asynchronous distributed system, there is no globally defined reception order because each node observes messages at different times, and no shared clock exists. Therefore, no protocol can guarantee execution strictly according to a single universal arrival sequence. This limitation follows from the basic constraints of distributed consensus under asynchronous communication, not from any particular design choice.

The most intuitive and strongest notion of fairness is called Receive-Order-Fairness (ROF). It simply means “first-come, first-served.” ROF dictates that if most nodes receive transaction A before transaction B, then A should be processed before B.

That sounds simple and fair. However, the problem is that nodes do not all see transactions at the exact same time. Messages travel at different speeds. Some computers might receive A first. Others might receive B first. Because of this, it is impossible to guarantee perfect “first-come, first-served” fairness unless every node can communicate instantly with no delays. In real networks, that never happens.

There is also a deeper problem called the Condorcet paradox. This idea comes from voting theory. It shows that even when each person (or node in this case) has a clear and consistent order in their own mind, the group as a whole can end up with a loop that makes no sense.

This produces a majority preference cycle (A→B→C→A), meaning no single ordering satisfies the majority view across all pairs. The network cannot construct one sequence that matches what most nodes observed first.

Because perfect ROF is unachievable under these conditions, practical systems adopt some weaker fairness guarantees as outlined in the sections below.

Hedera, which employs the hashgraph algorithm, approaches the fairness problem through a directed acyclic graph (DAG) of cryptographically linked events. It is a leaderless consensus algorithm that operates in a fully asynchronous setting and achieves Asynchronous Byzantine Fault Tolerant (aBFT). Under this model, honest nodes eventually reach agreement on the same transaction log even under unbounded message delays. Consensus ordering emerges from network-wide observation through a virtual voting process: the order is calculated collectively by nodes rather than assigned by a designated block producer.

When a node receives a transaction, it packages it into a message called an event and gossips it to peers. When another node creates a subsequent event, it records the hash of the events it has already seen and digitally signs the new event. This provides cryptographic proof that the node had seen prior events before signing the new one. The hashgraph, therefore, enforces causal order: once a node publishes an event, the ancestry embedded in that event proves which transactions preceded it.