🟢
Pools
Xfai V0 Protocol Pools
Unlike most automated market makers (AMM), Xfai's decentralized exchange (DEX) design does not have token pairs. Xfai uses unique token pools for every token hosted on the DEX instead. To minimize the slippage experienced during trades, every pool utilizes an internal weight.
When a liquidity pool contract is first created, its token balance and weights are set to 0. In order for the pool to facilitate trades, it must be "seeded" with an initial deposit of tokens. This deposit is used to establish the pool's initial balance and weight, as well as the token's price in relation to other tokens on the Xfai DEX. To provide liquidity to a pool on the Xfai DEX, the end-user has to provide an amount of pool tokens and ether. The pool tokens are used to establish the primary pool's initial balance, while the ether is used to set the primary pool's weights. Xfai's approach to liquidity provisioning is therefore intentionally two-sided. For more information on how this weight mechanism works, see the Theory subsection of this page.
When a user deposits liquidity into a pool on the Xfai DEX, they are rewarded with unique tokens called liquidity tokens. These tokens are minted and sent to the user's address to represent their contribution to the pool. The amount of liquidity tokens a user receives is determined by the proportion of the pool's liquidity that they provide. These tokens serve as a way to track and reward liquidity providers (LPs) for their contributions to the pool. Whenever a trade is made on the Xfai DEX, a fee is charged to the transaction sender.
of the fees get distributed pro-rata to all LPs in the pool, whereas the other
get distributed to all Infinity NFT holders (see the Infinity NFT section). To retrieve their underlying liquidity, plus any fees they have accrued, LPs must "burn" their liquidity tokens, exchanging them for their share of the pool and their proportional fee allocation. It's worth noting that liquidity tokens themselves are tradable assets, so LPs have the option to sell, transfer, or use them in any way they choose.
Xfai uses a weighted pool system as its AMM model. Each pool is made of an ERC20 token reserve
, and a dynamic weight
which determines the exchange values of the token.
The Xfai CPMM model does not require a whitelisting procedure for the on-boarding of new pools. Anyone on Xfai can create new pools in a permissionless way, with deterministic addresses that can be computed offline.
Xfai uses a two-sided liquidity provisioning approach to provide liquidity to a pool. As an example, let there be a pool
. To mint a given amount of liquidity tokens for
, we send tokens
to
as well as ether (Ethereum's native coin). After the states are updated, a given amount of liquidity tokens are minted and sent to a recipient:
Where
represents the amount of liquidity tokens minted,
represents the reserve of tokens
within the pool,
represents the weights of the pool,
represents he amount of tokens
inserted into
,
represents the amount of ether provided to
, and
represents the total amount of already minted liquidity tokens for
.
Liquidity providers receive fees whenever a trade occurs within the pool of their liquidity token. Swap fees occur at the input pool, that is, if someone initiates a swap from
to
, the LP fee is applied at
. Besides swap fees, a fee is also applied to burning liquidity tokens as well. The burn fee exists to prevent external contracts from using Xfai's liquidity for fee-less swaps (by adding and removing liquidity across pools within the same transaction). During swaps, fees are applied to the input pool (i.e. the primary pool). In the case of liquidity redemption, when the liquidity tokens of a pool
are burned to redeem the underlying liquidity and any accrued fees, the fee is applied to the secondary pool (
).
Liquidity redemption on Xfai requires selecting a primary pool and a secondary pool. By burning one's primary pool liquidity tokens, one can redeem a given amount
and
:
Where
represents the amount of liquidity token that get burned from the selected primary pool.
To minimize therefore one's divergence loss (also known as impermanent loss), it is in one's own interest to add and redeem liquidity from correlated pools, i.e. pools whose exchange values tend to move together. If a user chooses to exit in ETH, no redeeming fee is applied.
To see how to implement liquidity provisioning on a smart contract level, read the Liquidity Provisioning Implementation subsection of the developers documentation.
Last modified 1mo ago