Ordering, finality and fairness

A fair market needs one agreed order of events that nobody can change afterwards. The two failures are front-running, trading ahead of an order seen before it executes, and reversal, a reported result undone later. On Hyperliquid, consensus and the block proposer decide the order, in public.

Say you rest a bid and send a cancel at the same moment a taker sends an IOC sell. The taker can pay for time: 2 bps of IOC priority (p = 20000) buys about 90 ms on mainnet and costs 2 USDC worth of HYPE on a 10,000 USDC fill, burned. Your cancel still almost always executes first, because all cancels go before all immediately executable orders.

One ordering, final on commit

The docs’ design principle is one consistent order of transactions, achieved through HyperBFT. All honest nodes agree on the ordered list of committed rounds, and HyperCore and the HyperEVM both execute from it. Block height rises only on rounds with at least one transaction, and the first L1 block in each block interval produces a HyperEVM block.

Every HyperCore order, cancel, trade and liquidation has one-block finality, per the docs. Commit usually takes 2 pipelined blocks, counted inside end-to-end latency. The API answers only after commit: no confirmations to count.

Finality is conditional on more than 2/3 of stake being honest. The docs say there is currently no automatic slashing.

Cancels run before GTC and IOC orders

One consensus batch. The protocol sorts actions into three groups and keeps the proposer's order inside each group. A block usually holds 1 or 2 batches.

Inside each consensus batch, actions are sorted into three groups:

1. Actions that send no GTC or IOC order to any book, such as ALO orders and transfers.
2. Cancels.
3. Actions that send at least one GTC or IOC order. A modify is grouped by the new order it places.

Per the latency guide, cancels and ALO orders sent at time t almost always execute before GTC and IOC orders sent at t, a preference spanning several blocks.

Priority fees buy position

The mempool is sorted by effective time, not raw arrival:

effective_time = arrival_time + f(action, priority_fee)
f is strictly decreasing in priority_fee, and 0 for prioritised actions such as cancels
priority rate = p / 100000000

• IOC priority buys time linearly up to 8 bps. Above that it only breaks ties, highest fee first, among qualifying IOC orders the proposer would execute in the same 70 ms window.
• ALO priority does not move a transaction in the mempool. It reorders by fee the orders placed at a price level in the last 400 ms, and is charged at placement on resting notional, whether or not the order fills.
• Gossip priority is per hop. It helps only if the IP on chain exactly matches the IP the sending peer sees, and each node along the way may or may not respect it.

The official docs differ

The docs say CoreWriter order actions are delayed a few seconds, to remove any latency advantage from bypassing the L1 mempool through the HyperEVM. Measured on mainnet, they landed 0.35 to 0.51 s after their HyperEVM block (n=52); only vault transfers were delayed, 4.05 to 4.10 s (n=6).

What the rules protect, and what they leave open

The rules protect	The rules leave open
One ordering, final on commit. No single party can reorder a result reported to you.	Pending transactions are visible. A non-validating node can stream them before execution, which the docs list as a way to predict the sequence; a paid gossip priority auction sells earlier delivery to specific IP addresses.
Cancels beat takers sent at the same time.	Time can be bought. A later IOC order with a higher fee can go ahead of an earlier one; the docs’ example sorts three orders in reverse order of arrival.
Paying for position does not pay the proposer. HyperCore order and gossip priority fees are burned; on the HyperEVM, priority fees are burned as well as base fees, unlike most EVM chains.	The proposer orders each group.

The docs never name MEV or claim front-running is impossible, and nothing here measures it on mainnet.

The numbers

Parameter	Value
Commit quorum	more than 2/3 of stake
Finality	1 block, per the docs
Time to commit	usually 2 blocks, pipelined
Consensus batches per block	usually 1 to 2
Priority tie-break window	70 ms, which the docs say usually corresponds to 1 block
IOC priority, linear range	0 to 8 bps (p 0 to 80,000)
IOC priority, effect	about 45 ms per 1 bp, mainnet
IOC priority, maximum rate	100%
ALO priority window	400 ms
Gossip priority, effect	about 25 ms per auction slot, mainnet
Split client blocks	reads of inputs 70 to 150 ms earlier
Predictable ordering	send-time variation under 10 ms
Validator epoch	100,000 rounds, about 90 minutes on mainnet

Trading under these rules

• Quote with ALO and pull with cancels.
• IOC priority is charged as a fraction of filled notional, from your undelegated staking balance, converted to HYPE at the spot mark price, and burned.
• Assume anyone with a node sees your order just before it executes, and your resting orders always.

Setting priority from code

Priority is set on the order action’s grouping field; p = 80000 is 8 basis points (orders array left empty here):

{ "type": "order", "orders": [], "grouping": { "p": 80000 } }

• Priority grouping needs every order on a non-outcome asset, and all IOC or all non-reduce-only ALO.
• The IOC priority fee paid appears as priorityGas in the user_fills files a node writes.
• Split client blocks from your own node predict the sequence before execution. They carry inputs only, not results.

For the fee rules in full, see Priority fees; for these rules as strategy, see Latency, priority and infrastructure.