Priority fees and the activation fee

Being early means reading blocks and mempool transactions first, or landing orders first, and both can be bought. The docs present priority fees as a way for market makers to focus on strategy instead of hyper-optimising infrastructure.

Say you send a 100,000 USDC IOC with "grouping": {"p": 10000}, a 1 bp rate. Per the docs’ mainnet figure, it cuts about 45 ms of latency. If it fills, you pay 10 USDC, charged in HYPE.

Both fees are burned, and neither overrides the protocol’s ordering: whatever the fee, all cancels go before all immediately executable orders.

Gossip priority buys an earlier read

Gossip priority lets a node order its peers by an on-chain auction, and the docs say the foundation non-validator opts in. It applies equally to all mempool-stream data, including split and normal client blocks carrying responses. It does nothing for orders, just as order priority does nothing for market data.

• 2 independent Dutch auctions, one per slot (schedule and prices in the numbers). Each result applies for the duration of the next auction.
• Lower slots are strictly prioritised, and slots are not additive: an IP that wins several ranks by its lowest.
• The winning IP must exactly match the IP the sending peer sees. Behind a chain of nodes, each hop respects the ordering or not, per its configuration.
• Any address may bid for any IP.

{"type": "gossipPriorityBid", "slotId": 0, "ip": "1.2.3.4", "maxGas": 100000000}

maxGas is in HYPE wei, so 100000000 caps the bid at 1 HYPE. {"type": "gossipPriorityAuctionStatus"} returns the winners in force and the live auctions; fees paid are in a node’s replica_cmds files.

Order priority buys time or queue position

Order priority is bought through the grouping field of an order action (orders):

{"type": "order", "orders": [{"a": 4, "b": true, "p": "1100", "s": "0.2", "r": false, "t": {"limit": {"tif": "Ioc"}}}], "grouping": {"p": 10000}}

• Rate: p / 100000000, so p: 10000 is 1 bp.
• Eligible only if every order is on a non-outcome asset, so HIP-4 books can’t be prioritised, and either all are Ioc or all are non-reduce-only Alo.
• Charged from the undelegated staking balance on filled notional (IOC) or resting notional (ALO), converted to HYPE at the spot mark price. In USDC: order_price * order_sz * rate.

IOC priority buys time. The mempool sorts transactions by

effective_time = arrival_time + f(action, priority_fee)

where f is strictly decreasing in the fee and zero for prioritised actions such as cancels. Up to 8 bps (p = 80000) the effect is linear, about 45 ms per bp. Block boundaries do not matter for a given action type: transactions within a block are still sorted by effective_time.

Above 8 bps (up to 100 per cent) no more time is bought: IOC orders at 8 bps or more that the proposer would execute in the same 70 ms unix-time bucket sort by decreasing fee. Docs’ example: arrivals at T, T + 30 ms and T + 69 ms paying 8, 9 and 10 bps execute in reverse order.

ALO priority buys queue position. ALO orders pass the mempool first in, first out, about as fast as cancels, whatever the fee. After execution, each price level’s tail (orders placed within the last 400 ms) is sorted by decreasing rate, each new order comparing against it as it lands: a continuous window, not buckets. The fee is deducted at placement, even if the order never fills or is cancelled a moment later.

The docs' ALO example. A higher fee only reorders orders that are still inside the 400 ms tail, so B keeps a place that C, paying more, cannot take.

In node data, the IOC fee paid per fill is priorityGas in the user_fills file; the ALO ordering can be rebuilt from insertBefore on new-order entries in the raw book diffs.

What this means for you. Above 8 bps only ties within 70 ms are decided, so 20 bps pays off only against others at 8 bps or more. A maker who reprices often pays ALO priority on every placement.

Client libraries differ from the docs

One SDK documents p in units of 1e-7 of notional, calls 80,000 (8 bps) the maximum and allows IOC only. Its 80,000 is 8 bps only under the docs’ unit, p / 100000000: scaling a rate by 1e7 sends a tenth of the intended rate. The docs allow up to 100 per cent and all-ALO batches; follow the docs.

A new account costs 1 quote token to activate

The first transaction naming a new HyperCore account as destination costs 1 quote token (1 USDC, 1 USDT), whatever asset is sent, once per account (transfers). Node data records it as an AccountActivationGas ledger entry with amount and token.

Measured	fee recorded
Testnet (controlled): first send to a fresh address	1.0
Testnet: second send to the same address	0.0
Testnet: first send to a second fresh address	1.0
Mainnet: sends to two freshly deployed contracts, sender’s ledger	"1.0" each
Mainnet: payout to an existing account	"0.0"

Unactivated accounts can’t send CoreWriter actions. CoreWriter never reverts, so a contract acting from a fresh address silently does nothing until its address receives a HyperCore transaction; the docs suggest deployers send it themselves. The account must already exist when the EVM block that emits its first CoreWriter action is built.

Separately, the API refuses a never-funded address: Must deposit before performing actions.

The numbers

Item	Value
Gossip auctions	2 slots, Dutch, on a shared 3-minute schedule
Gossip auction start	10 x the slot’s previous winning price
Gossip minimum price	0.1 HYPE
maxGas unit	1e-8 HYPE
Gossip effect (mainnet, per docs)	about 25 ms per slot
Order priority rate	p / 100000000 of notional
IOC linear range	0 to 8 bps (p 0 to 80000)
IOC effect (mainnet, per docs)	about 45 ms per 1 bp
Maximum rate	100%
IOC tie-break bucket	70 ms of unix time, for orders at 8 bps or more
ALO priority window	400 ms
Priority fees paid from	undelegated staking balance (order); spot balance (gossip)
Activation fee	1 quote token, once per new account

Running priority from a bot

• Fund priority with cDeposit into the undelegated staking balance (not spot or perps), without a tokenDelegate (staking).
• Split batches by type: one mixed or ineligible order disqualifies the whole batch.
• Bid with the IP the upstream peer sees; behind NAT or a load balancer that is not the machine’s own.
• Poll gossipPriorityAuctionStatus before bidding: the start price follows the last winning price, so a slot’s cost changes every 3 minutes.
• Compare priorityGas from node fills against the latency gained.

Before paying for priority, see Optimising latency for what to fix in code. For priority as a trading decision, see Latency, priority and infrastructure.