Hyperliquid

Hyperliquid fees are protocol rates plus app-specific Builder Code charges

Hyperliquid fees are fill-based trading costs made from the protocol maker or taker rate plus any Builder Code charge authorized for the app routing the order. The protocol rate changes with the trader's rolling 14-day weighted volume and HYPE staking tier. A Builder Code does not replace that rate: it adds a per-order amount, capped by the user's onchain approval. The fill record reports the combined fee and identifies the builder portion separately.

From Builder Code approval to settled fill

Builder Codes begin with an onchain maximum approved for one builder address. Before routing eligible orders, an app asks the user to sign this fee ceiling on HyperCore.

The approval does not force every order to use the maximum. Each routed order carries an optional builder address and fee parameter. The app may set a lower rate or omit the charge. HyperCore checks the submitted amount against the approval, then applies it to the notional that fills. The user may revoke the permission later.

A builder must hold at least 100 USDC in perpetual account value. One user may keep no more than 10 active Builder Code approvals. These constraints make the receiving address and spending ceiling inspectable, yet the app still chooses the rate attached to each eligible order.

Perpetual and spot base rates establish the starting cost

Hyperliquid's base fee schedule starts with separate maker and taker rates for perpetuals and spot. At volume tier 0, a perpetual taker pays 0.045% and a perpetual maker pays 0.015%. The corresponding spot rates are 0.070% for takers and 0.040% for makers (see also Hyperliquid walkthrough ).

Execution determines the classification. An order that rests and adds liquidity receives maker treatment when filled. An immediately marketable order removes liquidity and pays the taker rate, even when submitted as a limit order. An Add Liquidity Only order prevents an immediate cross, protecting maker intent at the cost of possible rejection or non-execution.

Those Hyperliquid fees apply to filled notional, not posted collateral. A leveraged perpetual position therefore pays on its full executed value. Using 10× leverage does not divide the fee base by 10.

Fourteen-day volume and HYPE staking reprice the protocol rate

The Hyperliquid fee tier uses rolling 14-day weighted volume and is reassessed at the end of each UTC day. One tier covers standard perpetuals, HIP-3 perpetuals, and spot markets. Spot volume contributes at 2× its raw value.

Volume thresholds begin above $5 million, then advance above $25 million, $100 million, $500 million, $2 billion, and $7 billion. The published tier-6 base rates reach 0.024% for perpetual takers and 0.025% for spot takers. Maker rates reach 0% from tier 4 before separate market-maker rebates are considered.

HYPE staking supplies another discount ladder. More than 10 HYPE earns 5%; more than 100 earns 10%; more than 1,000 earns 15%; more than 10,000 earns 20%; more than 100,000 earns 30%; and more than 500,000 earns 40%. Sub-account volume joins the master account's tier, while vault volume remains separate.

A staking address may be linked to a different trading address, but the link is permanent. The staking user also gains control of the trading user. Trading and staking from the same address avoids that added dependency.

Builder fee caps and tenths of a basis point

A Builder Code fee is added to the discounted protocol rate. Builder fees are capped at 0.1% for perpetual fills and 1% for eligible spot fills.

The order parameter expresses the charge in tenths of a basis point. A value of 1 means 0.001%. A value of 10 means one basis point, or 0.01%. This unit conversion matters because the approval and the submitted order use the same scale.

Consider a $25,000 tier-0 perpetual taker fill with no staking or referral discount. The 0.045% protocol rate costs $11.25. If the app adds one basis point, the builder portion is $2.50. The total reported fee is $13.75 for that fill. Its builderFee field shows $2.50, while fee includes both amounts.

Comparing Hyperliquid fees through this additive arithmetic prevents double-counting. Opening and closing transactions remain separate fills, so a round trip contains two fee calculations.

Spot sides, quote assets, and HIP-3 markets change the formula

Builder Code eligibility differs between spot and perpetual trading. Builder charges settle only in the quote or collateral asset. They therefore apply to both sides of USDC-margined perpetual fills but not to the buying side of spot trades. An eligible spot sale may carry the charge.

HIP-1 spot market structure adds further protocol adjustments. A pair between two designated spot quote assets receives 80% lower taker fees, maker rebates, and volume contribution. An aligned quote asset receives a 20% taker discount, 50% stronger maker rebates, and 20% more tier contribution.

HIP-3 perpetuals introduce deployer settings alongside Builder Codes. Growth mode reduces protocol fees, rebates, weighted volume contribution, and HyperCore rate-limit contribution by 90%. Outside growth mode, a deployer may configure an additional fee share from 0% to 300%; growth mode limits that range to 0% through 100%. Above a 100% share, the protocol fee rises to equal the deployer fee.

