From Strategies to Portfolios
We further construct diversified portfolio of instruments to trade.
Asset weights
Each trading strategy generates a signal/forecast for a single instrument. Now we need to combine these instruments into a diversified portfolio. This is where the system identifies how to allocate capital across different assets (E.g. $ETH, $BTC, $HYPE, $GOLD, e.t.c.).
The diversification challenge in crypto
Traditional portfolios benefit from low correlations between asset classes. Stocks and bonds often move inversely. Commodities provide uncorrelated returns. But in crypto, correlations are persistently high. During market stress, everything moves together. During the May 2022 collapse, for example, BTC, ETH, and major alts all dropped simultaneously with correlations exceeding 0.9.
Yet diversification still helps. Even with 0.8 correlations, a five-asset portfolio provides meaningful risk reduction compared to single-asset exposure. One major benefit of using Hyperliquid is the ability to eventually include tokenized stocks into the portfolio, which can benefit diversification a lot and further reduce correlations in the portfolio.
Portfolio weights
Our flagship portfolio keeps constant weights and is further enhanced by $HYPE allocation and LST (liquid staking token exposure) to enhance risk-adjusted returns further. Here's the portfolio asset allocation we propose for the HyperCroc launch:

Other possible portfolios we already mentioned in the docs use static instrument weights that reflect long-term strategic allocations:
Shallow Waters
100% to yield-generating stablecoins, vaults, lending protocols
Ultra-low risk
Swamp Wader
90% Yield 5% BTC 5% HYPE
Low-medium risk
Deep Swamp
70% Yield 10% HYPE 10% BTC 10% ETH
Medium risk
Apex Predator
Custom allocations (e.g. %100 to new farm or volatile-stable AMM pool).
Custom risk targets
These weights can be dynamically adjusted based on rolling correlation and volatility metrics to increase defensive positions when markets are tanking.
Optimized weights
However, our system is capable of supporting many different portfolios and custom Vault allocations, so we need a procedure to search for "optimal" weights. We use statistical bootstrap for this:
Normalize asset returns.
Chose a random subset of past returns.
Calculate correlations and expected returns.
Solve the "optimization" problem (e.g. maximize for risk-adjusted return with risk aversion gamma).
Record resulting asset weights.
Repeat from step 2 a number of times.
Average out asset weights from many optimisations, renormalise if needed.
Final calculation
Now have all components needed to calculate actual trading positions:
Asset forecast: Combined forecast for each asset (-1 to +1)
Volatility scale: Position multiplier based on target volatility
Asset weights: Allocation percentage for each asset
Portfolio value: Total capital available
The multiplication by 2 in the position calculation converts our -1 to +1 range into a -2 to +2 multiplier, allowing positions up to 2x the base allocation when conviction (the signal) is maximum.
Rebalancing and trade execution
Positions drift as prices move and trading strategies update their signals. We need systematic rules for when to rebalance.
Rebalancing triggers
We rebalance when the actual position diverges from the target position by more than a threshold percentage. The threshold balances responsiveness against transaction costs.
For liquid assets like BTC and ETH on HyperLiquid, we use a 10% threshold. If our target ETH position is 1.0 and actual position is 0.89 or 1.11, we rebalance. For less liquid assets, we use a 15% threshold.
Time-based rebalancing
Additionally, we execute a full rebalancing every optimal rebalancing frequency regardless of position drift. This ensures strategy signals don't become stale and positions don't drift excessively from targets during low-volatility periods.
Execution considerations
HyperLiquid's order book allows us to optimize execution beyond simple market orders. We use limit orders placed at mid-quote with time-in-force limits. If not filled within optimal timeout, we adjust toward market price. This reduces transaction costs without sacrificing too much execution certainty.
Last updated
