âšī¸Usage guide
This section is meant to give brief explanations pertaining to how several processes can be successfully performed on the dApp from liquidity provision to trading, as well as PSP22 metadata specs.
PSP22 metadata specification
The protocol utilizes P2P22 tokens for its functions ranging from the liquidity pool tokens to the tradeable tokens including locks/burns.
Because of the limitations to the Balance variable (or u128) and its MAX value capped at 2 ^ 128 - 1 (u128::MAX), there may be concerns that would lead to overflows or values exceeding the limits for the values input for swaps, liquidity provision, etc, hence it is advisable to create and utilize PSP22 tokens with decimals ranging from 6 to 12 as specified with the psp22Metadata::tokenDecimals() method on the protocol. Values higher than this can lead to unintended results because of exceedance of the MAX expected u128 (Balance) value.
In as much as smaller decimals would help, it is also recommended not to use decimal values lower than 6 as it would lead to losses as a result of low precision; numerics cannot be represented with precision (decimal places) than the specified decimals.
Creating pairs
Pairs can be created by selecting the tokens that are intended to make up the liquidity pool.
There are two forms of liquidity pools, which are:
AZERO/PSP22 pairs AZERO/PSP22 pools are trading pairs associated with AZERO and any PSP22 token supplied at any given ratio, say USDT/AZERO.
PSP22/PSP22 pairs PSP22/PSP22 pools are trading pairs associated with two PSP22 tokens only, say APE/USDT for instance.
Once a liquidity pair is created, it is left empty (valueless) until tokens are supplied to them.
Adding liquidity
Once a liquidity pair is created, the next thing that is done is to supply tokens to define the initial price of the pool. The price of the pool is determined by the ratio of the amounts deposited. An example can be deduced from a situation where 100 USDT is provided against 500 AZERO. The AZERO price of the pool would be 100/500 to give 500 AZERO, or 500/100 to give 0.2 USDT. In essence, the price of any pair is given by the ratio of the volume of tokens in the pair.
To supply liquidity, two to three transactions are signed depending on the sort of pool in question.
For an AZERO/PSP22 pool, two transactions are signed, which are; approval for the pool contract to spend the corresponding PSP22 token amount to be deposited to allow for transfer into the pool and the actual liquidity provision submission, which would make a payable contract call to the pool to initiate a successful deposit.
For a PSP22/PSP22 pool, two transactions are signed, which are; approval for the pool contract to spend the two PSP22 tokens' amount to be deposited to allow for transfer into the pool and the actual liquidity provision submission, which would make a contract call to the pool to initiate a successful deposit.
Any time tokens are provided into any pool, an equivalent amount of liquidity pool tokens are minted and issued to the provider to represent their share of the pool so they can in turn deposit them to take out the tokens plus any accrued profit deducted from traders (swappers). Note that it is not assured that liquidity providers will be in profit anytime they withdraw LP tokens from the pool; they may be subject to impermanent loss at a point (in certain circumstances). You can find out more about the subject with this link.
Removing liquidity
As earlier stated, any time tokens are provided into any pool, an equivalent amount of liquidity pool tokens are minted and issued to the provider to represent their share of the pool.
When their share of the liquidity is removed, the liquidity tokens in their possession in the ratio they deposit are retrieved and burnt by the pool contract. Liquidity tokens in AndromedaSwap are tradeable like every other PSP22 token and can be used to transfer liquidity pool share ownership at any point in time.
Swapping
Tokens can be swapped against pairs created on the protocol at their market rates (prices). Typically, two transactions are performed for a complete swap to take place, depending on which sort of pool and which asset is being deposited against the other to be received.
If it is an AZERO/PSP22 pool in question, and a swap is to be performed from the PSP22 token to AZERO, two transactions will be signed:
approval for the pool contract to spend the provided amount of PSP22 tokens intended to be deposited.
actual contract call to perform the deduction and issue the appropriate amount of AZERO to them based on the deposited PSP22 token volume.
However, if this is the case but AZERO is to be deposited, only one transaction is signed, which is a payable call to the pool contract to initiate the swap with the amount of AZERO provided to be paid in exchange for the evaluated amount of PSP22 tokens in the pool based on the price.
Likewise, if it is a PSP22/PSP22 token pair, either of the swaps to be done (from token A to token B and vice versa) would ideally lead to two transactions being signed and submitted, which are:
approval for the pool contract to spend the provided amount of PSP22 tokens intended to be deposited against the other.
actual swap contract call to the pair contract to get the other PSP22 token based on the market rates.
As a swap performs, the price of the pool gets updated (because the ratio of the number of tokens in the pool gets updated as well).
Slippage (tolerance)
For every swap performed on the protocol, users can specify the slippage tolerance in percentage. The slippage implies the acceptable change in price in percentage from when the user initiates the swap on the GUI and the actual price when the transaction is confirmed on the Blockchain.
So, imagine on the GUI that the amount of USDT to be received when one deposits AZERO in a pool of AZERO/USDT is 500 and they send the transaction for the swap with a slippage of 10%. Should the price of the pool update, leaving the amount of USDT to be sent out to them be 450, it means the percentage difference between the output in GUI and the output upon confirmation on the Blockchain is 10.526%. The transaction will fail because the percentage difference is 10.526%, while the expected percentage difference (slippage) is 10% (more or less than the expected slippage).
Locking tokens
Users will be able to lock tokens on the protocol, as well as manage and share proofs of locks by dynamic URLs associated with them.
For a lock to be conducted, the user is liable to specify the amount and date of unlocking as well as sign two transactions thus:
approval for the lock/burn contract to withdraw the number of tokens intended for the deposit from the users' wallets for the lock.
the actual lock/burn smart contract call to initiate the lock on-chain.
The process is temporary as tokens can be retrieved from the pool at a date in the future.
Locks can be shared with URLs to display proofs to users via a GUI that enlists details pertaining to the given account/token locked.
Burning tokens
Users will be able to burn tokens on the protocol, as well as manage and share proofs of burns by dynamic URLs associated with them.
For a burn to be conducted, the user is liable to specify the amount to be burnt as well as sign two transactions thus:
approval for the lock/burn contract to withdraw the number of tokens intended for the deposit from the users' wallets for the lock.
the actual lock/burn smart contract call to initiate the burn on-chain.
The process is permanent as tokens cannot be retrieved from the pool after they are burnt.
Burns can be shared with URLs to display proofs to users via a GUI that enlists details pertaining to the given account/token burnt.
Last updated