Hyperliquid Outcome Market-Making Bot: Open-Source Trading Bot

What Is Hyperliquid Outcome Market-Making Bot?

Hyperliquid Outcome Market-Making Bot is an open-source Rust market-making bot built by gelatotrade for crypto quant developers and market-neutral desks; it runs three strategies side by side against Hyperliquid HIP-4 outcome markets, Polymarket, and Kalshi, and the first HIP-4 contracts went live on 2 May 2026. Hyperliquid Outcome Market-Making Bot is one of the best Market Making Bots tools for Rust developers, crypto quant traders, and market-neutral desks. It is built for teams that care about microsecond-level latency, exchange-specific order semantics, and shared risk controls rather than retail-style automation.

The repo is not a generic trading wrapper. It is a venue-aware execution engine that quotes binary outcome books, crosses spreads across venues, and trades BTC outcome parity against the perp market using one normalized event pipeline.

Quick Overview

Who Should Use Hyperliquid Outcome Market-Making Bot?

• Rust-first builders who want to keep the hot path in a compiled language and avoid Python event-loop overhead.
• Market-neutral traders who need a single system for quoting, cross-venue arbitrage, and parity trades instead of three separate bots.
• Crypto infrastructure teams operating live order flow across Hyperliquid, Polymarket, and Kalshi with real risk gating.
• Quant researchers testing inventory-skew, microprice, and volatility-based quoting on binary outcome markets.

Not ideal for:

• Beginners who want a web UI and no exchange integration work.
• Teams without live ops to monitor keys, fills, venue outages, and reconciliation.
• Pure spot or perp traders who do not care about outcome contracts or cross-venue event arbitrage.

Key Features of Hyperliquid Outcome Market-Making Bot

• Three-strategy execution engine — The bot runs avellaneda_stoikov, cross_venue_arb, and btc_parity in the same process. That matters because the strategies share the same book cache, the same inventory view, and the same risk gate, so you do not get inconsistent state across separate services.

• Normalized connector event model — Every venue connector emits Book, Trade, Fill, OrderUpdate, Resyncing, and Resynced events into one ConnectorEvent stream. The design keeps Hyperliquid, Polymarket, and Kalshi aligned at the abstraction layer instead of leaking exchange-specific payloads into strategy code.

• Avellaneda-Stoikov market making — The quoting logic uses reservation price and half-spread math with risk aversion γ, arrival intensity κ, volatility σ², and time-to-expiry T - t. The bot can skew bids and asks around the YES microprice, mirror the NO side via p_no = 1 - p_yes, and widen or tighten the band as inventory changes.

• Cross-venue arbitrage — The cross_venue_arb strategy lifts cheap legs and hits rich legs across Hyperliquid, Polymarket, and Kalshi when prices diverge after fees and slippage. This is useful when a prediction market lags a perp move or when two venues disagree on the same event probability.

• BTC parity trading — The btc_parity strategy trades the spread between the BTC up/down outcome and the BTC perpetual market. That gives the bot a relative-value engine instead of a single-direction bet, which is the correct shape for binary outcome convergence plays.

• Built-in risk gate — No order bypasses the risk layer. Position limits, drawdown limits, and kill-switch logic sit between strategy intent and venue submission, so the bot can resize or reject orders before they reach the exchange.

• Live dashboard and observability surface — The crates/dashboard app serves http://127.0.0.1:8787 and streams snapshots over a WebSocket at 4 Hz. It renders KPI cards, PnL, top-of-book data, signals, and 3D Plotly panels, which makes live diagnosis much easier than tailing logs alone.

Hyperliquid Outcome Market-Making Bot vs Alternatives

Pick Hummingbot if you want broader exchange coverage and do not need outcome-market-specific parity logic. It is the safer choice for teams that value connector breadth over custom microstructure math.

Pick Freqtrade if your work is mostly research, backtesting, and signal execution on spot or futures. It is less specialized for event markets, but it is easier to use for traditional alpha pipelines.

