Skip to content
Get in touch

Architecture

Overview

The architecture of liquidity pools involves the Parent Pool, hosted on a single chain, and Child Pools, deployed to the rest of the supported chains. The Parent pool has exclusive rights to control liquidity on each of the child pools.

Logo

The advantage this architecture brings is the ease of use for the liquidity providers, as the fee is earned universally throughout all the pools, regardless of the volume discrepancies between each pool. The liquidity provider is entitled to a share of earned fees, which is determined in proportion to the amount of LP tokens held by the liquidity provider and the sum of earned fees across every pool in the infrastructure. This approach removes the need of the liquidity provider to transfer the liquidity from low-volume pools, to the ones with greater volume. Additionally, the initial distribution of equal proportions of provided liquidity is taken care of by the Parent pool. In order to interact with the infrastructure as a liquidity provider, all actions are taken exclusively through the Parent Pool.

Liquidity cap

The speed of the settlement layer (~24 minutes) allows for a very efficient liquidity usage. This led us to set a liquidity cap for our pools in order to maintain high APY rates and to reduce risks for liquidity providers.

Deposits

The cross-chain liquidity deposit logic consists of 4 stages with all communication between the LP and the infrastructure taking place in the parent pool. The liquidity infrastructure uses the well-known concept of liquidity tokens, which represent a portion of the liquidity with fees the provider is entitled to.

Deposit Flow

  1. LP deposits the funds into the parent pool
  2. Parent pool uses CLF to fetch liquidity data on all chains in order to determine the LP amount to issue to the depositor
  3. Parent pool receives liquidity data and issues LP tokens in proportion to the deposit, to the liquidity provider
  4. Parent pool initialises the liquidity distribution using Chainlink CCIP, sending an equal proportion of the deposit to each of the pools, completing the liquidity provision

Logo

Withdrawals

As with any LP-related actions, the withdrawals are processed strictly through the parent pool, which in a similar fashion to deposits, interacts with the child pools in order to obtain total liquidity, burn the LP tokens and perform the withdrawal. As at the point of requesting the withdrawal, the liquidity is distributed across multiple chains. Therefore, the withdrawal process is split into three parts: the initiation of the withdrawal, the collection of cross-chain liquidity in the Parent pool, and the completion of the withdrawal.

Logo

In order to obtain liquidity that is present on the child pools, the parent pool invokes the CLA+CLF contract, which is responsible for the delayed triggering of the liquidity withdrawal from child pools back to the parent pool. After a withdrawal request is placed into the contract, a deadline of +7 days is counted, after which a liquidity pull will be performed. For automating the task, Chainlink Automations is used, which check the condition of the contract with every block, and trigger Chainlink Functions for performing the liquidity pull using one of the authorised messenger wallets, the private key of which is located in DON-Hosted secrets, similarly to the execution layer of the user-facing infrastructure.

After the liquidity has been collected in the parent pool, the liquidity provider can call the completeWithdrawal() function in the parent pool, which will burn the LP tokens that were originally taken and send the liquidity back to the depositor, thus completing the withdrawal process.

Withdrawal Flow

  1. LP initiates the withdrawal request and approves LP tokens to spend
  2. Parent pool obtains cross-chain liquidity of child pools using CLF
  3. Parent pool submits a pending withdrawal request to CLA+CLF contract
  4. 7 days later, CLA+CLF sends a withdrawal request to child pools, moving the liquidity back to the parent pool
  5. After the liquidity is moved to the parent pool, the LP calls the withdrawal completion, which burns the LP tokens and returns the liquidity