Hyperliquid Priority Fees Explained: Gossip Auctions, Order Priority, and Latency Gains

Hyperliquid launched priority fees on mainnet in April 2026. There are two separate systems here, and they solve different problems.

The Simple Version

Gossip Priority = Pay to See First

Normally, transactions execute first and then results are shared across the network. With split_client_blocks enabled, transactions are streamed to nodes before they execute - giving you a head start measured in hundreds of milliseconds. Gossip priority controls who gets that early stream first.

You bid HYPE in a 3-minute auction (5 slots available). Win a slot, and other nodes prioritize sending transaction data to your IP before anyone else. Slot 0 sees everything first. Slot 4 sees it last. Each slot is worth roughly 10 ms.

The catch: you get raw, unconfirmed transactions. No execution results yet. You have to predict outcomes yourself - estimate fills, balances, liquidation triggers. Useful for HFT, arbitrage, and liquidation strategies where seeing the order flow early is the edge.

Order Priority = Pay to Jump the Queue

When submitting orders, you can attach a tip (up to 8 bps of your filled notional, paid in HYPE from your unstaked balance). Higher tip = your order gets matched before lower-tip orders. Think of it like surge pricing - you pay more to get picked up first.

Two important catches:

• Cancels always go first, regardless of any priority tip. So you can always get out.
• Currently only works for IOC orders on HIP-3 assets.

Why Burn the Fees Instead of Paying Validators?

If validators got the fees, they would be incentivized to reorder transactions to maximize what they collect (MEV). Burning removes that incentive entirely - the queue is just the queue, no funny business.

TL;DR: Pay HYPE to either see transaction data before others (gossip) or get your orders filled before others (order priority). Fees are burned, not paid to anyone. Cancels are always free to jump the queue.

Now for the details. The rest of this guide covers the exact API calls, what priority fees cost at different trade sizes, and when they make economic sense compared to infrastructure investment.

Two Layers in Detail

Gossip Priority: Bidding for Faster Data

"Gossip" is how Hyperliquid nodes share data peer-to-peer. When a node enables split_client_blocks: true in its gossip configuration, it streams uncommitted transactions to peers before they are executed or finalized on L1. This gives recipients a preview of incoming order flow - hundreds of milliseconds before execution results are available.

Gossip priority controls which nodes receive this early stream first. You bid in an auction, and winning nodes' IPs get transaction data delivered ahead of everyone else. This only affects reading (receiving transactions). It does not affect sending or execution order.

How the Auction Works

Five independent Dutch auctions run on a synchronized 3-minute schedule. Each auction corresponds to a priority slot (index 0-4). Lower index means higher priority - other nodes send data to slot 0 winners before slot 1, slot 1 before slot 2, and so on.

After each 3-minute cycle, every auction resets its price to 10x the previous winning bid. The minimum bid is 0.1 HYPE. If the winning bid was 0.5 HYPE, the next cycle starts at 5 HYPE and drops over the 3-minute window. This reset prevents auction prices from collapsing to the minimum.

The empirical latency effect is roughly 10 ms reduction per slot. Winning slot 0 gives you the earliest access to uncommitted transaction data across the gossip network.

API: Placing a Gossip Priority Bid

Submit a bid through the Hyperliquid API info endpoint:

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

The maxGas parameter is denominated in wei of HYPE, not HYPE units. 100000000 wei equals 0.0000001 HYPE - well below the 0.1 HYPE minimum for a winning bid. To bid 1 HYPE, set maxGas to 1000000000000000000 (1e18). Getting this unit wrong is the most common implementation mistake.

The ip field specifies which server receives the prioritized data. You can bid on behalf of any IP address, useful if you operate multiple servers or bid from a management server for a trading server.

The fee is deducted from your spot HYPE balance. Make sure you have sufficient spot HYPE funded before bidding.

API: Checking Auction Status

Query the current auction state before placing a bid to avoid overpaying or getting caught by a 10x reset:

{
  "type": "gossipPriorityAuctionStatus"
}

This returns the current winning prices and time remaining for each of the 5 slots. Use it to time your bids and gauge competition.

For full peer prioritization, your node must have ports 4001 and 4002 publicly open.

Order Priority: Paying for Execution Sequence

Order priority affects the sequencing of IOC (Immediate-Or-Cancel) orders on HIP-3 assets. When multiple IOC orders compete for the same liquidity, higher-priority orders execute first.

How Priority Grouping Works

You attach a priority grouping parameter to your order action:

{
  "grouping": {
    "p": 12345
  }
}

The rate equals p / 100,000,000, applied as a fraction of the filled notional value. At p = 10000, the rate is 1 bp (0.0001). At p = 12345, the rate is 1.2345 bps.

