Deposit
Explanation of the Deposit Transaction
Last updated
Explanation of the Deposit Transaction
Last updated
In Duality’s concentrated liquidity model, liquidity providers (LPs) can provide liquidity to a specific trading pair by depositing tokens at a specific price into one or both sides of the pair in “a liquidity pool”. When depositing into the pool LPs must choose a fee for their deposit. This fee will be paid every time a trader swaps through a liquidity pool. When a trader wants to buy or sell one of the tokens in the pair, they must first pay the pool fee, which is a percentage of the trade value, to the liquidity pool. This fee is then shared among the LPs in proportion to their share of the liquidity in the pool. By providing liquidity, LPs earn a portion of the transaction fees and may also earn incentives for depositing in certain liquidity pools. In a concentrated liquidity DEX, LPs can set their own price range for each token in the pair. This means that they can set a higher price for selling their token and a lower price for buying the other token, or vice versa. This allows LPs to earn more fees by capturing the spread between the buying and selling prices. However, providing liquidity in a concentrated liquidity DEX can also carry risks, such as impermanent loss, where the value of the tokens in the pool may diverge from their initial ratio due to price fluctuations. LPs may also be exposed to potential losses if the DEX is hacked or suffers from smart contract vulnerabilities. It is important for LPs to carefully consider these risks before providing liquidity.
When depositing into an LP position (PoolReserves
) a user specifies amounts of Token0 and Token1 as well as a TickIndex and a fee. The liquidity is added to the reserves for the respective ticks. Token0 will be deposited into the PoolReserves
struct with the matching fee at TickIndex - fee
and Token1 will be deposited into the PoolReserves
at TickIndex + fee
.
In the most basic case, when depositing into a pool, the ratio of Token0 to Token1 will be preserved. If a user does not provide tokens in the same ratio, then only a portion of their total deposit will be used so as to maintain the pool ratio.
NOTE: Most pools will only have Token1 OR Token0, so most deposits will only be providing one tokens to one side of the pool.
In return for depositing tokens into a pool the user is issued PoolShares corresponding to the specific liquidity pool in which they have deposited. These can be used in the future to withdraw the user’s pro-rata share of the PoolLiquidity in the future. The PoolShares are also fungible denoms that can be bought, sold, and traded.
The amount of pool shares issued is calculated using the following formula:
By default the autoswap
option is enabled, which allows use to deposit their full deposit amount. Autoswap provides a mechanism for users to deposit the entirety of their specified deposit amounts by paying a small fee. The fee for performing an autoswap is deducted from the total number of shares the the user is issued. When calculating share issuance the same formula as above is used for the balanced portion of the deposit, with the following formula use to calculate the shares issues that would unbalance the pool:
Feild | Description |
---|---|
Field | Description |
---|---|
Creator
string (sdk.AccAddress)
The account from which deposit Tokens will be debited
Receiver
string (sdk.AccAddress)
The account to which PoolShares will be issued
TokenA
string
Denom for one side of the deposit
TokenB
string
Denom for the opposing side of the deposit
AmountsA
[]sdk.Int
Amounts of tokenA to deposit
AmountsB
[]sdk.Int
Amounts of tokenB to deposit
TickIndexesAToB
[]int64
Tick indexes to deposit at defined in terms of TokenA to TokenB (ie. TokenA is on the left)
Fees
[]uint64
Fees to use for each deposit
Options
[]DepositOptions
Additional deposit options
Autoswap
bool
Toggle to use autoswap (default true)