Vault Protections
The mechanisms that bound what can go wrong operationally, independent of whether the strategy makes money.
Valuation and settlement are separate permissions
The valuation manager can propose a NAV and nothing else. The curator can settle a NAV the valuation manager already proposed. Neither key can do the other's job, so a single compromised operational key cannot both invent a valuation and act on it.
The vault is configured so a proposed NAV never applies by timeout. It applies only through an explicit settlement.
A valuation that fails its checks is never used
Every computed NAV passes a set of guards before it can be pushed or settled:
- First NAV zero. On a fresh vault the first NAV must be zero, so the first depositor anchors the share price at par.
- Divergence cap. A NAV moving more than a configured number of basis points against the previous one is rejected. The HyperEVM deployment has run this at 1000 bps.
- Negative NAV is fatal. A negative computed value halts the cycle rather than being clamped.
- Per-cycle locks. One cycle at a time, so a slow cycle cannot overlap the next.
A NAV that fails a guard produces a missed settlement, not a mispriced one.
The first-NAV-zero rule exists because of a real failure. On a test vault a curator pushed an inflated first valuation, and the resulting share price of roughly 27 times par was permanent: the framework has no in-band way to unwind it.
The trading key cannot withdraw
On Hyperliquid the trading key is registered as an agent of the Safe. It can trade the account and cannot move funds out of it.
Venues and assets are allowlisted
Every asset and venue adapter sits on an admin-maintained allowlist. An unlisted venue cannot be used by the execution layer.
Execution bounds are enforced, not requested
Slippage bounds are computed from onchain TWAP prices rather than supplied by the backend. A minimum cooldown enforces spacing between rebalances. Aggregate notional per rebalance is capped as a fraction of NAV. A proposal that violates any of these is rejected atomically; there is no partial execution.
Pre-trade risk checks sit outside strategy code
Every order passes an independent, fail-closed risk engine before it reaches the venue: gross exposure, notional, traded-notional and delivered-volatility caps, all enforced separately from the strategy code that produced the order.
Daily-loss halts block new risk while always allowing the book to flatten, and allocation is constrained by a drawdown budget. Orders are skipped unless monitoring is provably alive: missing data never trades.
Stale signal means hold, never flatten
If the signal is stale the strategy holds its current book rather than closing it. Flattening on stale data would turn an information outage into a realised loss, at the moment the system knows least about the market.
Fee changes are delayed onchain
Fee rates sit behind a 24 hour cooldown. A change is visible as pending before it takes effect.
Emergency evacuation
The curator carries an eject subsystem: a kill switch that empties the vault's Hyperliquid footprint back into the Safe on HyperEVM and keeps it there until explicitly disarmed.
It exists for one scenario above all: the venue itself being compromised, an exploit in progress or credibly imminent, where every participant who realises what is happening is racing for the same exits. The design metric is therefore time to evacuation, not completeness of unwind: free collateral is bridged out first, positions are unwound and swept after. The same mechanism covers the slower case of a runaway strategy, where the urgency is lower but the mechanics are identical.
Two properties are worth knowing:
- Evacuated funds can only land in the Safe. The bridge action the eject uses carries no destination parameter; the recipient is implicitly the sender, which is the Safe itself. There is no address to mistype or hijack in a panic.
- While ejected, the vault stays out. The routine cycle that bridges idle USDC back to the venue is suppressed until an operator disarms the eject, so capital does not drift back into a venue that triggered an evacuation.
The trigger is a human operator. It is not a user-facing pause, and there is no Guardian role in the deployed contracts. Redemption requests keep queueing normally through an eject and settle once operations resume.
Monitoring
The curator pages a human on a signing key running low on gas, three consecutive failed cycles, and no successful NAV push within a watchdog window. Critical conditions escalate by SMS rather than chat alone.
That design followed an incident: in June 2026 a signing key ran out of gas and settlements froze for 34.7 hours while a single muted chat alert was deduplicated silently.