Cross-Chain Vault Integration
Operational considerations for a vault that spans more than one chain.
Audience: Atomists, Risk Owners, and Vault Governance
Companion Document: For smart contract architecture, fuse interactions, and strictly technical execution flows, please refer to the Cross-Chain Vault Integration - Technical Overview.
1. Executive Summary & Business Objective
The IPOR Fusion cross-chain integration enables an existing Fusion vault to allocate capital to strategies on remote blockchains without fragmenting the user experience.
1.1 The Customer Proposition
For the end-user (depositor), the source Fusion vault remains the single point of interaction. Users deposit assets and receive a unified ERC4626 share token that reflects the combined Net Asset Value (NAV) of both local and remote strategies.
Cross-chain allocation is strictly an internal portfolio-management capability executed by the Alpha. It offers:
Geographic Diversification: Access to approved yield opportunities across multiple supported networks.
Unified Accounting: Centralized NAV calculation and share issuance at the source vault.
Controlled Routing: Secure bridging infrastructure without requiring users to navigate external bridges or manage multiple gas tokens.
1.2 What the Integration Does (and Doesn't) Do
This solution provides a secure, asynchronous pathway to deploy and recall capital. However, it is crucial for Atomists to understand the system's boundaries.
The system does NOT provide:
Synchronous Liquidity: Remote positions cannot be withdrawn instantly by end-users. The recall process is asynchronous and subject to bridge finality.
Automatic Strategy Selection: The system does not automatically rebalance or select the "best" remote yield.
Hardcoded Economic Exposure Limits: The smart contracts enforce authentication and routing safety, but they do not enforce maximum AUM limits per remote chain.
Therefore, economic limits, liquidity buffers, and allocation policies must be explicitly defined and monitored by the vault's governance layer.
2. Solution Architecture at a Glance
The IPOR Fusion cross-chain integration uses a "Hub and Spoke" model to extend the reach of a single Fusion vault.
2.1 The Hub and Spoke Model
The Hub (Source Fusion Vault): This is the user-facing vault on the origin chain (e.g., Ethereum Mainnet). It handles all user deposits, issues shares, and acts as the central command center for the portfolio manager (Alpha).
The Spokes (Remote Operations): The Hub deploys capital to remote chains via a bridging layer. On the destination chain, the capital is managed by a remote operation that deposits into yield-generating strategies.
2.2 Separation of Concerns (Executor vs. Dispatcher)
To keep the core Fusion vault secure, cross-chain messaging logic is strictly separated into dedicated components:
The Executor (Source Chain): A dedicated gateway contract on the source chain. It is permanently bound to your specific Fusion vault. It routes the vault's commands over the bridge (Stargate or CCIP) and maintains the internal accounting ledgers (e.g., tracking what has been sent vs. what is verified as settled remotely).
The Dispatcher (Destination Chain): A remote operator contract on the destination chain. It receives instructions exclusively from its paired Executor. It holds the assets and executes the actual deposit/redeem operations into approved remote ERC4626 vaults.
3. Governance and Operating Roles
Operating a cross-chain Fusion vault requires a strict separation of duties. To ensure security and accurate accounting, day-to-day portfolio management is isolated from risk parameter configuration and Net Asset Value (NAV) attestation.
3.1 The Atomist Responsibilities
The Atomist acts as the vault's risk and governance owner. They do not actively trade, but they define the strict boundaries within which the Alpha can operate. Key responsibilities include:
Approving the Infrastructure: Registering the required cross-chain fuses, balance fuses, and NAV validation hooks on the source Fusion vault.
Setting the Boundaries: Explicitly allowlisting approved remote vaults and granting the necessary substrates. The Alpha cannot route funds to any destination that the Atomist has not pre-approved.
Exposure Policy: Defining and monitoring the maximum capital exposure per transport, destination chain, and remote vault.
3.2 Operational Roles
Beyond the Atomist, the cross-chain lifecycle relies on several distinct operational roles:
Alpha: The active strategist who initiates the movement of capital. The Alpha triggers supply, remote allocation, redeem, and recall actions. They are strictly constrained by the rules and allowlists set by the Atomist.
Balance Proposer: An off-chain observer that reads the remote operation's state (tracked assets and remote vault shares) and proposes this valuation back to the source chain.
Balance Approver: An independent entity that verifies the proposed remote state for freshness and accuracy before the source vault's NAV is officially updated. To prevent manipulation, the Approver must be a different address than the Proposer.
Rescue Admin: A highly privileged, break-glass role capable of scheduling delayed recovery actions (e.g., recovering stuck tokens). It is highly recommended that this role is held by a multisig or a controlled governance contract.
Rescue Guardian: An independent safety check with the unilateral power to veto and cancel any pending action scheduled by the Rescue Admin. They cannot execute rescues themselves, ensuring a balance of power.
4. Per-Vault Integration & Onboarding Blueprint
Integrating cross-chain capabilities into a Fusion vault is a repeatable process, but it requires careful due diligence by the Atomist.
4.1 Vault and Asset Eligibility
Before enabling cross-chain routes, the Atomist must verify:
Liquidity Policy: Can the source vault's liquidity model tolerate the asynchronous nature of bridging? Recalling funds from remote chains takes time.
Asset Support: Does the chosen transport layer (e.g., Stargate or CCIP) support the vault's underlying asset on both the source and destination chains?
Pricing: Is there a robust, validated price feed for the asset on the source chain?
4.2 Remote Strategy Due Diligence
The Atomist must conduct full risk assessments on the proposed destination strategies. This includes evaluating:
The target protocol's smart contract security.
The liquidity depth of the remote ERC4626 vault.
Any asynchronous withdrawal queues or lockup periods imposed by the remote protocol.
4.3 The Substrate Permission Model
IPOR Fusion uses "substrates" as granular permission keys. To enforce the results of the due diligence, the Atomist must configure two types of substrates on the source Fusion vault:
Executor Substrates: These explicitly authorize the Alpha to send capital to a specific bridging gateway.
Remote Vault Substrates: These bind a destination chain ID to a specific remote ERC4626 vault address.
Crucially, the Alpha cannot route capital to any destination that has not been explicitly granted as a substrate by the Atomist. This ensures that the portfolio manager operates strictly within the pre-approved risk boundaries. For a technical deep-dive into how substrates are structured, refer to Section 3 of the Technical Integration Guide.
5. The Capital Lifecycle
As an Atomist, it is important to understand how capital flows through the cross-chain architecture so you can establish proper monitoring and liquidity policies. The portfolio management process follows a strict, asynchronous lifecycle.
5.1 Supply and Allocation
Supply: The Alpha initiates an action through the source Fusion vault. Capital moves from the vault to the source-side executor, which then bridges the assets to the remote dispatcher.
Deposit: Once the assets arrive on the remote chain, the Alpha sends a business command to deposit them into the explicitly allowlisted remote vaults.
5.2 NAV Recognition
Remote yield is not automatically added to the source Fusion vault. It must be recognized through a rigorous attestation process:
An off-chain observer prepares a canonical state of the remote assets.
An independent proposer submits this observation.
An independent approver validates and approves it, officially refreshing the Fusion vault's cross-chain Net Asset Value (NAV).
5.3 Redemption and Recall
Redeem: The Alpha withdraws the remote position. If the remote vault uses asynchronous withdrawals, this is a two-step process (requesting shares, then redeeming them).
Recall: The Alpha initiates a recall, bringing the idle assets from the remote dispatcher back across the bridge to the source executor.
Claim: Finally, a claim action pulls the returned assets from the executor back into the main Fusion vault, making them available for user withdrawals.
6. Exposure Limits and Risk Management
The cross-chain architecture delegates strict structural and authentication controls to the smart contracts, but business risk limits are managed by governance. The Atomist is responsible for configuring these risk parameters.
6.1 The Fail-Closed Mechanism
The integration uses a fail-closed accounting model. If a remote observation exceeds the configured staleness threshold, or if an in-flight transfer takes too long, the system considers the cross-chain NAV unreliable. When this happens, the Fusion vault automatically halts all share-price-sensitive operations (like user deposits and withdrawals) to protect existing liquidity providers from transacting at a distorted valuation.
6.2 Configuration Responsibilities
As an Atomist, you must define and govern:
Staleness Limits: The maximum permitted age for remote NAV observations and in-flight transfers.
Exposure Caps: The maximum capital allowed per transport, destination chain, and remote vault. Note: The smart contracts do not hardcode AUM limits; these must be enforced through your operational policies and monitoring.
Liquidity Reserves: A minimum liquidity buffer on the source Fusion vault to handle standard user withdrawals while cross-chain capital is locked in transit.
Fee Budgets: Maintaining adequate native token budgets for message transports (like CCIP or Stargate) to ensure cross-chain messages do not fail due to insufficient gas.
7. Offboarding and Emergency Procedures
Because cross-chain operations rely on external bridges, the architecture includes robust failure handling and emergency break-glass mechanisms.
7.1 Graceful Offboarding
You cannot simply disconnect a remote chain while capital is deployed. Offboarding a remote lane requires a controlled unwind sequence:
Halt all new cross-chain supply operations.
Redeem all remote vault shares and complete any pending asynchronous withdrawals.
Recall all assets back to the source executor and claim them into the Fusion vault.
Verify that all remote shares, tracked idle balances, and in-flight records are zero.
Only then can the Atomist safely remove the remote vault substrates and cross-chain fuses.
7.2 Command Failures
If a remote execution fails (for example, due to tight slippage limits on the destination chain), the remote dispatcher will return a negative acknowledgement. The capital remains secure on the remote chain, and the Alpha can either adjust the parameters and retry the command, or cancel it entirely.
7.3 Emergency Rescue Roles
For severe incidents—such as a permanent bridge failure or unexpected token surpluses—the system utilizes a delayed rescue module.
Rescue Admin: Can schedule emergency recovery actions to forcefully reconcile accounting or extract trapped fee dust. This role is strictly bound by a minimum 24-hour execution delay.
Rescue Guardian: Possesses the unilateral authority to veto and cancel any scheduled rescue action before the delay expires.
To maintain maximum security, the Rescue Admin and Rescue Guardian must be operated by independent entities or multisigs.
Last updated
Was this helpful?