How to Build a Grid Bot on Hyperliquid
Hyperliquid has no grid bot product — a grid is a program you write or run. Fee-floor spacing, tick rounding, liquidation guards, hourly funding, and the kill switch.
Direct answer: Hyperliquid's app has no grid bot product — it has Scale and TWAP order types, but no grid. A grid on Hyperliquid is a program you write or run yourself, signing orders through the API. The real design work is not the ladder of orders; it is fee-floor spacing, price/size rounding, leverage and liquidation guards, hourly funding on inventory, reconciliation, and a kill switch that fires when price leaves the range.
What a grid bot actually is on Hyperliquid
A grid bot places a ladder of buy orders below a center price and sell orders above it, then re-quotes each rung after a fill. When price oscillates, the bot buys low and sells high repeatedly. When price trends, the ladder stops refilling on one side and the bot is left holding inventory against the move. For the venue-neutral basics, see what a grid trading bot is and grid bot settings that survive fees.
On Hyperliquid there is nothing to click to get this. The exchange exposes an API (REST and WebSocket, with an official Python SDK), and a grid is a program that:
- pulls the price feed,
- maintains buy and sell rungs across a chosen range,
- re-quotes rungs as fills happen,
- tracks position, margin, and funding,
- shuts down when conditions break.
Those last two items are where most grid code is actually written.
Component diagram
price feed (WS)
│
▼
grid engine ──── range + rung definitions
│
▼
order router ── ALO/post-only rungs, batched orders
│
▼
fill reconciler ── order status, fills, orphans
│
▼
risk gate ──── inventory limit, liquidation distance,
│ funding drift, reject streaks
▼
kill switch ─── range exit, drawdown, heartbeat loss
│
▼
alerts / shutdown
This is the same shape as the general trading bot architecture — price data in, orders out, a reconciliation layer in between, and a risk gate before anything dangerous happens. For a deeper treatment of the shutdown path, see the kill switch architecture post and the guardrails for autonomous trading agents.
Fee-floor spacing: the math that decides viability
Hyperliquid fees are based on rolling 14-day volume. At Tier 0 (base rate), perpetuals cost 0.045% taker / 0.015% maker. Higher volume tiers discount both, and the maker fee drops to 0% from Tier 4 up; separate maker rebates (−0.001% to −0.003%) go to accounts with more than 0.5%, 1.5%, or 3% of 14-day weighted maker volume; HYPE staking and referral discounts also apply; and HIP-3 perps can carry deployer fee shares or growth-mode reductions. (Numbers verified against the official fees page, 2026-10-25.)
For a grid, the relevant number is the round trip on one filled-and-refilled rung, as a hypothetical example:
- Both sides fill as maker: 2 × 0.015% = 0.030% per round trip
- Both sides fill as taker: 2 × 0.045% = 0.090% per round trip
That is before slippage and before funding.
The spacing rule that follows: the gap between rungs must clear the round trip you actually pay. If your rungs fill as maker at 0.5% spacing, the fee is 0.030% of a 0.5% gross capture — meaningful but manageable. If your ALO quotes keep getting rejected and you fall back to taker fills at 0.3% spacing, you are paying 0.090% to capture 0.3%. Post-only (ALO) orders exist precisely for this: an ALO order is only executed as a resting order and is rejected rather than crossing the spread, so a maker-first grid uses ALO rungs and re-quotes on rejection.
There is no universal minimum spacing. Any spacing heuristic you read elsewhere is someone else's answer to "does spacing clear my round trip, plus inventory risk" — compute your own from the fee tier you actually trade at.
Price and size rounding: why rungs collapse on cheap assets
Hyperliquid has no single tick size. Perp prices allow up to 5 significant figures and no more than (6 − szDecimals) decimal places (sizes round to the asset's szDecimals from the meta endpoint). Integer prices are always valid regardless of significant figures.
The consequence for a grid: every rung price must be rounded to a valid price. Take a hypothetical perp trading around $0.0050 with szDecimals = 2: prices may carry at most 6 − 2 = 4 decimals (tick and lot size docs), so the only valid prices nearby are 0.0049, 0.0050, and 0.0051 — steps of about 2% of price. Once the allowed precision runs out, rounding collapses your spacing: two rungs you wanted 1% apart (0.00500 and 0.00505) end up either on the same valid price or a full step apart. Fetch szDecimals from the meta endpoint at startup and enforce minimum spacing after rounding, not before.
Leverage and liquidation guards
Leverage on a perp is an integer between 1 and the asset's maxLeverage from the meta endpoint. The range across assets is wide (roughly 3x to 40x currently), cross margin is the default, isolated is supported, and some assets are strict-isolated only. Initial margin is position_size × mark_price / leverage.
A grid bot is a liquidation machine if you treat leverage casually, because a breakout produces exactly the failure shape that liquidation punishes: one side of the ladder fully filled, inventory growing against a trend, and unrealized PnL going negative. The maintenance margin is half of the initial margin at max leverage (between roughly 1.25% and 16.7% notional depending on the asset). Liquidations use the mark price, not the last trade. Orders hit the book first; if equity falls below 2/3 of maintenance margin without a successful book liquidation, a backstop liquidation through the liquidator vault takes the position — and for a cross position, that can mean the whole cross margin goes with it. For liquidatable positions above 100k USDC (10k USDC on testnet), only 20% of the position is sent to the book at first; for 30 seconds after a partial liquidation, any further market liquidation orders for that user are for the entire position.
Practical guards for a perp grid, all generic:
- cap notional inventory as a fraction of account equity, sized so that maintenance margin at your worst-case one-sided fill stays far away,
- compute the liquidation price with the official formula (
liq_price = price − side × margin_available / position_size / (1 − l × side)), not a rule of thumb, and halt new rungs well before it, - prefer isolated margin for a grid so a runaway position cannot drain cross collateral,
- treat funding as a live input to the risk gate, not a footnote (next section).
Funding is hourly, and it is not always income
Funding on Hyperliquid is purely peer-to-peer with no fee collected on payments. The rate follows the 8-hour convention used by major CEXs, but Hyperliquid pays funding every hour at one eighth of the computed rate, capped at 4% per hour, with the payment calculated as position_size × oracle_price × funding_rate — note the oracle price, not the mark price.
For a grid bot this matters in both directions. A balanced ladder has roughly offsetting long and short exposure over time, so funding payments roughly wash. A post-breakout one-sided position does not: it pays or receives funding every hour depending on the rate's sign (longs pay shorts when the rate is positive, shorts pay longs when it is negative), and when it pays, that cost stacks on top of the adverse move. Model funding as an hourly cost on net inventory; a grid that looks fee-viable but holds one-sided inventory through trending hours can turn funding-negative (funding docs). And never treat funding as guaranteed income — the sign flips with the premium.
Reconciliation: the unglamorous half of the bot
The API enforces hard limits you must design around: REST requests share 1,200 weight per minute per IP, most info requests weigh 20 (a handful weigh 2, e.g. l2Book and clearinghouseState), and batched order requests are one IP-weighted request but n address-weighted requests. Separate address-based limits apply to actions, with a generous carve-out so cancels still go through when you are rate-limited.
The reconciler's job, per loop:
- confirm every open rung is actually resting (order status, not assumption),
- match fills to rungs and re-quote,
- detect orphan orders (placed, unfilled, lost track of) and cancel them,
- track consecutive rejects (ALO orders are canceled instead of immediately matching, so a streak of ALO rejections means the book has moved onto your rung prices — pause rather than spam),
- persist enough state that a restart resumes instead of double-placing the ladder.
The docs specifically recommend an API wallet per trading process with periodic batching of order/cancel requests — which doubles as the key-hygiene rule below.
Key hygiene: agent (API) wallets
A master account can approve API wallets (also called agent wallets) to sign on its behalf; they are only used to sign, never to query account data. The official docs also warn that API wallets and their nonce state can be pruned — when deregistered, expired, or when the registering account has no funds — and strongly recommend not reusing agent wallet addresses: once an agent is deregistered, its pruned nonce state means previously signed actions could be replayed. Generate a fresh agent wallet for future use, and use a separate agent per trading process (nonces are tracked per signer, so shared agents share a nonce tracker).
The operational rules that fall out of this:
- agent wallets are for signing orders; never give a bot your master key or seed phrase,
- rotate/revoke the agent wallet when the bot stops,
- don't reuse an agent wallet address across deployments — generate a new one,
- one agent wallet per process; subaccounts get their own agents.
Kill switch for grids
A grid's failure mode is not a crash — it is a trend. The kill switch conditions specific to grids:
- range exit: price closes beyond the ladder's high or low by a buffer; cancel everything, flatten or hedge per policy,
- drawdown: account or position drawdown past a threshold,
- funding drift: hourly funding on net inventory exceeding a per-hour cost threshold,
- heartbeat loss: the bot itself stops receiving its own loop confirmations (process hung, WS dead) — an external watchdog cancels the ladder. Hyperliquid's API also has a schedule-cancel action (a dead man's switch) that cancels all open orders at a set time; a healthy bot can keep pushing that time forward. The docs cap it at 10 triggers per day.
Design the cancel path so it works when the trading process is already dead — that is the whole point of the kill switch architecture pattern.
A sane rollout path for any grid you write: testnet first, then paper trading against live data, then small size live. Each stage exists to catch a different class of bug — logic errors on testnet, latency and reconciliation behavior on paper, and psychology-plus-fee-reality at small size. The paper-vs-live discipline applies to grids the same as any other strategy, and the build guide covers the general stack choices. Keep API credentials scoped and rotated — the API key safety checklist applies even to self-hosted code.
FAQ
Does Hyperliquid have a grid bot? No. Hyperliquid's app has no grid bot product — it offers Scale and TWAP order types, but a grid is a program you write or run yourself through the API.
Can a grid bot withdraw my funds? A properly scoped bot signs orders through an agent wallet. The hygiene rules: never hand over your master key, revoke the agent wallet when you stop, don't reuse agent addresses, and run one agent per process.
What fees does a Hyperliquid grid pay? At Tier 0, 0.015% maker / 0.045% taker on perps. A hypothetical all-maker round trip is 0.030%; all-taker is 0.090%. Volume tiers, staking/referral discounts, and HIP-3 structures change these. Spacing must clear your actual round trip.
Spot or perp grid on Hyperliquid? Spot grids carry inventory risk but no liquidation. Perp grids add leverage, liquidation, and hourly funding to the same inventory problem — which is why the risk gate and kill switch sections above are perp-specific.
Is a hosted Hyperliquid grid bot safe? Evaluate any hosted bot the same way: what keys it holds, what it can sign, what its kill switch is, and whether you can verify any performance claim. The fee-floor and liquidation math above applies to hosted bots identically — and if a hosted bot can't answer the liquidation-distance question, that is the answer. For how hosted grid platforms compare on custody and exit controls, see best grid trading bots in 2026.
Sources
Official Hyperliquid documentation, checked 2026-10-25: Fees · Order types · Tick and lot size · Margining · Liquidations · Funding · Rate limits and user limits · Nonces and API wallets · Exchange endpoint
Risk disclaimer
Not financial advice. Grid strategies lose money in strong trends — the ladder accumulates inventory against the move, and fees and funding compound the damage. Leveraged perp grids can be liquidated. All fee and funding figures here are from official documentation or labeled hypothetical examples; no outcome, profit, APR, or ROI is promised or implied.
Run a free scan → /scan/