Hyperliquid Trading Bot Guide (2026): Automated Trading with Native Orders, the Python SDK and Third-Party Bots

You can automate trading on Hyperliquid in three ways: with the built-in order types (TWAP, Scale, Chase, Trailing Stop, TP/SL), with your own bot using the official Python SDK and an API wallet that can trade but not withdraw, or with a third-party bot platform that charges a builder fee. Orders and cancels cost no gas; a bot pays only trading fees on fills (0.045% taker / 0.015% maker at the base tier). Its real constraints are the rate limits: one action per 1 USDC traded plus a 10,000-action starting buffer.

1. Built-in automation: no code needed

The order form on Hyperliquid has three tabs, Market, Limit and Pro. The Pro menu holds Chase, Scale, Stop Limit, Stop Market, Take Limit, Take Market, Trailing Stop and TWAP. For many people who search for a “bot”, these are enough:

Checked in the app and docs on September 25, 2026. TWAP suborders accept at most 3% slippage each. TP/SL triggers on the mark price, a median of Hyperliquid and external exchange prices that updates about every 3 seconds. There is no native iceberg order and no native grid or DCA bot.

A TWAP runs on the exchange, so it keeps working if you close the browser; Chase does not. Details and examples: TWAP, Scale and Chase guide, trailing stop tutorial, all order types.

2. Your own bot: API wallet, sub-account and SDK

1. Fund the account. Deposit at least 5 USDC (smaller deposits can be lost) from Arbitrum or another supported route; see how to use Hyperliquid. The minimum order is $10 of notional on perps.
2. Create a sub-account for the bot (More → Sub-Accounts). Sub-accounts unlock after $100,000 of volume (10 at first, more with volume). They share your fee tier and are treated as separate users for rate limits. Note: referral discounts do not apply to sub-accounts. See sub-accounts explained.
3. Create an API wallet (More → API). The app describes it plainly: “API wallets (also known as agent wallets) can perform actions on behalf of an account without having withdrawal permissions.” You can have one unnamed and three named API wallets per account, plus two named per sub-account, each valid for up to 180 days. Store its private key safely. Step-by-step (name, expiry, per-sub-account wallets, revoking): API wallet setup.
4. Install the SDK: pip install hyperliquid-python-sdk (version 0.24.0, MIT licence, Python 3.9+). The docs also link community SDKs in TypeScript (nktkas/hyperliquid, nomeida/hyperliquid) and Rust.
5. Test on testnet first (constants.TESTNET_API_URL in the SDK), then switch to mainnet with a small size.

One detail trips up most first bots: the API wallet only signs. To read balances and orders you query the real account address. If you query the API wallet address you get an empty result. The full endpoint reference is in our Hyperliquid API guide.

3. Code skeleton: a post-only grid with a dead man’s switch

This uses the official Python SDK to place five buy and five sell ALO (add-liquidity-only, i.e. post-only) orders on ETH, 0.5% apart, in one batched action, then arms a cancel-all 60 seconds ahead. On September 25, 2026 ETH traded at about $2,696; ETH sizes have 4 decimals, and prices may have at most 5 significant figures (so $0.1 steps near $2,700).

import os, time
import eth_account
from hyperliquid.exchange import Exchange
from hyperliquid.info import Info
from hyperliquid.utils import constants

ACCOUNT = os.environ["HL_ACCOUNT_ADDRESS"]   # main account address (for reads)
SUB = os.environ.get("HL_SUB_ACCOUNT")        # optional: the bot's sub-account
agent = eth_account.Account.from_key(os.environ["HL_API_WALLET_KEY"])  # cannot withdraw

info = Info(constants.MAINNET_API_URL, skip_ws=True)
ex = Exchange(agent, constants.MAINNET_API_URL, account_address=ACCOUNT, vault_address=SUB)

COIN, LEVELS, STEP, SIZE = "ETH", 5, 0.005, 0.01   # 0.01 ETH is about $27, above the $10 minimum
mid = float(info.all_mids()[COIN])

