Symbiosis
Search…
🟪
Metarouter V3 | Symbiosis Finance

Introduction

Metarouter is a smart contract that manages calls to different contracts on behalf of a user during a cross-chain swap and cross-chain zap. The smart contract is deployed and tuned by Symbiosis administrators while adding a blockchain to the Symbiosis protocol.
High/low gas fees. A gas fee is always paid for in the native cryptocurrency of that blockchain, where the transaction gets executed. Thus, when we compare gas prices on different blockchains, we compare them, for example, in the USD equivalent.
There are two cases while doing cross-chain swaps:
  • Case 1: a cross-chain swap from a blockchain with a high gas fee to a blockchain with a lower gas fee,
  • Case 2: a cross-chain swap from a blockchain with a lower gas fee to a blockchain with a high gas fee.
As an example, let us consider the pair Ethereum — Binance Smart Chain.
The Symbiosis protocol works with USDC on Ethereum and BUSD on Binance Smart Chain. Since the gas fee on Ethereum is higher than the gas fee on Binance Smart Chain, the liquidity pool to do cross-chain swaps for this pair is located on Binance Smart Chain. This liquidity pool contains sUSDC <> BUSD, where sUSDC represents USDC of Ethereum on Binance Smart Chain with the ratio of 1:1.
Metarouter also process cross-chain zap operations while adding liquidity to the liquidity pools owned by Symbiosis or third party DiFi protocols.

Case 1: UNI -> CAKE

There is an example of a cross-chain swap from a blockchain with a high gas fee to a blockchain with a lower gas fee.
A user would like to do a cross-chain swap: UNI ERC20 on Ethereum → CAKE BEP20 on Binance Smart Chain.
The route of UNI to CAKE may look like: UNI → USDC → sUSDC → BUSD → CAKE
The Metarouter contract manages all calls within one blockchain, as shown in Scheme 1.
Scheme 1. The Metarouter routine for a UNI → CAKE cross-chain swap.
When 1inch indexes Symbiosis’ {stablecoin <> sToken} liquidity pools, Steps 10, 11 will become one step with 1inch: sUSDC → CAKE.
Cross-chain swap (explanation of Scheme 1)
  1. 1.
    The user signs a transaction allowing MetarouterGateway to take some ERC20 tokens (UNI in this example) from the user's address. If the origin token of the cross-chain swap is a native cryptocurrency or if the user has got ERC20 tokens approved earlier, then this step is omitted.
  2. 2.
    The user signs one transaction consisting of a sequence of intermediate swaps necessary to obtain CAKEs for UNIs and sends this transaction to Ethereum (the origin blockchain).
  3. 3.
    Metarouter requests UNIs needed for the swap from MetarouterGateway. MetarouterGateway performs security checks and then sends user's UNIs to Metarouter. If the origin token of the cross-chain swap is a native cryptocurrency, then this step is omitted.
  4. 4.
    Metarouter swaps UNIs to USDCs with the 1inch router. If there is no 1inch on the blockchain, then DEXes are used for this intermediate swap.
  5. 5.
    Metarouter approves Portal to take the USDCs received during the swap from its address. Portal deposits the USDCs from the Metarouter address to its address.
  6. 6.
    Portal calls BridgeV2. BridgeV2 emits an event that some actions should take place on Binance Smart Chain (the destination blockchain).
  7. 7.
    Relayers sign a transaction for Binance Smart Chain. The transaction contains a sequence of actions to be done on Binance Smart Chain for the user to receive CAKEs.
  8. 8.
    BridgeV2 receives the request and handles it to Synthesis.
  9. 9.
    Synthesis mints sTokens and passes control to Metarouter.
  10. 10.
    Metarouter swaps sTokens for BUSD on Symbiosis’ DEX, at the rate current at the time of the swap (the rate may differ from the rate at the time of transaction signing in Step 1).
  11. 11.
    Metarouter swaps BUSDs for CAKEs with the 1inch router, at the rate current at the time of the swap (the rate may differ from the rate at the time of transaction signing in Step 2). If there is no 1inch on the blockchain, then DEXes are used for this intermediate swap. After the swap BUSDs are deposited to the DEX address that used to swap, CAKEs are deposited to the user's address on Binance Smart Chain.
Steps 2-6 are done within one transaction. This means that if we get to a step that cannot be done, all changes made before that step will be rolled back.
Steps 7-11 are done within one transaction. This means that if we get to a step that cannot be done, all changes made before that step will be rolled back.
Emergency
User's assets get locked in Portal on Ethereum, but nothing happens on Binance Smart Chain. To get back assets on Ethereum the user should call Synthesis on Binance Smart Chain to revert the cross-chain swap. As soon as the transaction is executed, assets will be deposited to the user’s address on Ethereum.
For more information on the emergency, please refer to Minting and Burning > Emergencies

Case 2: CAKE -> UNI