The maximum rate is 8 bps (p = 80,000), reduced from an initial 20 bps based on community feedback before launch.

The empirical latency effect is approximately 45 ms reduction per 1 basis point of priority fee paid. At 8 bps, that translates to a maximum of roughly 360 ms of execution priority advantage.

Fee Source and Calculation

Order priority fees are deducted from your undelegated staking balance in HYPE, converted at the spot mark price at the time of fill. This is different from gossip priority, which draws from your spot balance. If all your staked HYPE is delegated, you have zero balance available for order priority fees.

For a $100,000 notional fill at 1 bp:

Fee = $100,000 x 0.0001 = $10.00 (in HYPE equivalent)

At 8 bps (maximum):

Fee = $100,000 x 0.0008 = $80.00 (in HYPE equivalent)

The Cancel-First Guarantee

The design detail that matters most for market makers: cancel orders execute before all taker orders, regardless of priority fee. A taker paying 8 bps in priority fees still cannot front-run your cancel of a stale quote. This preserves Hyperliquid's existing ordering hierarchy:

1. Cancel orders (always first)
2. Post-only orders
3. GTC and IOC taker orders (priority fees affect ordering within this tier)

Priority fees only reorder within the taker tier. They do not break the cancel-first design that Hyperliquid introduced to reduce toxic flow by "at least 10x" compared to other platforms.

Tracking Priority Fees Paid

Check the priorityGas field in user_fills to see how much you have paid in priority fees per fill. Use this data for PnL attribution and to calibrate whether your priority fee spend is generating positive ROI.

Cost-Benefit: When Priority Fees Beat Infrastructure

No existing guide compares priority fees against the alternatives. Here is a framework.

Priority Fee Costs at Different Trade Sizes

At 1 bp, you get roughly 45 ms of execution advantage. A market maker filling $50,000 notional orders pays $5 per fill for that 45 ms. Whether that pays off depends on your edge per trade and how often that 45 ms makes the difference between getting filled and missing the opportunity.

Alternative Latency Strategies

Running your own non-validating Hyperliquid node is free but demands serious hardware: at minimum 32 CPU cores and 500 MB/s disk throughput. The --disable-output-file-buffering flag reduces local latency further. Total cost is the server itself plus operational overhead.

Co-locating servers near validators reduces network transport latency but requires identifying validator locations and maintaining infrastructure in those regions.

Dwellir's validator-adjacent order book server delivers faster order book data through managed WebSocket endpoints positioned next to a Hyperliquid validator. This is a read-side optimization - you receive market data sooner, which means your strategy reacts faster to price movements, fills, and liquidation opportunities. Dwellir does not affect order submission latency; your orders still travel through the standard API path.

These Are Complementary, Not Competing

Priority fees and infrastructure optimization target different parts of the latency stack:

• Read-side infrastructure (your own node, co-location, Dwellir managed endpoints) reduces how fast you receive market data - order book updates, fills, liquidation events. Faster reads mean your strategy sees opportunities sooner.
• Gossip priority also improves read-side latency, but at the protocol level - your node gets pre-finality data before others.
• Order priority affects write-side ordering - where your order sits in the execution queue after it reaches the matching engine.

A market maker using Dwellir's order book server sees price changes faster, enabling quicker strategy decisions. Paying 1 bp in order priority (roughly 45 ms execution improvement) then ensures those decisions execute ahead of competitors. Read speed and write priority are independent advantages - optimizing one does not help the other.

Implementation Checklist

If you are adding priority fees to an existing Hyperliquid trading bot, work through these steps in order.

1. Fund the correct HYPE balances. Gossip priority draws from your spot HYPE balance. Order priority draws from your undelegated staking HYPE balance. These are two separate pools. If your staking balance is fully delegated, order priority fees will fail silently.

2. Monitor auction status before gossip bids. Query gossipPriorityAuctionStatus before every bid. The 10x reset mechanism can spike costs dramatically if you bid right after a new cycle starts. Time your bids toward the end of the 3-minute window for lower prices, though you risk losing to earlier bidders.

3. Start order priority at 1-2 bps and benchmark. At 1 bp you get roughly 45 ms of improvement for a modest per-fill cost. Measure your fill rate improvement before scaling up to higher rates. Jumping straight to 8 bps is expensive and may not yield proportionally better results depending on your strategy.

4. Implement cancel-first logic in your strategy. Cancels always execute before takers regardless of fee. Structure your market-making logic to cancel stale quotes aggressively - the protocol guarantees your cancel will beat any taker trying to hit that quote, even if they are paying maximum priority fees.