orders = []
for i in range(1, LEVELS + 1):
    for is_buy, sign in ((True, -1), (False, 1)):
        px = round(mid * (1 + sign * STEP * i), 1)
        orders.append(dict(coin=COIN, is_buy=is_buy, sz=SIZE, limit_px=px,
                           order_type=dict(limit=dict(tif="Alo")), reduce_only=False))

print(ex.bulk_orders(orders))                             # one action, 10 orders
ex.schedule_cancel(int(time.time() * 1000) + 60_000)   # cancel all in 60 s unless re-armed

What a real bot adds: a WebSocket subscription to your fills (userFills / orderUpdates) that re-places the opposite order one step away after each fill; re-arming schedule_cancel while it is healthy (it must be at least 5 seconds ahead, fires at most 10 times a day, reset at 00:00 UTC); a maximum position size; reconnect logic; and a nonce counter if several processes sign. Real-time data patterns are in the WebSocket guide. The SDK also has a set_referrer call, which always signs without a vault address, so the code lands on the main account (sub-accounts do not get the referral discount anyway). The simpler route is to open the sign-up link below once; either way, Hyperliquid stops accepting a code once the account has traded more than $10,000.

4. Rate limits a bot must respect

Orders on Hyperliquid cost no gas, so the ceiling on how much a bot can do is the rate limit, not the fee. There are two kinds: per IP (how fast you can talk to the API servers) and per address (how many actions your account has earned by trading). The complete published list:

Source: Hyperliquid docs “Rate limits and user limits” and “Nonces and API wallets”, checked September 25, 2026. Sub-accounts count as separate users for address-based limits. A batch of n orders is one request for the IP limit but n requests for the address limit.

The address budget: 1 action per 1 USDC traded

Every address starts with 10,000 actions and earns one more for each 1 USDC of volume it trades. The docs’ own example: with an order value of 100 USDC, you need a fill rate of 1% just to break even on actions. Check where you stand with the userRateLimit info request (info.user_rate_limit(address) in the Python SDK): it returns cumVlm (your cumulative volume), nRequestsUsed and nRequestsCap, which is your volume plus the 10,000 buffer. If you run out, you are limited to one action every 10 seconds, but cancels keep a larger allowance, min(limit + 100,000, limit × 2), so you can always flatten.

Worked example. A grid bot that cancels and re-places 20 orders every minute uses 20 × 60 × 24 = 28,800 address actions a day. A new address starts with 10,000, so it would run dry in about 8 hours unless the bot trades at least about $28,800 of notional a day to earn the difference. After that it is throttled to one action every 10 seconds. The fix is not a bigger server but a quieter bot: modify orders only when price has moved a full step, widen the grid, and let fills (not a timer) drive changes.

Buying headroom. Instead of trading for it, an account can reserve extra actions with the reserveRequestWeight exchange action at 0.0005 USDC per request, paid from the Perps balance (it can also pay for another existing user). 10,000 extra actions cost 5 USDC. That is cheap insurance for a low-volume bot, but a bot that needs it every day is usually sending too many orders.

The IP budget: 1,200 weight per minute

Polling clearinghouseState (weight 2) every 100 ms is 600 requests and 1,200 weight a minute: the whole budget, with nothing left for orders. The same account data arrives by WebSocket at no REST cost. A market maker sending 500 single orders and 500 single cancels a minute uses 1,000 weight; batching them into groups of up to 39 keeps each batch at weight 1 and the total a small fraction of the budget (the address budget still counts every order in a batch). Paginated history calls such as userFills add weight per 20 items returned, so pull history on a schedule, not in the trading loop.

Congestion and stale actions

During high congestion an address can use at most twice its previous-day maker share of block space, computed once per UTC day, so accounts that actually provide liquidity get more room. The docs advise not resending cancels whose results have already come back. If you set the optional expiresAfter field on an action, an action cancelled because it went stale consumes five times the usual address-based rate limit, so set it with a realistic margin.

Design patterns that stay under budget

