This post summarizes our recent paper, which proposes a protocol-level rule that lets applications express preferences over how their transactions should be ordered, without giving up composability.
Blockchains promise a globally integrated, decentralized financial system: one shared ledger where every application can build on, trade with, and plug into every other. But that shared ledger comes with shared rules, and one rule in particular, how transactions are ordered, has become a binding constraint on what applications can be built.
Many applications require a specific ordering of transactions: PropAMMs need oracle updates to execute before swaps, central limit order book markets (like Hyperliquid) may want cancellations of limit orders to execute before market orders, and an on-chain auction may want the highest bid to execute first. Today, deploying an application with ordering requirements is challenging: either those requirements happen to be compatible with the blockchain's ordering logic (e.g., PropAMMs and the Jito sequencer on Solana), or the application is forced to create its own chain (e.g., Hyperliquid), giving up composability.
This post describes a way out of that tradeoff: an ordering rule, which we call unanimity override, that lets applications express ordering preferences directly on a shared chain. The post also shows exactly which of those preferences can be guaranteed even against a powerful attacker.
💡 Summary
The intuition behind unanimity override is that whenever the applications with a stake in a pair of transactions agree on their order, the protocol respects that agreement. Unanimity, however, does not generate a complete order: there may be transactions that no application ranks, and applications may disagree over others. Hence, a default order (i.e., priority fee) is used to complete the unanimity order.
This naive approach, however, has a problem: the unanimity ranking can have cycles, which need to be broken by a fallback that demotes some transactions. This fallback rule is also the main attack vector: an attacker may try to overrule the applications' unanimous preferences by inserting transactions and applications, so as to create cycles and trigger the fallback.
However, under the specific fallback rule proposed in the paper (and discussed below), two guarantees hold even against an attacker who controls the block's default order, deploys applications, and injects transactions (but cannot censor). (1) All transactions that interact with a single application that expressed preferences are ordered according to that application's preferences, even when they also interact with other applications that did not express preferences. (2) Gatedtransactions, that is, transactions that cannot be outranked in the unanimity order by any transaction crafted by an attacker, always execute as the applications unanimously prefer, even when they touch many applications.
Oracle updates and cancellations of limit orders are gated, because the corresponding application will never rank an attacker-crafted transaction strictly higher than those transactions. They are therefore protected by the second guarantee: a transaction that performs cancellations across multiple markets (and perhaps interacts with other applications with no ordering preferences) is guaranteed to execute before market orders, and similarly for oracle updates. On-chain auctions (and similar designs, like AMMs that auction off the right to perform the first swap) are protected by the first guarantee: as long as bidders do not embed their bids in complex transactions that touch multiple applications that expressed preferences, the application always ranks bids correctly.
Finally, the first guarantee implies that unanimity override extends rollup sequencing guarantees. A rollup's transactions are, by construction, confined to the rollup; they cannot touch other applications on the chain. Unanimity override orders such transactions exactly according to the rollup's preferences. But it goes further: the guarantee extends to transactions that also interact with applications that have no ordering preferences on the same chain. This matters, for example, for bridging. Non-native assets are represented on chain by smart contracts with no ordering preferences of their own. Because a rollup cannot interact with these contracts directly, assets must be bridged (i.e., locked on the base chain and reissued on the rollup), and bridges have been a persistent source of hacks. Under unanimity override, an application with rollup-like sequencing guarantees lives directly on the base chain, where its transactions can touch the asset contracts natively. No bridge is needed.
Unanimity Override in Detail
Applications can declare ordering preferences over the transactions that interact with them. Transactions declare which applications (among those that declared preferences) they intend to interact with. For each pair of transactions, the protocol looks at the applications both transactions interact with; if all of them agree on the pair's order, that order is respected. A default order (for example, the priority fee each transaction pays) then fills in the remaining comparisons to recover a complete execution order.
As an example, suppose there are two applications and three transactions a, b, and c. Application 1 would want the execution order to be: a, b, c. Application 2 would want the execution order to be: a, c, b. That is, both applications agree that a should execute first, but disagree on the ordering of the other two. The unanimity ranking is a before b, and a before c, and there is no unanimity ranking between b and c (see Figure 1). The default order is therefore used to rank b and c.
The Hard Part: Cycles
The main problem with the above approach is that the unanimity relation can have cycles. Again, consider an example with three applications and three transactions, but now each transaction interacts with two of the applications: Application 1 interacts with a and b, and wants a to execute before b; Application 2 interacts with b and c, and wants b before c; Application 3 interacts with c and a, and wants c before a. Each pairwise comparison is unanimous, yet together the three comparisons form the cycle a before b before c before a, which no execution order can satisfy (see Figure 2).
The mechanism for breaking cycles is where the design work lies. In the paper, we show that cycles can arise only when at least two transactions interact with multiple opinionated applications, that is, applications that have expressed preferences (we call these transactions multi-opinion; a transaction that interacts with exactly one opinionated application is single-opinion). For this reason, we propose to break cycles by demoting one or more of the multi-opinion transactions: the protocol removes a demoted transaction's unanimity comparisons with the others in its cycle and places it after them, with the default order ranking multiple demoted transactions among themselves. The demoted transactions are selected using the default order: in the example above, if c ranks lowest in the default order, the fallback demotes c: its comparisons with a and b are removed, and c is placed after both. The surviving comparison (a before b) then yields the execution order a, b, c (see Figure 3).
Demotion resolves the cycle, but it overrides the applications' preferences for the demoted transactions. And that opens an attack surface: an adversary can inject transactions specifically to create cycles and manipulate the resulting order.
Here is the canonical attack. Two honest applications, 1 and 2, both rank transaction x above transaction y, so absent any attack, x executes before y. To reverse this, the attacker deploys its own application M and injects two transactions: w₁, which interacts with Application 1 and M, crafted so that Application 1 ranks it below y (for example, it pays a low fee); and w₂, which interacts with Application 2 and M, crafted so that Application 2 ranks it above x (for example, it pays a high fee). Since M is the only application with a stake in the pair (w₁, w₂), the attacker freely ranks w₁ above w₂. The result is the cycle x before y before w₁ before w₂ before x, built at the cost of two transactions and one application deployment. If x is multi-opinion and the default order (which the attacker may control) ranks x lowest on the cycle, the fallback demotes x: the execution order places y before x, overturning the honest applications' unanimous preference (see Figure 4).
What an Attacker Cannot Break
The main results identify which preferences are protected even against a strong adversary: one who controls the default order, deploys applications of their own, and injects arbitrary transactions. Two guarantees hold:
Guarantee 1: single-opinion transactions are safe. A transaction that interacts with only one opinionated application always executes according to that application's preferences. When two transactions interact with a given opinionated application and one of them is single-opinion, only that one application can express preferences over the pair, so the unanimity ranking coincides with its preferences, and the fallback never demotes single-opinion transactions.
Guarantee 2: gated transactions are safe. A necessary condition to place a transaction on a cycle is that the attacker can craft a transaction that outranks the target in the unanimity ranking. A transaction that cannot be outranked, for example because it is ranked first by every application it touches, is gated: it can never lie on a cycle and is never demoted. It executes in the order the applications unanimously prefer, no matter how many applications it interacts with.
These guarantees map directly back to the motivating applications. Oracle updates and cancellations — including cancellations that span many markets — are gated because nothing an attacker can craft ranks strictly above them. Auctions, and AMMs that rank swaps by fee, rest on the first guarantee together with a simple sender incentive: route your transaction through a single opinionated application and its ordering is safe.
No cheap front running
The above results are about how an attacker cannot overturn the applications' unanimous preferences. However, users also have preferences. In particular, one possible concern is that unanimity override makes it easier to attack a transaction over which no application has expressed preferences, and which is therefore not covered by the above guarantees.
For example, suppose the block contains a swap on a traditional AMM, which did not express any preference. An attacker could deploy an opinionated application and some transactions, so as to create a chain of transactions linked by unanimity comparisons. This chain must then be merged with the swap, which is isolated (it has no unanimity comparison with any other transaction), and depending on the merging rule, the attacker may be able to front-run it. The concern is that unanimity override makes it cheaper to front-run isolated transactions relative to the baseline of priority-fee ordering.
This concern is addressed by how the unanimity relation (after cycles are removed) is completed into a full execution order: via Kahn's topological-sort algorithm, which builds the block from the top. Call a transaction available if it has not yet been scheduled and no unscheduled transaction is ranked above it in this relation. At each step, the algorithm schedules the available transaction with the highest priority fee; scheduling a transaction may make new transactions available, and the algorithm repeats until every transaction is scheduled.
As an example, suppose the unanimity relation contains x₁ before x₂ and x₁ before x₃, while x₄ has no unanimity comparison with anything, and the fees rank x₁ > x₂ > x₄ > x₃. At the first step of Kahn’s algorithm, x₁ and x₄ are available, and x₁ pays more, so it is scheduled first. Scheduling x₁ makes x₂ and x₃ available, and x₂ now outbids both x₃and x₄. The execution order is x₁, x₂, x₄, x₃. Note the position of x₄, the transaction with no unanimity comparisons: it executes after x₁ and x₂, which pay more, and before x₃, which pays less. Its position in the block is determined by fees alone.
The key property is that a transaction over which no application has expressed preferences is available from the very first step of Kahn's algorithm: it executes as soon as its fee is the highest among the available transactions. Hence, another transaction executes before it only if that transaction pays a strictly higher priority fee. Outbidding is therefore necessary to front-run such a transaction, exactly as under pure priority-fee ordering.
Initial implementation considerations
How could unanimity override be implemented on a real chain? The design is still at an early stage, but a possibility is to identify a set of special applications: those allowed to express ordering preferences. A transaction that wants to interact with one or more of these applications must declare them upfront, in a dedicated field of the transaction payload (similar to an access list, but restricted to preference-expressing applications). The declaration also includes the function calls and any values needed to compute the applications’ preferences. This information is then used to compute the execution order before transactions are executed.
An interesting design consideration is what to do with transactions that either misspecify their declared list or do not declare one at all. For example, a transaction that declares that it intends to access a special application but then tries to access another special application not in its initial list should probably revert. A transaction that specifies nothing in the list (for example, a legacy type of transaction), on the other hand, may still execute even if it accesses some special applications, but at the bottom of the block: under Kahn's algorithm, it would be treated like an isolated transaction with a very low priority fee.
Note that this design involves a tradeoff. The no-cheap-front-running guarantee discussed above relies on transactions without application preferences competing by their actual fee from the first step of Kahn's algorithm. Here, instead, undeclared transactions execute after every declared transaction regardless of the fee they pay, so a declared transaction can execute before them without outbidding them. For many transactions this probably does not matter: a plain transfer is indifferent to executing at the bottom of the block. But it may matter for some. A fee-sensitive transaction, such as a swap on an application without ordering preferences, loses the priority-fee protection unless the design lets it declare an explicit empty list.
The specific design is still under active discussion: feedback and comments are most welcome!
Conclusion
Composability is one of the main economic benefits of blockchains, but it has so far forced a choice on application designers: stay on the shared chain and accept its ordering rule, or acquire sequencing rights by leaving for an app-chain or rollup and give up integration with everything else. Unanimity override overcomes this stark tradeoff: a protocol can respect applications' ordering preferences wherever they agree, break the inevitable cycles in a way that protects the transactions that matter most, and give precise, adversarially robust guarantees about which preferences survive.
Check out the paper for the full analysis, including the formal model, the threat model and proofs of the guarantees, and a generalization of the unanimity rule to any Paretian aggregation rule.
