Running a trading bot on Hyperliquid
Verified against Hyperliquid docs: Nonces and API wallets and Hyperliquid docs: Fees · by Hyperliquid Academy
The permission model, which is the good news
There is no bot application, no separate agreement and no key issued by a support ticket. You approve an API wallet and start.
That agent can place and cancel orders. It cannot withdraw. So the worst case for a leaked key is bounded: someone can trade your account badly, and they cannot take the balance.
Compare that with an exchange API key carrying withdrawal permission, where a leak is terminal. It is a genuinely better arrangement and it is the main reason automated trading here is less nerve-wracking than elsewhere.
Bounded is not the same as safe
A hostile agent key can still open a maximum-leverage position and lose the account into a liquidation. The limit is that the money leaves as trading losses rather than as a transfer.
Treat the key as a credential, use one agent per process, and never reuse a deregistered agent address — the documentation warns that pruned nonce state makes an old action replayable.
What the venue is structurally good at
Two properties shape which strategies fit.
The maker side is paid. At the entry tier the maker fee is roughly a third of the taker fee, it reaches zero at higher volume, and above that there are rebates for a large share of maker volume.
Cost of a $10,000 taker order as each discount is added
- Base rate, no discounts $4.50 0.045% Tier 0, nothing staked
- With referral code $4.32 0.0432% 4% off, applies from trade one
- Referral + Silver staking $3.67 0.03672% Over 1K HYPE staked and linked
- Referral + Diamond staking $2.59 0.02592% Over 500K HYPE staked and linked
- Everything, at the top volume tier $1.38 0.01382% Over $7B of 14-day volume as well
For a bot this compounds in a way it never does for a person. A strategy crossing the spread a thousand times a day is paying the difference a thousand times a day, and moving from taker to maker is a bigger change to its economics than any parameter in it.
Funding settles hourly. The rate is paid between traders every hour rather than every eight, which makes funding-based strategies granular and their carry easy to model. Funding arbitrage is the obvious expression.
Everything is public. Every fill, position and liquidation, for every address, with no key needed. That is a research dataset most venues charge for, and it is also true of your own bot.
Which strategies fit
| Strategy | Fits because | Watch |
|---|---|---|
| Passive quoting | Maker fees and rebates | Latency competition, and inventory risk |
| Funding arbitrage | Hourly settlement, spot on the same venue | The rate flipping while you hold |
| Basis and carry | Both legs in one account | Margin interaction between them |
| Systematic directional | Cheap execution, deep majors | Slippage on anything outside the majors |
| Liquidation-adjacent | Public data, visible positions | Being on the wrong side of a cascade |
What fits poorly is anything that must cross the spread constantly on a thin market. The fee is the small part; the book depth is the large one, and no amount of fee optimisation fixes it.
The failure modes that actually cost money
Not the algorithm. These.
A process that dies with orders resting. Nothing cancels because your bot stopped. Those orders keep filling, into positions nothing is now managing. Decide up front whether your strategy needs a heartbeat and a cancel-all on exit.
A position nobody is watching. A stopped bot leaves an open position accruing funding hourly and drifting toward a liquidation price nothing is monitoring. This is the one that turns a crash into a loss.
Two processes on one agent. Nonces are ordered per agent. Run one agent per process and the problem disappears; share one and you get intermittent failures that look like network errors.
Sizing against the balance rather than the book. A strategy that can afford a position is not the same as a market that can absorb it. Size against depth.
A restart that re-enters everything. State that lives only in memory means a restart is a fresh set of orders on top of the existing ones. Reconcile against the exchange on startup, always, before acting.
Silent rate limiting. Requests start failing, the strategy stops updating, and it looks like the market went quiet. Log rejections separately from errors.
Before you run it with real size
Reconcile on start. Query your actual positions and open orders and make the bot’s view match reality, rather than assuming it starts flat.
Cap the damage in code. A maximum position size and a maximum daily loss, enforced by the bot itself, are worth more than any amount of care in the strategy logic.
Use reduce-only on every exit. Without it, an exit larger than the position opens one the other way. In an automated loop that error repeats.
Run small for longer than feels necessary. The behaviours that matter — restarts, disconnections, a fast market — only appear over time, and they are cheaper to discover on a small position.
Where to go next
The API and its limits, the Python SDK for the shortest path to a first order, and the fee levers, which matter more to a bot than to anyone else.
Frequently asked questions
Are trading bots allowed?
Yes, without asking anyone. There is no application, no separate agreement and no distinct fee schedule. Approving an API wallet is the whole permission step.
Can a bot withdraw my money if it is compromised?
Not with an agent key. Agents sign trading actions only; withdrawals need the master wallet. A compromised bot can still lose money by trading badly, which is a real risk with a real ceiling.
Do bots pay different fees?
No. The same schedule applies, which means the maker and taker gap matters far more to a bot than to a person, because a bot crosses the spread many more times.
What strategies suit Hyperliquid specifically?
Anything that earns from the maker side or from funding: passive quoting, funding arbitrage against a spot leg, and basis trades. The venue pays makers at higher tiers and settles funding hourly, so both are structurally supported.
Do I need to co-locate or run low latency?
Not for most strategies. Serious market making competes on latency everywhere, but funding and basis strategies operate on hourly timescales where a normal server is entirely adequate.
What happens if my bot crashes?
Its resting orders stay on the book and keep filling, and its open positions stay open, accruing funding. Nothing cancels because your process stopped, and deciding what should happen is part of the design rather than an afterthought.
Sources
- Hyperliquid docs: Nonces and API walletshyperliquid.gitbook.io
- Hyperliquid docs: Feeshyperliquid.gitbook.io
We link the primary source for every number on this page. If a figure here disagrees with the Hyperliquid documentation, the documentation is right and we want to know.