Alembix
Non-custodial vault infrastructure for Hyperliquid. Curators run trading strategies. Depositors hold vault shares. A contract holds the funds, prices the shares and enforces exits.
Overview
A vault pools deposits around one strategy. Depositors receive shares whose value follows the vault's results. The curator (a trader, quant desk, market maker or fund) chooses the strategy and the keys that run it, but cannot take the funds.
On Hyperliquid today, putting money into someone else's strategy means trusting whoever controls the account, or trusting a team that computes the vault's value offchain. HyperEVM changes that: a contract can now own a HyperCore trading account (through CoreWriter) and read its state (through precompiles). Alembix builds on that.
- Each vault is a HyperEVM contract that owns its own HyperCore account.
- The curator trades through a narrow set of typed actions. There is no generic call and no Hyperliquid API wallet.
- The contract computes the vault's value from onchain state. No one posts a price.
- A matured withdrawal can be processed by anyone, not only the team or the curator.
- Shares are a standard transferable ERC-20, so they can be held in any EVM wallet and later used elsewhere in DeFi.
Permissionless to build, curated to discover
Anyone can create a vault from the factory: the contract guarantees are the same for every vault. Trust in the strategy comes from a separate curation layer in the app, where each curator gets a registry tier:
- Institutional: established firms, with the broadest verification.
- Verified: curators reviewed by Alembix.
- Community: open to anyone, with limited verification.
A tier is about who runs the strategy, not a recommendation: custody and exits work the same in every tier, and any vault can lose money.
Why it's different
Every vault platform has to answer one question: how does the chain know what the vault is worth? The answer decides who depositors have to trust.
| Alembix | Buoy | Rini | |
|---|---|---|---|
| Who values the vault | The contract, from onchain state | An offchain service run by the team | An offchain keeper; the team's Safe settles |
| Who can process a withdrawal | Anyone, once it matures | The team's service | The team's Safe, once margin is free |
| Curator's power | Trade only, inside a market set fixed at launch | Trade only | Trade only |
| Markets in v1 | Hyperliquid perps, major spot markets, trade.xyz (HIP-3) | Broader, since valuation happens offchain | |
Buoy and Rini value vaults offchain, which gives curators a wider mandate and makes depositors trust the valuer. Alembix fixes each vault's markets at creation, so the contract can price everything the vault can hold. The mandate is narrower, and there is no trusted valuer.
Comparison based on our review of each platform's public contracts and docs, September 2026.
Protocol design
Contracts
Eight deployed contracts: the vault, three fixed vault modules (Authority, Redeem, Trading), two fixed registry modules, the vault config and a factory. The factory only creates vaults from qualified templates, as EIP-1167 clones. There is no upgrade path: a clone is bound to its implementation for life.
Two layers
HyperEVM runs the contracts. HyperCore is Hyperliquid's native exchange, where trading and custody actually happen. Each vault's HyperCore account has the same address as the vault contract.
- Writes go through CoreWriter. A successful EVM transaction only proves the action was queued. The contract treats it as done only after it observes the result on HyperCore.
- Reads go through precompiles: balances, account values, positions and marks. If a required read fails, the operation reverts. The protocol never guesses a value.
Market envelope
Each vault declares at creation exactly what it can hold. In v1, that is the set where most Hyperliquid volume and most systematic strategies live:
| Venue | v1 scope |
|---|---|
| Hyperliquid perps | The native perp DEX: BTC, ETH, SOL, HYPE and the rest of the list, except isolated-only markets |
| Spot | The major spot markets against USDC: HYPE, BTC (UBTC), ETH (UETH) and SOL (USOL) |
| HIP-3 | trade.xyz, the USDC-collateral DEX for equities and other real-world markets (for example NVDA) |
| Deposit and accounting asset | USDC |
The set is fixed because the contract has to read and price every place the vault can hold value, in every NAV computation. A short, liquid list keeps that complete and affordable, and avoids pricing thin spot tokens whose marks are easy to move. Tokens and venues cannot be added to an existing vault. Within the set, a per-vault market policy can restrict markets, cap order notional or bound order prices against a reference. Tightening the policy is immediate; relaxing it goes through the delay.
Scope and what comes next
v1 starts deliberately narrow: perps, the big spot markets and trade.xyz. New markets and venues (more HIP-3 DEXes, HIP-4 outcome markets, lending, Portfolio margin mode) come as new vault templates when curators ask for them; existing vaults keep the envelope they launched with.
The longer goal is for a vault to be operated with the same breadth as a regular Hyperliquid account, from a frontend or through an API. Part of that depends on CoreWriter itself, for example confirming execution and not only submission, and we are discussing those limits with the Hyperliquid ecosystem.
Valuation
NAV is the value of everything in the envelope (spot balances priced at HyperCore marks, plus the account value on each perp DEX) minus a small execution reserve that belongs to the vault and not to depositors. Share price is NAV divided by share supply. Deposits mint at this price and withdrawals are priced when their batch executes, not when they are requested.
The NAV is exact with respect to HyperCore's marks, but a mark is not a guaranteed liquidation price. In stressed markets, realizable value can differ.
Account mode
Vaults run in Hyperliquid's Unified account mode, so the same USDC backs spot and perp positions. A vault starts in Standard mode and switches to Unified once during launch.
Roles
The curator chooses who holds each role. These are four permissions, not four required people: one address can hold several, and the app should say so when it does. Alembix offers a dedicated multisig as the default Guardian; it responds to incidents and does not run the strategy.
| Role | Can | Cannot |
|---|---|---|
| Owner governance | Launch the vault, schedule role changes and unpauses, relax market policy (after the delay), pause, reduce risk, enter WindDown, rescue unrelated tokens | Change the vault's value, withdraw depositor funds, edit fees or the market set |
| Manager daily operations | Submit the launch mode command, prepare liquidity for withdrawals, tighten market policy, run cleanup | Place trades unless it also holds the Trading Wallet role, set withdrawal prices, move funds out |
| Trading Wallet strategy execution | Place and cancel orders inside the envelope, route cash back to spot | Withdraw, send funds to any other address, act as an API wallet |
| Guardian safety | Pause, revoke the Manager or Trading Wallet, cancel pending changes, tighten policy, enter WindDown | Trade, move funds, grant roles, enable risk |
| Anyone | Prepare liquidity for matured withdrawals, observe it, arm and execute settlement | Claim someone else's withdrawal |
Changes that add power (granting a role, lifting a pause, relaxing policy) wait 72 hours on mainnet, which gives depositors time to exit and the Guardian time to cancel. Changes that reduce power (pausing, revoking, tightening, WindDown) apply immediately. WindDown is irreversible.
A Guardian could close a healthy vault by forcing WindDown. This is accepted in v1 because the Guardian cannot take value or block exits.
Parameters
Fees and the market set are fixed when a vault is created and cannot change afterwards.
| Parameter | v1 value |
|---|---|
| Management fee | Set per vault, at most 5% a year |
| Performance fee | Set per vault, at most 50% of gains above the high-water mark |
| How fees are paid | Minted as new vault shares |
| Protocol share | 10% of minted fee shares |
| Entry fee, exit fee, hurdle | None |
| Curator stake while Live | The seed recipient chosen by the curator keeps at least 5% of shares |
| Withdrawal notice | Set per vault at creation, from 0 to 72 hours |
| Delay on power-adding changes | 72 hours on mainnet (60 seconds on testnet) |
| Liquidity preparation expiry | 900 seconds |
| Withdrawals priced per batch | Up to 12 |
| Minimum order size | 10 USDC notional |
| Optional order limits | Per-order notional cap, maximum deviation from a reference price |
| Execution reserve | 1 USDC per vault, excluded from NAV |
| Deposit asset | USDC |
Processes
Vault lifecycle
Bootstrapping → Live → WindDown → Terminal
- Bootstrapping. The factory creates the vault from a qualified template with a seed deposit. The Manager sends the one-time command that switches the account to Unified mode, and the Owner confirms launch once it is observed. If launch fails, the seed can be recovered through an abort path.
- Live. Deposits, trading and withdrawals.
- WindDown. Entered by the Owner or Guardian, permanently. No new deposits or risk. Cancels, reduce-only cleanup and all exits continue. Management fees stop accruing.
- Terminal. All shares are burned and all claims paid. A finished vault is never reused.
Deposit
The depositor sends USDC. The vault mints shares at the current share price and moves the full amount to its HyperCore account.
Trading
The Trading Wallet places orders through the vault. The contract checks each order against the market policy, encodes it as a typed HyperCore action and submits it. The result shows up in the vault's HyperCore state and therefore in NAV.
Withdrawal
Withdrawals are asynchronous and go through a single first-in, first-out queue.
- Request. The depositor locks shares in the queue. A request cannot be cancelled.
- Notice. The request matures after the vault's notice period.
- Prepare. USDC is moved from HyperCore to the vault on HyperEVM, then the contract observes that the move actually happened. After maturity, anyone can do this if the cash is already available.
- Settle. Anyone arms and executes the batch. Pricing, burning the shares and assigning the USDC happen in one transaction.
- Claim. The depositor, or an operator they approved, collects the USDC.
Funded exits cannot be paused or redirected, by anyone. If the vault's capital is still in open positions, freeing it depends on the trading side unwinding. v1 does not include a forced unwind. The Guardian's answer to an unresponsive curator is WindDown.
The app
The interface is built as an allocator's terminal rather than a retail DeFi app. Its job is to answer three questions before anyone deposits: what does the strategy do, who controls what, and how do I get out. The preview at alembix.xyz connects a browser wallet on HyperEVM testnet; deposits and withdrawals are previews and vault figures are mock values.
What you see that vault platforms rarely show
- Custody, stated on the vault page. A "Non-custodial by contract" banner says the curator's trading key can trade but cannot withdraw, with a link to how that is enforced.
- Who holds each role. A roles and contracts section lists the vault contract, the trading key, the Owner and the Guardian, and shows "Not assigned" when a role is empty instead of hiding it.
- What the vault is allowed to touch. A risk and exposure section lists the venues, the settlement asset and the maximum leverage the strategy can use, next to the safeguards that apply.
- The exit before the entry. The deposit and withdraw panel shows the withdrawal notice and remaining capacity up front, so the asynchronous exit is known before any request.
- Typed activity. Recent operations separate deposits, withdrawal requests and settlements, with statuses such as Queued and Claimable, so the withdrawal pipeline is readable.
- Curator profiles. Each curator has a page with type, tier, description, vaults, TVL, founding year and base. Allocators choose a team before they choose a vault.
- Registry tiers. Institutional, Verified and Community appear as a badge, a column and a filter, so the level of verification is always visible.
- Returns over several windows. Net APR over 7 days, 30 days and since launch, so one good week does not hide the trend.
- Capacity. How full the vault is relative to its cap, both in the list and on the vault page.
Vault list
Two views: cards for newcomers, and a comparison table for allocators (Vault, Tier, Curator, Net APR, TVL, Capacity, Risk, Age). Filters by registry tier and APR window, and search across vault names, curators and strategy types.
Coming next
- Exposure breakdown by asset, side (long or short) and venue, instead of a raw list of positions.
- A withdrawal stepper (request, notice, preparation, settlement, claim) inside the withdraw panel.
- A fees view that separates curator fees from the protocol share.
- A solvency view per vault. Because NAV is computed onchain, it can be checked directly; testnet.alembix.xyz is a first version.
Label mapping between the app and the protocol: "Curator agent" is the Trading Wallet, and "Owner timelock" is the Owner role with its built-in delay.
Status and links
- Done: v1 specification (16 September 2026), contracts, full testnet qualification (23 September 2026): deposits, spot, perp and HIP-3 orders, onchain NAV and a public withdrawal through to Terminal.
- Next: independent review of the contracts, a first mainnet vault funded by the team, then a public launch once both are clean.
- Deferred from v1: HIP-4 markets, lending, Portfolio mode, faster redemption paths.