Dedust SDK v2 uses different messages for native TON and jetton swaps

Factory lookups locate the pool and its input vault

Factory lookups resolve the contract objects that a swap integration needs for its selected asset pair. Describe native TON with Asset.native() and a jetton with Asset.jetton(rootAddress) . The getPool lookup takes the pool type and asset pair. Resolve the native vault with getNativeVault or the selected jetton's vault with getJettonVault . These objects have different roles in the eventual request: the input vault receives the asset and the pool address identifies the exchange calculation.

The asset descriptor and jetton vault lookup must refer to the same token root. Keep that identity associated with the request throughout construction, including when resolving the owner's token wallet.

Which contracts must be ready before a swap?

The selected pool and input vault must report ReadinessStatus.READY before the integration sends a funded swap request. Resolving their addresses does not establish readiness, and sending funds to an inactive contract can cause irretrievable loss. Use the readiness getter on each relevant object. Set suitable execution funding and a minimum output for the intended trade; readiness alone does not establish an acceptable exchange price.

Open full-size image

Native TON requests separate the trade amount from execution funds

The native vault's sendSwap method receives the TON trading amount directly, alongside the target pool and an execution allowance.

Keep the traded TON separate

The amount field specifies the TON quantity offered for exchange. The gasAmount field supplies an additional execution allowance. The SDK constructs a message value from their sum, so the payment attached to that message exceeds the trading quantity when the allowance is positive. That sum describes the attached message value; it does not establish the complete wallet debit.

Changing gasAmount changes the attached value without changing amount . Putting the combined payment into the trading field would encode a different input quantity.

Retain the pool and output condition

The poolAddress argument identifies the pool that should process the exchange. The native vault remains the destination of the funded call. Include the minimum acceptable output in limit before submitting the request. That condition concerns the asset received, while amount concerns TON sent for exchange.

Jetton requests carry the swap inside a token transfer

A jetton input uses its owner's token-wallet contract to transfer the asset, with the swap instruction embedded in that transfer. The native vault's calling pattern does not replace this token-wallet operation.

Resolve the token-specific sending wallet

Create a JettonRoot object from the selected token's root address, then resolve its wallet with getWallet(sender.address) . This gives the contract that holds that owner's balance of the selected jetton. The owner account, jetton root and resolved token wallet identify different objects. Retain those distinctions when selecting which opened contract receives sendTransfer .

Separate the destination from the swap payload

The transfer's destination is the input jetton's vault address. Build its forwardPayload with VaultJetton.createSwapPayload , supplying the intended pool address and output limit. The pool address belongs inside that instruction; it does not replace the vault destination in the enclosing token transfer.

Creating the payload produces a serialized cell. The transfer moves jettons into the vault's jetton wallet. That wallet sends the cell to the vault in a transfer notification only when a positive TON amount is forwarded.

Fund the forwarded instruction

The transfer's amount specifies the jetton quantity. The attached TON value must cover transfer costs and the forwardAmount sent with the vault notification to fund the swap. Preserve those asset units when building the call: copying the token quantity into a TON funding field changes the meaning of the request.

How does a direct swap enforce its minimum output?

A direct Protocol v2 swap is rejected if its output falls below the specified limit. The SDK accepts limit in both the native swap arguments and the jetton payload builder. Keep the limit in the output asset's units, separate from the input quantity and TON execution budget.

The pool's getEstimatedSwapOut getter accepts assetIn and amountIn , then returns assetOut , amountOut and tradeFee . Those fields identify the estimate's direction and output quantity. The estimate does not fix the later execution price. Encode the acceptable floor in the funded request itself, so acceptance depends on that condition when the pool processes the swap.

Pool fees and execution budgets describe different costs

The pool's getTradeFee getter reads a numerator and denominator, returning their ratio. Read the selected pool's value instead of treating one fee percentage as a constant across integrations.

Funding figures in SDK snippets are call inputs. They do not establish a universal execution cost, and a forwarded TON allowance does not describe the pool's trading fee.

The token transfer also has a responseAddress for returned excess TON. Keep that address distinct from the vault destination and the swap's output recipient. Returned execution funds and purchased tokens have different meanings even when an integration directs them to the same owner.

Can native TON and jetton swaps share integration code?

Native TON and jetton swaps can share asset selection, pool resolution and minimum-output handling, while their funded message builders remain distinct. Keep the asset associated with every amount. A native trade quantity, a jetton quantity and a TON execution allowance cannot become interchangeable because an API uses the same field name.

Readiness implementations also differ. The native vault checks whether its contract is active. The jetton vault additionally reads its readiness flag, while the pool requires an active contract and positive reserves for both assets. Calling each object's getReadinessStatus preserves those checks when shared code handles multiple input types.

Multi-hop routing can extend a swap instruction through next . Liquidity provision uses separate deposit methods and payloads. Keep those operations outside the direct-swap message builder, then choose the native-vault or jetton-wallet path from the asset that the integration will send.