Technical Summary: Ordering by Unanimity

1. Problem Statement

Blockchain applications often possess specific preferences regarding the execution order of transactions to function correctly. Examples include automated market makers (AMMs) requiring oracle price updates to precede swaps, order-book exchanges needing cancellations to execute before market orders, and on-chain auctions requiring bids to be processed from highest to lowest. Currently, transaction ordering is determined by the underlying blockchain (e.g., via block proposers or priority fees), which may not align with these application-specific requirements.

Existing solutions to enforce ordering often sacrifice composability—the ability of applications to interact freely on a shared ledger. For instance, PropAMMs (oracle-dependent AMMs) are feasible on Solana due to its specific ordering rules but difficult to implement elsewhere; exchanges like Hyperliquid have created isolated chains to secure their ordering logic; and rollups achieve ordering control only by isolating transactions from the base layer. This paper addresses the challenge of granting applications sequencing rights without fragmenting the blockchain or sacrificing composability.

2. Methodology: Unanimity Override

The paper proposes a protocol-level ordering rule called unanimity override. The core intuition is that if all applications involved in a pair of transactions agree on their relative order, the protocol should respect that agreement. If applications disagree or if the resulting preferences form a cycle, a fallback mechanism resolves the conflict.

The Mechanism

The algorithm operates in two primary steps:

1. Unanimity Relation ($\succ_u$): A directed relation is constructed where transaction $x_i \succ_u x_j$ if and only if every application that interacts with both $x_i$ and $x_j$ ranks $x_i$ above $x_j$, and at least one application strictly prefers $x_i$.

   • This relation is generally incomplete (some pairs are unranked) and non-transitive (cycles can form).
   • Cycles arise specifically when transactions interact with multiple "opinionated" applications (applications that have expressed strict preferences).

2. Cycle Breaking (Fallback): To recover a total execution order, the protocol must break cycles. The paper introduces a demotion rule:

   • Cyclic Components: The algorithm identifies maximal strongly connected components (cycles) in the unanimity graph.
   • Demotion: Within a cyclic component, the rule selects a set of transactions to "demote." Crucially, only multi-opinion transactions (those interacting with $\ge 2$ opinionated applications) are eligible for demotion.
   • Selection Logic: The fallback iteratively demotes the multi-opinion transaction with the lowest "default order" value (e.g., lowest priority fee) until the component becomes acyclic.
   • Repaired Relation ($\tilde{\succ}_u$): Demoted transactions are removed from the unanimity comparisons within the cycle and placed below all non-demoted transactions in that component. Their relative order is determined by the default order.
   • Completion: The resulting acyclic partial order is extended to a total execution order ($\succ_e$) using a reverse-Kahn topological sort, using the default order to break ties within layers.

3. Threat Model

The analysis assumes a strong form of censorship resistance (transactions cannot be withheld). The attacker is modeled as a player who can:

• Deploy new applications with arbitrary preferences.
• Inject transactions into the block with specific attributes (e.g., fee, target applications).
• Control the default order ($U_d$) in the worst-case scenario (e.g., acting as the block proposer).
• The attacker cannot modify honest transactions or change the preferences of existing honest applications.

4. Key Results and Guarantees

The paper derives two primary guarantees that hold against any feasible attacker strategy, including those controlling the default order:

Guarantee 1: The Single-Opinion Guarantee

If a transaction $x$ interacts with exactly one opinionated application (a single-opinion transaction), and that application strictly prefers $x$ over another transaction $y$ (which may interact with other applications), then $x$ will execute before $y$.

• Reasoning: Since $x$ is single-opinion, no other application can express a preference over the pair $(x, y)$. Thus, the unanimity ranking coincides with the single application's preference. Because the fallback rule never demotes single-opinion transactions, this preference is preserved in the final execution order.
• Significance: This extends the guarantees of isolated rollups to the base layer. Applications can secure their critical transactions (like oracle updates or cancellations) by ensuring they interact with only that specific application, even if other parts of the transaction touch non-opinionated contracts.

Guarantee 2: The Gated Region Guarantee

There exists a set of transactions, $X^*$, termed the gated region, which is protected against reordering. A transaction belongs to $X^*$ if:

1. No transaction outside $X^*$ (whether pre-existing or injectable by the attacker) can be unanimously ranked above it.
2. The subgraph of unanimity relations restricted to $X^*$ is acyclic.

• Result: No member of $X^*$ is ever demoted. Consequently, if a transaction in $X^*$ is unanimously ranked above another, it executes first, regardless of the attacker's ability to inject transactions or control the default order.
• Application: This protects transactions like oracle updates from designated addresses or cancellations that are ranked highest by all relevant markets, provided the "gate" (the set of transactions that could outrank them) cannot be breached by the attacker.

Vulnerability: Multi-Opinion Transactions

The paper identifies that multi-opinion transactions (interacting with $\ge 2$ opinionated applications) are the only ones vulnerable to reordering attacks. An attacker can construct a cycle involving a target multi-opinion transaction and inject transactions to force the fallback to demote it. However, the paper notes that if the target is a single-opinion transaction, such an attack is impossible.

5. Comparison with Benchmarks

• Vs. Attacker-Controlled Default Order: Unanimity override strictly reduces the set of reversible transaction pairs compared to a system where the attacker has full control over the block order.
• Vs. Priority-Fee Ordering: The comparison is nuanced. Unanimity override protects single-opinion and gated transactions regardless of fees. However, for unprotected multi-opinion transactions, the cost of an attack (e.g., front-running) may be higher or lower depending on the specific topology of the cycle and the fee structure. The paper notes that griefing attacks (reordering honest transactions to damage a competitor) are possible under unanimity override but impossible under pure priority-fee ordering.

6. Significance and Scope

The paper claims to provide a mechanism that expands the application design space on blockchains without sacrificing composability.

• Preservation of Guarantees: It allows applications to enforce ordering preferences (like oracle updates before swaps or cancellations before trades) without requiring isolation on separate chains or rollups.
• Incentive Alignment: The mechanism tells senders in advance which transactions are safe. For example, in an on-chain auction, bidders are incentivized to keep their bids as single-opinion transactions to ensure they are not demoted, thereby ensuring the auction functions as intended.
• Theoretical Contribution: The work connects transaction ordering to social choice theory. It acknowledges that the unanimity relation is non-transitive (a consequence of Arrow's Impossibility Theorem) and proposes a specific Paretian aggregation rule that sacrifices "independence of irrelevant alternatives" to achieve a complete, acyclic execution order.

The paper concludes by noting that the definition of "interaction sets" (which applications a transaction touches) is a practical challenge. It discusses the trade-off between using declared interactions (easier to verify, but potentially over-estimating multi-opinion status) and actual interactions (stronger guarantees, but requiring a fixed-point solution for consistency). The current analysis assumes interaction sets are given.