# IPOR Fusion Vaults Now Reach Hyperliquid and HIP-3: Routes, Rules and Example Vaults

> Three routes from an IPOR Fusion vault to Hyperliquid and HIP-3 stock perps: native HyperCore, cross-chain from Arbitrum and external positions.

Source: https://ipor.io/news/ipor-fusion-vaults-reach-hyperliquid  
Published: 2026-11-10  
Ecosystem · Fusion Team · 8 min read

IPOR Fusion vaults on HyperEVM can now hold their own Hyperliquid account. Assets can move between HyperEVM and HyperCore. Perp positions, including HIP-3 stock perps, can be opened and closed within the limits set in the vault’s configuration. The position is valued onchain in the vault’s share price.

With the HyperCore fuses, the vault itself sends every Hyperliquid action. No separate account holder sits between the vault and Hyperliquid, so which markets, how much exposure and where assets can go stay enforced by smart contracts.

## TL;DR

- An IPOR Fusion vault on HyperEVM can now be its own Hyperliquid account: it trades perps on HyperCore, including HIP-3 stock perps, with no API wallet, off-chain signer, custodian or sub-account holding its assets.
- Every action is limited to the markets, assets and size caps set in the vault’s configuration, and the position is valued onchain from Hyperliquid’s own data.
- The contracts are open source and deployed on HyperEVM since 22 October 2026. The Python SDK v4.0 supports them, with its HyperCore and cross-chain APIs in preview.

## Get started