• WebSocket for data, REST for actions. Subscribe to l2Book, userFills and orderUpdates; keep a local order and position state; reserve REST for placing, modifying and cancelling.
• Batch every 0.1 seconds. The docs suggest one batching task per process that sends orders and cancels every 0.1 s, with ALO (post-only) orders in separate batches from IOC and GTC because ALO-only batches are prioritised by validators.
• Modify instead of cancel-and-replace. One modify or batchModify action replaces two.
• A local token bucket. Mirror the published limits with a safety margin (for example 900 of the 1,200 weight). When it is empty, queue non-urgent requotes but never drop reduce-only or flatten commands.
• Back off with jitter after a rate-limit rejection instead of retrying on a fixed timer, and log which class of request (market data or order entry) hit the wall.
• One process, one API wallet, one sub-account. Nonces are tracked per signer and address budgets per user, so separation avoids nonce collisions and gives each strategy its own budget. Setup: API wallets and sub-accounts step by step.
• Post-only by default. Rejected would-take orders still consume actions; pricing inside the book with ALO keeps most messages useful.

Monitor in production: actions per minute by type (new, cancel, modify, info), reject rate and reason (post-only would cross, rate limit, margin), WebSocket reconnects and resubscribe time, drift between local and exchange position after a reconnect, and nRequestsUsed against nRequestsCap once an hour.

5. Strategies: what people automate, and what can go wrong

Grid trading: fee math, failure modes and tooling

A grid rests buy limits below the price and sell limits above it, one per level. When a buy fills it re-quotes a sell one level higher, and the reverse; each buy-then-sell is a cycle that earns the spacing times the level's notional. It is a bet that price oscillates inside the range. Hyperliquid has no native grid UI: you run it through the API (the code skeleton above is a post-only grid), a framework or a third-party bot. Orders and cancels cost no gas; the only costs are fees, funding on held inventory and the address rate limit.

Tier-0 fees from Hyperliquid's schedule; a referral code and HYPE staking lower them, volume tiers lower them further. Every grid order should be Alo: if it would cross, it is rejected instead of paying the taker fee, so the bot must handle "Post only order would have immediately matched" and re-quote one tick away.

Worked example. $10,000 in a neutral ETH grid at about $2,640 (mid on September 19, 2026), range ±5%, 20 levels, so spacing ≈ 0.5% and $500 per level. One cycle earns $2.50 gross, pays $0.15 in maker fees and nets $2.35. Ten cycles in a day net $23.50, about 0.24% of capital before funding; zero cycles because price walked out of the range earn nothing and leave you holding inventory. Each order needs at least $10, so a small account cannot be split into a hundred levels.

How grids fail.

• Breakout and inventory. If price falls through the bottom of a neutral grid, every buy has filled and no sell will: in the example, $5,000 of ETH bought on the way down, now underwater, and no cycles. Set a stop bound just outside the range that cancels the ladder and flattens the position, or a rule to re-centre wider and accept the loss.
• Leverage. Size on the fully filled side, not on the per-level margin. Run the same grid with 5x per level and a full buy side is $25,000 of ETH against $10,000 of equity: by Hyperliquid's liquidation formula (ETH maintenance margin 2%) liquidation sits about 39% below the average entry. At 10x it is $50,000 and about 18%, a move ETH has made within a week many times.
• Funding bleed. $5,000 of long inventory pays $1.50 a day at the baseline rate, comparable to a day of cycle fees, and several times that when longs are crowded.
• Dead bot, live orders. Re-arm scheduleCancel on every loop so a crash cancels the ladder.
• Range set by hope. Derive the range from recent realised volatility plus a buffer, not round numbers.

Tooling. (A) Your own script on the official Python SDK: batched ALO ladder with level-encoded client order IDs, userFills over WebSocket, opposite order on each fill, a reduce-only IOC to flatten at the stop bound; test on testnet first. (B) Open-source: Hummingbot has Hyperliquid spot and perp connectors with grid-style controllers (check whether the connector adds a builder fee); Freqtrade and CCXT also support Hyperliquid. (C) Hosted grid bots connect through an agent wallet you approve and usually charge a builder fee on top of Hyperliquid's fee; the referral discount also applies to orders placed through apps with a builder code, so set your referral code before the bot's first trade. (D) No code: Aster's order-book perps have a native futures grid (neutral, long or short, auto range from Bollinger Bands) with 0% maker fees, and Lighter Standard charges 0% maker and 0% taker but has no documented grid, so you still need a bot.

