Quant research on Hyperliquid

What Hyperliquid gives you that other venues don't

Hyperliquid is the deepest open perp orderbook in crypto with a real, programmatic API. That sentence does most of the work. The implications stack up quickly: a public REST and websocket surface that exposes the same data the GUI sees; a funding mechanism that accrues every hour against the mark price (not every eight hours, not via index-only proxies); a fee schedule with explicit maker/taker tiers; and an L1-settled clearing model that makes fills and PnL reproducible from a block, not from a private exchange ledger.

For a quant, that combination is rare. Most CEXes give you data with caveats — rate-limited history, throttled websockets, missing funding, opaque fee tiers. Most DEXes give you slippage that wrecks any signal under a 12-hour holding period. HL gives you both depth and openness, which is what evidence-based research needs. You can compute realistic costs, you can source clean funding, you can replay your own fills against the public state. That is the table-stakes you build on top of.

The component library — 199 registered components

Keel ships 199 registered pipeline components, all visible to the executor and searchable from the strategy builder or via keel components search on the CLI. They break down into data loaders (price, funding, open interest), signals (cross-sectional momentum, carry, mean-reversion, dispersion, basis), five regime detectors (FundingLevelRegime, FundingDispersionRegime, plus vol-, trend-, and correlation-based regimes), portfolio aggregators (forecast weighting, rank normalization, sign splitting), risk overlays (vol targeting, position caps, gross/net leverage limits), and a handful of execution operators (buffered rebalancer, neutralization, sector caps).

This is a composable toolkit, not a curated catalog. There is no 199-row table of pre-stamped IC, ICIR, and half-life numbers for every component against every universe — that kind of catalog requires opinionated choices about universe, horizon, cost model, and decay window that you are better off making yourself for your strategy. What you get is the composable parts plus the evaluation surface to triage them on your own data.

Signal evaluation toolkit

Triage is where most research time goes. Keel's signal evaluators are the same ones used internally to decide which components survive: information coefficient (Pearson and Spearman) computed cross-sectionally per bar, rolling IC across a window for stability, IC half-life from the decay curve, quantile spread (top decile minus bottom decile) for monotonicity, and turnover and cost-sensitivity diagnostics for whether the signal survives realistic frictions.

The point of the toolkit is not the metrics — every desk computes IC. The point is that they wire into the same pipeline that produces the signal, so the value you evaluate is exactly the value the backtester and the live broker will see. No separate research notebook with subtly different alignment, no skew from re-implementing the signal in pandas after it was prototyped in numpy. Build it once as a component, then evaluate it, backtest it, and deploy it as the same thing.

Backtesting that mirrors live

The Keel backtest engine is a production-grade portfolio simulator. It applies per-instrument funding to cash at the native hourly cadence between bars, tracks cumulative funding separately so the equity curve decomposes into price-only and funding components, models fees from the HL maker/taker schedule, and applies slippage from a configurable spread model. It runs on the full universe in one pass, not as a per-asset Python loop.

The non-trivial property is that the buffered rebalancer used in the backtest is the same component used live. When you size in the backtest with a 10% drift band, live execution reads the same component config and only fires trades when actual position drift exceeds 10% from target. No translation layer, no separate live config that diverges from the research config. The pipeline graph is the contract between research and execution.

What's not yet shipped

The following are on the roadmap, not yet shipped:

• Walk-forward optimization. Single-window backtests are shipped; rolling and anchored WFO is not. If you need it today, run multiple single-window backtests across manually rolled IS/OOS dates and stitch the results.
• Monte Carlo on backtests. Block-bootstrap resampling for Sharpe and drawdown confidence intervals is roadmap. The lab-app Monte Carlo resampler widget covers the offline case in the browser.
• Out-of-sample holdout at strategy level. Signal-level OOS subsampling exists; strategy-level train/test/holdout splitting is roadmap.
• PBO and Deflated Sharpe. Bailey-Borwein PBO and Bailey-López de Prado DSR diagnostics are not shipped on the platform. Use the lab-app calculators in the meantime.

Everything else in the headline para — 199 components, IC and decay, regime detectors, portfolio aggregation, vol targeting, the backtest engine, live parity — is shipped and in production use.