> For the complete documentation index, see [llms.txt](https://docs.ensemble.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ensemble.io/how-it-works/cross-chain-routes.md).

# Cross-chain routes

Remote deposits, redemptions, and claims settle against the HyperEVM vault.

Cross-chain routes are designed to let you enter or exit a vault from another network. They add a delivery step: the HyperEVM vault settles the shares or USDC, then a message carries the result to the destination. The recorded production deployment has CCIP disabled for all six vaults.

```mermaid
flowchart LR
    RemoteUser["User on a supported source chain"] --> Router["Source router"]
    Router --> CCIP["Authenticated cross-chain message"]
    CCIP --> Composer["HyperEVM composer"]
    Composer --> Breaker["CircuitBreaker trusted conduit"]
    Breaker --> Vault["Canonical HyperEVM vault"]
    Vault --> Pool["Canonical share pool"]
    Pool --> CCIP
    CCIP --> RemoteShare["Remote representation or payout"]
```

## Production availability

The recorded production generation `production-six-vault-20260929` has `ccipEnabled: false` for all six vaults. This guide describes the cross-chain contract design; that deployment record does not establish an enabled production route. Use native HyperEVM entry and exit unless a separately verified production route is published and enabled. See [Fees and caps](/how-it-works/fees-and-caps.md).

## Where settlement happens

Using another chain does not change where your shares are priced or accounted for.

The HyperEVM vault determines the share price and amount owed. A token representing those shares on another network does not create a separate source of value or accounting.

## Authenticated identity

A route must verify who authorized the transaction on the source chain.

A trusted routing contract must tie the account to a verified source message or signature. The same address appearing on two networks is not enough to prove that the same person controls it.

## Deposits

A cross-chain deposit must arrive through a supported route and prove who sent it.

The composer settles verified source-chain intent through an explicitly enabled CircuitBreaker route. Cross-chain routes should be installed with bounded limits before activation.

## Redemptions and pending claims

A completed vault transaction can still await delivery to the other network. The return message needs a delivery fee. If it cannot pay that fee automatically, the result remains claimable for its original receiver.

Deposits set aside part of the incoming USDC for the return message fee, called the skim in the contract. They deposit or refund the remaining principal. Successful redemptions return net USDC after the withdrawal fee and skim; the caller's minimum output applies to this net amount.

A return is sent automatically only when the quoted fee is zero or its USDC fee is covered by that message's own skim. Native-token fees, other fee tokens, or USDC fees above the skim create a `pendingReturns` claim bound to the original receiver. This can happen after a successful deposit, a deposit refund, or a successful redemption. Anyone may call `executePendingReturn` with the exact current route fee. The executor receives that message's reserved USDC skim after successful dispatch.

A failed vault redemption instead records the canonical shares in `pendingRedeemRefunds`. Anyone may call `executePendingRedeemRefund`, supplying the exact current fee. This path has no reserved skim reimbursement. Both claim paths require an enabled route and a fee quote within its cap, preserve the original receiver, and consume the claim only if dispatch succeeds.

Canonical settlement and remote delivery are separate steps. A submitted return message still needs destination-chain completion.

## Emergency claims

After emergency withdrawals are enabled, some pending share claims can be paid in recovered USDC.

Once emergency withdrawals freeze canonical share transfers, pending share returns and failed-redeem share refunds can use `executeEmergencyPendingShareReturn`. The composer claims its recovered USDC once and allocates each pending share claim its fixed pro-rata amount. The receiver stays bound to the inbound message, and the executor supplies the current route fee. Shares held in a canonical lock pool follow a separate recovery process; this composer claim does not recover those holdings.

## Additional risks

Cross-chain use adds router, pool, message, relayer, fee, finality, and remote token risk. Review [Risks before you deposit](/start-here/risks-before-you-deposit.md).