- **Docs:** the vault-setup guide for AI agents and developers, [llms-fusion.txt](https://ipor.io/docs/llms-fusion.txt).
- **Integration guides** (configuration, markets and limits): [HyperCore fuses README](https://github.com/IPOR-Labs/ipor-fusion/blob/main/contracts/fuses/hypercore/README.md) and [cross-chain fuses](https://github.com/IPOR-Labs/ipor-fusion/tree/main/contracts/fuses/crosschain)
- **Python SDK v4.0:** `ipor_fusion.hypercore` and `ipor_fusion.crosschain` (preview), with worked examples for a HyperCore vault and a CCIP vault between Arbitrum and HyperEVM. The CLI inspects HyperEVM vaults, and simulations cover the full cross-chain lifecycle.
- **MCP:** connect an AI agent at [mcp.ipor.io](https://mcp.ipor.io/) to inspect Fusion vaults across chains.

## Three ways a Fusion vault reaches Hyperliquid

Operators can pick the route that fits where their capital sits and how they want to run the strategy.

**1. Native HyperCore.** The vault lives on HyperEVM and runs its own HyperCore account through typed fuses, trading native perps and HIP-3 markets. It controls order and position caps, valuation circuit breakers and settled transfers.

**2. Cross-chain.** A hub vault on Arbitrum moves liquidity over Chainlink CCIP to a HyperCore vault on HyperEVM, which runs the trading leg. Vault accounting stays consistent across both chains. Arbitrum is the first supported cross-chain lane, with more networks rolling out progressively based on operator demand.

**3. External position.** A vault on Ethereum holds a Hyperliquid position through the ExternalState fuse, with an operator-run account trading on Hyperliquid. It relies on permitted fund routes, separated roles and two-key position reporting.

All three are configured through the same Fusion building blocks as any other vault: fuses define what the vault can do, and substrates define where.

The tooling has been built up over four SDK releases since early October: HyperEVM support in the CLI, simulations that model HyperCore, a worked example of a full trade cycle, and v4.0 moving everything onto the released contracts.

## Rules enforced on both sides

For institutions, onchain funds and allocators alike, reaching another venue only works if the rules travel with the capital. Whichever route an operator picks, the vault’s configuration still defines which markets it can use, how large positions can get and where assets can move.

The vault’s smart contracts check every action against those limits before it goes through, and reject any action outside them.

### On HyperCore

A Fusion vault on HyperEVM manages its own HyperCore account. No external position manager, API wallet or sub-account ever gets control of its assets.

Seven typed fuses cover deposits, margin, transfers, perp limit orders, cancellations, builder fees and valuation, with no raw access to Hyperliquid’s actions.

Vaults can trade native Hyperliquid perps and USDC-collateral HIP-3 markets deployed by builders such as Trade.xyz. The vault’s configuration sets the limits:

- **Order and position caps.** A maximum notional per order and an optional cap on the total position per perp market, both enforced before an order is sent.
- **Valuation guards.** A circuit breaker stops the vault if its value jumps beyond a set limit between updates, deposits and withdrawals check that mark prices stay close to the oracle, and a negative account value freezes the market until it is restored.
- **Settled transfers.** A transfer between HyperEVM and Hyperliquid counts as settled only when the balance actually arrives, with a timeout. While one is in flight, new vault actions and capital flows wait.

### On the external route

IPOR Fusion vaults deployed on networks beyond HyperEVM can also hold a Hyperliquid position.

The native HyperCore fuses only work on HyperEVM, where Hyperliquid exposes its trading engine to smart contracts. A vault on Ethereum, for example, uses the ExternalState fuse instead. An operator-run account trades on Hyperliquid, and the position is reported back into the vault.

This route works for any venue, with a different trade-off: once assets reach the operator’s account, they sit outside the vault’s onchain limits, so the controls focus on how value is reported:

- **Permitted routes out.** The vault only sends assets along routes its configuration allows.
- **Separated roles.** Executing strategy actions, changing the vault’s configuration and reporting value are held by different roles.
- **Two-key accounting.** One key proposes the value of the Hyperliquid position, a second confirms it, and neither can confirm its own proposal. Stale reports block new entries into the vault until the value is confirmed.

### IPOR Fusion principles across all three routes

Whichever route a vault uses, its permissions, asset routes and allocations are recorded onchain. Holders, allocators and auditors can verify them independently. Operators set the rules once in the vault’s configuration, and the vault applies them on every chain it operates on.

## Trade-offs to know

Running a vault on Hyperliquid comes with constraints that operators should plan for:

- **Asynchronous execution.** HyperCore executes queued actions a few seconds after the EVM transaction. Vault actions pause briefly while a transfer crosses between HyperEVM and HyperCore.
- **Withdrawals from HyperCore take a step.** Value on HyperCore has to come back to HyperEVM before it can be paid out, so vaults holding most of their value there pair with withdrawal requests.
- **Mark-price valuation.** The vault values perps at Hyperliquid’s mark price. On thin HIP-3 markets the oracle band and position caps limit manipulation but cannot remove it.
- **HIP-3 operator trust.** Each builder-deployed market sets its own oracle and leverage and can halt trading. Enabling a market means trusting its operator.
- **Scope.** The first version covers USDC collateral and perp limit orders. Spot orders, sub-accounts, staking and leverage changes are out of scope.
- **Cross-chain latency.** Moving liquidity between Arbitrum and HyperEVM over CCIP adds delivery time compared with a native HyperEVM vault.

## What operators can build

With Hyperliquid in reach, a Fusion vault can combine onchain lending and tokenized assets on one chain with Hyperliquid perps, under one rulebook. A few examples of what operators can set up:

**Equity basis vault**

- Route: cross-chain, with an Arbitrum hub vault and a HyperCore vault on HyperEVM
- Holds: tokenized stocks used as collateral in lending markets on Arbitrum
- Hedge: a matching short on a HIP-3 stock perp, such as `xyz:NVDA`
- Limits: position cap per perp market, mark-vs-oracle band on deposits and withdrawals

**Perp funding vault**

- Route: native HyperCore, USDC vault on HyperEVM
- Holds: USDC on HyperCore as perp margin
- Trades: limit orders on granted native perp markets only
- Limits: per-order notional cap, total position cap, valuation circuit breaker

**Staked ETH, hedged on Hyperliquid**

- Route: external position, vault on Ethereum
- Holds: liquid staked ETH, such as wstETH, on Ethereum, plus USDC sent as margin to a Hyperliquid account run by the operator
- Hedge: an ETH perp short sized to offset the staked ETH’s price moves
- Aim: staking rewards with ETH price exposure offset, net of perp funding and costs
- Limits: permitted asset routes, separated roles, position value confirmed by two keys, entries blocked on stale reports

### Deeper visibility in the IPOR Fusion app

Everything above can be verified onchain. The IPOR Fusion app will progressively surface the details of vaults with a Hyperliquid leg, starting with read-only views of HyperCore positions and the limits each vault is configured with.

## Ecosystem context

Hyperliquid is moving past crypto-native trading. Recently, Intercontinental Exchange, the owner of the New York Stock Exchange, [announced](https://ir.theice.com/press/news-details/2026/Intercontinental-Exchange-and-TradeXYZ-to-Bring-Hyperliquid-Based-Perpetual-Markets-Onshore/default.aspx) plans with Trade.xyz to bring Hyperliquid-based perpetual markets onshore in the US, subject to regulatory approval. As more institutions look at Hyperliquid, vault infrastructure that keeps their rules enforced onchain becomes the way in.

_This article describes infrastructure capabilities for information only. It is not investment, operational or financial advice. The HyperCore and cross-chain contracts are released and open source; the Python SDK’s HyperCore and cross-chain APIs are in preview and may change._