Introduction

1. Executive Summary

King’s Vault is a permissioned DeFi gateway that simplifies access to on-chain protocols through purpose-built smart contracts. Its products include Ethereum Network Lending, AAVE GHO Saving, and Hyperliquidity Provider (HLP).

Ethereum Network Lending

Deposit USDC to earn lending yield through Aave V3 and Morpho. Users hold King's Vault shares and withdraw in USDC. The King's Vault Performance Fee is 0%.

AAVE GHO Saving

Deposit USDC to earn yield through Aave sGHO. King's Vault handles the USDC → GHO → sGHO conversions, and users hold King's Vault shares rather than sGHO directly. Withdrawals are paid in USDC. The King's Vault Performance Fee is 0%.

Yield follows the variable sGHO savings rate. Aave/GSM conversion costs and network gas are separate from the Performance Fee. See deposits, withdrawals and costs, yield accounting, and contract addresses.

Hyperliquidity Provider (HLP)

Deposit USDC on Ethereum to access Hyperliquid's HLP strategy through the cross-chain integration. Withdrawals follow a request, Keeper execution, and claim process. Returns can be negative, and completion depends on underlying lockups, liquidity, and cross-chain processing. The King's Vault Performance Fee is 0%.

Shared Infrastructure

The V2 system connects these execution environments:

Ethereum Mainnet — the user-facing accounting hub, hosting the KingsVaultV2 / KingsVaultV2Async vaults and the Controller coordinator contract.
HyperEVM / HyperCore — Hyperliquid's EVM and trading execution environments, which share HyperBFT consensus. HyperEVM hosts HyperCoreAllocator and HyperCoreRouter; the HLP position is on HyperCore. HyperEVM is not a separate L2 chain. See Hyperliquid's architecture.

King's Vault V2 employs a two-phase NAV settlement model with active strategy management. Authorized Keepers dispatch capital through the Controller to registered strategies. The confirmed NAV mark is updated by proposal and confirmation, while strategy-reported values can change between confirmations. This separates settlement responsibilities but does not by itself eliminate manipulation, stale-data, or privileged-role risk.

2. Architecture Layers

Layer 1 — Vault (User Entry Points)

The vault layer accepts investor deposits and manages share issuance using a dual-pricing model.

Component	Description
KingsVaultV2	ERC-4626 vault with synchronous deposits and withdrawals. Triggers a liquidity waterfall from strategies when idle cash is insufficient.
KingsVaultV2Async	Asynchronous withdrawal variant. Shares are escrowed on `withdraw()`; a Keeper executes the batch, then investors `claim()` their assets.

Layer 2 — Controller (System Coordinator)

The Controller is a UUPS-upgradeable proxy contract acting as the central coordinator for the V2 vaults. It manages role-based access control, strategy registration, NAV settlement, and configurable performance fee accounting. The current performance fee rate for Ethereum Network Lending, AAVE GHO Saving, and Hyperliquidity Provider (HLP)—the V2 portals documented here—is 0%.

Component	Description
Controller	UUPS-upgradeable proxy. Manages RBAC, vault registry, NAV epochs (`proposeValues` / `confirmValues`), configurable performance fee accounting and conditional fee-share minting, fund invest/divest, and emergency procedures. The current fee rate for the V2 portals documented here is 0%.

Layer 3 — Strategies (Yield Adapters)

Strategy adapters implement the IStrategy interface (invest / divest / harvest / exit) and are registered with the Controller on Ethereum Mainnet. A shared interface does not make all strategies synchronous or equally liquid: valuation, exit capabilities, and completion checks remain strategy-specific.

Ethereum Mainnet Strategies

Strategy	Description
AaveV3Strategy	Deposits and withdraws USDC from the Aave V3 lending pool.
ERC4626Strategy	Generic wrapper for any ERC-4626-compatible vault (e.g., Morpho).
GHO Saving integration	Converts USDC to GHO and deposits into Aave sGHO. Accounting and user withdrawals remain USDC-denominated.
HyperStrategy	Cross-chain bridge strategy registered on Ethereum. Manages USDC flows to/from HyperEVM via Circle CCTP V2. See below for full flow.

HyperStrategy — Cross-Chain Bridge (Ethereum Mainnet)

HyperStrategy is a standard IStrategy adapter that lives on Ethereum Mainnet and is registered with — and managed by — the Ethereum Controller. It is the cross-chain gateway between the Ethereum vault and the HyperEVM execution environment.

Invest flow (Ethereum → HyperEVM):

