The AMM maintains a list of pools. Each pool contains two assets that can be traded against each other.
Pools can be listed via the
Poolsstorage item of the AMM pallet. It consists of a triple map of both pool assets and some states about the pool.
We would like to be able to control who can create a new pool at the runtime level. Indeed, for the StakingSwap instance of the AMM pallet, we would like to make sure no users can abuse its underlying system by creating a custom pool. The simple way to do this would normally to introduce an
Origincheck, however, it is not necessarily possible given that we need to know where to create LP tokens, which means we have to use an
ensure_signedstatement, however, origins are not always signed, especially if they come from a governance pallet. Instead, we propose to add two things to the AMM pallet:
- 1.A configuration flag to enable or disable the creation of new pools by "normal" users.
- 2.A new extrinsic to "force" the creation of a new pool, protected by an
Adding liquidity is done via the
add_liquidityextrinsic. It takes in argument:
- the pool to add liquidity to
- two amounts of tokens to add → when adding tokens to an existing pool it is important to respect the proportions of tokens already in the pool. For instance, if the current ratio is 100 DOT and 10 KSM you will have to deposit 10 DOT and 1 KSM. → the amounts of tokens must be ordered similarly to the pool parameters, see examples
- some minimum amounts of the respective liquidity tokens. You can use this for slippage control
Removing liquidity can be done via the remove_liquidity extrinsic. It takes in parameters the pool to remove liquidity from, and the share of liquidity tokens to cash out (assuming the user has at least 100 liquidity tokens)
Whenever a user trade some currency on an AMM pool, some fees need to be taken out in order to compensate, and incentivize, the Liquidity Providers.
The protocol would collect some fees to fuel its treasury.