Correlation Risk in Multi-Strategy Bots: Netting Exposure Across Venues

Three of our strategies once went short ETH beta at the same time without any of them knowing about the others. A Hyperliquid perp bot was short ETH directly. A Solana LP-hedging bot was short a basket that happened to be 40% ETH-correlated. And a Polymarket position on an "ETH ETF approval by Q3" market was, functionally, a long-vol short-price bet on the same underlying. On paper we had three uncorrelated alpha streams. In reality we had one 3.2x oversized short that got run over on a single green candle. Nobody sized it that way on purpose. The system just let it happen because no layer was looking at total exposure.

That is correlation risk in a multi-strategy bot, and it is almost always an accounting failure before it is a market failure. Each strategy manages its own risk correctly in isolation. The blowup lives in the gaps between them.

Why per-strategy risk limits don't add up

Every strategy you run has a position-sizing rule. Maybe it's a Kelly fraction with a vol target, maybe it's a fixed notional cap. Those rules are almost always local — they see only the positions that strategy opened. A Kelly-plus-vol-target sizer on a Hyperliquid bot does an excellent job keeping that book inside its risk budget. It has no idea another bot is expressing the same directional view through a different instrument.

The naive fix is to sum notionals. That's wrong too. $100k short ETH-perp and $100k short a SOL/ETH LP hedge are not $200k of correlated exposure, because SOL and ETH aren't perfectly correlated and the LP hedge has its own delta profile. Summing raw notional overstates risk and makes you leave money on the table. Ignoring correlation understates it and gets you liquidated. You need the middle path: net exposure in a common risk factor space.

Reduce everything to factor exposure

The core move is to stop thinking in "positions" and start thinking in factor betas. Pick a small set of risk factors that actually drive your P&L. For a crypto multi-strat book that's usually:

• BTC beta
• ETH beta
• A SOL / alt-L1 factor
• A stablecoin-depeg / basis factor
• Net vega (if you touch options or event markets)

Every position, regardless of venue, gets projected onto those factors. A Solana perp short is mostly SOL-factor with some BTC beta. A Polymarket "will SOL flip $X by date" contract is a nonlinear SOL bet you approximate with a local delta near current price. An ETH-perp short is almost pure ETH beta. Once everything speaks in betas, netting is just matrix math.

Concretely, you maintain a live exposure vector per strategy and sum them:

import numpy as np

# rows = strategies, cols = factors [BTC, ETH, SOL, DEPEG, VEGA]
exposures = {
    "hl_eth_perp":   np.array([  0.0, -100_000,      0.0,    0.0,     0.0]),
    "sol_lp_hedge":  np.array([-15_000,  -40_000, -60_000,    0.0,     0.0]),
    "poly_eth_etf":  np.array([  0.0,  -35_000,      0.0,    0.0, +12_000]),
}

net = sum(exposures.values())
# net ETH factor = -175_000  <-- the number nobody chose
gross = sum(np.abs(v).sum() for v in exposures.values())

# correlation-adjusted risk using a factor covariance matrix Sigma
port_vol = np.sqrt(net @ SIGMA @ net)   # annualized $ vol of the whole book

That net vector is the thing you actually risk-limit. In the example the ETH factor nets to -$175k across three "independent" strategies. If your book-level ETH limit is $120k, the netting layer should have blocked the third fill or forced the others to trim. The covariance term net @ SIGMA @ net turns it into a single portfolio-vol number you can put a hard ceiling on — that's the number that matters, not any individual strategy's self-reported risk.

Getting the betas right

The betas aren't constants, and this is where people cut corners and regret it. Use a rolling regression — 30-day hourly returns is a reasonable default — of each instrument against your factor returns, and refresh the covariance matrix SIGMA on the same cadence. Two gotchas that bite in production:

• Correlations go to 1 in a crash. Your calm-market SIGMA says SOL and ETH are 0.6 correlated. On a liquidation cascade they're 0.95. Keep a separate "stress" covariance matrix estimated only from your worst 5% of return days and run both. Limit against the stress number.
• Polymarket and event markets have unstable, path-dependent betas. A prediction contract at 0.5 has meaningful delta; the same contract at 0.95 barely moves. Recompute its factor loading from its current price on every cycle, not once at entry.

The netting layer sits between strategy and exchange

Architecturally, don't bolt this into any single bot. Put a pre-trade exposure gate in the order path that every strategy routes through. Before a fill is sent to Solana, Hyperliquid, or Polymarket, the strategy asks the gate: "I want to add this factor delta — is the book still inside limits after it?" The gate holds the live net exposure vector and either approves, trims, or rejects.

A workable flow:

1. Strategy computes intended factor delta for the order.
2. Gate adds it to the current net vector, computes projected port_vol against both normal and stress SIGMA.
3. If projected vol breaches the ceiling, gate returns a reduced size that just fits, or rejects.
4. On fill confirmation, the gate updates the authoritative exposure vector.

Keeping the gate as the single writer of the exposure vector is what prevents the race conditions that make this stuff fail silently. Two strategies firing simultaneously must not both read a stale "we have room" and both fill. Serialize the check-and-commit, or use optimistic concurrency with a version counter and retry.

This is the same discipline we push in a pre-trade circuit breaker for Solana depeg and stale-oracle conditions: the safety check belongs at the order-submission boundary, not inside strategy logic where a crash or a code path can skip it. And like the slippage and price-impact guardrails on a Jupiter swap bot, it has to be cheap enough to run inline on every order without adding meaningful latency.

Cross-venue mechanics that break the model

The math assumes you can see and value everything in one place. Reality fights you:

• Different settlement assets. Hyperliquid margins in USDC, Solana perps might settle in USDC too but your LP is in SOL, Polymarket is USDC on Polygon. Convert all exposure to a single USD reference at live prices, and treat the stablecoins themselves as a factor if you're running size — a USDC depeg is its own correlated event across all three venues.
• Latency skew. Your Solana position state comes from an RPC that might be 2–3 slots behind; Hyperliquid's websocket is near-instant. If you net a fresh Hyperliquid fill against stale Solana state you'll mis-size. Timestamp every exposure update and widen your limits by a latency buffer, or block trading when any venue's state is older than a threshold.
• Funding and carry aren't in the delta vector but they correlate too. Three positions all paying negative funding in the same regime is a correlated bleed even if their price betas net to zero. Track a separate carry line.

Start smaller than you think

You don't need the full covariance apparatus on day one. A single-factor version — just net BTC-equivalent beta across every position with a hard dollar cap — catches the majority of accidental-stacking blowups and takes an afternoon to wire in. Add ETH and SOL factors once that's stable, then the stress matrix, then vega. The instrumentation is worth more than the sophistication early on; you mostly need to see the net number before you can limit it.

If you're standing this up, the two things worth getting a second set of eyes on are the concurrency in the exposure gate and the beta estimation, since both fail quietly — a code review and audit catches the race conditions and stale-covariance bugs that don't show up until a volatile day. A live trading dashboard that plots net factor exposure alongside per-strategy exposure is the single most useful thing you can build here, because it makes the invisible stacking visible before it costs you, and keeping the factor models fresh as venues and instruments change is exactly the kind of thing ongoing support and maintenance exists for.

If you're running more than two strategies against correlated crypto venues and can't currently answer "what's my true net ETH exposure right now" in one number, that's the gap to close — and it's the kind of exposure-netting layer our code review and audit engagements are built to design and pressure-test.