Sifchain Liquidity Pools

Introduction
Liquidity pools enable you to buy or sell an asset for another asset on a crypto-currency exchange. This page highlights how Sifchain uses this concept.
On Sifchain, the Rowan Token is used as the trading pair for all Pools (e.g. Atom / Rowan, ETH / Rowan, etc). Traders can still swap ETH for Atom seamlessly, but behind the scenes the trade will be routed between the ETH / Rowan and Atom / Rowan pools.
Liquidity providers are able to add liquidity into Sifchain’s liquidity pools, where they can earn income from Trading Fees and incentivized rewards.
Liquidity providers on Sifchain can add liquidity whenever they chose. Removing liquidity is subject to a 7 day unbonding period -  see the Pool page for details.
If you are considering providing liquidity to Sifchain, please ensure you are familiar with the concept of Impermanent Loss. Bear in mind that the rewards from providing liquidity may help to offset this.
Liquidity Provider Fees
Liquidity providers will only need to pay gas fees when adding liquidity to a pool (usually a fraction of a ROWAN).
It is important to note, that there is a potential loss of value for a liquidity provider depending on how much slippage is created in the pool's price when depositing an asset. As a general rule, the deeper the pool is (greater total value of pool), the less slippage there will be.
This slippage calculation is:
If (native_asset_balance x external_asset_amount) > (native_asset_amount x external_asset_balance) then:
slip_adjustment = (native_asset_balance x external_asset_amount) - (native_asset_amount x external_asset_balance) / [(native_asset_amount + native_asset_balance) x (external_asset_amount + external_asset_balance)]
otherwise:
slip_adjustment = (native_asset_amount x external_asset_balance) - (native_asset_balance x external_asset_amount) / [(native_asset_amount + native_asset_balance) x (external_asset_amount + external_asset_balance)]
Resources: https://github.com/Sifchain/sifnode/blob/cff2ed4cfdd55f84d296b5e46d7b63dfa55768e3/x/clp/keeper/calculations.go#L283-L289​
Asymmetric Liquidity Pool‌
The constraint that most decentralized exchanges put on liquidity providers is that they must put in an equal value of each token pair. For example, in the ETH/DAI liquidity pool in Uniswap, a user is required to add 0.33 ETH for every 1,000 DAI that is added (at the time of writing). They then receive a proportionate amount of the fees charged by the pool when users trade with it.
With Sifchain, users who want to add liquidity to a pool can add any amount of either or both tokens. This is known as adding liquidity asymmetrically, which gives users ultimate flexibility. Based on the amount of tokens in the pool and the amount that the user adds, they will then own a percentage of the entire pool.
Important Notes on adding liquidity asymmetrically vs. symmetrically:
To avoid loss, LPs should deposit asymmetrically ONLY if the pool is already imbalanced.
Asymmetrical deposits are when a user deposits an unequal value of the two assets to a pool. So for example, let's say a user deposits $1000 of ETH and $0 of ROWAN to the already-balanced ETH/ROWAN pool. The user is given a % ownership of the pool that takes into account the slip created in the price. Because of this, the liquidity provider will end up with less than $500 in ETH and less than $500 in ROWAN. The deeper the pool, the closer to a total of $1000 the LP will own.
This means that LPs can get into a situation where they have 'less' than what they added. The ways that LPs can end up with "less" tokens are either through:
1.Pooling asymmetrically when the conditions to do so are not favorable
2.From Rowan price shifts
If an LP adds symmetrically their ownership is really just going to fluctuate with the price of Rowan and the balance of the pool they're in. These fluctuations should be proportional on each side. For example, if their cUSDT balance is going down, their Rowan balance should be going up and vice versa.
In order to help user's with the above asymmetrical vs. symmetrical adding of liquidity, we have implemented the following:
'Pool Equally' slider: If this is turned on (it is on by default), then we will automatically calculate the non-filled in 'Input' field for you as to where the slipAdjustment = 0% (i.e the amounts added will be done some in a symmetrical way).
A user may choose to turn this 'Pool Equally' slider off. In this case, the user is free to input ANY amount in either field and we will not do any automatic calculations.
How does the system ensure that there’s enough liquidity in a pool, if users only have to add one token in the pool and not both?
The interesting thing about the formula that Sifchain uses to calculate ownership, is that it creates an economic incentive for users to balance the pool. If the pool gets too oversubscribed on one side, the formula gives users an incentive to add liquidity to the other side by giving them a higher ownership % to add to the side that needs more units to balance the pool.
When a user only puts in one side of the pool, how is their ownership % calculated?
The formula that is used to calculate ownership % is designed to incentivize users to keep the liquidity pool balanced. As one side of the pool increases, users can gain a higher % of the overall pool by adding tokens to the other side.
Below is the formula used to calculate the units owned by a user when they add Rowan or another asset to the liquidity pool.
r = rowan deposited
a = asset deposited
R = Rowan Balance (before)
A = Asset Balance (before)
P = Existing Pool Units
The liquidity provider is allocated a portion of the fees collected from swappers proportional to their ownership of the pool. For example, If the liquidity provider owns 2% of the pool, they are allocated 2% of the fees collected.
How does the system ensure that pools are balanced?
The interesting thing about the formula above is that it creates an economic incentive for users to balance the pool. If the pool gets too oversubscribed on one side, the formula gives users an incentive to add liquidity to the other side by giving them a higher ownership % to add to the side that needs more units to balance the pool.
Here’s an example:
In this liquidity pool, Rowan is oversubscribed at 10,000 compared to Token A at only 1,000. In scenario 1, Bob adds 1,000 Rowan to the pool, which gives him ownership of 4%. In scenario 2, Bob adds 1,000 to the undersubscribed side (Token A) of the pool, which gives him ownership of 20%. By rewarding users with a higher ownership % to add liquidity to the undersubscribed side of the pool, the system creates an incentive to balance the pool.
We see in these examples that there is some slippage when adding liquidity. To avoid high slippage, users must be conscious of adding liquidity in chunks small enough relative to the total pool depth. If you are adding a large amount of liquidity to a relatively shallow pool, it would be best to do this in chunks, and to balance the pool by adding to one side then the other until you have reached the desired amount of pool share.
Liquidity Provider Income Determination
The amount of income that liquidity providers can earn is dependent on the below-identified factors.
1.) Amount of Liquidity Provided
Pool Ownership calculation
Below is the formula used to calculate the units owned by a user when they add Rowan or another asset to the liquidity pool. The Liquidity Provider is then able to withdraw that amount of ownership at any time.
r = ROWAN deposited
a = Asset deposited
R = ROWAN Balance (before)
A = Asset Balance (before)
P = Existing Pool Units
As can be seen, as long as either r or t is non-zero, then the stake units can be calculated. The staker now owns an equal share of both sides of the pool.
2.) Time
This is the length of time a liquidity provider keeps their liquidity in a pool. We reward liquidity providers that keep their liquidity in the pool for longer durations of time.
3.) Fee Revenue
Swap Fees
Liquidity Providers also get a share of the swap fees accrued for their contributions to the pool. Pools with higher daily volume generate more swap fees. Sifchain uses Thorchain's slip-based Continuous Liquidity Pool model to calculate trade slip, liquidity fee, and resulting swap.
The liquidity provider is allocated a portion of the fees collected from swappers proportional to their ownership of the pool. For example, If the liquidity provider owns 2% of the pool, they are allocated 2% of the fees collected.
Potential Price Slippage
Swappers who are in a hurry to exchange assets will tend to make larger swaps. Larger swaps lead to greater price slips and therefore higher fees. Always make sure to check the price impact your trade is causing, and notice the amount of fees that you would pay to LPs. Especially when trading considerable amounts on low-depth pools, always double check the Price Impact and Fees paid to LPs in order to avoid surprises.
Generalized Model of Liquidity Allocation
Sifchain’s Automated Marker Maker(AMM) Specification is based on a derivation of liquidity pool architecture from first principles. It is important to us that we don’t enforce any formula on users. At launch, Sifchain will use Thorchain’s slip based fee formula. In the future, we’re going to update this to allow governance to control the liquidity pool formula by voting with their Rowan on a per liquidity pool basis.

We are currently extending this model to derive the optimum balance between rewards to validators and rewards to liquidity providers.
Rebalancing mechanism for system rewards distribution
Inspired by Thorchain’s incentive pendulum, Sifchain combines liquidity provider rewards and validator block rewards into system income. This incentive pendulum keeps the network in a balanced state. It stops the network from becoming unsafe or inefficient by changing the distribution of rewards to both node operators and liquidity.
In comparison, Thorchain’s incentive pendulum uses a scalar to define the ratio of total system income given to each subsystem. This means it is limited to two subsystems (validator subsystem and liquidity provider subsystem). On the other hand, Sifchain uses a vector in which each element is a weight on its subsystem’s income. This means it is extensible to more than two subsystems (for example, Sifchain validator subsystem, Sifchain liquidity provider subsystem, peg zone validator subsystem, an external chain’s liquidity provider subsystem, etc.). Near-term this will be immaterial, but as IBC develops and Sifchain becomes more composable, it will be useful for allowing Sifchain to dynamically change rewards in its two subsystems in response to on-chain activity from other blockchains.
​
​
Liquidity Pools Architecture‌
For additional information on our Liquidity Pool Architecture, please refer to our documentation here.