Before you send an order there are two questions: which way is price going, and what will your own order do to it. Most signal work obsesses over the first and ignores the second — which is backwards, because the second one is directly measurable. Kyle's lambda is the canonical measure: the price impact per unit of signed order flow. Illiquidity, expressed as a number.

The model in one paragraph

In Kyle's 1985 model, a market maker faces a blend of informed and uninformed flow and protects herself by moving price linearly with net order flow: net buying arrives, she marks price up; net selling, she marks it down. The slope of that line is lambda (λ). Empirically you estimate it the same way — regress short-horizon price changes on signed volume — and the result reads directly: high λ means small flow moves price a lot (a thin, informationally fragile market); low λ means the book absorbs size without repricing. λ is the inverse of depth, in units you can act on.

Why intraday crypto needs it

Lambda is anything but constant in crypto. It compresses when market makers quote competitively and spikes when they step back — around liquidation cascades, funding windows and session handoffs. The same order costs a different amount at different hours of the same day, and λ is how you see that before paying it. That makes it double-duty: a pre-trade cost input, and a regime gauge — an abrupt rise in price_discovery.kyle_lambda@1h:zscore says the book has thinned, whatever price itself is doing.

Sizing — in the linear model, expected impact is λ × size, so the gauge maps straight onto participation limits: scale down as λ rises.
Regime filtering — gate mean-reversion entries on λ. Reversion logic assumes someone will absorb your flow, which is exactly what is missing when λ spikes.
Cross-checking — price_discovery.amihud_illiq (absolute return per unit of volume, after Amihud 2002) and price_discovery.roll_spread (the effective spread implied by price-change autocovariance, after Roll 1984) measure illiquidity from different angles; when all three rise together, the thinning is real.
Comparing assets — use the pctrank transform so 'illiquid for BTC' and 'illiquid for SOL' are each read against that asset's own distribution.

All of these are served signals in the price-discovery category, alongside price_discovery.hasbrouck_spread for an information-based read of the effective spread. Price discovery is a Quant-tier category — gating is listed per plan on pricing and per signal in the catalog.

bash

# Was the book thin at my decision times? λ, its z-score, and two cross-checks
curl -s -X POST https://api.quant-api.dev/v1/features/historical \
  -H "Authorization: Bearer fk_live_<secret>" \
  -H "Content-Type: application/json" \
  -d '{
    "rows": [
      {"asset": "BTC", "as_of": "2026-06-09T13:00:00Z"},
      {"asset": "BTC", "as_of": "2026-06-09T14:00:00Z"}
    ],
    "features": [
      "price_discovery.kyle_lambda@1h:level",
      "price_discovery.kyle_lambda@1h:zscore",
      "price_discovery.amihud_illiq@1h:pctrank",
      "price_discovery.roll_spread@15m:level"
    ]
  }'

◆

Impact estimates are unusually easy to leak: λ at time T must be estimated from trades up to T, not from a window centred on it. Centre the regression window — as plenty of research code quietly does — and your backtest 'predicts' impact using trades that had not happened yet. QUANT_API resolves every value strictly from data with ts <= as_of, live and historical, so the λ in your matrix is the one that was estimable at that instant.

Lambda will not tell you which way price is going. It tells you what acting on your view will cost, and how fragile the market is while you do it — often the difference between a signal that survives execution and one that dies in slippage. Pull the live values with GET /v1/features/live, build the matrix above for your own timestamps, and see the leak-free backtesting guide for the methodology underneath.

Browse the catalog — 161 signals, point-in-time ↗