DCA (dollar-cost averaging)

Buy a fixed amount on a schedule, for example $50 of spot HYPE or BTC (UBTC) every day. Spot orders must be at least 10 units of the quote token (10 USDC), and a $50 market buy costs $0.035 at the 0.070% spot taker fee. A limit order slightly below the price (0.040% maker) is cheaper if you accept that some days will not fill. A native TWAP is not a DCA tool: it slices one order over at most 7 days and cannot repeat.

Funding carry (delta neutral)

Hyperliquid funding is paid every hour and capped at 4% per hour. Its baseline interest component is 0.01% per 8 hours (0.00125% per hour), about 11.6% a year paid by longs to shorts when the premium is zero. A carry bot holds spot and shorts the perp to collect it. Measured: over the 30 days to September 25, 2026, BTC funding on Hyperliquid added up to 0.7664% (72% of hours exactly at the baseline, 93% positive), versus 0.5421% on Binance and 0.4421% on Bybit over the same window. On a $10,000 short that is about $77 in a month. Entry and exit cost roughly $23 at base taker fees (0.070% spot + 0.045% perp, twice), so the trade needs weeks, not hours, to pay. Funding can turn negative, the spot and perp prices can drift apart, and the short leg can be liquidated in a spike if you post too little margin. Full method, with a 7-day worked table and a calculator: funding rate arbitrage guide (what is specific to Hyperliquid: Hyperliquid funding rate arbitrage).

Market making: maker fees, rebates and the real risks

Market making on Hyperliquid is permissionless: fund an account, create an API wallet and quote both sides with post-only orders. The docs say plainly there is no designated market maker program, no special rebates or fees and no latency advantages; everyone gets the same schedule.

Hyperliquid fee docs via the registry. The referral discount covers your first $25M on the main account (not sub-accounts or vaults) and does not change rebates. Spot volume counts double toward tiers.

Why retail quoting on majors loses money. On September 25, 2026 the public book showed spreads of BTC 0.12 bp ($1), ETH 0.37 bp ($0.10), HYPE 0.11 bp, NEAR 2.43 bp, against a base maker fee of 1.5 bp per side. A quote that captures the whole BTC spread still pays more in fees than it earns. Retail makers who last quote wider on less crowded markets, keep inventory small and use maker orders for trades they wanted anyway. The first rebate tier needs a share of the whole exchange's maker volume, which at $4–8B a day of perp volume means tens of millions of dollars of maker fills a day.

• Quoting: tif: "Alo" on every quote, batch updates (the docs suggest every 0.1 s), use batchModify instead of cancel-and-replace, and tag orders with client IDs. Cancels and ALO-only batches sent at the same time as IOC/GTC orders are executed first; optional priority fees buy more.
• Rate limits: the binding constraint is the address budget (one action per 1 USDC traded plus a starting buffer), not capital: a quoter refreshing four orders every two seconds needs about $173k of daily fills to keep up. Open orders are capped at 1,000 to start (full limits).
• Inventory risk is where makers lose: when price trends, your bids keep filling on the way down. A 1% move against 1 ETH of inventory costs about as much as hundreds of perfect round trips at a $0.10 spread. Cap inventory, skew quotes away from it, widen or pull around CPI and FOMC, and remember that held inventory pays hourly funding.
• Operational risk: a stuck process with resting quotes is a free option for everyone else; scheduleCancel and a separate monitor are not optional.

Without running a bot: HLP, the protocol vault, market-makes across Hyperliquid, runs liquidations and takes part of trading fees; anyone can deposit (APR at the last build 3.5%, 4 days lock-up after each deposit; it can lose money in sharp moves; see the vaults guide). On other venues: Lighter Standard and Aster charge 0% maker, but Lighter Standard delays cancels by 300 ms, which exposes resting quotes, and Lighter Premium removes the delay at 0.004% maker. Hyperliquid charges more per fill and sequences cancels first on the deepest books; many makers use more than one venue (Hyperliquid vs Lighter).

Execution bots

If you only need to get a large order done, the native TWAP is usually better than code: it runs on the exchange, has an optional Randomize setting and caps slippage at 3% per suborder. Build your own only when you need logic the TWAP lacks, such as pausing when the spread widens.

