How the vault is designed, and what it must prove before it opens
Deposits and redemptions signed by your own wallet, a trading key that can only trade, and books that stop when they cannot prove their own balance. The design of our first vault, and the gates still ahead of it.
Our first official strategy will be offered through a non-custodial vault on Hyperliquid. Deposits are not open yet. This post describes how the vault is designed to work. It also covers what the vault still has to prove before anyone can put money in, which matters just as much.
The shape of it
A vault contract on HyperEVM, Hyperliquid's EVM chain, is bound to exactly one HyperCore trading account. HyperCore is the part of Hyperliquid where the perpetuals trade. Each vault has one strategy run, one ledger and one risk budget, and vaults never share a pool.
Depositing
- You sign the deposit from your own wallet. The approval covers that exact amount, not an unlimited allowance.
- You pay native USDC on HyperEVM straight to the vault contract. It never passes through an Algonius wallet.
- The payment and the issue of your shares happen in the same transaction. If the payment fails or arrives short, the whole transaction reverts and no shares are issued.
- The contract records your shares, and they cannot be freely transferred.
Trading
The vault's own HyperCore account does the trading. The key that places those trades lives in a separate signing service. It can only sign risk-checked trades for that one vault: it cannot send funds to another address, and it has no withdrawal rights. The program that runs the strategy never holds the vault's main wallet. Every new position passes the risk engine first. Trades can still lose money.
Redeeming
- Only the holder can request a redemption, by signing it.
- The payout goes to the address that made the request. No operator, keeper or administrator can change it.
- Your shares are burned or locked at a verified price, and that fixes what the vault owes you. The debt is cleared only by an actual USDC payment to your address. A timeout or a manual adjustment cannot clear it.
- When the vault needs to free up funds, it cancels orders and reduces positions. The money comes back to the vault's own address before it is paid to you.
Pricing, and when it refuses to price
Net asset value is the vault's USDC on HyperEVM plus its spot and perpetual equity on HyperCore, measured at one consistent checkpoint, minus what the vault already owes.
The hard case is money crossing the bridge between those two sides. While a transfer is in flight, or the two sides cannot be read at a matching checkpoint, the vault stops. It does not price deposits or redemptions, and it does not open positions. It never counts the same money on both sides. Nor does it assume a transfer has landed just because enough time has passed. Until the books agree, only cancels, reductions and safe exits are allowed.
What still has to be proven
The route is decided, but it is not proven yet. Before deposits open on testnet, each of the following must pass and be accepted independently:
- Protocol feasibility. How the deployed contracts and the bridge actually behave, including pauses, upgrades, fees, liquidity and checkpoints, and recovery from network failures and unknown results.
- The full testnet cycle for each strategy. Deposit, shares, real fills and fees, redemption to the same address, and a three-way reconciliation that rebuilds the ledger.
- Real users and real operations. Testers completing repeated full cycles, continuous monitoring, and an independent product review.
Mainnet comes later still. It needs an independent audit, a security and compliance review, a whitelist and operational approval. Until each gate passes, the shelf shows the strategy as paper and deposits stay closed.