There is an example of a cross-chain swap from a blockchain with a lower gas fee to a blockchain with a high gas fee.
A user would like to do a cross-chain swap: CAKE BEP20 on Binance Smart Chain → UNI ERC20 on Ethereum.
The route of CAKE to UNI may look like: CAKE → BUSD → sUSDC → USDC → UNI
The Metarouter contract manages all calls within one blockchain, as shown in Scheme 2.
Scheme 2. The Metarouter routine for a CAKE → UNI cross-chain swap.
When 1inch indexes Symbiosis’ {stablecoin <> sToken} liquidity pools, Steps 4, 5 will become one step with 1inch: CAKE → sUSDC.
Cross-chain swap (explanation of Scheme 2)
  1. 1.
    The user signs a transaction allowing MetarouterGateway to take some ERC20 tokens (CAKE in this example) from the user's address. If the origin token of the cross-chain swap is a native cryptocurrency or if the user has got ERC20 tokens approved earlier, then this step is omitted.
  2. 2.
    The user signs one transaction consisting of a sequence of intermediate swaps necessary to obtain UNIs for CAKEs and sends this transaction to Binance Smart Chain (the origin blockchain).
  3. 3.
    Metarouter requests CAKEs needed for the swap from MetarouterGateway. MetarouterGateway performs security checks and then sends user's CAKEs to Metarouter. If the origin token of the cross-chain swap is a native cryptocurrency, then the step is omitted.
  4. 4.
    Metarouter swaps UNIs to USDCs with the 1inch router. If there is no 1inch on the blockchain then DEXes are used for this intermediate swap.
  5. 5.
    Metarouter swaps BUSD for sTokens on Symbiosis’ DEX, at the rate current at the time of the swap (the rate may differ from the rate at the time of transaction signing in Step 1).
  6. 6.
    Metarouter approves Synthesis to take the sTokens received during the swap from its address. Synthesis deposits the sTokens to its address and burns them.
  7. 7.
    Synthesis calls BridgeV2. BridgeV2 emits an event that some actions should take place on Ethereum.
  8. 8.
    Relayers sign a transaction for Ethereum. The transaction contains a sequence of actions to be done on Ethereum for the user to receive UNIs.
  9. 9.
    BridgeV2 receives the request and handles it to Portal.
  10. 10.
    Portal deposits USDCs to the Metarouter address.
  11. 11.
    Metarouter swaps USDCs for UNIs with the 1inch router, at the rate current at the time of the swap (the rate may differ from the rate at the time of transaction signing in Step 2). If there is no 1inch on the blockchain, then DEXes are used for this intermediate swap. After the swap USDCs are deposited to the DEX address, UNIs are deposited to the user’s address on Ethereum.
Steps 2-7 are done within one transaction. This means that if we get to a step that cannot be done, all changes made before that step will be rolled back.
Steps 8-11 are done within one transaction. This means that if we get to a step that cannot be done, all changes made before that step will be rolled back.
Emergency
User's sTokens get burned on Binance Smart Chain, but nothing happens on Ethereum. To revert burning on Binance Smart Chain the user should call Portal on Ethereum. As soon as the transaction is executed, assets will be deposited to the user’s address on Binance Smart Chain.
For more information on the emergency, please refer to Minting and Burning > Emergencies

Cross-chain Zaps

There is an example of a cross-chain Zap.
A user has some tokens on Blockchain 1 and would like to add liquidity to a liquidity pool located on Blockchain 2. Its a cross-chain operation.
The route of any token on Blockchain 1 to the liquidity pool on Blockchain 2 may look like: any token → TokenB → sTokenB → Liquidity pool
Scheme 3. The Metarouter routine for a cross-chain Zap.
Cross-chain Zap (explanation of Scheme 3)
  1. 1.
    The user signs a transaction allowing MetarouterGateway to take some ERC20 tokens from the user's address. If the origin token of the cross-chain zap is a native cryptocurrency or if the user has got ERC20 tokens approved earlier, then this step is omitted.
  2. 2.
    The user signs one transaction consisting of a sequence of intermediate necessary steps.
  3. 3.
    Metarouter requests tokens needed for the swap from MetarouterGateway. MetarouterGateway performs security checks and then sends user's tokens to Metarouter. If the origin token of the cross-chain zap is a native cryptocurrency, then this step is omitted.
  4. 4.
    Metarouter swaps any token to TokenBs with the 1inch router. If there is no 1inch on the blockchain, then DEXes are used for this intermediate swap.
  5. 5.
    Metarouter approves Portal to take the TokenBs received during the swap from its address. Portal deposits the TokenBs from the Metarouter address to its address.
  6. 6.
    Portal calls BridgeV2. BridgeV2 emits an event that some actions should take place on Blockchain 2 (the destination blockchain).
  7. 7.
    Relayers sign a transaction for Blockchain 2. The transaction contains a sequence of actions to be done on Blockchain 2 to add liquidity to the liquidity pool.
  8. 8.
    BridgeV2 receives the request and handles it to Synthesis.
  9. 9.
    Synthesis mints sTokenBs and passes control to Metarouter.
  10. 10.
    Metarouter deposits sTokenBs for BUSD to the specified on Step 2 liquidity pool and the user gets LP token ons Blockchain 2.
Steps 2-6 are done within one transaction. This means that if we get to a step that cannot be done, all changes made before that step will be rolled back.
Steps 7-10 are done within one transaction. This means that if we get to a step that cannot be done, all changes made before that step will be rolled back.
Emergency
User's assets get locked in Portal on Blockchain 1, but nothing happens on Blockchain 2. To get back assets on Blockchain 1 the user should call Synthesis on Blockchain 2 to revert the cross-chain zap. As soon as the transaction is executed, assets will be deposited to the user’s address on Blockchain 1.
For more information on the emergency, please refer to Minting and Burning > Emergencies