Setting Portfolio Risk Limits Across Multi-Venue Algo Strategies

Running three bots across three venues looks like diversification until SOL drops 18% in forty minutes and every single one of them bleeds in the same direction. The failure mode is not the individual strategy — it is the absence of a layer above the strategies that treats the whole book as one portfolio. What follows is the framework we use when building and operating multi-venue algo systems: a concrete set of controls for position sizing, drawdown gating, and correlation-aware concentration limits.

Defining the Canonical Risk Unit

Before you can aggregate risk across Solana, Hyperliquid, and Polymarket, you need a single unit that all positions translate into. We use notional USD delta — the change in portfolio value for a 1% move in the underlying — normalised at the top level.

For a Hyperliquid perpetual SOL long at 5x leverage with $10,000 margin, delta = $50,000 × 0.01 = $500/%. For a Solana AMM LP position in SOL-USDC at $20,000 notional, delta is roughly half that because the IL curve means you hold less SOL as price rises; you model it as $250/% at current spot. For a Polymarket YES position on "SOL above $150 at month-end," you need an option delta: price the binary as a digital call and assign a percentage-of-notional delta that reflects current probability sensitivity.

This is tedious but not optional. Without it, your "portfolio view" is just a list of positions.

The Three-Layer Limit Stack

We structure limits in three concentric layers, each independently enforced:

1. Strategy-level limits — each bot has its own max open notional, max single-trade notional, and a per-session drawdown breaker. These live in the bot's own config and are enforced locally. They exist because a strategy may blow up even when the portfolio is fine.

2. Venue-level limits — aggregate notional per venue, independent of strategy. A single venue going down (or having a liquidation cascade) should not be able to take out more than a configured fraction of total equity. We typically cap any single venue at 40% of portfolio notional delta.

3. Portfolio-level limits — total net delta across all venues, total gross exposure, and rolling drawdown from high-water mark. The portfolio limit is the hard ceiling. When it is breached, all strategies get a kill signal before any individual strategy limit would have triggered.

A common mistake is to set limits only at layer 1 and assume that aggregation takes care of itself. It does not, because strategies can stack directional exposure independently while each staying within its own bounds.

Real-Time Net-Delta Aggregation

The aggregation service is the hardest operational piece. You need position data from three venues, each with a different API shape and latency profile, combined into a single number that is fresh enough to matter.

Our implementation uses a shared in-memory state store (Redis in practice, anything with sub-millisecond reads works) that each venue adapter writes to on every fill and every heartbeat mark. The portfolio risk engine reads from that store on a 250ms tick and recomputes net delta, gross exposure, and rolling drawdown. At 250ms you catch most intraday moves before they compound; going faster is possible but the marginal value drops quickly for strategies that are not pure HFT.

Key implementation details:

• Venue adapters write a position snapshot, not a delta-from-last. This means a missed message causes a stale snapshot, not silent accumulation of error.
• Each snapshot includes a last_updated timestamp. The portfolio engine treats any snapshot older than 2 seconds as stale and immediately pauses new order flow for that venue until a fresh snapshot arrives.
• Unrealised PnL is included in drawdown calculations. Mark-to-market matters for risk even if you have not closed the trade.

Correlation Clustering and Hidden Concentration

Net delta aggregation still misses one category of risk: two strategies that trade different assets but whose PnL is driven by the same factor. A Solana memecoin momentum bot and a Hyperliquid SOL perp trend-follower look decorrelated on paper until crypto risk-off arrives and they both dump simultaneously.

We run a weekly correlation pass on rolling 30-day hourly PnL vectors for each active strategy. Strategies with a pairwise correlation above 0.6 are assigned to the same correlation cluster, and the cluster has its own notional limit — typically tighter than the sum of the individual strategy limits would imply.

The practical effect: if you have three strategies in the same cluster that are each allowed $30,000 notional, the cluster cap might be $50,000 rather than $90,000. You are explicitly pricing in the correlation. This is the only mechanism that reliably prevents hidden concentration from building up over time as strategies evolve.

Kill-Switch Logic and Recovery

The portfolio-level kill switch does one thing: it sends a flatten-all signal to every venue adapter and blocks new order submission until a human re-enables it. It fires on two conditions — portfolio drawdown from high-water mark exceeding a threshold (we default to 5% of total equity on a rolling 4-hour window), or net delta exceeding the hard cap.

Critically, the kill switch does not try to be smart. It does not partially reduce. It does not assess which strategy caused the breach. It flattens everything. The reason is operational: partial reduction logic has edge cases that will bite you exactly when markets are moving fastest.

Recovery requires a human to review the state store, confirm positions are flat on all venues, and manually re-enable the system. We log the exact trigger condition, the portfolio snapshot at trigger time, and the flatten confirmation for each venue. That audit trail is what allows a fast, confident restart rather than a cautious multi-hour investigation.

---

If you are building or scaling a multi-venue algo operation and want a risk architecture reviewed or built from scratch, reach out — this is the kind of system we design and run in production.