Cross-chain Deposit

Phase 0: Route Generation and Selection

1. The user selects a vault to deposit into, a funding token, and the amount to deposit into the vault

2. User requests routes from the Superform API

3. User selects a route

4. User approves permit2 contract for funding token (if needed)

Phase 1A: Bridging Liquidity and Data

Atomic phase

1. User calls singleXChainSingleVaultDeposit. The function sends the funding token and data containing desired bridge/swap route and end states (chain, vault) to SuperformRouter. The function parameters are complex; therefore, using the Superform API to generate valid function parameters is suggested

2. Once the request is initiated, the tokens may be swapped to the target vault's underlying token if the funding token differs from the underlying. The swap can be performed before the bridge, on the source chain, or after the bridge, on the destination chain. Swaps will be performed on the chain with the best execution

3. SuperformRouter bridges the tokens via the bridge route selected in the first step

4. SuperformRouter generates a payload and proof with the singleVaultSFData and calls dispatchPayload to send them via the AMBs specified in initial request. This payload contains instructions that CoreStateRegistry will use on the destination chain for how to process the incoming tokens

5. SuperformRouter sends the cross-chain payment to the PayMaster contract on the source chain

Phase 1B: Receiving Liquidity and Data

Transit phase (non-atomic)

1. In no particular order

   1. Payload is received by CoreStateRegistry on the destination chain

   2. Payload proof is received by CoreStateRegistry on the destination chain

   3. Liquidity/tokens are received by CoreStateRegistry on the destination chain

   4. ALTERNATIVELY: Tokens are received by dstSwapper. dstSwapper Keeper will call processTx which will swap the the bridged tokens and send them to CoreStateRegistry

2. Updater Keeper calls updateDepositPayload to finalize amount of tokens received before the deposit is processed

Phase 2A: Depositing and Sending Acknowledgment to Source

Atomic phase

1. Processor Keeper calls processPayload to trigger the deposit into the vault

2. This triggers xChainDepositIntoVault and tokens are deposited into the target vault via the target vault’s Superform contract

3. Vault shares are minted to target vault’s Superform

4. Destination CoreStateRegistry generates an acknowledgement payload and proof and calls dispatchPayload to send them back to the source chain with the same AMBs used in the initial request. In this payload the exact amount of vault shares minted will be sent back to the source chain so the equivalent amount of SuperPositions can be minted to the depositing user

Phase 2B: Receiving Acknowledgement

Transit phase (non-atomic)

1. Acknowledgment payload is received by CoreStateRegistry on the source chain

2. Acknowledgement payload proof is received by CoreStateRegistry on the source chain

Phase 3: Minting SuperPositions

Atomic phase

1. Payload is validated

2. CoreStateRegistry processor calls processPayload

3. SuperPositions are minted to the user