πCross Chain
Wombatβs foundational algorithm for the swaps has remained essentially unchanged. You may refer to Wombatβs Whitepaper, the Wombat Side Pool, and Dynamic Whitepaper to understand Wombatβs mechanics better.
Invariant in the Context of Single-Chain
To facilitate crosschain transactions, we modify our stableswap invariant with an additional term, Credit, which serves as a network-neutral representation of value.
Credit is equivalent to the value of 1 token in the pool when the coverage ratio of the token is 100%. In other words, 1 credit can be swapped into 1 token when its coverage ratio is 100%, and vice versa. Users will only obtain credit when the transaction of the designated chain is not executed. Letβs define the crosschain pool invariant for a single chain as follows:
C represents the amount of outstanding credit, which represents the net amount of unrealized credit for that network. In a scenario where all credits are settled (swapped into tokens), C equals zero and is identical to our stableswap invariant.
Invariant in the Context of Crosschain Network
Users can swap between native assets on different chains using a crosschain pool. In a multi-networks setting, we allow network-specific amplification factors, A, and Credit, Cn.
Users can obtain gas tokens on the designated network by sending more gas from the source network, supported by the Wormhole relayer. If a user wants to swap token x from Network A to token B on Network B, we can understand the process in three steps.
The user swaps token X for credit by putting a certain amount of token X into the pool on chain A to get the corresponding amount of C.
Credit is relayed from Network A to Network B with an identical amount of credit.
The user swaps credit to the token and gets token Y on Network B.
Wormholeβs Messaging Layer
Wormhole is the message layer to relay messages in crosschain transactions. The WormholeAdaptor contract is an adapter between the pool and the Wormhole Relayer, publishing messages to the Wormhole Network. It also completes the swap at the designated chain when it receives the signed message, also known as Verified Action Approvals (VAA).
Credit, Mitigating MEV, and Slippage
As the transaction between the source chain and the designated chain is asynchronous, the final received amount is not deterministic when the transaction at the source chain is executed. To address this issue, we introduce the concept of βcreditβ β an imaginary intermediate token.
The transaction in the source chain swap fromToken into credit.
The amount of credit is then relayed to the designated chain, where it is swapped into the toToken.
If no intermediate transactions are performed on the toToken, the final amount received will equal that of a same-chain swap.
Users can specify a minimum amount to receive for the first and second steps.
If the slippage in the first step exceeds the specified amount, the transaction will be reverted to the source chain.
The user will receive credit if the slippage at the second step exceeds the specified amount.
Users can swap credit for native tokens on the designated network or bridge the credit back to the source chain and swap it for native tokens in the source network.
Steps of a Crosschain Swap
To initiate a crosschain swap, the sender will call CrossChainPool. swapTokensForTokensCrossChain.
The Wormhole Relayer requires extra gas tokens to relay the message to the contract on the designated chain. These tokens should be attached in the value field of the message.
To determine the amount of value required, use WormholeAdap- tor.estimateDeliveryFee.
The Guardian Network observes and signs messages.
Wormhole Relayers relay the signed message (the VAA) to the designated chain. Once complete, they will invoke the pool to swap tokens and send them to the receiver.
Users will receive credit if the slippage is too significant and the swap is reverted on the designated chain. Users can then exchange their credit for native tokens.
Last updated