The deployer setting belongs to the market. The Builder Code belongs to the routing app and remains bounded by the user's approval. Treating them as separate lines exposes why two interfaces quoting the same HIP-3 market may produce different totals.

Maker rebates, referrals, and hourly funding hit different lines

Maker rebates, referral discounts, and perpetual funding alter trading economics through separate mechanisms. None is an app-specific Builder Code charge.

A maker share above 0.5% of rolling weighted volume earns a -0.001% maker rate. Shares above 1.5% and 3% raise that rebate to -0.002% and -0.003%. Negative fees are credited continuously to the trading wallet as fills settle.

An active referral reduces eligible protocol fees by 4% for the trader's first $25 million in volume. Referral rewards for the referring account cover the referred user's first $1 billion. These thresholds affect the protocol side of the ledger, not the separately requested builder rate.

Perpetual funding settles every hour between long and short positions, and Hyperliquid collects no fee from that transfer. The funding cap is 4% per hour. Its fixed interest component is 0.01% per eight hours, expressed as 0.00125% each hour, while the premium component follows the contract's market-to-oracle difference. Price impact is another execution cost, but it is not a fee.

Protocol and builder portions reach different recipients

The Hyperliquid protocol portion flows to community mechanisms that include the Hyperliquidity Provider, or HLP, the assistance fund, and eligible market deployers. The assistance fund converts collected fees into HYPE and burns the acquired tokens.

A Builder Code portion goes to the named builder address instead. Builders claim accumulated amounts through the referral-reward claim process. The app-facing charge is therefore distinct from a HIP-3 deployer share, even when one interface supplies both the market and the order route.

Fill data preserves the distinction. The fee value contains the total, including the optional builderFee. Subtracting the builder field from the total isolates the remaining protocol charge; adding the two fields would count the builder amount twice.

Compare app charges before authorizing a builder

An app quote for Hyperliquid fees should separate the protocol rate, any market-level adjustment, and the Builder Code rate. Two apps may reach the same HyperCore order book while requesting different builder charges.

Use this decision checklist for the exact order under review:

Network movement charges sit outside that comparison. A new HyperCore account requires a fee of 1 quote token on the first transaction for which it is the destination. A native USDC bridge withdrawal charges 1 USDC for validator gas on Arbitrum. Neither amount changes the rate attached to a trading fill.

The approval ceiling deserves as much attention as the immediate quote. A low per-order charge and a much higher standing approval are different commitments. Comparing the same market, order side, notional, fee tier, and funding interval produces a meaningful app-to-app estimate.

Key questions about Hyperliquid fees

Does cancelling an unfilled order create a Builder Code charge?

No fee is charged when an order produces no fill. Builder Codes attach charges to executed notional, so a cancelled, rejected, or expired order with zero execution has no builder fee or protocol trading fee. If part of the order fills before cancellation, only that executed portion carries the applicable protocol and builder rates.

How are Builder Code fees applied to partial fills?

Each partial fill is charged against the notional executed in that fill. Several partial executions therefore produce several fee entries whose sum represents the order's total cost. Hyperliquid's fill-query interface may aggregate some executions by time when requested, but the combined fee still includes the builder amount reported through builderFee.

When does a Builder Code approval expire?

A Builder Code approval remains active until the user revokes it or replaces its maximum. The approval is tied to a specific builder address, not merely to an app name or browser session. Because one user may hold only 10 active approvals, old permissions should be reviewed before another app requests a new slot.

Why must the main wallet approve a builder address?

The main wallet must sign because the approval creates an onchain ceiling for app-specific fill charges. An agent or API wallet cannot authorize that maximum on the user's behalf. After approval, routed order actions may include the permitted builder address and fee parameter, while the approved ceiling remains controlled by the main wallet.

What causes the one-quote-token charge before a first trade?

The charge is HyperCore's one-time activation gas fee for a new account. The first transaction naming that unactivated account as its destination requires 1 quote token, such as 1 USDC, 1 USDT, or 1 USDH, regardless of the transferred asset. It is an account-activation cost, not a maker, taker, or Builder Code fee.

What happens when a closing order carries the same Builder Code?

An eligible closing fill pays the Builder Code rate again when that closing order includes the builder parameter. The approval is a reusable maximum rather than a one-fill coupon. Opening and closing notionals are calculated separately, and each fill also receives its own maker or taker classification. A closing order without the builder parameter incurs only the applicable protocol-side costs.

Updated on August 2026