[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-81787":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":8,"htmlUrl":8,"language":9,"languages":8,"totalLinesOfCode":8,"stars":10,"forks":11,"watchers":12,"openIssues":13,"contributorsCount":13,"subscribersCount":13,"size":13,"stars1d":13,"stars7d":13,"stars30d":13,"stars90d":13,"forks30d":13,"starsTrendScore":13,"compositeScore":14,"rankGlobal":8,"rankLanguage":8,"license":8,"archived":15,"fork":15,"defaultBranch":16,"hasWiki":17,"hasPages":15,"topics":18,"createdAt":8,"pushedAt":8,"updatedAt":19,"readmeContent":20,"aiSummary":21,"trendingCount":13,"starSnapshotCount":13,"syncStatus":12,"lastSyncTime":22,"discoverSource":23},81787,"Hyperliquid-Outcome-Market-Making-Bot-","gelatotrade\u002FHyperliquid-Outcome-Market-Making-Bot-","gelatotrade",null,"Rust",44,21,2,0,4.03,false,"main",true,[],"2026-06-12 02:04:19","# Hyperliquid Outcome Market-Making Bot\n\nA low-latency, multi-strategy market making and arbitrage bot for the new\n**HIP-4 Outcome Markets** that went live on Hyperliquid mainnet on\n**2 May 2026**. Written in Rust because every microsecond on the wire shows\nup as either captured spread or adverse selection.\n\nThe bot trades three signals side by side, sharing one book cache and one\nrisk gate:\n\n| # | Strategy                          | Goal                                                                  |\n|---|-----------------------------------|-----------------------------------------------------------------------|\n| 1 | `avellaneda_stoikov` (MM)         | Capture spread by quoting both sides of HIP-4 YES + NO outcome books. |\n| 2 | `cross_venue_arb`                 | Lift cheap leg \u002F hit rich leg across HL \u002F Polymarket \u002F Kalshi.        |\n| 3 | `btc_parity`                      | Trade the divergence between the BTC up\u002Fdown outcome and the BTC perp. |\n\n> ℹ **HIP-4 in one paragraph.** Hyperliquid HIP-4 introduces fully\n> collateralised, on-chain prediction markets that share the same matching\n> engine, account, and ~200 k orders \u002F second throughput as Hyperliquid\n> perps and spot. Each event has two tokens — `YES` and `NO` — that pay\n> exactly **1 USDH** to the holder if they were correct at expiry, and\n> **0 USDH** otherwise. Opening \u002F minting is free; fees only apply on\n> close, burn, or settle. The first contracts are daily BTC binary\n> thresholds that reset at 06:00 UTC; the bot ships pre-configured for\n> the very first one (`OUT:BTC-78213-2026-05-03-YES`).\n\n---\n\n## Table of contents\n\n1. [Architecture](#architecture)\n2. [Performance dashboard (live)](#performance-dashboard-live)\n3. [Strategies and the math behind them](#strategies-and-the-math-behind-them)\n   - [Avellaneda-Stoikov market making](#avellaneda-stoikov-market-making)\n   - [Cross-venue arbitrage](#cross-venue-arbitrage)\n   - [BTC up \u002F down vs. perp parity](#btc-up--down-vs-perp-parity)\n4. [Kelly-criterion position sizing](#kelly-criterion-position-sizing)\n5. [Why Rust](#why-rust)\n6. [Configuration & running](#configuration--running)\n7. [Repository layout](#repository-layout)\n8. [Risk model & safety rails](#risk-model--safety-rails)\n9. [References](#references)\n\n---\n\n## Architecture\n\n```mermaid\nflowchart LR\n    subgraph Venues\n      HL[Hyperliquid\u003Cbr\u002F>WS + REST]\n      PM[Polymarket\u003Cbr\u002F>CLOB API]\n      KAL[Kalshi\u003Cbr\u002F>v2 API]\n    end\n\n    subgraph Connectors\n      HLC[hl-omm-connectors\u003Cbr\u002F>hyperliquid::*]\n      PMC[hl-omm-connectors\u003Cbr\u002F>polymarket::*]\n      KLC[hl-omm-connectors\u003Cbr\u002F>kalshi::*]\n    end\n\n    subgraph Core\n      BC[Book cache\u003Cbr\u002F>DashMap<MarketKey, OrderBook>]\n      EV[(ConnectorEvent stream)]\n    end\n\n    subgraph Strategies\n      AS[AvellanedaStoikov]\n      XV[CrossVenueArb]\n      BP[BtcParity]\n    end\n\n    R[Risk gate\u003Cbr\u002F>position \u002F dd \u002F kill switch]\n    DASH[Web dashboard\u003Cbr\u002F>Plotly 3D + WS]\n\n    HL --> HLC --> EV\n    PM --> PMC --> EV\n    KAL --> KLC --> EV\n    EV --> BC\n    BC --> AS\n    BC --> XV\n    BC --> BP\n    AS -->|Quote| R\n    XV -->|Take| R\n    BP -->|Take| R\n    R --> HLC\n    R --> PMC\n    R --> KLC\n    BC --> DASH\n    R --> DASH\n```\n\nEvery connector emits a normalised `ConnectorEvent` (`Book`, `Trade`,\n`Fill`, `OrderUpdate`, `Resyncing`, `Resynced`). The bot's main task drains\nall three connectors via `tokio::select!`, updates the book cache, and\nfans out to every strategy in zero allocations on the hot path\n(`Arc\u003CRwLock\u003C…>>` + lock-free DashMap).\n\nA second task drains strategy events, runs them through the risk gate, and\nhands surviving orders to the right venue. Orders never bypass risk; risk\nnever blocks the receive path.\n\n```mermaid\nsequenceDiagram\n    participant WS as Hyperliquid WS\n    participant CN as Connector\n    participant BC as Book cache\n    participant ST as Strategy\n    participant RG as Risk gate\n    participant EX as Exchange REST\n\n    WS->>CN: l2Book delta\n    CN->>BC: BookUpdate\n    BC-->>ST: notify (mpsc)\n    ST->>ST: re-quote (γ, σ, q)\n    ST->>RG: StrategyEvent::Quote\n    RG-->>ST: RiskDecision::Pass \u002F Resize \u002F Reject\n    RG->>EX: signed action(msgpack + EIP-712)\n    EX-->>CN: order_update\n    CN-->>BC: OrderUpdate \u002F Fill\n```\n\n---\n\n## Performance dashboard (live)\n\nThe bot ships with a built-in dashboard (`crates\u002Fdashboard`) at\n**`http:\u002F\u002F127.0.0.1:8787`**. It serves a single HTML page, streams\nsnapshots over `\u002Fapi\u002Fstream` (WebSocket, 4 Hz) and re-renders the KPI\nstrip, PnL line, top-of-book table, signals tail and the three 3D\nPlotly views on every push.\n\nThe GIF below is the same dashboard replayed against a live snapshot\nwindow — KPI cards, PnL curves, top-of-book table and signals scatter\nall evolving tick-by-tick on real venue data captured by\n`scripts\u002Fscrape_live.py`:\n\n![Performance dashboard — live replay](docs\u002Fdiagrams\u002Fdashboard.gif)\n\n### Reproducing it from your own data\n\nThe scraper has two modes and **no synthetic fallback** — every datapoint\nthat ends up in `docs\u002Fdiagrams\u002Flive_snapshots.json` is fetched from a\npublic venue or archive endpoint:\n\n| `--mode`      | Source                                                                                              |\n|---------------|------------------------------------------------------------------------------------------------------|\n| `live`        | Hyperliquid `\u002Finfo` (`allMids`, `l2Book`), Polymarket gamma + CLOB, Kalshi v2.                       |\n| `historical`  | Hyperliquid `\u002Finfo` `candleSnapshot` (BTC perp), Polymarket CLOB `\u002Fprices-history`, Kalshi `\u002Fcandlesticks`. |\n| `auto` (default) | Tries `live` first; if any venue is unreachable, falls back to `historical` for the same window. |\n\n```bash\n# 1. Capture a 60-second window from the public endpoints.\npython3 scripts\u002Fscrape_live.py --secs 60 --interval 0.5 \\\n    --kalshi-ticker KXBTCD-26MAY03-78213-Y    # only required in historical mode\n\n# 2. Replay the snapshots as four animated GIFs under docs\u002Fdiagrams\u002F.\npython3 scripts\u002Fanimate.py\n```\n\nIf both modes fail (e.g. fully air-gapped host), the script exits\nnon-zero — it will never write fabricated data. The animation script\nrefuses to run on a snapshot file whose `source` is anything other\nthan `\"live\"` or `\"historical\"`.\n\nThe web dashboard adds three interactive 3D Plotly panels on top of\nthis static replay (AS quote band, cross-venue divergence,\nBlack-Scholes parity surface) — those are illustrated next to the\nstrategies that produce them.\n\n---\n\n## Strategies and the math behind them\n\n### Avellaneda-Stoikov market making\n\nThe classic stochastic-control market maker, adapted to a binary outcome\nwhere the \"mid\" is itself the implied probability of YES.\n\nFor risk aversion `γ`, arrival intensity `κ`, realised variance `σ²` and\nremaining time-to-expiry `T - t`, the reservation price and optimal\nhalf-spread are\n\n```\nr(s, q, t) = s − q · γ · σ² · (T − t)\nδ(t)       = γ · σ² · (T − t) + (1\u002Fγ) · ln(1 + γ\u002Fκ)\n\nbid = r − δ                ask = r + δ\n```\n\nThe mid `s` is the YES microprice (size-weighted top-of-book), clamped to\n`[tick, 1 - tick]`. Inventory `q` is signed YES tokens. Quotes are\nmirrored on the NO leg using `p_no = 1 - p_yes`; both legs share the same\nmatching engine on Hypercore so the maker captures liquidity rebates on\neither side as the flow lands.\n\nThe animation below stacks three surfaces — the inventory-skewed\nreservation `r` (blue), the ask `r + δ` (red) and the bid `r − δ`\n(green) — over `(σ, q)`. As realised σ pumps the band fans out; as `q`\ndrifts away from zero the whole stack tilts so the bot is willing to\n*buy cheaper \u002F sell dearer* to mean-revert its book. The neon dot is\nthe live `(σ, q, mid)`:\n\n![Avellaneda-Stoikov quote band — live (σ, q) drives bid \u002F ask](docs\u002Fdiagrams\u002Fas_surface.gif)\n\n> Key implementation knobs (see `config\u002Fdefault.toml#strategy.avellaneda`):\n> `gamma`, `kappa`, `min_size`, `max_inventory`, `vol_half_life_secs`,\n> `tick`, plus the per-strategy Kelly cap (next section). The volatility\n> estimator is an EWMA of `Δlog(p) \u002F √Δt`; the first 10 seconds use a\n> prior so cold-starts don't post stupidly wide.\n\n### Cross-venue arbitrage\n\nThe same logical event (\"BTC ≥ 78,213 USD at 03 May 2026 06:00 UTC\") trades\non **at least three venues** today: Hyperliquid HIP-4, Polymarket and\nKalshi. After fees and bridging costs these prices ought to converge — but\nthey don't always.\n\n```mermaid\nflowchart TB\n    subgraph LogicalEvent[\"Logical event\"]\n      EV[\"OutcomeKey{ BTC, 7821300¢, 2026-05-03T06:00Z, ≥ }\"]\n    end\n    EV --> A[\"HL OUT:BTC-78213-...-YES\"]\n    EV --> B[\"Polymarket condition_id 0xabc...\"]\n    EV --> C[\"Kalshi BTC_2026-05-03_78213_YES\"]\n\n    A -- 0.572 \u002F 0.575 --> Q1[(\"quotes\")]\n    B -- 0.561 \u002F 0.564 --> Q1\n    C -- 0.580 \u002F 0.583 --> Q1\n\n    Q1 --> ARB{\"net edge ≥ min_edge_bps?\"}\n    ARB -- yes --> ACT[\"buy cheap leg\u003Cbr\u002F>sell rich leg\"]\n    ARB -- no  --> SKIP[\"wait\"]\n```\n\nPer tick the strategy:\n\n1. Snapshots the YES top-of-book on every linked leg.\n2. Finds the cheapest ask and the richest bid.\n3. Subtracts per-venue fees (`fee_bps_per_venue`) plus Polygon bridging\n   (`bridging_bps_polygon` for Polymarket).\n4. If the surviving edge exceeds `min_edge_bps`, fires IOC orders on\n   both legs simultaneously. The qty is the smaller of top-of-book\n   depth, the configured `max_notional_usd`, and the Kelly-optimal\n   stake (next section).\n\nThe **inefficiency surface** below makes the signal visual. The X-axis\nis venue (HL · Poly · Kalshi), Y is the lookback window, Z is each\nvenue's `|YES − mean|`. A flat surface ⇒ venues agree. A peak ⇒ one\nvenue is dislocated. As soon as the peak crosses the cost-adjusted\nthreshold the white-ringed marker fires on the divergent venue, the\nbot lifts\u002Fhits both legs, and the surface flattens again — ready for\nthe next dislocation.\n\n![Cross-venue inefficiency surface — peak ⇒ arb signal](docs\u002Fdiagrams\u002Finefficiency.gif)\n\n> A real production deployment would also short-circuit through Hyperliquid's\n> `mintOutcome` action when the *minted* round-trip (mint YES on HL → sell\n> on Polymarket) is cheaper than buying YES on the open book — that's left\n> as a follow-up because it requires a USDH treasury, which has nothing to\n> do with strategy logic and a lot to do with operational plumbing.\n\n### BTC up \u002F down vs. perp parity\n\nThis is the most interesting signal — the binary outcome is exactly a cash\ndigital on the BTC mark price. Under the same risk-neutral measure that\nprices the perp, the YES leg's no-arbitrage value is\n\n```\nP(YES) ≈ Φ((ln(S\u002FK) − ½σ²τ) \u002F (σ √τ))\n```\n\nwhere `S` is the perp microprice, `K` the strike, `σ` the realised\nannualised vol of the perp, and `τ` the time to expiry in years. The bot\nmaintains an EWMA of `Δlog(S)² \u002F Δt` to estimate `σ` and updates the\nfair value continuously; whenever the YES mid drifts more than `min_edge`\naway from the surface, the strategy fires:\n\n| Edge sign         | Action on YES   | Hedge on perp        |\n|-------------------|------------------|----------------------|\n| YES rich  ( + )   | sell YES        | long BTC perp        |\n| YES cheap ( − )   | buy YES         | short BTC perp       |\n\nThe perp leg size is the digital's **delta**:\n`∂P\u002F∂S = φ(d) \u002F (S σ √τ)`. It is rebalanced any time the YES position\ndrifts by more than `delta_rebalance_thresh`, which means PnL only depends\non whether the YES leg returns to fair value — not on the realised path of\nBTC.\n\nThe animated surface below shows `P(YES)` over `(σ, S)` with τ shrinking\nfrom 12 h to 30 min over the run. The neon dot is the bot's live\n`(S, σ, YES_mid)` — when it leaves the surface the parity strategy fires\non the YES leg and emits the matching delta hedge on the perp:\n\n![BTC parity P(YES) — surface deforms as τ shrinks](docs\u002Fdiagrams\u002Fparity.gif)\n\n---\n\n## Kelly-criterion position sizing\n\nEvery order in the bot is sized by the Kelly criterion — the fraction of\nequity that maximises the long-run logarithmic growth of capital. Three\nspecialised forms (one per strategy) live in\n`crates\u002Fstrategies\u002Fsrc\u002Fkelly.rs`:\n\n### Binary outcome (parity strategy)\n\nWhen we have a point estimate `p_true` of the true YES probability and the\nmarket is offering YES at `p_market`, the closed-form Kelly fraction is\n\n```text\nf* = (p_true − p_market) \u002F (p_market · (1 − p_market))\n```\n\nPositive ⇒ buy YES, negative ⇒ sell YES (equivalently buy NO). For the\nBTC parity strategy `p_true = Φ((ln(S\u002FK) − ½σ²τ) \u002F σ√τ)` from the\nBlack-Scholes digital and `p_market` is the YES microprice, so the bot\nsizes itself precisely as much as the *information edge* warrants.\n\n### Continuous Kelly (market making)\n\nFor the AS market maker the per-fill expected return is the captured\nhalf-spread `δ` and the per-fill dispersion is `σ`:\n\n```text\nf* = μ \u002F σ²    (with μ = δ, σ = realised vol)\n```\n\nThis shrinks the quoted size as soon as realised vol explodes — which is\nexactly when adverse selection kills MM PnL — and grows it back when the\nbook quiets down.\n\n### Fee-aware arb Kelly (cross-venue)\n\n```text\nf* = (edge_bps − cost_bps) \u002F 10000\n     ─────────────────────────────\n              (var_bps \u002F 10000)²\n```\n\n`cost_bps` aggregates per-venue fees + Polygon bridging; `var_bps` is the\nempirical variance of the realised round-trip edge. The numerator can go\nnegative — in which case the strategy doesn't trade at all.\n\n### Practical safeguards\n\nFull Kelly is famously aggressive (50 % drawdowns are routine even on\npositive-expectancy bets). The bot's defaults are:\n\n| Knob (`config\u002Fdefault.toml`) | Default | Effect                                              |\n|------------------------------|---------|-----------------------------------------------------|\n| `kelly.fraction`             | `0.25`  | quarter-Kelly — ~ 75 % of full-Kelly growth at half the variance |\n| `kelly.max_fraction`         | `0.05` – `0.10` | hard cap on fraction of equity per trade   |\n| `kelly.min_qty`              | venue-specific | drop signals where the optimal stake is below the minimum quote |\n| `kelly.size_decimals`        | `2`     | snap to venue tick before submission                |\n\nThese are then passed through the same risk gate (drawdown \u002F kill switch\n\u002F open-orders cap) as every other order — Kelly tells you *what* the\nlog-optimal stake is, the risk gate decides whether you're allowed to\ntake it.\n\n---\n\n## Why Rust\n\nEvery microsecond between a HIP-4 book delta and a re-quoted post-only\norder is either captured maker rebate or adverse selection. The hot path\nbudget on a quote turn is roughly\n\n| Stage                                                      | budget       |\n|------------------------------------------------------------|--------------|\n| WS frame parse + book replay                               | ≤ 30 µs      |\n| AS quote computation (one floating-point pass)             | ≤ 5 µs       |\n| Risk check (DashMap lookups)                               | ≤ 3 µs       |\n| msgpack + keccak + EIP-712 sign                            | ≤ 50 µs      |\n| TLS write to `\u002Fexchange`                                   | ≤ 200 µs     |\n| **Total local turn-around**                                | **≤ 300 µs** |\n\nRust gives us deterministic latency without a GC pause, native TLS over\n`rustls`, and zero-copy WS parsing via `tokio-tungstenite`. The release\nprofile in `Cargo.toml` is configured for `lto = \"fat\"`,\n`codegen-units = 1`, `panic = \"abort\"`, which is what you actually want\nin a trading binary that ought to fail fast.\n\n> Comparable C++ would be *equivalent*. Go would not — its STW pauses\n> show up directly in the latency histogram. A scripting language would\n> not even keep up with the WS feed at peak.\n\n---\n\n## Configuration & running\n\n1. **Toolchain.** Project pins to stable Rust via `rust-toolchain.toml`.\n   Anything ≥ 1.85 works.\n2. **Secrets.** Copy `.env.example` to `.env` and fill in:\n   - `HL_OMM__VENUES__HYPERLIQUID_PK` — the EOA private key that owns\n     your Hyperliquid account (or an API agent wallet).\n   - Polymarket API triple (`KEY`, `SECRET`, `PASSPHRASE`, `MAKER`) and\n     Kalshi RSA-PSS key path \u002F id, if you want the cross-venue leg.\n3. **Markets.** Edit `config\u002Fdefault.toml#strategy` to match the daily\n   HIP-4 contract you want to trade. Tickers follow\n   `OUT:\u003CUNDERLYING>-\u003CSTRIKE>-\u003CYYYY-MM-DD>-\u003CYES|NO>` (parsed by\n   `outcome::parse_outcome_market_id`).\n4. **Build & run:**\n\n   ```bash\n   cargo build --release\n   RUST_LOG=hl_omm=info,info .\u002Ftarget\u002Frelease\u002Fhl-omm-bot\n   ```\n\n5. **Open** `http:\u002F\u002F127.0.0.1:8787` for the live dashboard.\n\n---\n\n## Repository layout\n\n```\n.\n├── Cargo.toml                    # workspace manifest, release-tuned\n├── rust-toolchain.toml           # stable channel\n├── config\u002Fdefault.toml           # all knobs (env-overridable)\n├── dashboard\u002Fstatic\u002F             # index.html + app.js + style.css\n├── docs\u002Fdiagrams\u002F                # the GIFs used in this README\n│   ├── dashboard.gif             #   ↳ live performance dashboard replay\n│   ├── as_surface.gif            #   ↳ Avellaneda-Stoikov quote band\n│   ├── inefficiency.gif          #   ↳ cross-venue inefficiency surface\n│   └── parity.gif                #   ↳ Black-Scholes digital surface\n│                                 #   live_snapshots.json is generated on\n│                                 #   demand by scrape_live.py — never committed.\n├── scripts\u002F\n│   ├── scrape_live.py            # live or historical capture → JSON (no synth)\n│   └── animate.py                # JSON snapshots → animated GIFs\n└── crates\n    ├── core              # venue-neutral domain types (Order, OrderBook, …)\n    ├── connectors        # hyperliquid, polymarket, kalshi (REST + WS)\n    │   └── hyperliquid   #   ↳ outcome.rs (HIP-4 ticker layout)\n    │                     #   ↳ signing.rs (msgpack + keccak + EIP-712)\n    ├── strategies        # avellaneda_stoikov, xvenue_arb, btc_parity, kelly\n    ├── risk              # position \u002F open-order \u002F drawdown \u002F kill switch\n    ├── dashboard         # axum web + WS streaming\n    └── bot               # binary (`hl-omm-bot`) - wires everything up\n```\n\n---\n\n## Risk model & safety rails\n\n```mermaid\nflowchart LR\n    Q[\"Strategy quote\"] --> C{\"check\"}\n    C -- \"kill switch?\" --> K1[\"REJECT\"]\n    C -- \"open orders > cap?\" --> K2[\"REJECT\"]\n    C -- \"abs(q + Δq) > max?\" --> RZ[\"RESIZE down\"]\n    C -- \"drawdown > limit?\" --> KILL[\"set kill switch + REJECT\"]\n    C -- \"else\" --> OK[\"PASS\"]\n    OK --> EX[\"connector → exchange\"]\n    RZ --> EX\n```\n\n- `max_gross_notional_usd` — soft cap on aggregate exposure across markets.\n- `max_per_market_qty` — hard ceiling on a single market's net position.\n- `max_open_orders_per_market` — guards against a runaway requote loop.\n- `max_drawdown_usd` — flips the kill switch and rejects new orders.\n- `stop_on_disconnect` — flatten + halt if any venue session is lost.\n\nRisk decisions emit a `RiskDecision::{Pass, Resize(qty), Reject(why)}`;\nthe strategy router resizes when allowed and logs the rejection with the\nbreached limit otherwise.\n\n---\n\n## References\n\n- Hyperliquid Docs — [Info endpoint](https:\u002F\u002Fhyperliquid.gitbook.io\u002Fhyperliquid-docs\u002Ffor-developers\u002Fapi\u002Finfo-endpoint),\n  [WebSocket](https:\u002F\u002Fhyperliquid.gitbook.io\u002Fhyperliquid-docs\u002Ffor-developers\u002Fapi\u002Fwebsocket),\n  [Subscriptions](https:\u002F\u002Fhyperliquid.gitbook.io\u002Fhyperliquid-docs\u002Ffor-developers\u002Fapi\u002Fwebsocket\u002Fsubscriptions),\n  [Exchange endpoint](https:\u002F\u002Fhyperliquid.gitbook.io\u002Fhyperliquid-docs\u002Ffor-developers\u002Fapi\u002Fexchange-endpoint)\n- HIP-4 mainnet launch — [Bitcoin News](https:\u002F\u002Fnews.bitcoin.com\u002Fhyperliquid-launches-hip-4-and-targets-polymarket-with-zero-fee-outcome-markets\u002F),\n  [CryptoTimes](https:\u002F\u002Fwww.cryptotimes.io\u002F2026\u002F05\u002F02\u002Fhyperliquid-launches-prediction-markets-can-it-rival-polymarket\u002F),\n  [Bitget News](https:\u002F\u002Fwww.bitget.com\u002Famp\u002Fnews\u002Fdetail\u002F12560605394797)\n- HIP-4 deep-dive — [QuickNode blog](https:\u002F\u002Fblog.quicknode.com\u002Fhip4-hyperliquid-outcome-contracts\u002F),\n  [Datawallet](https:\u002F\u002Fwww.datawallet.com\u002Fcrypto\u002Fhip-4-explained-hyperliquid-upgrade),\n  [HypeRPC](https:\u002F\u002Fhyperpc.app\u002Fblog\u002Fhyperliquid-outcome-trading-hip-4)\n- USDH stablecoin — [usdh.com](https:\u002F\u002Fusdh.com\u002F)\n- Polymarket — [Docs](https:\u002F\u002Fdocs.polymarket.com\u002F),\n  [Rust CLOB client](https:\u002F\u002Fgithub.com\u002FPolymarket\u002Frs-clob-client)\n- Kalshi — [API quick-start](https:\u002F\u002Fdocs.kalshi.com\u002Fgetting_started\u002Fquick_start_market_data),\n  [Order book API guide](https:\u002F\u002Fwww.quantvps.com\u002Fblog\u002Fkalshi-order-book-api-endpoints-explained)\n- Avellaneda & Stoikov 2008 — *High-frequency trading in a limit order book*\n\n---\n\nThis bot trades real money on real markets. Read the configuration before\nlaunch; start in testnet (`HL_OMM__NETWORK__IS_MAINNET=false`); verify the\nrisk caps; and watch the dashboard.\n","该项目是一个针对Hyperliquid平台上的HIP-4 Outcome Markets的低延迟、多策略做市和套利机器人。它采用Rust语言编写，以实现极高的执行效率。核心功能包括三种交易策略：基于Avellaneda-Stoikov模型的双边报价做市、跨平台套利以及比特币涨跌与永续合约之间的价差交易。这些策略共享同一订单簿缓存和风险管理机制，确保高效且安全地捕捉市场机会。适用于需要在高度竞争的市场环境中快速响应价格变动的场景，如高频交易或专业量化交易团队使用。","2026-06-11 04:06:43","CREATED_QUERY"]