Cross-Chain Vault Integration - Technical Overview
Technical detail behind cross-chain vault integration: NAV attestation and emergency recovery roles.
1. Architecture Overview
The IPOR Fusion Cross-Chain Vault system extends the core PlasmaVault architecture to enable asynchronous, secure, and transport-agnostic capital allocation across multiple blockchain networks. By leveraging the existing modular Fuse system, source-chain vaults can permissionlessly deploy liquidity to destination-chain strategies while maintaining a unified ERC4626 interface for end-users.
1.1. Core Design Principles
The cross-chain architecture is built upon three foundational pillars:
Hub and Spoke Execution: User interactions (deposits, withdrawals, and share minting) are strictly isolated to the Source Vault (the Hub). Destination networks host Remote Vaults (the Spokes) which are dedicated exclusively to local yield generation and cannot accept direct user deposits.
Asynchronous Accounting (Fail-Closed): Cross-chain messaging is inherently asynchronous and subject to transport delays or execution failures. The system implements a "fail-closed" state machine utilizing Epochs and State Versions to track pending transactions. If a message fails, the vault protects user funds by temporarily locking state transitions until the failure is repaired or rescued by a Guardian.
Transport Agnosticism: The bridging layer is structurally abstracted. The core cross-chain logic does not depend on a specific bridge, allowing the protocol to securely route liquidity using the optimal transport layer (e.g., Stargate or Chainlink CCIP) based on the asset type and destination network.
1.2. Component Roles & Relationships
The cross-chain flow involves a precise choreography between source and destination components. This separation of concerns ensures that the core PlasmaVault logic remains pristine, offloading cross-chain complexity to dedicated adapters.
Source Vault (
PlasmaVault): The primary ERC4626 vault where liquidity providers deposit assets. It holds the canonical state of total assets (NAV), issues shares, and acts as the central command center for theALPHA_ROLEstrategist.Crosschain Fuses: Operation and balance fuses natively attached to the Source Vault. For example, a
CrosschainBalanceFusetracks the value of assets deployed on remote chains, while aCrosschainClaimFuseinitiates the harvesting of remote yields.Dispatcher: The remote operator contract deployed on the destination chain. It holds the tracked remote assets and executes authenticated commands.
Executor: The vault-specific gateway deployed on the source chain. It acts as the origin point for all cross-chain commands and maintains the source-side accounting ledger.
Remote Vault (
PlasmaVault): A streamlined vault deployed on the destination chain. It receives liquidity from the Dispatcher and utilizes its own local Fuse system to deploy capital into destination-native DeFi protocols.
1.3. Transport Layers: Stargate vs. CCIP
To maximize security and routing efficiency, the IPOR Fusion Cross-Chain architecture supports multiple arbitrary messaging bridges (AMBs). The initial implementation provides native integration for Stargate (built on LayerZero V2) and Chainlink CCIP.
Stargate Transport: Optimized for highly liquid stablecoin transfers and native asset routing. It utilizes LayerZero's messaging primitives to provide fast, cost-efficient execution. The
StargateCrosschainFactoryhandles the deployment.Chainlink CCIP Transport: Utilized for scenarios requiring Programmable Token Transfers combined with maximum security guarantees. CCIP benefits from Chainlink's Risk Management Network, making it the preferred transport for large-scale operations. Configured via the
CcipCrosschainFactory.
2. Smart Contract Components
The cross-chain architecture relies on a suite of specialized smart contracts designed to strictly segregate bridging logic from core vault accounting. This modularity ensures that the PlasmaVault remains secure and unaware of transport-specific complexities.
2.1. Factories (StargateCrosschainFactory, CcipCrosschainFactory)
Factories serve as the shared platform infrastructure responsible for the deterministic deployment and configuration of cross-chain components. There is a distinct factory implementation for each supported transport layer.
Deterministic Deployment (
CREATE3): Factories utilizeCREATE3to ensure that an Executor deployed on the source chain and its corresponding Dispatcher deployed on the destination chain share the exact same contract address. This same-address pairing is a foundational security guarantee for cross-chain authentication.Route and Asset Governance: Factories maintain the canonical configuration of supported source-to-destination routes, cross-chain gas policies, fee ceilings, and allowed bridge tokens.
Access Control: Factory configurations are governed by the platform team (often behind a timelock) and can enforce creator restrictions, allowing only approved addresses to deploy new Executor instances.
2.2. Executors
The Executor is the vault-specific gateway deployed on the source chain. It acts as the origin point for all cross-chain commands and maintains the source-side accounting ledger.
Immutable Binding: An Executor is not a shared omnibus account. Upon deployment, it is permanently bound to a single
MANAGER(the sourcePlasmaVault), a specific asset, and a specific transport layer.Source Accounting: The Executor tracks the business state of capital through different phases:
idle: Assets returned to the source chain but not yet claimed by the vault.inFlight: Outbound assets awaiting authenticated settlement on the destination chain.settled: The approved, canonical value of assets deployed remotely.
Recovery Boundary: Each Executor maintains its own isolated incident state, ensuring that a failure in one cross-chain lane does not halt operations in another vault's Executor.
2.3. Dispatchers
The Dispatcher is the remote operator contract deployed on the destination chain. It receives instructions exclusively from its same-address Executor counterpart on the source chain.
Remote Custody: The Dispatcher holds the "tracked idle" assets on the destination chain as well as the shares issued by remote ERC-4626 vaults.
Execution Engine: It decodes authenticated commands (e.g.,
DEPOSIT,REDEEM,REQUEST_SHARES) and executes them against the allowlisted remote vaults.Canonical State Publication: The Dispatcher exposes a public, monotonic state version and accounting epoch. Off-chain observers read this state to attest to the remote NAV back on the source chain.
2.4. Fuses
Fuses act as the connective tissue between the source PlasmaVault and the Executor, translating standard portfolio manager intents into cross-chain operations.
Transport Supply Fuses: Validates vault liquidity and transfers fresh assets to the Executor, initiating an outbound bridging message to the destination Dispatcher. It is also used to trigger asynchronous
RECALLrequests.Transport Command Fuses: Dispatches authenticated business actions (e.g., allocating tracked idle assets into a specific remote vault) to the destination chain.
CrosschainClaimFuse: A shared, transport-agnostic fuse that pulls returningidleassets from the Executor back into the sourcePlasmaVault's active balance.CrosschainBalanceFuse: Calculates the tracked market value of one or more Executors. It aggregatesidle,inFlight, andsettledledgers, prices the Executor's asset using the vault'sPriceOracleMiddleware, and returns the USD-WAD market value for the vault's NAV calculation.
2.5. Hooks (CrosschainNavValidationPreHook)
To protect the integrity of the source vault's share price during cross-chain operations, the system introduces the CrosschainNavValidationPreHook.
Fail-Closed Protection: If cross-chain messaging stalls, observations expire, or a state-version gap is detected, the
CrosschainBalanceFusewill revert to protect against pricing inaccuracies.Share-Price Gating: The
CrosschainNavValidationPreHookcatches this "fail-closed" state and blocks all share-price-sensitive operations on thePlasmaVault(e.g.,deposit,mint,withdraw,redeem).This ensures users cannot enter or exit the vault at a distorted valuation when the remote state is unverified or compromised.
2.6. Attestation & Rescue Modules
Because cross-chain bridges are asynchronous and cannot directly return synchronous return values, the architecture relies on robust attestation and recovery modules.
Attestation Library: Implements a two-role approval process (
PROPOSERandAPPROVER) to recognize remote yield. An off-chain observer reads the Dispatcher's state and proposes it on the source chain. The approver validates the state version and freshness before the Executor'ssettledledger is updated.Rescue Module: A generic, delayed break-glass mechanism built into both Executors and Dispatchers. It allows a
RESCUE_ADMINto schedule arbitrary recovery transactions (e.g., recovering stuck tokens). To prevent abuse, all rescue actions are subject to a mandatory 24-hour timelock and can be unilaterally canceled by an independentRESCUE_GUARDIAN.
3. Substrates & Configuration
The IPOR Fusion architecture uses "substrates" as granular permission identifiers. The cross-chain integration extends this system by introducing specific typed substrates that authorize remote execution pathways. This ensures that the portfolio manager (the ALPHA_ROLE) cannot arbitrarily bridge funds or interact with unvetted remote contracts.
3.1. EXECUTOR Substrates
Before a source PlasmaVault can interact with an Executor, the vault's governance (ATOMIST_ROLE) must explicitly grant it permission using an EXECUTOR substrate.
Structure: An
EXECUTORsubstrate is abytes32identifier generated by encoding the specific Executor contract address.Validation: Both the
CrosschainSupplyFuseand theCrosschainCommandFusevalidate that the target Executor is granted as a substrate on the source vault.Purpose: This prevents the portfolio manager from routing funds to unauthorized bridging contracts or rogue Executors, effectively locking the outbound capital flow to verified pathways.
3.2. REMOTE_VAULT Substrates
To control where capital is deployed on the destination chain, the source vault uses REMOTE_VAULT substrates.
Structure: A
REMOTE_VAULTsubstrate binds a specific destinationchainIdto a specificremoteVaultAddress. This prevents the ambiguity of using the same vault address on the wrong network.Source-Side Enforcement: When the portfolio manager submits a command (e.g.,
DEPOSIT) via theCrosschainCommandFuse, the fuse verifies that the target(chainId, remoteVaultAddress)is an approvedREMOTE_VAULTsubstrate on the sourcePlasmaVault.Destination-Side Enforcement: The remote Dispatcher only executes authenticated commands. Because the command originated from the source vault (which already validated the substrate), the Dispatcher implicitly trusts the target. However, as a secondary defense, the Dispatcher also maintains its own local allowlist of approved remote vaults.
3.3. Market ID Assignments
In the IPOR Fusion architecture, every integration is associated with a specific MARKET_ID. The cross-chain integration utilizes dedicated market IDs to group related Executors and define their dependencies.
Cross-Chain Market ID: A unique market ID (e.g.,
CROSSCHAIN_MARKET) is assigned to group all Executors belonging to a specific cross-chain strategy.Balance Fuse Association: The
CrosschainBalanceFuseis registered against this specific cross-chain market ID. WhenPlasmaVault.updateMarketsBalances()is called, it triggers the balance fuse for this market, updating the aggregate tracked value of all granted Executors.Dependency Graph: The cross-chain market depends on the
ERC20_VAULT_BALANCEmarket. This dependency ensures that the vault's local token balances are updated before calculating the cross-chain NAV, preventing double-counting during theclaimprocess when assets move from the Executor'sidleledger back into the vault's local token balance.
4. Execution Flows
This section details the lifecycle of capital and operational commands as they move between the source PlasmaVault and destination remote vaults. The operations rely on the ALPHA_ROLE passing specific FuseAction payloads to PlasmaVault.execute().
4.1. Deployment & Initialization
Before any capital is moved, the lane must be initialized:
Factory Setup: Shared transport infrastructure is deployed and routes are configured by the platform team.
Executor & Dispatcher Creation: The factory deploys a vault-specific Executor on the source chain, followed by a deterministically paired Dispatcher on the destination chain.
Source Configuration: Vault governance (
ATOMIST_ROLE) registers the transport fuses, balance fuse, claim fuse, and the NAV pre-hook. It also grants the necessaryEXECUTORandREMOTE_VAULTsubstrates.Bounded Canary: A small, bounded test transaction is executed to verify end-to-end accounting and attestation before full exposure limits are approved.
4.2. Cross-Chain Supply (Source to Destination)
To move fresh liquidity to a remote network, the portfolio manager initiates a supply action.
Execution: The
ALPHA_ROLEcallsexecute()with aFuseActiontargeting the transport-specific supply fuse. The fuse verifies live NAV and transfers assets from thePlasmaVaultto the Executor.Bridging: The Executor dispatches the underlying assets via the configured transport layer (e.g., CCIP or Stargate) to the remote Dispatcher.
Accounting State: The assets transition from the vault's local physical balance to the Executor's
inFlightledger. They are not consideredsettleduntil an authenticated destination response completes the accounting transition.
4.3. Remote Vault Deposit/Redeem
Once assets arrive safely at the Dispatcher, they are classified as tracked idle remote assets. The ALPHA_ROLE can now allocate them to remote yield strategies.
Deposit: The manager sends a
DEPOSITcommand via theCrosschainCommandFuse. The source validates theREMOTE_VAULTsubstrate. Once received by the Dispatcher, it deposits theidleassets into the allowlisted remote ERC-4626 vault and begins tracking the issued shares.Redeem: The manager sends a
REDEEMcommand. The Dispatcher redeems the specified shares, converting them back into trackedidleassets.Asynchronous Withdrawals: If the remote PlasmaVault utilizes an asynchronous withdrawal queue, the redemption requires two sequential commands:
REQUEST_SHARES(entering the queue) followed byREDEEM_FROM_REQUEST(claiming the assets once the lockup expires).
4.4. Recall and Claim (Destination to Source)
Returning capital to the source vault is a managed, two-step asynchronous process to protect against liquidity shocks.
Recall: The
ALPHA_ROLEtriggers aRECALLrequest through the source supply fuse. The Dispatcher on the destination chain packages the requestedidleassets and sends them back across the bridge.Claim: When the assets arrive at the source Executor, they are added to the source
idleledger. Finally, theALPHA_ROLEexecutes the sharedCrosschainClaimFuse, which pulls the assets from the Executor back into the sourcePlasmaVault's active balance, restoring local liquidity.
4.5. NAV Attestation Flow
Because physical token balances on remote chains cannot be synchronously read, the system relies on an off-chain attestation pipeline to recognize remote yield.
Observation: The remote Dispatcher exposes a canonical observation containing its
idlebalances and remote vault shares, tied to a monotonic state version.Proposal: An off-chain observer prepares this state, and an independent
PROPOSERsubmits it to the source Executor.Approval: An independent
APPROVERverifies the state's freshness and version sequencing. Once approved, the Executor'ssettledledger is updated with the new valuation.Market Refresh: Immediately following approval, the source vault's
updateMarketsBalances()function must be called. This triggers theCrosschainBalanceFuseto read the newsettledvalue and persist the updated cross-chain market NAV within thePlasmaVaultcache. Share-price-sensitive operations are then permitted against the fresh valuation.
5. NAV and Accounting Internals
Accurate Net Asset Value (NAV) reporting is essential for maintaining the integrity of the ERC4626 share price. Cross-chain operations introduce the challenge of asynchronous state. To address this safely, the IPOR Fusion Cross-Chain architecture decouples physical token balances from accounted value and implements strict fail-closed state machines.
5.1. Tracked Value vs. Physical Balances
The architecture relies strictly on "tracked value" ledgers rather than raw IERC20.balanceOf() readings. This design prevents direct, unauthenticated token transfers (e.g., unexpected airdrops or "donations" to the Dispatcher) from instantly distorting the vault's NAV.
Value is divided into strict accounting ledgers across the two chain environments:
Source Executor Ledgers:
idle: Assets successfully returned to the source chain via a recall, but not yet swept into the primaryPlasmaVaultby the Claim Fuse.inFlight: Outbound assets that have left the source chain but are awaiting authenticated delivery confirmation on the destination chain.settled: The last approved, canonical valuation of assets deployed remotely on the destination chain.
Remote Dispatcher Ledgers:
idle: Unallocated assets physically held by the Dispatcher.remote shares: Tracked share positions in approved ERC4626 remote vaults.pending requests: Tracked shares locked in remote asynchronous withdrawal queues.queued response: Token value queued for an outbound recall response (specifically applicable for CCIP transports).
When the CrosschainBalanceFuse calculates the market value, it sums the Executor's idle, inFlight, and settled ledgers. It then prices the aggregated underlying asset using the source vault's PriceOracleMiddleware to return the precise USD-WAD market value. Remote yield only affects the settled ledger after passing through the off-chain attestation pipeline.
5.2. The Fail-Closed Mechanism
Because cross-chain bridging is asynchronous, transport layers can experience congestion, outages, or delivery failures. To protect liquidity providers from minting or redeeming shares against stale or inaccurate valuations during these periods, the system adopts a "fail-closed" security posture.
The CrosschainBalanceFuse actively monitors the health of the cross-chain lane. A call to getBalance() will intentionally revert if any of the following safety tripwires are hit:
Stale NAV: The last approved remote observation exceeds the configured maximum staleness threshold.
Stale In-Flight Transfers: An outbound transfer has remained in the
inFlightledger longer than the configured maximum settlement time.Blocked Lanes: A state-version gap is detected, indicating that a sequential bridging message was lost or skipped, rendering the current state unreliable.
When the balance fuse reverts, it triggers the CrosschainNavValidationPreHook. This hook acts as a circuit breaker attached to the source PlasmaVault. By catching the fail-closed state, it blocks share-price-sensitive vault entry points:
depositanddepositWithPermitmintwithdrawredeemandredeemFromRequestupdateMarketsBalances
Special Handling for execute: Unlike deposits and withdrawals which are strictly blocked, the pre-hook delegates the blocking decision for execute to fuse-level controls. This crucial distinction ensures that while new cross-chain exposure is blocked during a fail-closed state, approved recovery and rescue actions can still continue within a narrowly scoped recovery context.
5.3. State Versions & Epochs
To guarantee that remote observations are processed sequentially and accurately, the accounting system utilizes monotonic identifiers.
State Versions: The remote Dispatcher maintains a monotonic
stateVersion. Every time a value-mutating remote action occurs (e.g., executing a remoteDEPOSITor generating yield), this version increments. When proposing a new remote observation back to the source Executor, the off-chain observer must include this state version. The source strictly validates that version numbers are sequential. If a state-version gap is detected (e.g., bridging message #4 arrives but message #3 never settled), the Executor enters a blocked state.Epochs: The
epochcounter tracks major structural configuration changes (like redefining rescue roles or changing allowed vault parameters). If an observer attempts to attest to a remote balance using an outdated epoch, theAPPROVERpipeline will reject it, ensuring that old state cannot overwrite new architectural rules.
6. Transports and Cross-Chain Messaging
The IPOR Fusion cross-chain architecture abstracts the underlying messaging protocols while strictly isolating their execution contexts. To prevent complex failure dependencies, the system does not automatically route between different bridge providers. Instead, a dedicated Executor and Dispatcher pair is deployed for each specific transport and asset combination.
The current implementation natively supports two isolated transport stacks: Chainlink CCIP and Stargate with LayerZero V2.
6.1 Transport Layer Comparison
While both transports expose a unified interface to the PlasmaVault's supply and command fuses, their underlying mechanics, routing identities, and failure-handling models differ significantly.
Capability
Chainlink CCIP
Stargate / LayerZero V2
Asset Movement
Programmable Token Transfers (via CCIP Router).
Stargate taxi transfers with a mandatory compose payload.
Message Transport
CCIP Router messages.
LayerZero V2 OApp messages.
Route Identity
Immutable CCIP chain selector and registered peer.
Append-only chain ID/EID mapping and same-address peer.
Remote Responses
Ordered, bounded FIFO response queue with permissionless head flush.
LayerZero delivery/retry execution model.
Recall Behavior
Token-bearing return response via CCIP.
Request via OApp, Stargate token/compose return.
Fee Model
Native or configured fee token, bounded by per-call ceilings.
Native token budgets for LayerZero/Stargate sends and responses.
Note on USDC Operations: Both transports utilize their respective protocol-configured USDC liquidity pools. The current implementation does not integrate native Circle CCTP directly.
6.2 Chainlink CCIP Implementation
The CCIP implementation (CcipCrosschainFactory, CcipRouteLib) uses Chainlink's arbitrary messaging combined with Programmable Token Transfers.
FIFO Response Queue & Flushing:
Because CCIP strictly orders messages, a failed remote execution on the source chain (e.g., due to an out-of-gas error or logic revert upon receiving an ACK/NACK) can block subsequent messages in the lane. To prevent channel blocking, the CCIP Dispatcher implements a bounded FIFO response queue.
If a response fails to process automatically upon delivery, it is queued.
Keepers or users can invoke a permissionless flush of the FIFO head once the underlying issue (e.g., insufficient fee budget) is resolved.
A guardian-vetoable delayed skip is available as an emergency break-glass mechanism if a queued response is permanently unprocessable.
Delivery Policy and Fees:
Route policies—including fee tokens, gas limits, and fee ceilings—are governed by the factory. Route policy updates utilize a 24-hour configuration delay to protect inflight messages, followed by permissionless synchronization across the lane.
6.3 LayerZero V2 & Stargate Implementation
The Stargate implementation leverages LayerZero V2's Omnichain Application (OApp) standard for passing arbitrary logic, coupled with Stargate V2 taxi transfers for capital movement.
Execution and Retries:
Unlike the CCIP implementation, LayerZero V2 handles message execution and retries natively at the protocol layer via the EndpointV2.
Outbound messages are paid for using native gas budgets.
If a
composepayload or OApp message fails on the destination, it is caught by the LayerZero endpoint's internal retry mechanism rather than a custom vault-level FIFO queue.The route mapping relies on EID (Endpoint ID) mappings, which are append-only to prevent historical message corruption.
6.4 Message Lifecycle and Delivery Guarantees
Both implementations guarantee strict ordering for business commands to prevent race conditions during remote strategy execution. The lifecycle enforces the following rules:
One Active Command Limit: The
Executorallows only one active business or configuration command per destination chain. Subsequent commands revert until the active command receives a terminal response.Sequenced ACK / NACK:
ACK (Acknowledgement): The destination
Dispatchersuccessfully executed the command (e.g., deposited into the remote ERC-4626 vault). The sequence is finalized.NACK (Negative Acknowledgement): The remote execution reverted (e.g., due to slippage bounds or paused remote vaults). The command is returned as failed.
Retry and Cancellation: A command that results in a NACK is not automatically discarded. The
ALPHA_ROLEcan explicitly trigger a retry of the failed command or formally cancel it to clear the lane.Command Abandonment: If a command is sent but an ACK/NACK response is permanently lost (due to bridge failure or irrecoverable state), a delayed, vetoable rescue action must be utilized to abandon the command and reconcile accounting.
7. Security, Governance, and Access Control
The cross-chain architecture extends IPOR Fusion's robust IporFusionAccessManager with domain-specific access controls. Because cross-chain operations introduce asynchronous state and bridge-dependency risks, the system strictly separates day-to-day portfolio management from NAV attestation and emergency recovery.
7.1 Immutable Vault Binding
To prevent omnibus-style commingling of funds, the Executor is not a shared router. Upon deployment, the Executor is permanently bound to a single source PlasmaVault (assigned as the immutable MANAGER).
The supply and command fuses actively verify this relationship before forwarding any
FuseAction.The destination
Dispatcherdeterministically inherits this isolation, accepting authenticated messages only from its pairedExecutor.
7.2 Attestation Roles: Proposer and Approver
To prevent a single compromised key from artificially inflating the source vault's Net Asset Value (NAV), remote yield recognition requires a two-role attestation process on the Executor:
PROPOSER_ROLE: Responsible for querying the remoteDispatcher, structuring the canonical observation, and proposing it to theExecutor.APPROVER_ROLE: Independently verifies the proposed state (including state versions, aggregate vault shares, and tracked idle assets) and approves it.
Note: The smart contract enforces that the PROPOSER_ROLE and APPROVER_ROLE must be distinct addresses. Approvals are subject to configurable freshness thresholds and large-change rate limits.
7.3 Recovery Roles: Admin and Guardian
The generic rescue mechanism provides a powerful break-glass authority to execute arbitrary calls from the Executor or Dispatcher during critical bridge failures. To secure this, control is bifurcated:
RESCUE_ADMIN: Schedules and executes delayed recovery actions. This role operates as a full delayed administrator and should be assigned to a multisig or timelocked governance contract.RESCUE_GUARDIAN: Possesses the authority to veto and cancel one or all pending rescue actions.
Note: The RESCUE_ADMIN and RESCUE_GUARDIAN must be independent addresses. The system natively enforces a strict minimum 24-hour execution delay on all scheduled rescues.
7.4 PlasmaVault Configuration and Substrates
On the source PlasmaVault, cross-chain interactions are authorized by the ATOMIST_ROLE using the standard PlasmaVaultGovernance interface. Integration requires granting typed substrates via CrosschainSubstrateLib:
Executor Substrates: Granted as
EXECUTOR(executorAddress)to authorize the vault to supply capital to the bridge.Remote Vault Substrates: Granted as
REMOTE_VAULT(chainId, vaultAddress)to explicitly allowlist destination ERC-4626 vaults. TheDispatcherwill reject anyDEPOSITcommand targeting a vault not explicitly granted by the source.
8. Failure Handling and the Rescue Module
Cross-chain messaging protocols are subject to latency, message loss, and destination-chain reversions. The IPOR Fusion cross-chain architecture is built to gracefully handle NACK (Negative Acknowledgement) responses, state desynchronization, and permanent channel blocks.
8.1 Structural Safety Bounds
To prevent out-of-gas errors and limit theoretical exposure during incident response, the contracts enforce strict structural bounds:
Max Remote Vaults: Maximum 32 approved/tracked remote-vault positions per
Dispatcher.Max In-Flight Transfers: Maximum 16 concurrent in-flight transfer records per chain where the transfer-slot model applies.
Active Commands: Only 1 active business or configuration command, and 1 active recall permitted per destination chain at any time.
FIFO Bounds: Maximum 64 queued responses in the CCIP
Dispatcher.Stargate Chain Limits: Maximum 32 registered Dispatcher chains in the Stargate Executor.
Rescue Queue: Maximum 64 pending rescue records.
8.2 Command Failures and Retries
If a remote execution fails (e.g., due to slippage bounds in the remote ERC-4626 vault or a paused protocol), the destination returns a NACK. The active command sequence remains open on the source Executor.
Retry: The
ALPHA_ROLEcan adjust parameters (if applicable) and trigger a retry of the failed command.Cancellation: The
ALPHA_ROLEcan formally cancel the failed command, resetting the lane and moving the allocated capital back to the tracked remote idle ledger.
8.3 State-Version Gaps and Frontier Repair
The Dispatcher increments a monotonic state version on material accounting transitions. If the source Executor receives an observation where , it indicates a lost or permanently stalled message.
This immediately triggers the fail-closed NAV protection, halting share-price-sensitive operations.
Operators must utilize the Frontier Repair mechanism. This allows the system to advance the source state version (up to 32 versions per action) after a 6-hour cooldown, forcefully reconciling the accounting ledgers and allowing fresh attestations to resume.
8.4 The Rescue Module
When standard retry or cancellation paths are insufficient (e.g., unexpected token surpluses, permanent bridge blacklisting, or lost outbound settlement evidence), the RescueModule is invoked.
Tracked-Ledger Protection:
While the RescueModule can execute broad calls, it is constrained by a strict accounting invariant. The RescueModule cannot transfer or rescue tokens that are actively accounted for in the Executor or Dispatcher tracked ledgers (Settled Value, In-Flight, or Tracked Idle). It can only be used to extract untracked fee dust or unexpected airdrops/donations.
If tracked backing must be manually manipulated due to a catastrophic bridge failure, it requires a fully governed, delayed force-resolution path that explicitly declares the final accounting outcome, subject to the RESCUE_GUARDIAN veto.
Last updated
Was this helpful?