Keeper calls Controller.fundInvest(vault, strategy, amount).
Vault transfers USDC to HyperStrategy through its Controller-gated fund-transfer entry point.
HyperStrategy.invest(amount) initiates a CCTP USDC burn on Ethereum. Circle's off-chain service produces an attestation after the required confirmations; a burn transaction alone does not complete delivery.
Keeper calls HyperCoreAllocator.handleInvestMessage(message, attestation) on HyperEVM, minting USDC and issuing internal shares. This function emits an UpdatedStateMessage via CCTP sendMessage for the Keeper to relay.
Keeper calls HyperStrategy.updateRemoteState(stateMessage, attestation) on Ethereum, triggering handleReceiveFinalizedMessage on HyperStrategy which updates the cached _totalAssets / _totalSupply.

Divest flow (HyperEVM → Ethereum):

Keeper calls Controller.fundDivest(vault, strategy, amount).
HyperStrategy.divest(amount) sends a CCTP RedeemMessage to HyperCoreAllocator specifying how many remote shares to redeem.
HyperCoreAllocator queues the request. Once sufficient remote assets have been unwound and collected into its idle balance, the Keeper executes the remote redemption, burning USDC on HyperEVM with an UpdatedStateMessage in the hook data.
Keeper calls HyperStrategy.completeDivest(message, attestation) — the CCTP transmitter mints USDC back to HyperStrategy on Ethereum, the hook data updates the cached _totalAssets / _totalSupply, and USDC is forwarded to the vault.

NAV tracking: HyperStrategy.totalAssets() combines cached remote value, tracked in-flight invest assets, and its local balance. It does not perform live cross-chain reads. The Keeper's NAV proposal therefore inherits the freshness and successful processing of the last accepted remote state update.

These are conceptual flows, not a substitute for a deployment-specific runbook. See cross-chain completion requirements and the current interface reference. Verify deployed entry points and message handling before execution.

HyperEVM Contracts (Not Managed by Ethereum Controller)

These contracts are deployed on HyperEVM and are not registered as strategies with the Ethereum Controller. They are the counterparts to HyperStrategy and contain the actual capital allocation logic inside Hyperliquid.

HyperCoreAllocator — Cross-Chain Entry Point (HyperEVM)

HyperCoreAllocator is a UUPS-upgradeable contract that acts as the HyperEVM-side counterpart to HyperStrategy. It maintains internal share accounting (ERC-4626 style) and coordinates asset routing to one or more HyperCoreRouter instances.

Invest flow (receiving USDC from Ethereum):

Keeper calls HyperCoreAllocator.handleInvestMessage(message, attestation) on HyperEVM with the message and Circle-produced attestation for the source burn.
CCTP verifies and processes the attested message, completing the destination USDC mint to HyperCoreAllocator.
Allocator mints internal shares proportional to the deposited amount (ERC-4626 virtual offset formula).
Allocator emits an UpdatedStateMessage (new totalAssets, totalSupply) via CCTP sendMessage. The Keeper fetches this attestation and relays it to Ethereum, allowing HyperStrategy.handleReceiveFinalizedMessage() to update its cached NAV.
Keeper calls HyperCoreAllocator.allocate(routerIdx, amount) to push USDC to a specific HyperCoreRouter.

Divest flow (sending USDC back to Ethereum):

HyperStrategy.divest() sends a RedeemMessage (number of shares to redeem) to HyperCoreAllocator via CCTP.
CCTP MessageTransmitter delivers the message; HyperCoreAllocator.handleReceiveFinalizedMessage() decodes it and increments pendingRedeemShares.
After the relevant HLP lockup and reverse-allocation stages complete, the Keeper collects the router's available HyperEVM USDC into the allocator's idle balance.
The Keeper uses the allocator's executeRedeem entry point to execute the pending redemption and initiate a return burn with state hook data, according to the deployed ABI. Its parameterization must be verified; do not confuse it with the Ethereum async vault's same-named method.
Keeper calls HyperStrategy.completeDivest(message, attestation) on Ethereum to finalize — USDC lands at HyperStrategy, hook data updates the cached state, and USDC is forwarded to the vault.

HyperCoreRouter — 3-Stage Asset Pipeline (HyperEVM ↔ HyperCore L1)

HyperCoreRouter connects HyperEVM ERC-20 balances with HyperCore accounting. Read precompiles expose HyperCore state, while the CoreWriter system contract at 0x3333333333333333333333333333333333333333 submits write actions for later HyperCore processing. Each dependent step requires confirmation of the previous result; the whole pipeline is not one atomic cross-environment operation. See interaction timing.

Valuation components: HyperEVM ERC-20 idle balance, HyperCore spot balance, withdrawable perp balance, and HLP equity, less the implementation's reserved fee. Accounting value does not imply immediate withdrawability.

Unit note: The documented USDC router converts 8-decimal spot amounts to 6-decimal USDC units. Do not generalize this conversion to every HyperCore field or token; confirm the deployed implementation's unit conversions and reserved-fee handling.

Invest path — EVM → Spot → Perp → HLP Vault:

