Devine Group

Native Hyperliquid Vault Platform Integration

Overview

The Devine OS Hyperliquid Native Vault System runs on Arbitrum and Hyperliquid L1, providing institutional‑grade quantitative trading strategy access to DeFi users.

It operates like the standard Devine OS bridged vaults, with one key difference:

When bridging from Arbitrum to Hyperliquid L1, funds are deposited from the pooled devine OS wallet directly into a Hyperliquid native vault.

This means capital is custodied within Hyperliquid’s vault infrastructure from the moment it reaches L1, giving users direct exposure to the vault’s managed strategy while still benefitting from Devine OS’s batching, fee handling, off‑chain coordination and ERC‑4626 tokens.

Key Parameters

  • Deposit fee: <DEPOSIT_FEE_PCT>% (e.g., 0.20)

  • Performance fee: <PERFORMANCE_FEE> (e.g., None / 0%)

  • Custody: Hyperliquid native vault (non‑custodial under Hyperliquid protocol rules)

  • Bridge path: Arbitrum ERC‑4626 vault → Devine OS platform wallet → Hyperliquid bridge → Hyperliquid native vault

Deposit Flow for Users

1. User Initiation (Frontend → Smart Contract)

  • User enters deposit amount via Devine OS frontend.

  • The frontend calls depositUSDC(<AMOUNT_USDC>) on the Arbitrum‑based HyperliquidVaultRouter ERC‑4626 contract.

  • Contract:

    • Checks user balance & allowance.

    • Deducts <DEPOSIT_FEE_PCT>% deposit fee.

    • Records the net amount as a pending deposit under a unique user‑specific nonce.

    • Emits DepositInitiated(user, <NET_AMOUNT_USDC>, nonce).

2. Off‑Chain Batch Processing (Devine OS → Platform Wallet)

  • Devine OS backend listens for DepositInitiated events.

  • Deposits are batched into a single transfer for efficiency.

  • Backend prepares a batch transaction from the Arbitrum vault to the Devine OS platform wallet.

3. Bridging to Hyperliquid L1

  • The platform wallet calls batchedDepositWithPermit on the Hyperliquid Bridge contract, moving the batched funds from Arbitrum to Hyperliquid L1.

  • The bridge destination is the Devine OS Hyperliquid L1 account (platform‑controlled).

4. Immediate Transfer to Native Vault

  • Upon L1 receipt, Devine OS immediately transfers the bridged funds into the Hyperliquid native vault via the Hyperliquid SDK:

    • vault_usd_transfer(<VAULT_ADDRESS>, is_deposit=true, amount_micro=<AMOUNT_MICRO>)

  • This moves capital from the Devine OS Hyperliquid L1 wallet into the vault’s custody.

  • Hyperliquid vault applies the native vault performance attached to the Devine OS platform wallet that represents the pooled funds, so credited amount matches the pending deposit record.

5. On‑Chain Deposit Confirmation

  • Devine OS verifies via Hyperliquid API that:

    • The vault received the exact net amount.

    • The transaction ID matches the bridge + vault transfer.

  • Backend calls confirmDeposit(user, <NET_AMOUNT_USDC>, <TX_HASH>, nonce) on the Arbitrum vault contract:

    • Confirms pending deposit.

    • Mints ERC‑4626 shares to the user based on current NAV.

    • Emits DepositConfirmed.

6. User Notification

  • Frontend updates user’s vault share balance.

  • Transaction references for both the Arbitrum bridge and the Hyperliquid vault deposit are shown to the user.

Withdrawal Flow for Users

1. User Initiation (Frontend → Smart Contract)

  • User requests withdrawal by specifying share amount via frontend.

  • Frontend calls initiateWithdrawal(<SHARE_AMOUNT>) on the Arbitrum vault.

  • Contract records withdrawal request and emits WithdrawalInitiated.

2. Off‑Chain Batch Processing

  • Devine OS batches withdrawals for settlement.

  • Calculates total USDC needed from the Hyperliquid native vault.

3. Native Vault → L1 Wallet Transfer

  • Devine OS calls:

    • vault_usd_transfer(<VAULT_ADDRESS>, is_deposit=false, amount_micro=<AMOUNT_MICRO>)

  • This moves USDC from the Hyperliquid native vault to the Devine OS Hyperliquid L1 wallet.

4. Bridging Back to Arbitrum

  • From the L1 wallet, funds are bridged via Hyperliquid Bridge contract back to the Arbitrum vault contract’s custody.

5. On‑Chain Withdrawal Confirmation

  • Devine OS calls confirmWithdrawal(user, <SHARE_AMOUNT>, <TX_HASH>, nonce):

    • Burns the user’s shares.

    • Transfers bridged USDC to the user’s Arbitrum wallet.

6. User Notification

  • Frontend shows net USDC received and transaction references for:

    • Hyperliquid vault withdrawal

    • L1 → Arbitrum bridge transfer

    • On‑chain withdrawal confirmation

Example Timeline

Deposit

  • <T_DEPOSIT_START> — User deposits <DEPOSIT_AMOUNT_USDC> USDC → Arbitrum vault.

  • <T_FEE_APPLIED> — <DEPOSIT_FEE_PCT>% fee applied, <NET_AMOUNT_USDC> USDC pending.

  • <T_BRIDGED_OUT> — Batched and bridged to Hyperliquid L1 wallet.

  • <T_VAULT_TRANSFER> — Funds immediately transferred to Hyperliquid native vault.

  • <T_CONFIRMED> — Devine OS confirms deposit on Arbitrum and mints shares.

Withdrawal

  • <T_WITHDRAW_INIT> — User initiates withdrawal of <SHARE_AMOUNT> shares.

  • <T_BATCH_READY> — Withdrawals batched; liquidity prepared.

  • <T_VAULT_TO_L1> — Native vault transfers <WITHDRAW_USDC_FROM_VAULT> USDC to L1 wallet.

  • <T_BRIDGED_BACK> — Funds bridged back to Arbitrum.

  • <T_WITHDRAW_CONFIRMED> — On‑chain withdrawal confirmed; user receives <NET_USDC_TO_USER> USDC.

PreviousHyperliquidVaultRouter ContractNextNon-Custodial Vault Management Schematic

Last updated