Self Balancing Cross-Chain Liquidity Pools

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.

  1. Excess State (L > SL)
    In this state, total available liquidity is more than the supplied liquidity. This state means users are exiting this chain and transferring their funds from current chain to other chains.
  2. Deficit State (L < SL)
    In this state, total available liquidity is less than the supplied liquidity. This state means users are coming to this chain from other chains. In this state, transfer fee paid by the user is more and it increases as the pool becomes more deficit.
  3. Equilibrium State ( L == SL)
    In this state, total available liquidity is equal to the supplied liquidity. This is the state where we want each pool to be in and all actions done on the pool should try to bring the pool in equilibrium state either by charging more transfer fee or rewarding some transfers.

Deposit Event

This event is the result of deposit transaction done by the user on source chain. This event always increases the total available liquidity (L) of the pool for the given asset.

Now depending on the state of this pool, this transaction can be a normal transaction or an arbitrage transaction. Let’s consider different states of the pool.

  1. Excess State
    In this state, L > SL, so this deposit transaction is just increasing the L of the pool and moving the pool further in Excess State. So this will be considered a normal deposit transaction and user funds will be deposited in the pool and a Deposit event will be emitted from the smart contract.
  2. Deficit State
    In this state, L < SL, so this deposit transaction is increasing L and hence taking the pool towards equilibrium state. So we should reward this transaction and this deposit transaction will be our arbitrage transaction and will be rewarded from the tokens accumulated in the Incentive Pool. The amount of reward will depend on how close this transaction is taking the pool to equilibrium state.
  3. Equilibrium State
    In this state, L == SL, so pool is already in equilibrium state and this deposit is taking the pool from equilibrium to excess state. So this deposit will be considered a normal deposit transaction and user funds will be deposited in the pool and a Deposit event will be emitted from the smart contract.

Reward amount for Arbitrage Transaction

Here reward to be given from Incentive Pool (IP) depends on the amount deposited and how much closer that deposit brings the pool to the equilibrium state.

R(ip) = (a * IP) / (L(e) - L) when a < (L(e) - L)

R(ip) = IP when a ≥ (L(e) - L)

where

a ⇒ Amount deposited by the user in the pool

L(e) ⇒ Liquidity at equilibrium state

L ⇒ Current liquidity of the pool for given asset

IP ⇒ Incentive Pool Amount for given asset

R(ip) ⇒ Reward amount calculated from Incentive Pool for a given a

Transfer Event

This event is triggered by the Executors on destination chain and is the result of a Deposit event on other supported chains. This event always reduces the available liquidity (L) of the pool.

In this event, the transfer fee (F) is charged from the user and after deducting the transfer fee, rest amount is transferred to the user from the Liquidity Pool.

Transfer fee (F) to be deducted from the transferred amount depends on the state of the pool. It varies with different states.

F(e) is the percentage fee to be charged when the pool is in equilibrium state. This is currently set to 0.1%

  1. Equilibrium State
    In this state, L == SL, so F = F(e) = 0.1%

  2. Deficit State
    In this state, L < SL, so the transfer event will move the pool away from equilibrium state so transfer fee should be more. So F > F(e)

  3. Excess State
    In this state, L > SL, so the transfer event will reduce L and will move the pool towards equilibrium state. So this transfer should be charged less. So F < F(e)

There is also an upper limit to the percentage fee we’ll be deducting from the transfer fee.

F(max) = 10% , the max fee to be deducted from the transfer amount.

So if the transfer amount is more and is taking the pool further away from the equilibrium state, F will be high and if after transfer L >> SL, F will be way smaller than F(e) and approaches to 0, if there’s an infinitely large amount of liquidity available compared to SL.

Fee can be calculated using the formula below:

F(L(e), L(r)) = F(max) * F(e) *L(e)^d / F(e)*L(e)^d + (F(max) - F(e))*L(r)^d

where,

L(e) ⇒ Liquidity at equilibrium state. L(e) == SL

L(r) ⇒ Resulting liquidity after the transfer is done. L(r) = (L - transfer Amount)

F(max) ⇒ Max percentage fee to be deducted. F(max) = 10% (Constant value)

F(e) ⇒ Fee to be deducted at equilibrium state. F(e) = 0.1% (Constant value)

d ⇒ Deep Factor. Value that decides how much deeper the curve looks

This is the transfer fee which user needs to pay from the amount transferred. This fee is divided into two parts.

F = F(lp) + F(ip)

where,

F(lp) ⇒ Liquidity Provider Fee. This fee is ≤ F(e) i.e., Liquidity Provider fee will never exceed F(e), either its 0.1% or less.

F(ip) ⇒ Incentive Pool Fee. This fee is 0, if F ≤ F(e) i.e., if pool is still in Excess state then we don’t charge any Incentive Pool Fee from the transfer. Whole fee goes to Liquidity Providers.

Total Transfer Fee

The total fee to be paid by the user is Transfer fee calculated above + Gas fee. Gas fee is calculated in the token being transferred and is also deducted from the transferred amount and is accumulated on Liquidity Pool to be taken by the Executor that initiated the Transfer transaction.

This gas fee accumulated can be claimed by the executor later in bulk and convert it back to native currency to be used to continue doing Transfer transactions.

F(total) = F(lp) + F(ip) + F(gas)

where,

F(gas) ⇒ Gas fee calculated on-chain based on computation done in transfer transaction. This is denoted in the same asset being transferred. Some premium (in terms of gas overhead) can be set on the gas fee to compensate Executors as they get the exposure to the conversion of asset being transferred back into native currency of blockchain. And both prices can vary.

So to take some use cases, when the pool is in Excess state or Equilibrium state, user only pays F(lp) + F(gas) as F(ip) = 0 in this case.

Conclusion

This self rebalancing liquidity pool model can be used in any cross chain bridge solution that does not depend on any other external AMM or bridge to rebalance the liquidity across the pools.

In Hyphen we’ll be using the same model to deploy the liquidity pools which will scale Hyphen and adding new chains and assets on Hyphen will become very easy and it will also introduce arbitrage opportunities for the users to get incentivised for bridging their assets.

We expect the community to build out these rebalancing arbitrage bots who will identify the arbitrage opportunity in Hyphen as it is created and will rebalance the pools as there’ll be incentive for them to do so.

Thanks to @TimelordEth for his help in designing the dynamic fee bonding curve and @TreborYatska , @AraBalaghi for polishing it.

If you haven’t tried Hyphen. Try out now https://hyphen.biconomy.io

5 Likes