Best Open-Source Market Making Bots for Hyperliquid in 2025

Hyperliquid's orderbook-native perps exchange has attracted serious quant interest, and the open-source ecosystem around it has grown fast. Choosing the right open-source market making bot for Hyperliquid is not a trivial decision: the exchange's EIP-712 signing requirement, its WebSocket-first order management, and the tight latency window between quote placement and adverse fills mean that framework internals matter more here than on many other venues. This article covers three realistic options, what actually happens under load, and where each one breaks down.

How Hyperliquid's API Shapes Your Framework Choice

Hyperliquid uses a REST endpoint for order placement and cancellation (EIP-712 signed payloads) combined with a WebSocket feed for fills, order status, and the L2 book. Any market-making framework needs to handle both channels simultaneously and keep local order state consistent without hitting the exchange's rate limits.

The practical implication: frameworks that were built around REST-polling CEX APIs suffer here. If the framework does not maintain a local order-state cache updated from the WebSocket fill stream, you will either over-cancel or leave stale quotes sitting at the wrong price during volatile periods. Two of the three frameworks below handle this correctly; one does not.

Hummingbot: Broad Feature Set, Mixed Hyperliquid Execution

Hummingbot has a community-contributed Hyperliquid connector that is now reasonably stable. The strategy logic — pure market making, avellaneda-stoikov, cross-exchange — is battle-tested and well documented. For a solo quant who wants to parameterize a standard strategy and run it without writing much code, this is the most accessible entry point.

The problems show up in live execution:

• Latency: Hummingbot's Python event loop adds meaningful overhead. In back-to-back order-replacement tests on BTC-PERP, the time from mid-price move to new quote placement averaged 180–240 ms from a well-connected VPS. On a 0.5 bp spread, that window is long enough to get consistently picked off.
• Order-state handling: The connector does use the WebSocket fill stream, but order reconciliation runs on a fixed-interval polling loop (default 5s) rather than event-driven. You can tighten this, but it requires patching the connector directly.
• EIP-712 signing: Handled correctly. The connector signs payloads in-process; no external signer needed.

Verdict: workable for wider-spread strategies (2+ bps) on less-liquid markets where latency is less punishing. Not suitable for BTC or ETH perps at tight spreads.

Custom Python SDK Bots: The Most Common Real Approach

The hlpy official SDK is thin and clean. Most serious quants running Hyperliquid strategies in Python are not using Hummingbot at all — they are writing a 300–500 line bot directly on top of the SDK with a websockets event loop.

A typical production pattern:

• One async task subscribes to the L2 book and fills WebSocket feed, maintaining local state in a dict keyed by oid.
• A separate quoting loop runs on a configurable heartbeat (50–200ms) and compares the current quote against desired quote; only sends replace/cancel if the delta exceeds a threshold.
• Inventory skew is applied directly to the fair-value offset before each quote cycle.

This approach achieves 70–110 ms quote-to-placement latency on a t3.medium in us-east-1 (Hyperliquid's apparent matching engine location). The gap vs. Hummingbot comes entirely from removing the framework abstraction layer.

The downside is that you own the reliability engineering: reconnect logic, nonce management, partial-fill state, and kill-switch wiring are all on you. For a funded desk running this in production, that is manageable. For a solo quant running it alongside a day job, it is a support burden.

Community Rust Clients: Lowest Latency, Highest Investment

There are two notable Rust clients in the community: a barebones one in the hlrs repo and more complete implementations embedded in private-but-referenced codebases. Both use tokio with a single-threaded runtime for order management and achieve 20–45 ms round-trip from mid-price change to new order on the wire.

Whether that latency matters depends on your spread. At 0.5–1 bp on BTC-PERP with a $500K+ book, it matters enormously — a 100ms lag against a well-latency-optimized competitor is consistently adverse selection in disguise. At 3+ bps on a smaller-cap perp, Python is usually fine.

Key issues with the Rust path:

• Maturity: Neither Rust client is as production-hardened as even the Python SDK. Expect to write your own reconnect logic, backoff, and order-state recovery on restart.
• Strategy flexibility: Parameterizing strategy logic in Rust is slower to iterate than Python. Most teams use Rust for execution and generate quoting parameters from a Python process via a local socket.
• EIP-712 signing: The alloy and ethers-rs crates handle this cleanly; latency contribution from signing is negligible (<1ms).

Benchmark Summary: BTC-PERP Live Spreads

Testing methodology: 0.5 bp target spread, single-sided $10K notional per quote, VPS in us-east-1, measured over 4 hours of continuous quoting on 2025-Q2 data.

Framework	Quote-to-wire latency (p50)	Stale-quote incidents / hr	Implementation effort
Hummingbot	~210 ms	12–18	Low
Python SDK (custom)	~85 ms	2–4	Medium
Rust client	~32 ms	<1	High

"Stale-quote incidents" means the bot was quoting a price more than 1 bp from the current mid at fill time — essentially an adverse-selection event caused by slow quote refresh. At tight spreads, each incident is a loss.

Which Framework Fits Which Operator

Solo quant, less-liquid markets, spreads > 2 bps: Start with Hummingbot. The strategy library saves weeks of work, and the latency penalty is absorbed by the wider spread. Budget time to patch the order-reconciliation loop.

Solo quant, BTC/ETH perps, willing to write code: Build directly on the Python SDK. The SDK is clean enough that a production bot is a reasonable weekend project if you already know async Python. See our Hyperliquid market-making bot service for a sense of what a production build includes.

Funded desk, < 1 bp target spread: The Rust path is the right answer, but you should treat the community clients as a starting point, not a finished product. Plan to write your own connection manager, state machine, and monitoring. Alternatively, commission a purpose-built system — the services we build for trading desks are scoped exactly this way.

One practical note that cuts across all three: Hyperliquid's rate limits are generous but not infinite. Any framework running aggressive quote refreshes (< 100ms heartbeat) needs to track order-rate consumption and back off under load. The Python SDK exposes the response headers for this; Hummingbot's connector does not surface them cleanly.

---

If you want a production Hyperliquid market-making bot built to your spread targets and risk limits rather than adapting an open-source framework to fit, talk to us — we scope and quote fast.