Step	Function	Action
1	`depositToSpot(amount)`	Approves and deposits ERC-20 USDC into `CoreDepositWallet`, moving it from HyperEVM to the router's L1 spot balance.
2	`spotToPerp(amount)`	Sends a `USD_CLASS_TRANSFER` action via `CoreWriter` — moves funds from L1 spot into perp margin.
3	`perpToVault(amount)`	Sends a `VAULT_TRANSFER` (deposit) action via `CoreWriter` — deposits perp margin into the HLP vault.

Divest path — HLP Vault → Perp → Spot → EVM:

Step	Function	Action
1	`vaultToPerp(amount)`	Sends a `VAULT_TRANSFER` (withdraw) action via `CoreWriter` — withdraws from HLP vault into perp margin.
2	`perpToSpot(amount)`	Sends a `USD_CLASS_TRANSFER` action via `CoreWriter` — moves perp margin back to L1 spot.
3	`withdrawFromSpot(amount)`	Sends a `SPOT_SEND` action via `CoreWriter` to the base system address, triggering withdrawal back to HyperEVM ERC-20.

HLP has a four-day lockup from the most recent deposit into the underlying HLP account. For this integration, the relevant state is each router's HLP position, not simply the time an investor requests redemption. Keeper scheduling, subsequent deposits, available liquidity, and CCTP processing can affect completion; the portal's 96-hour estimate is not a guaranteed delivery time. Official HLP rules.

3. Key Design Principles

Dual-Pricing: Conversions compare the strategy-reported spot value with the last confirmed NAV mark. deposit(assets) issues the lower share amount; mint(shares) requires the higher asset amount; withdraw(assets) burns the higher share amount; redeem(shares) pays the lower asset amount. See the rounding table.
Two-Phase NAV Settlement: The Keeper proposes a new NAV snapshot (proposeValues), which the Admin then confirms (confirmValues). Performance fee shares can be minted only after confirmation and only when the configured fee rate is above 0%. The current V2 portal fee rate is 0%, so no fee shares are minted. Review of values and the security of the authorized accounts remain necessary.
Configurable Fee Model: The contracts support collecting performance fees by minting new shares directly to the feeReceiver address when a profitable epoch is confirmed and the configured fee rate is above 0%. The current V2 portal fee rate is 0%, so the mechanism is inactive and no performance fee shares are minted.
Liquidity Waterfall: When a synchronous withdrawal exceeds idle cash, KingsVaultV2 attempts to replenish liquidity from registered strategies via the Controller. Withdrawals can still fail if sufficient assets cannot be recovered. Vaults may retain idle capital, and HyperStrategy does not support synchronous replenishment.
Cross-Chain Accounting: User-facing V2 shares, confirmed NAV marks, and fee-share minting are on Ethereum. The HyperEVM allocator maintains its own internal shares and asset accounting. Attested state messages are relayed to Ethereum to update HyperStrategy's cached remote state before a subsequent NAV proposal and confirmation.
Strategy-Reported Valuation: NAV proposals use vault idle assets and registered strategies' reported values, not a uniform live price feed. Those reports can depend on underlying conversion rates, exit quotes, or cached cross-chain state. The Controller does not directly read the HyperEVM allocator across chains, and a reported value is not a guarantee of immediately recoverable USDC.

4. Terminology

Term	Definition
NAV	Vault idle assets plus registered strategies' reported values. Distinguish the current report from the Controller's last confirmed mark and from immediately withdrawable liquidity.
Dual-Price	Compares spot and confirmed-mark conversions with action-specific rounding; `withdraw(assets)` and `redeem(shares)` are different operations.
Epoch	A settled NAV snapshot. Each `confirmValues` call advances the epoch counter and locks in the new NAV as the confirmed mark.
Strategy	An adapter contract that deploys vault capital into an external yield protocol behind a standardized `invest` / `divest` interface.
Keeper	The authorized operator role that proposes NAV, invests/divests funds, sets fee rates, and executes async redemptions. The current V2 portal fee rate is 0%.
proposeValues	Called by the Keeper to snapshot asset value and share supply as separate fields of a pending NAV epoch.
confirmValues	Called by the Admin to promote the pending epoch to confirmed. Performance fee shares may be minted only if profit is recognized and the configured fee rate is above 0%; the current V2 portal fee rate is 0%.
CCTP V2	Circle Cross-Chain Transfer Protocol V2 — enables native USDC burn-and-mint across supported chains (used by `HyperStrategy`).
HLP	Hyperliquidity Provider — the protocol vault on HyperCore used by the cross-chain strategy. Returns depend on strategy performance and can be negative.
HyperCoreAllocator	HyperEVM contract that receives USDC from CCTP and allocates it into HyperCore.
Liquidity Waterfall	Attempts proportional replenishment from strategies when synchronous withdrawals exceed idle cash; completion still depends on recoverable liquidity.
emergencyRedeem	Post-shutdown function allowing investors to burn shares and receive a pro-rata share of remaining idle vault cash.