Skip to content

HyperEVM Cross-chain Flow

This document details the cross-chain bridging process from the source chain (Ethereum) to HyperEVM using HyperStrategy and Circle CCTP V2, as well as the internal allocation inside HyperEVM.

This is the V2 HLP strategy flow. It does not describe GHO Saving's same-chain conversion route or the separate per-user V3 GHO Staking product, which is hidden from the public mainnet frontend. The diagrams describe multiple transactions and asynchronous processing, not a single atomic operation or executable ABI. Verify each target's deployed entry points and parameters before use; see pending deployment verification.

Cross-chain Invest: Source Chain To HyperEVM

sequenceDiagram
    participant Keeper
    participant Controller
    participant HyperStrategy
    participant CCTP
    participant Allocator as HyperCoreAllocator

    Controller->>HyperStrategy: invest(amount)
    HyperStrategy->>CCTP: depositForBurn(amount, HyperEVM, allocator)
    HyperStrategy->>HyperStrategy: processingAssets += amount
    Keeper->>Allocator: handleInvestMessage(message, attestation)
    Allocator->>CCTP: receiveMessage()
    Allocator->>Allocator: mint internal shares
    Allocator->>CCTP: send state message back
    Keeper->>HyperStrategy: completeInvest/updateRemoteState

Key State Tracking

Contract Field Meaning
HyperStrategy _processingAssets Source-chain assets burned and waiting for HyperEVM confirmation.
HyperCoreAllocator totalSupply Internal shares representing source-chain ownership of HyperEVM assets.
HyperStrategy _totalAssets, _totalSupply Latest confirmed remote allocator state.

Cross-chain Divest: HyperEVM To Source Chain

sequenceDiagram
    participant Keeper
    participant Controller
    participant HyperStrategy
    participant CCTP
    participant Allocator
    participant Vault

    Controller->>HyperStrategy: divest(amount)
    HyperStrategy->>HyperStrategy: convert amount to remote shares
    HyperStrategy->>CCTP: sendMessage(RedeemMessage(shares))
    Allocator->>Allocator: queue pendingRedeemShares
    Note over Keeper,Allocator: Wait for underlying exits and sufficient idle assets
    Keeper->>Allocator: executeRedeem(sharesToRedeem)
    Allocator->>CCTP: depositForBurnWithHook(amount, source, state hook)
    Keeper->>HyperStrategy: completeDivest(message, attestation)
    HyperStrategy->>HyperStrategy: update remote state from hook
    HyperStrategy-->>Vault: transfer source-chain assets to receiver

Asynchronous liquidity

HyperStrategy.replenish() is intentionally unsupported and always reverts with FunctionNotSupported(). The synchronous vault liquidity waterfall cannot pull partial liquidity from HyperStrategy. divest() requests an asynchronous redemption; it does not return remote assets in the initiating transaction. Completion requires the remote asset return and CCTP processing.

HyperStrategy.exit() only transfers its local source-chain asset balance. It does not unwind remote HyperEVM or HLP positions. Strategy revocation or vault shutdown must not be interpreted as proof that those positions have been recovered; see the emergency limitations.

HyperCore Allocation Flow

HyperCoreAllocator (on HyperEVM) can hold idle HyperEVM assets and allocate assets to registered routers. A router reads HyperCore state through precompiles and submits HLP-related write actions through CoreWriter.

CoreWriter submits actions for HyperCore to process. An EVM transaction receipt is not by itself proof that the resulting HyperCore balance change is complete. In particular, vault transfers are delayed and appear as separate enqueue and execution events. Dependent actions require confirmation of the resulting HyperCore state. See Hyperliquid's CoreWriter documentation.

sequenceDiagram
    participant Keeper
    participant Allocator
    participant Router
    participant HyperCore

    Keeper->>Allocator: allocate(routerIdx, amount)
    Allocator-->>Router: transfer asset
    Keeper->>Router: depositToSpot(amount)
    Router->>HyperCore: CoreDepositWallet.deposit
    Keeper->>Router: spotToPerp(amount)
    Router->>HyperCore: USD_CLASS_TRANSFER
    Note over Keeper,HyperCore: Confirm resulting balance before dependent action
    Keeper->>Router: perpToVault(amount)
    Router->>HyperCore: VAULT_TRANSFER into HLP

Reverse Allocation (Collection)

  1. Subject to the underlying HLP position's unlock status and available liquidity, the Keeper calls router.vaultToPerp(amount).
  2. After confirming the resulting HyperCore balance, the Keeper calls router.perpToSpot(amount).
  3. After confirming the spot balance, the Keeper calls router.withdrawFromSpot(amount).
  4. After the ERC-20 asset is back on the router, the Keeper calls allocator.collect(routerIdx, amount).
  5. The Router approves the allocator via approveOnlyForAllocator().
  6. The Allocator pulls the assets back.

The underlying HLP lock-up is four days from its most recent deposit, not a fixed countdown from a King's Vault redemption request. The portal's 96-hour processing estimate does not include a guarantee against additional Keeper, liquidity, or bridge delays. See HLP withdrawal timing and Hyperliquid's lock-up rule.