Cross chain swaps in the current form are incomplete. While most exchanges use bridges to facilitate cross chain asset movements, they do not yet combine providers to offer users access to more cross chain assets and better pricing.
This results in a poor user experience as possible economic loss, since users need to bridge, then manually swap to their desired asset on the destination chain.
Token beam seeks to solve this problem, by using cross chain liquidity provided by Thorchain, Chainflip and Maya along with 0x aggregation to provide users with long tail asset swaps at greater speed and better pricing.
This project integrates:
- ChainFlip
- Chainflip Cross Chain Messaging (CCM -> Uniswap to Any Swaps)
- Thorchain
- Maya Protocol
- SwapKit SDK & API
Continue below for an explanation on how each of the aforementioned are integrated into the project.
How it Works
- Users select their source / destination chain and token. The list of available tokens is a combination of coingecko token lists along with SwapKit tokens supported for each provider (Thorchain, Chainflip & Maya). The list is also searchable to make it as easy as possible for users to find their tokens.
- Once a source / destination token and amounts are set, the system will search for the best trade routes and present them to the user. For each route, the UI displays the steps taken on each chain along with a callout for cross chain movements. Users can select different routes within this section to see their respective paths. The optimal trade route is automatically selected for the user.
In the above example, we see that this trade route used liquidity from thorchain, chainflip and maya in the same swap to get users a direct path between BTC.b (avax) and PEPE (arbitrum)!
- When a user is ready to swap, they click the "Swap" button to initiate the swap. A modal will appear showing the user the steps involved in the swap and the swap progress.
Expanding ChainFlip Routes with CCM and Uniswap
Currently Chainflip does not support long tail assets, however with cross chain messaging one can expand the reach of swaps by implementing a contract to handle swaps to any asset. This is the approach we have taken with token beam.
The contract takes the desired input / output token and the input amount, then looks at all the pools on UniswapV3 for that pair. It will then perform a swap in the pool with the best exchange rate (quote + fee) prior to sending tokens to the receiver.
Here is an example of expanding the asset reach with this approach.
In this example, BONK is a memcoin not supported by any of the cross chain providers (chainflip, thorchain or maya). However can still swap to it in one operation. We receive the CCM message and ETH from chainflip to our contract receiver. Then we call into our uniswap swapper to find the best pool to execute with, then send the corresponding tokens to the receiver.
This method can be expanded to other exchanges like balancer / curve / etc or even aggregators like 1Inch and 0x.
Core Concepts
Routes: Defined as sequence of individual swaps, routes are instructions for getting from Asset A to Asset B either on the same chain or different chains. In it's most simple form, there are 3 types of route segments that create a crosschain swap.
- Swap Token to Native
- Swap Native to Native (cross chain)
- Swap Native to Token
Routes can also be expanded to encompass multiple route segments. Examples are:
- Token to Native (cross chain) = Token to Native + Native to Native
- Native to Token (cross chain) = Native to Native + Native to Token
To find the optimal quote, the system will first create a collection of the distinct routes able to get from the source to the target chain and asset. For each segment (swap) in the route, the system asks each provider if they can quote it and if they can, what is the estimated output amount. The provider with the best quote will be selected as the executor and the amountOut will be passed as the amountIn for the next swap until a final output amount is determined for the route.
The best route path (most output) is then chosen.
Connector Chains: When swapping between protocols there may not be a direct path between chain A and chain B. For example, swapping from AVAX to ETH on arbitrum. Thorchain exists on Avalache, but not on arbitrum while chainflip exists on aribitum and not on avalanche.
To facilitate this swap, we need a chain where both protocols exists. The system uses ETH for this. In the previous example, the swap would now become Avalanche -> Ethereum -> Arbitrum.
Providers: Are responsible for providing quotes and executing their part of routes when a user wants to swap. Currently the system supports (Chainflip, Maya, Thorchain and a custom Uniswap Provider built with CCM).
Adding a new provider to the system is simple and requires the provider to implement 4 methods:
- canQuote(swap)
- quote(swap, amountIn, network[testnet|mainnet])
- createOperation(swap, prev, next, network) [ Do anything needed before execute (i.e. get deposit address)
- execute(swap, prev, next, network)
Integrations
ChainFlip: The app uses liquidity provided by the ChainFlip network to facilitate swaps between ARB, ETH and BTC. Quotes and deposit addresses are requested from a hosted api (token-beam-api) using the ChainFlip SDK.
The implemented chainflip provider is responsible for building swaps to publish to the chainflip network. When it receives an execute instruction, it looks at the next step in the proposed swap to see if a cross chain message needs to be constructed. If yes, then it calls the next provider to get information to build the swap. It is also responsible for determining what asset to transfer to the destination address (native / erc20)
Cross Chain Messaging (CCM): The app uses cross chain messaging to facilitate long tail asset swaps via Uniswap pools. The procedure is explained in more detail above.
Thorchain: In addition to other chains, thorswap is the sole route provider for AVAX and BSC chains. Liquidity is accessed through the thorswap api which also expands asset coverage to 1Inch approved tokens via swapIn / swapOut functionality on approved aggregators.
The implemented provider will deposit tokens to the destination address provided by the next swap, or the user address if it is the last step in the chain of swaps.
The app would need an approved aggregator deployed on the Thorchain network to allow chaining Thorchain -> Thorchain or Thorchain -> Maya routes. Thorchain -> Thorchain may not seem needed but can provide better rates since it would access different liquidity than a direct swap. (Play with the UI to see how!)
Maya: Provides long tail assets swaps on arbitrum along with native swaps between mainstream chains. The app accesses liquidity through the SwapKit api.
SwapKit SDK & API: Each implemented provider is responsible for telling the system whether or not it can quote a route segment. This is used to prevent making unneeded api calls. To do this providers need to understand what assets they support on various chains. The token lists provided by the SDK is how providers access this information.
In addition to token information, the SDK / Api are used in concert to provide quotes and transaction execution information to the system. Maya and Thorchain specifically rely on these calls for execution.