Sifchain Liquidity Pools
How it works on SifDEX
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 and remove liquidity whenever they chose. 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)]
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
Swap fees are currently fixed at 0.05%. This fee is paid to Liquidity Providers.
More details and technical breakdown of swap fees can be found here - https://github.com/Sifchain/sifnode/blob/master/docs/proposals/fixed_rate_swap_fees.md
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 used Thorchain’s slip based fee formula. Now, after proposal 108 passed, Sifchain uses a fixed rate swap fee that is controlled by governance token holders in the DAO.
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.
Since the introduction of PMTP and depending on the policy chosen by the SifDAO, pools parameters may have different weights. For further details, please look into the PMTP Technical Specification
Liquidity Pools Architecture‌
For additional information on our Liquidity Pool Architecture, you can refer to the documentation here. and the litepaper
Last updated
