How to Build a Market-Making Bot on Hyperliquid

Market making is one of the oldest trading strategies in financial markets. A market maker places orders on both the bid and ask side, aims to earn the spread between buy and sell prices, and provides liquidity to the market. Source: Hyperliquid docs.

With on-chain perpetual exchanges such as Hyperliquid, independent developers and small quant teams can now access order-book markets through open APIs without needing institutional infrastructure. This guide walks through the practical design of a Hyperliquid market-making bot, including strategy logic, system architecture, risk controls, and how to protect signing keys with a OneKey hardware wallet.

Key comparison table

What market making means for perpetual futures

In a spot market, a market maker holds physical inventory. In a perpetual futures market, inventory is your net long or short exposure.

A well-designed market maker generally tries to stay close to delta neutral. The goal is to refresh bid and ask quotes frequently and capture spread, rather than making a directional bet on price.

Hyperliquid’s order-book design is similar to a centralized exchange, while settlement happens on-chain and funds remain self-custodied by users. Hyperliquid’s official documentation covers order types, fees, WebSocket data, and API specifications, and should be treated as required reading before deploying any bot.

Core logic of a market-making bot

Spread calculation

A basic symmetric market-making strategy places bids and asks around the mid price:

bid_price = mid_price * (1 - spread / 2)
ask_price = mid_price * (1 + spread / 2)

The spread needs to be wide enough to account for:

• Trading fees, especially if your orders cross the spread or are filled in unfavorable conditions
• Adverse selection, where your quote gets filled just before the market moves against you
• Funding-rate volatility and hedging costs

Use Hyperliquid’s official documentation to check the fee tiers for each market, then choose a spread baseline that matches your capital size, expected fill rate, and risk tolerance.

Quote refresh logic

Markets move continuously, so stale orders can become dangerous. A bot needs clear rules for when to cancel and replace quotes.

Common refresh triggers include:

• Time-based refresh: update quotes every fixed interval, such as every 5 seconds
• Price-move refresh: refresh immediately when the mid price moves beyond a defined threshold from your current quotes
• Fill-based refresh: refresh after one side of your order gets filled so liquidity is replenished

Production systems usually combine multiple triggers. Refresh too often and you waste requests, increase operational complexity, and may hit rate limits. Refresh too slowly and your quotes can be picked off by faster traders.

Inventory risk management

Inventory risk is one of the main risks in market making. If one side keeps filling while the other does not, your position drifts away from neutral.

Two common controls are:

• Quote skewing: if you are net long, shift both bid and ask prices lower to encourage selling and discourage additional buying. If you are net short, do the opposite.
• Hard position limits: if net exposure exceeds a threshold, stop quoting in the direction that increases risk until the position returns to an acceptable range.

# Pseudocode: inventory-based quote skew

position = get_net_position("BTC")  # positive = long, negative = short

skew_factor = -position * inventory_risk_param

bid_price = mid_price * (1 - spread / 2) + skew_factor
ask_price = mid_price * (1 + spread / 2) + skew_factor

The exact skew model depends on market volatility, depth, order size, and your risk budget. Start simple, log everything, and iterate based on real fill data.

System architecture overview

A complete Hyperliquid market-making bot typically has three layers: data, strategy, and execution.

