A liquidity pool is a primitive for many decentralized cryptocurrency trading platforms including Uniswap, Sushiswap, Balancer, Mooniswap (from 1inch), MCDEX, Thorchain, Perpetual Protocol, Curve, Bancor and more. Centralized exchanges have even created a liquidity pool swap program because the returns are so lucrative.
Sifchain's liquidity pools are based on Sushiswap with extensibility in mind for potential updates. Rowan will be the settlement token for each pool, meaning each pool will contain Rowan as one asset and an external asset as the other. Sifchain’s swap UI will support swaps between external assets (for example, cMKR:cCOMP) but such transactions will actually require two swaps between two different liquidity pools (for example, cMKR:ROWAN and then ROWAN:cCOMP).
Liquidity providers need to be able to add liquidity into Sifchain’s liquidity pools where they can earn income. Liquidity providers should be able to deposit any token Sifchian supports to the appropriate pool. They should be able to add asymmetrically, meaning they can add only Rowan or only TKN for any token. This is as opposed to Uniswap where users must add equal values of the settlement token (ETH) and the other token (TKN). Liquidity providers should be able to add or remove liquidity whenever they choose.
Sifchain allows swappers to send a transaction to a liquidity pool with the amount of tokens they want to give up in exchange for tokens on the other side of the pool. Sifchain uses both an order book and a CLP for trade completion.
In many decentralized exchanges, users can add liquidity to liquidity pools and earn a portion of the transaction fees charged to other users who want to swap tokens in the pool. The constraint that most liquidity pools 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 2.64 ETH for every 1,000 DAI that is added at the time of this writing. And then based on the amount the user puts into the pool, they then receive a proportionate amount of the fees charged.
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. Sifchain will initially use the same formula to calculate ownership as BEPSwap.
**When a user only puts in one side of the pool, how is their ownership percentage 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. Learn more about asymmetric liquidity pools here
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, especially in a regime where we deploy temporary liquidity mining rewards. So far, our rebalancing policy is a vectorized extension of Thorchain’s Incentive Pendulum but this is under active research.
Inspired by Thorchain’s incentive pendulum, Sifchain combines liquidity provider rewards and validator block rewards into system income.
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.
Validators stake tokens to earn ROWAN.
Variables
- inflation rate
- percentage of tokens staked
- delegation rates
Revenue sources
- minting policy
- slashing rate
Participants provide liquidity to sifchain's CLP and earn rewards in ROWAN tokens.
Variables
- Rowan (settlement) token price
- swap volumes
- number of unique liquidity providers
Revenue sources
- Liquidity fee policy
- Swapping activity
The 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 node operators and liquidity
- Slip based fee model inspired by Thorchain
- Rowan as settlement token for all pools
- Asymmetric deposits and withdraws
https://github.com/Sifchain/sifnode/blob/develop/docs/4.Liquidity%20Pools%20Architecture.md