There are two kinds of cross-chain asset transfer bridges: bridges that mint new tokens on the destination chain and bridges that utilise existing tokens. Today, we’ll talk about the latter, and in order for this bridge to function you need two main components: Infrastructure & Liquidity.

Liquidity Pools are maintained on the source and destination blockchains, where users deposit funds on the source chain and withdraw funds from the destination chain, after deducting protocol and gas fees. Source chain transaction verification is outside of the scope of this article.

The Problem with Cross-Chain Liquidity Pools

This kind of Liquidity Pool setup requires balance across the various ends of like asset pools. As transfers take place, too much one sided demand can lead to pool imbalances, with low liquidity in highly demanded destination pools and high liquidity in popular source pools. In these cases, bridge transfers will fail unless the liquidity is rebalanced. Typically, node infrastructure carries out this rebalancing, bearing the burden of increased overhead without proper compensation.

The Solution

This article proposes a dynamic fee model that properly incentivises automatic liquidity pool rebalancing. In this model the transfer fee is determined by pool available liquidity, pools are independent of external AMMs, and native bridges are not required to carry out rebalancing.

If available liquidity in the pool is lower than the supplied liquidity the transfer fee is higher than the normal transfer fee (equilibrium fee), and vice versa. The higher transaction fees are used to incentivise cross chain transfers from low liquidity pools to high liquidity pools, thus rebalancing the pools.

In this approach, a single Liquidity Pool is deployed on each supported chain that contains liquidity of multiple supported tokens.

Liquidity pools are mutually exclusive and operate independently of other pools on other chains. They don't need to know the state of pools on other chains. Liquidity Suppliers provide liquidity to these pools and enjoy LP fees from user transfers.

Let's say a user is doing the cross-chain transfer from source chain to destination chain. During the transfer, two events happen. Deposit event on source chain and Transfer event on destination chain. What happens during these events will depend on the total available liquidity and total supplied liquidity on the pool where the event is happening.

Let's define some terms before proceeding forward:

LP ⇒ Liquidity Provider

Liquidity Pool ⇒ A smart contract deployed on each chain where LP provides liquidity

L ⇒ Available Liquidity on the pool

SL ⇒ Total Supplied Liquidity on the pool by LPs

F ⇒ Transfer fee percentage paid by the user on the destination chain

IP ⇒ Incentive pool. It's a state on the Liquidity pool itself and not a separate pool. This pool is filled by some part of the Transfer Fee paid by the user on the destination chain.

State of a Liquidity Pool

A pool can be in different state based on the available liquidity and supplied liquidity on the pool.