Cross Swap

Introduction

Hotcross introduced the cross bridge product that allows teams to create a BEP20 equivalent on the Binance Smart Chain and let the ETH token holders utilise their tokens on both chains at will. This turned to be a succesful product and we have already facilitated such bridging capability for a several projects. The aftermath of all this is that Hotcross is transferring value from ETH to BSC. The value is represented by the underlying assets which can, in theory, exist on multiple blockchain networks.

A natural extension of the cross bridge is the new product called cross swap. To explain what the product does we can look into the current situation with the cross bridge. At a very abstract level the cross bridge works like this:

  1. A team with an ERC20 token wants to create a new BEP20 token on the BSC side.
  2. Cross Bridge deploys a new BEP20 token.
  3. It then uses a set of bridge contracts on both sides to essentially lock tokens on one side and mint new tokens on the other side. Similarly, it allows BEP20 tokens to be burnt and ERC20 to be unlocked.

We should note here that the ERC20 and BEP20 refer to the same exact asset that happens to live on different chains. Another important thing to note is that part of the process of deploying the bridge is the creation of a new BEP20 tokens. Finally, the most important point is that the BEP20 tokens are minted and burnt based on the action that use is performing i.e. ETH → BSC or BSC → ETH.

This solution provides the following gurantees:

  1. A user that transferred their ERC20 to BEP20 can always claim back the locked amount by burning the BEP20.
  2. The balance of ERC20 locked and BEP20 supply on BSC will always be the same.

On the other hand, we can witness some evident shortcoming:

  1. This approach essentially causes the so called balkanisation of cross-chain bridges. There are lot of bridges that each serve one particular asset.
  2. Hotcross is no the only solution to bridge tokens from ETH to BSC. The practical result of that is there are a lot of BEP20 tokens that have already been bridged from one chain to another.
  3. The whole bridge ecosystem does not fit very well into the Defi context. There is no clear way of earning by providing liquidity.

How it works

The solution to the first two issues is creating a unified DApp that will facilitate the bridging of multiple assets rather that a single one. The problem with this approach is the tight coupling of those bridges to a particular technology. For example, Hotcross v2 does provide a DApp for multiple assets. However, all those assets will need to follow the proprietary bridging technology provided by Hotcross. As a result, all the other BEP20 that have been created using difference technologies render unusable within the context of V2.

Cross Swap is the answer to the above shortcomings. It is an interoperable cross-chain bridging solution that can facilitate existing ERC20/BEP20 pairs, as well as, create brand new (the way Hotcross V2 does it). In addition to that, it solves the issue of under-utilised assets. More specifically, a liquidity provider will be able to put their asset to work and earn fees by providing liquidity into the bridge and thus facilitating a smooth bridging event for users that simply want to swap their ERC20 tokens for the BEP20 counterpart.

Let’s see how that will work in practise. First of all let’s define the main roles in the system:

  1. Liquidity Provider: Any user that holds some assets and desires to earn income by putting those assets into a pool on Cross Swap.
  2. User: User who simply possess assets on one chain and want to bridge it to some other chain i.e. Send 100 USDT from ERC20 and receive 100 USDT on BSC

Let’s see a typical user journey that shows the aforementioned actors in practise:

  1. Alice(LP) deposits 100 USDT into the ETH Pool and she receives 100 cUSDT. The cUSDT plays the same role as an LP token on conventional AMM platforms i.e. proof that liquidity was provided and a means to claim back the liquidity plus any accrued fees.
  2. Bob(LP) deposits 100 USDT into the BSC pool and similarly received 100 cUSDT on the BSC side.
  3. The current states of the pools is: EthPool → 100USDT total liquidity BscPool → 100USDT total liquidity
  4. Carol(User) has got 50USDT on ETH and wants to transfer them to the BSC side. She sends the 50USDT into the EthPool and the bridging logic will make sure that she will get 50 USDT (minus any LP fees) on the BSC side.

The current states of the pools is: EthPool → 150USDT total liquidity BscPool → 50USDT total liquidity

