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 — 218 registered components

Keel ships 218 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), regime detectors (FundingLevelRegime, FundingDispersionRegime, RealizedVolatilityRegime, a pairwise-correlation regime and others), 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 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 and a backtester to measure what you build from them.

Signal evaluation: the diagnostics that matter

Triage is where most research time goes. The standard diagnostics are 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. Keel does not compute these for you; the research guide explains how to compute and read each one.

The metrics are the easy part — every desk computes IC. The hard part is alignment: the value you evaluate has to be exactly the value the backtester and the live system will trade. No separate notebook with subtly different alignment, no skew from re-implementing the signal in pandas after it was prototyped in numpy. Keel covers the second half of that chain: a strategy is one pipeline definition that the backtester and live execution both run, so there is no second implementation to drift from the first.

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 Keel does not do today

Worth knowing before you plan a workflow around Keel:

• Signal diagnostics. IC, rolling IC, decay, half-life and quantile spreads are not computed in the product.
• Walk-forward optimization. Keel runs a backtest over any date window and keeps every run; it does not schedule rolling or anchored folds. To walk forward, run each fold as its own backtest over manually rolled IS/OOS dates and compare the results.
• Monte Carlo on backtests. Keel reports point-estimate metrics; block-bootstrap confidence intervals on Sharpe and drawdown are not computed in the product. The Lab Monte Carlo resampler does it in the browser on a returns series you paste.
• Automatic out-of-sample holdout. Keel does not split a backtest into train and holdout; a holdout is two backtests over disjoint date ranges.
• PBO and Deflated Sharpe. Bailey-Borwein PBO and Bailey-López de Prado DSR are not computed on the platform. The Lab has standalone calculators for both.

Everything else in the headline paragraph — 218 components, regime detectors, portfolio aggregation, vol targeting, the backtest engine, live parity — is shipped and in production use. Diagnostics like these may come to Keel in the future.