Signal and momentum bots

Indicator bots (moving-average crosses, breakouts) are easy to write and easy to over-fit. Backtest on data you record yourself from the API (the API serves only the most recent 5,000 candles per market and interval) and paper-trade on testnet before using money; see how to backtest a DEX strategy. Which Hyperliquid historical data the API keeps per interval, and where to get the rest, has its own guide. We do not quote win rates or returns for any strategy, because they depend entirely on the market and your parameters.

6. What a bot pays in fees

14-day volume	Perp taker	Perp maker
Under $5M (tier 0)	0.045%	0.015%
Over $5M	0.040%	0.012%
Over $25M	0.035%	0.008%
Over $100M	0.030%	0.004%
Over $500M	0.028%	0%

Hyperliquid fee docs, September 25, 2026; spot volume counts double toward tiers. Spot base fees are 0.070% / 0.040%. HYPE staking discounts of 5% to 40% and the 4% referral discount apply on top. No gas on orders or cancels; a USDC withdrawal costs 0.2 USDC plus a tiny HyperEVM gas fee in HYPE.

On $1M of monthly taker volume, a bot pays $450 at the base rate; with the 4% referral discount, $432. A maker-only bot on the same volume pays $150. Details: Hyperliquid fees.

7. Third-party bot platforms

Several services run grid, copy-trading or market-making bots on Hyperliquid for you. We checked one against its own documentation: Dextrabot. Its Hyperliquid Grid Bot needs a Hyperliquid API wallet added in Dextrabot, lets you choose a price range, 2 to 36 grids (even numbers), arithmetic or geometric spacing, investment and leverage, and trades in cross margin only. Its fee page lists 0.01% per trade for the Hyperliquid grid and market-maker bots and 0.055% for Hyperliquid copy trading, charged as a builder fee on top of Hyperliquid’s own fee. Setting it up asks you to sign two things: the builder-fee approval and the API wallet. We have not tested it with money and do not endorse any provider.

Before you connect any platform, check three things:

• Builder fee: Hyperliquid caps builder fees at 0.1% on perps and 1% on spot, and you can revoke approvals in More → Builder Codes. On orders with a builder code, your referral discount still applies to Hyperliquid’s part of the fee; the builder fee is added on top and is not discounted (checked against mainnet fills on October 1, 2026).
• Permissions: the platform should need only an API wallet (trade, no withdraw). Never paste a seed phrase or your main private key into a bot website.
• Isolation: give it a sub-account with only the capital it needs.

More options, including copy trading and mobile apps: perp DEX APIs compared (built-in and third-party bots), Hyperliquid copy trading, builder codes guide.

8. Security and risk controls

• API wallets cannot withdraw, but they can trade your balance into the ground. Use one per bot and per sub-account, and never reuse an API wallet address: once deregistered, its nonce history may be pruned and old signed actions could be replayed.
• Expiry: API wallets last at most 180 days. Put the expiry date in your calendar so a bot does not silently stop.
• Dead man’s switch: schedule_cancel cancels all open orders at a time you set, unless you push it forward. Combine it with reduce-only exits so a crashed bot leaves no stray orders.
• Hard limits in code: maximum position, maximum orders per minute, daily loss limit, and a manual kill switch.
• Liquidation distance: keep leverage low on bots; maintenance margin is half the initial margin at max leverage (1.25% for BTC at 40x). See how to avoid liquidation cascades.
• Keys: environment variables or a secrets manager, not source code or a shared repository.
• Where you live: Hyperliquid’s Terms exclude the US, Ontario and sanctioned regions; a bot does not change that.

9. FAQ

Want a free-to-trade venue for a slow bot? Lighter charges 0% on Standard accounts (code 718610TD); see the Lighter bot guide. Compare venues in our best DEX guide, or read what a DEX is first.

Disclosure: HOLYGRAIL and 718610TD are our referral codes; we earn a share of fees paid by referred accounts. Code is an illustration, not production software or financial advice. Limits, fees and SDK details were checked in Hyperliquid’s docs, the official SDK and the public API on October 14, 2026.