Let’s pause for a second and compare this to the current bridging logic. At the moment, If carol want to transfer 50USDT to the BEP20 that would not be really possible. A more realistic scenario would be to transfer 100 FRONT from ETH to BSC. Hotcross Bridge has created the BEP20 for front and the bridge smart contracts are the sole owners of that contract. This means that validators can mint new BEP20 and burn them accordingly. However, USDT (and any other existing BEP20) does not fall into this category. In a nutshell, liquidity in the current solution is created and removed by the means of minting/burning tokens that fall into the current Hotcross ecosystem. In comparison, liquidity on Cross Swap is provided by the LPs; no minting or burning.

Alice(LP): Decides one day what she wants to withdraw some part of the deposited liquidity. She sends 50 cUSDT LP tokens to the EthPool and get’s back 50 USDT (plus any accrued LP fees).

The system will have to make sure that LPs can get back their liquidity, otherwise the entire idea will not work. Let’s look at an example that describes this situation:

  1. Alice(LP) deposits 100 USDT into the ETH pool
  2. Bob(LP) deposits 100 USDT into the BSC pool
  3. Carol(User) bridges 50 USDT from ETH → BSC
  4. Chunk(User) bridges 50 USDT from ETH → BSC
  5. Alice(LP) withdraws 100 USDT from the ETH pool The current states of the pools is: EthPool → 100USDT total liquidity BscPool → 0USDT total liquidity
  6. Bob(LP) wants to withdraw 100 USDT from the BscPool. However, the pool has no liquidity, whatsoever.

At first glance, it looks like Bob provided liquidity which was fully drained and now he’s left with his 100 cUSDT LP tokens. This might hinder anyone to provide liquidity in the first place;

The solution to this problem might involve some bridging logic. More specifically, we know that there will always be some liquidity on one or the other side. We know that because, users that drain liquidity on one side, provide the same liquidity on the other side. We can witness that in the above example. Although the BscPool has 0 liquidity, the EthPool has got 100 USDT which is enough to payback Bob for the liquidity he provided on BSC.

In essence, the solution allows liquidity to be withdrawn from a different chain from the one it was provided in the first place.

Architecture

image

Benefits

  1. The problem of balkanisation of cross-chain bridges becomes irrelevant. There can be a single place that allows people to swap tokens from one chain to another.
  2. For the same reason the lack of interoperability is fixed. The platform can facilitate tokens that were created using other bridging technologies, the Cross Bridge ones and literally any other custom solution.
  3. Create an entirely novel Defi product that allows users to earn money by locking liquidity in a bridge.
  4. We don’t have to deal with teams; spinning up validators and maintaining several bridges. This product targets the retail audience.
  5. We can provide utility to the CROSS token which can be used pay swap fees at a discount.

Open Issues

  • How do we send fees to LP when they withdraw liquidity from a different chain? We described an edge case above where the liquidity on one network becomes zero so LPs on that network would need to withdraw their liquidity from the other network. However, this poses an issue regarding the accrued fees.
    • Let’s demonstrate this with an example. Imagine the fees that users pay are 1% of the amount transferred. The above example will be like this:

    • Alice(LP) deposits 100 USDT into the ETH pool
    • Bob(LP) deposits 100 USDT into the BSC pool
    • Carol(User) bridges 50 USDT from ETH → BSC
    • Chunk(User) bridges 50 USDT from ETH → BSC
    • Alice(LP) withdraws 100 USDT from the ETH pool. She will also receive the accrued fees pro-rata i.e. according to her stake of LP tokens, which in this example is 100%. That is she will receive 101 USDT back
    • The current states of the pools is: EthPool → 100 USDT total liquidity BscPool → 0 USDT total liquidity

      Bob as explained earlier will have to withdraw the liquidity from the EthPool. So he will bridge 100 cUSDT from BSC to ETH and deposit burn it in the EthPool and get back 100 USDT.

      So far so good; However, the question is shouldn’t Bob get some part of the fees Alice received. The natural answer would be probably yes. However this complicated things a lot. Thus the following rule will have to be applied.

      Liquidity fees are claimable on the chain that LP tokens are burnt!

In any case, this is such an edge case. If we ever reach a point where the liquidity id 0 on one side then the entire thesis of cross-chain swap becomes invalid.