Cross-chain Deposit
Phase 0: Route Generation and Selection
The user selects a vault to deposit into, a funding token, and the amount to deposit into the vault
User requests routes from the Superform API
User selects a route
User approves permit2 contract for funding token (if needed)
Phase 1A: Bridging Liquidity and Data
Atomic phase
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 suggestedOnce 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
SuperformRouter bridges the tokens via the bridge route selected in the first step
SuperformRouter generates a payload and proof with the
singleVaultSFData
and callsdispatchPayload
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 tokensSuperformRouter sends the cross-chain payment to the PayMaster contract on the source chain
Phase 1B: Receiving Liquidity and Data
Transit phase (not-atomic)
In no particular order
Payload is received by CoreStateRegistry on the destination chain
Payload proof is received by CoreStateRegistry on the destination chain
Liquidity/tokens are received by CoreStateRegistry on the destination chain
ALTERNATIVELY: Tokens are received by
dstSwapper
.dstSwapper
keeper will callprocessTx
which will swap the the bridged tokens and send them to CoreStateRegistry
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
Processor keeper calls
processPayload
to trigger the deposit into the vault.This triggers
xChainDepositIntoVault
and tokens are deposited into the target vault via the target vault’sSuperform
contractVault shares are minted to target vault’s
Superform
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)
Acknowledgment payload is received by CoreStateRegistry on the source chain
Acknowledgement payload proof is received by CoreStateRegistry on the source chain
Phase 3: Minting SuperPositions
Atomic phase
Payload is validated
CoreStateRegistry processor calls
processPayload
SuperPositions are minted to the user
Last updated