5. Track priorityGas in user_fills for PnL attribution. Treat priority fees as a line item in your per-trade PnL. If you are paying $5 per fill in priority fees but your average edge per trade is $3, you are net negative on the priority spend.

6. Optimize your read-side latency separately. Priority fees handle write-side execution ordering. How fast you see market data is a separate problem. If you are not already using a low-latency data feed, consider running a local node (with --disable-output-file-buffering) or connecting to Dwellir's managed order book server for faster order book data. Faster reads let your strategy react sooner; priority fees ensure your reaction executes first.

How Priority Fees Fit Hyperliquid's Architecture

Priority fees make more sense in context of the system they operate within.

HyperBFT Consensus

Hyperliquid runs a custom L1 using HyperBFT consensus, derived from HotStuff. Blocks have instant finality with no reorgs - once a block finalizes, it cannot be reverted. This eliminates MEV strategies that depend on block reorganization, which is why Hyperliquid's priority fee design looks different from Ethereum's. No block builder market, no proposer-builder separation, no private mempools. Median finality is 0.2 seconds with the 99th percentile under 0.5 seconds.

HyperCore vs HyperEVM

Hyperliquid runs two execution environments on the same consensus layer:

• HyperCore is the native CLOB trading engine, processing 200,000 orders per second. Priority fees operate here.
• HyperEVM is a general-purpose EVM for smart contracts. eth_maxPriorityFeePerGas always returns zero. EVM gas uses EIP-1559-style base fees that are burned, but priority fees are not operative.

Two different execution layers, same consensus. When Chainstack or Alchemy document Hyperliquid's eth_maxPriorityFeePerGas, they are documenting the EVM layer where priority fees do not apply. The gossip and order priority system is HyperCore-only and uses HYPE from spot/staking balances, not EVM gas.

Why Fees Are Burned

All priority fees go to the zero address. This prevents validators from extracting MEV by selectively ordering transactions for their own profit. Combined with the cancel-first rule and the absence of private mempools, the priority system functions as a transparent, protocol-level ordering mechanism rather than a validator revenue stream.

The burn also adds a deflationary vector to the HYPE token. Hyperliquid already directs 97% of trading fee revenue to an Assistance Fund for HYPE buybacks - 49,360 HYPE were burned in a single day on April 2, 2026, at roughly $35 per HYPE. Priority fee burns stack on top of this existing mechanism.

HIP-3 Scope

Order priority applies only to IOC orders on HIP-3 (Builder-Deployed Perpetuals) assets. HIP-3 is the permissionless framework where third parties deploy their own perp markets by staking 500,000 HYPE. Builder codes on Hyperliquid have generated $223 billion in cumulative volume - not a marginal market, but a subset of total Hyperliquid trading activity.

Current Limitations and What to Watch

The priority fee system launched in alpha mode. Several constraints apply.

Order priority works only on IOC orders for HIP-3 assets. GTC orders, limit orders, and the core Hyperliquid perp markets are not covered. The feature is most relevant for aggressive taker strategies on builder-deployed markets, not for passive limit order market making on major pairs.

The maximum order priority rate was reduced from 20 bps to 8 bps based on community feedback before launch - a 60% reduction that suggests parameters will continue shifting. If you build automation around priority fees, make your rate parameter configurable. The alpha status means scope and mechanics may also change before general availability.

Things to watch:

• Expansion of order priority to non-HIP-3 assets and the core perp markets
• Support for limit orders and GTC orders with priority parameters
• Gossip auction dynamics as more participants compete for slots
• Changes to the 8 bps cap as the team gathers data on market behavior

The 60% cap reduction before launch based on community input signals that the team treats this as an iterative, feedback-driven system.

Getting Started

Priority fees are live on Hyperliquid mainnet. If you are running a trading bot on HIP-3 assets, the starting point is simple: add {"grouping": {"p": 10000}} (1 bp) to your IOC orders and measure fill rate over a few hundred trades. Fund your undelegated staking balance with enough HYPE to cover the fees, and track the priorityGas field in user_fills to attribute costs per fill.

For gossip priority, query gossipPriorityAuctionStatus to understand current slot prices before committing to a bid. The 10x reset mechanism means auction costs vary across cycles - bid toward the end of a window for better pricing.

Priority fees handle the write side: where your order lands in the execution queue. Read-side latency - how fast you see market data and react - is the other half. A 1 bp order priority fee gives you roughly 45 ms of execution advantage. Dwellir's validator-adjacent order book server gives you faster market data so your strategy triggers sooner. Faster reads plus priority execution is the full competitive stack for HIP-3 market making.

Contact the Dwellir team to set up dedicated Hyperliquid nodes and low-latency order book access.