Pick NautilusTrader if you want a more general trading framework that you can shape into your own stack. It is better when you need a foundation for multiple asset classes instead of a prebuilt HIP-4 workflow.

For observability around live fills and rejects, pair Hyperliquid Outcome Market-Making Bot with OpenTrace. For deployment automation and config rollouts, djevops fits the same production workflow. If you archive fills, books, and snapshots for analysis, DataHaven is the natural storage companion.

How Hyperliquid Outcome Market-Making Bot Works

The bot is built around a single normalized event loop. Each connector converts venue-specific messages into a shared ConnectorEvent, and the main task drains those events with tokio::select! so book updates, fills, and resync signals land in one cache instead of three disconnected state stores.

The core data model uses DashMap<MarketKey, OrderBook> for fast concurrent access and Arc<RwLock<...>> for shared runtime state where write contention is acceptable. That design choice keeps the hot path allocation-light while still allowing the strategies to read the same book snapshot without blocking the receive path.

Order flow is deliberately one-way: strategy output goes into the risk gate first, and only accepted orders are signed and routed to the proper venue. Hyperliquid actions are signed with EIP-712, venue payloads use msgpack where required, and the dashboard receives separate snapshots so humans can inspect the same state the bot sees.

# clone and build
cargo build --release

# run with the default config
cargo run --release -- --config config/default.toml

The build step compiles the Rust workspace into optimized binaries, which matters for the latency-sensitive quoting loop. The runtime command loads the default TOML config, starts the venue connectors, and opens the dashboard on port 8787 so you can verify book sync, inventory, and risk decisions immediately.

Pros and Cons of Hyperliquid Outcome Market-Making Bot

Pros:

• Low-latency Rust execution keeps the hot path compiled and predictable under load.
• Shared book cache prevents strategy drift between market making, arbitrage, and parity logic.
• Venue-normalized events make it easier to add connectors without rewriting every strategy.
• Hard risk boundary ensures strategy code cannot bypass position controls.
• Native dashboard gives live visibility into PnL, books, and signals without external tooling.
• Outcome-market specialization means the math matches HIP-4 binary contracts instead of generic spot trading.

Cons:

• Exchange-specific plumbing still needs maintenance for Hyperliquid, Polymarket, and Kalshi API changes.
• Operational complexity is higher than a single-exchange bot because you are managing multiple venues and reconciliation paths.
• No obvious turnkey cloud story is shown in the repo text, so production hosting and secrets management are on you.
• Limited beginner ergonomics because the repo assumes comfort with Rust, config files, and live trading systems.
• Unknown release cadence and community size from the scraped page, so you should audit commit activity before betting production capital on it.

Getting Started with Hyperliquid Outcome Market-Making Bot

Start by cloning the repository, compiling the workspace, and editing the default config for your venue keys and risk limits. The minimum viable setup is the Rust toolchain, valid Hyperliquid, Polymarket, and Kalshi credentials, and a config file that enables only the strategy you want to test first.

git clone https://github.com/gelatotrade/Hyperliquid-Outcome-Market-Making-Bot-
cd Hyperliquid-Outcome-Market-Making-Bot-
cargo build --release
cargo run --release -- --config config/default.toml

After the first run, verify that the book cache is syncing and that the dashboard is serving on 127.0.0.1:8787. Before sending real orders, set conservative inventory caps, confirm the venue mappings for HIP-4 symbols, and validate that the risk gate rejects oversized quotes the way you expect.

Verdict

Hyperliquid Outcome Market-Making Bot is the strongest option for Rust-native outcome-market automation when you need Hyperliquid, Polymarket, and Kalshi in one low-latency loop. Its best strength is the shared book cache plus risk gate; its main caveat is the operational burden of running multi-venue live trading infrastructure. Recommended for teams that can handle production-grade crypto ops.