Dedust
Dedust liquidity pools mint LP tokens after accepting both asset deposits
Last updated ·Dedust liquidity pools require both asset targets and any specified minimum LP output to be met before the pool issues liquidity provider (LP) tokens. Protocol v2 on TON tracks incomplete contributions through a temporary deposit contract, so sending one asset can leave funds pending without creating an LP position.
Separate asset arrivals delay LP minting
Protocol v2 coordinates separate asset arrivals through a temporary Liquidity Deposit contract, which records funding until both asset targets are reached. Each target corresponds to one of the pool's assets. Depositing into the corresponding vault records funding for that side. Once both balances reach their targets, the protocol can submit the contribution to the pool. Acceptance then determines whether the contribution produces LP tokens; a confirmed transfer of one asset therefore cannot, by itself, establish a completed liquidity position, even when that transfer has reached the correct vault and the deposit contract records the asset balance.
The contract terminates after the pool accepts the liquidity or the pending deposit is withdrawn.
What does the minimum LP output protect?
An LP minimum sets the lowest token quantity that a contribution may receive, adding an acceptance condition alongside the targets for deposited assets.
Both targets concern inputs. The minimum concerns the LP output. Raising an asset target changes the funding requirement; raising the LP minimum changes whether a proposed issuance is acceptable.
Protocol v2 refunds the deposited funds if the LP output falls below the specified
min_lp_amount
.
Equality therefore meets this minimum condition. It does not remove the requirement to fund both assets or make a submitted request equivalent to an accepted deposit.
This threshold protects the quantity of LP tokens at entry. It does not lock their future value or specify a withdrawal amount.
An LP estimate describes the proposed contribution
An integration can obtain a deposit estimate from the selected pool before setting its minimum, using
getEstimateDepositOut
with the two proposed asset amounts. The response contains a
deposits
pair and
fairSupply
, the estimated LP issuance. The asset amounts and the LP quantity belong to different tokens. Keep their units distinct when comparing the estimate with an LP minimum; a number representing a contributed asset is not an interchangeable LP balance. The estimate does not mint tokens.
A TON/DUST contribution may return surplus DUST alongside its LP tokens after acceptance. That surplus remains DUST; it is separate from the newly minted LP balance.
Matching deposit terms keep both asset transfers aligned
Both funding messages must describe the same intended contribution, even though native TON and jettons use different ways to reach their vaults.
The SDK v2 liquidity flow requires identical
assets
and
targetBalances
values across both deposits.
Preserve the asset order as well as the amounts that correspond to it. A pool type also forms part of the deposit request. Changing the asset pair or pool type changes the requested pool.
Native TON uses the vault's deposit-liquidity call. A jetton uses a transfer from its token wallet with a liquidity-deposit payload. The payload identifies the pool terms that the asset transfer serves.
Pending contributions and issued tokens allow different exits
A missing LP balance can reflect an unfinished deposit, while issued LP tokens indicate that the contribution has passed the pool's acceptance stage.
| Deposit stage | Required state | Contribution and LP status | Sender and contract roles |
|---|---|---|---|
| Prepare the contribution | Set the asset pair, pool type and targets; optionally set an LP minimum | No LP tokens issued | The sender specifies deposit terms |
| Receive the first asset | One asset reaches its corresponding vault | Contribution remains incomplete | The vault receives the asset; the deposit contract tracks funding |
| Reach both targets | Matching deposits fund both target balances | Contribution can reach the pool | The deposit contract coordinates the pending contribution |
| Accept the liquidity | The proposed LP output meets any specified minimum | The pool accepts the contribution | The pool determines LP issuance |
| Issue LP tokens | The pool accepts the funded contribution | LP tokens reach the depositor | The depositor receives LP tokens; the temporary deposit contract terminates |
Consider a contribution where the first asset transfer is confirmed but the other asset has not been sent. The expected final state is an LP balance; the observed state is a pending contribution. Repeating the first transfer does not supply the missing second asset. To stop the contribution, the depositor can cancel the pending deposit and request the deposited funds back.
To cancel the specific pending contribution, the SDK locates its Liquidity Deposit contract using the owner's address, pool type and asset pair, then uses
sendCancelDeposit
to request the return of the funds recorded for that deposit. A submitted cancellation is a request, not confirmation that the return transfer has completed.
An LP burn removes accepted liquidity
Withdrawing accepted liquidity requires burning LP tokens.
The pool's
getWallet
lookup resolves the owner's LP wallet for that particular pool. The burn amount refers to LP tokens, not either original deposit asset. The remaining choice is the amount of that LP balance to remove.
Common questions about Dedust liquidity pools
Which SDK field names set the minimum LP quantity?
SDK package version 0.8.7 uses minimalLPAmount in the native vault's sendDepositLiquidity method and minimalLpAmount in VaultJetton.createDepositLiquidityPayload. The lowercase p distinguishes the jetton payload's property name. Both encode the protocol's min_lp_amount field, so an integration must use the spelling that its selected method accepts.
Can execution funding satisfy the native TON deposit target?
The native deposit method keeps the contribution amount separate from the TON attached for execution. Its amount field specifies the TON contribution, while the method adds an execution allowance to the attached value. Sending that combined value does not redefine the asset quantity encoded in amount.
Does a READY pool status mean that a contribution has minted LP tokens?
READY describes the pool's state, not the completion of a particular contribution. The SDK pool check requires an active contract with positive reserves for both assets. It does not compare the pending contribution's balances with its targets or establish that its owner has received LP tokens.
How can an integration check the pool's asset order?
The pool's getAssets method returns its ordered pair of assets. Match each amount in a deposit estimate to the asset at the same position. The result describes the pool's assets; it does not report the funding already recorded in a pending deposit.
Is the minimum LP amount a pool fee?
The minimum LP amount is an acceptance threshold, while getTradeFee reads the pool's trading fee. The SDK calculates that fee ratio from the numerator and denominator returned by the pool. The LP minimum does not represent that ratio or the TON attached for transaction execution.
Can a liquidity deposit cancellation include a custom payload?
Protocol v2's cancel_deposit operation accepts an optional payload that can accompany the funds transfer to the user.
What identifies a jetton in a pool contribution?
A jetton's root contract address identifies that asset in the SDK's Asset.jetton value. A displayed ticker does not replace that contract input. The selected root must match the intended pool asset; the owner's jetton wallet is a separate contract that sends the tokens.