┌─────────────────────────────────────────────────────┐
│                 Market-Making Bot Main Loop          │
├──────────────┬──────────────┬────────────────────────┤
│ Data Layer   │ Strategy     │ Execution Layer         │
│              │ Layer        │                         │
│ WebSocket    │ Mid-price    │ REST API place/cancel   │
│ order book   │ calculation  │ Batch order management  │
│ subscription │ Spread model │ Signing                 │
│ User fills   │ Inventory    │ OneKey hardware layer    │
│              │ skew         │                         │
│              │ Risk limits  │                         │
└──────────────┴──────────────┴────────────────────────┘
        │                              │
 Market data input              Orders sent to [Hyperliquid](https://app.hyperliquid.xyz/)

The typical flow is:

1. The data layer subscribes to order-book updates and user fills through WebSocket.
2. The strategy layer calculates fair bid and ask prices based on the latest market state.
3. The execution layer cancels outdated orders and places new ones through the REST API.
4. Requests are signed securely, commonly using EIP-712 structured signing where applicable.

Technical implementation notes

Placing orders with the REST API

Batch order endpoints can submit both bid and ask orders in one request, which helps reduce latency and keeps quote updates consistent.

def refresh_quotes(exchange, coin, bid_px, ask_px, order_size):
    # Cancel old orders first
    open_orders = get_open_orders(coin)

    if open_orders:
        cancel_ids = [o["oid"] for o in open_orders]
        exchange.bulk_cancel(coin, cancel_ids)

    # Submit new bid and ask quotes
    new_orders = [
        build_limit_order(coin, is_buy=True,  px=bid_px, sz=order_size),
        build_limit_order(coin, is_buy=False, px=ask_px, sz=order_size),
    ]

    return exchange.bulk_orders(new_orders)

In production, add error handling, request retries, rate-limit controls, and state reconciliation after failed or partially completed requests.

Listening for fills with WebSocket

REST polling is usually not fast enough for fill handling. A market-making bot should subscribe to user fill events through WebSocket and immediately update inventory.

def on_user_fill(fill_data):
    coin = fill_data["coin"]
    side = fill_data["side"]   # "B" = buy fill, "A" = sell fill
    sz   = fill_data["sz"]
    px   = fill_data["px"]

    update_inventory(coin, side, sz, px)
    trigger_quote_refresh(coin)

WebSocket connections can disconnect. Implement automatic reconnects, resubscribe to all required channels, and reconcile local state after reconnecting.

Key risks to take seriously

Market making is not “risk-free arbitrage.” Major risks include:

• Inventory risk: your position can become heavily long or short during one-sided markets.
• Adverse selection: informed or faster traders may fill your quotes before the market moves against you.
• Funding-rate risk: perpetual funding changes can affect net profitability.
• Liquidity risk: during volatile periods, order-book depth can disappear quickly.
• Technical risk: bugs, stale data, failed cancels, WebSocket disconnects, and API errors can all cause losses.
• Key-management risk: exposed private keys can result in loss of funds.

Do not deploy with meaningful capital until the bot has been tested under small size, abnormal market conditions, reconnect scenarios, and API failure cases.

OneKey hardware wallet: better key management for bots

A market-making bot needs to sign requests frequently, but frequent signing does not mean private keys should sit unprotected on a server.

A OneKey hardware wallet stores private keys in a secure chip isolated from the internet. Even if a server is compromised, an attacker should not be able to export the private key from the hardware wallet.

A safer architecture is:

1. Use Hyperliquid’s API Agent feature to create a separate wallet or agent for bot operations and connect it to the main account.
2. Keep the main account and sensitive signing authority protected by a OneKey hardware wallet.
3. Have the bot construct transaction or order messages locally.
4. Route signing through a controlled local signing service connected to OneKey where appropriate.
5. Submit the signed request to Hyperliquid.

This structure helps separate strategy automation from custody. Even if the bot code is modified or compromised, fund movement should still require stronger controls instead of relying only on a hot private key stored on a machine.

For extremely high-frequency systems that require many signatures per second, teams may choose a hybrid model: delegate limited trading permissions to an API Agent or hot wallet, while using OneKey to secure the main account and fund transfers. This balances performance and security, but it still requires strict permissioning, monitoring, and withdrawal controls.

Performance optimization tips

• Use batch cancel-and-place workflows where supported to reduce latency and keep quotes synchronized.
• Prefer maker-only order types such as Alo where appropriate, so orders do not accidentally take liquidity.
• Track every fill with timestamp, price, side, and size.
• Attribute PnL into spread capture, fees, funding, and inventory losses.
• Add circuit breakers that stop the bot and send alerts when intraday drawdown, position size, or error rate exceeds predefined limits.
• Build rate-limit protection with a token-bucket model and back off automatically after HTTP 429 responses.
• Reconcile local state against exchange state periodically; never assume your local cache is always correct.

FAQ

Q1: How much capital do I need to start market making on Hyperliquid?

Hyperliquid does not define a universal minimum amount for market making. In practice, the threshold depends on the market price, minimum order size, fees, and your strategy design. Start with very small size to validate logic and infrastructure before increasing exposure.

Q2: Where does a market-making bot’s profit come from?

The main source is spread capture. If a bot buys at the bid and sells at the ask around similar price levels, it can earn the difference after fees. More active markets can create more opportunities, but they also attract more competition and can carry higher adverse-selection risk.

Q3: How can I test without risking real funds?

Hyperliquid provides a testnet environment. Refer to the testnet configuration section in the official documentation and switch the API endpoints accordingly. Testnet is useful for debugging logic, order handling, and reconnect behavior, but it does not perfectly reproduce mainnet liquidity or competition.

Q4: Will a OneKey hardware wallet become a performance bottleneck?

For many automated trading workflows, OneKey signing performance is sufficient. For ultra-high-frequency strategies that require dozens of signatures per second, consider using an API Agent or limited-permission hot wallet for trading execution, while keeping the main account and fund-transfer authority secured with OneKey.

Q5: How should I handle API rate limits?

Check Hyperliquid’s official documentation for current request limits. Implement request throttling, use batch endpoints where possible, and add automatic backoff and retry logic when rate-limit responses occur.

Conclusion

Building a market-making bot on Hyperliquid combines quant strategy, low-latency systems, exchange API integration, and key-management security. Spread calculation, quote refresh logic, inventory skew, failure handling, and signing architecture all matter.

If you do not want to start by building a bot from scratch, OneKey Perps offers a practical way to trade perpetual futures from a self-custody-first workflow. You can use OneKey to get familiar with perp markets, manage your wallet securely, and then decide whether an automated strategy is worth building.

Download or open OneKey, connect your wallet, and try OneKey Perps with small size first. Treat it as a way to learn market mechanics and execution behavior before committing capital to automation.

You can also visit Hyperliquid App to experience the market directly, or read Hyperliquid’s official documentation for API-level details.

Risk warning: Market making is a high-risk quantitative trading strategy. Losses can result from market volatility, leverage, technical failures, API issues, funding changes, or strategy breakdown. Perpetual futures can amplify gains and losses. This article is for technical education only and is not financial, investment, legal, or trading advice. Assess your own risk tolerance carefully and comply with the laws and regulations in your jurisdiction.