Dedust

Dedust routing connects swap pools through intermediate assets on TON

Dedust routing links pools so a swap can reach its destination through an intermediate asset. In Protocol v2 on TON, each hop names a pool and can set its own minimum output. The next step exchanges the previous step's output, allowing a linked path when a direct pool is absent or lacks liquidity.

A route describes an ordered exchange path. Reading that path requires distinguishing its intermediate quantities from the final output, then checking how pool readiness, trading fees and timing affect the request that will actually execute.

Intermediate assets determine which pools can connect

An onward hop works when the preceding liquidity pool produces the asset that the next pool accepts as input. The shared asset joins the pools in sequence, so an available first pool does not by itself establish an executable route. The onward pool also needs suitable liquidity.

SDK v2 represents the continuation with next , which points to another swap step. A linked request can carry consecutive swaps without a separate manual submission for every exchange. This describes how the selected path executes; choosing which path to submit remains a separate routing decision.

Vaults receive assets while pool addresses define the path

The input vault receives the asset being spent, while each pool address selects the exchange at that step.

The continuation follows the input-specific message

The initial message format changes with the input asset, while next still identifies the onward pool step.

Native TON input

For native TON, sendSwap carries next alongside the first pool address. Its trading amount remains the initial TON input, even when the destination asset lies beyond another pool.

Jetton input

For jettons, createSwapPayload places the first pool address and next inside the forwarded payload. The token transfer goes to the input vault; the onward pool addresses belong in that payload.

Pool lookup also includes the pool type

The Factory calculates the pool address from its type and assets. A calculated address does not establish deployment or usable reserves.

Quotes carry quantities from one hop into the next

Each pool's estimated output supplies the next pool's estimated input, so quoting a route requires consistent asset units across every hop. The pool's estimate_swap_out result supplies the output asset, estimated output amount and trading fee. Reading only the first estimate leaves the route's destination quantity unresolved.

The estimator's amount_out describes the output that the selected pool would deliver. Its trade_fee is denominated in the input asset. Subtracting that fee from the output again would mix different asset quantities. Pool reserves can change before execution, and a quote does not reserve an exchange rate. Minimum-output conditions determine which resulting quantities a request will accept.

Each minimum output protects its own routing step

A swap step's limit applies to the asset that its own pool would output, including intermediate assets on a linked route. Protocol v2 rejects a swap step when its output falls below that step's specified limit. The final step's limit concerns the destination asset; an earlier step's limit concerns a different quantity.

A minimum on the first hop does not replace a minimum on the last hop. Each limit needs the correct asset units. A minimum intended for a later pool belongs inside that pool's continuation step. The SDK permits omitted limits and encodes their value as zero, imposing no positive output floor for that step.

The protocol field stores a token amount, not a percentage. Decimal conversion must preserve the intended minimum quantity of that step's output asset.

A deadline measures arrival at the pool

An optional deadline rejects a swap that reaches a pool after its specified timestamp; setting that value to 0 disables the deadline check. It is an arrival condition, not a quoted completion duration. Because the parameter belongs to the whole swap, it accompanies the linked request. A timely first submission alone cannot prove that later pool arrivals satisfy it.

Can a ready pool still reject a routed swap?

Yes, a deployed pool with positive reserves can still reject a routed swap when a separate trading-start restriction applies to that pool. The SDK's pool readiness check requires an active contract and positive reserves for both assets. It does not incorporate the pool's configured trading-start timestamp.

The start_at value controls that scheduled opening. Attempts before the configured start fail with NOT_STARTED , exit code 306 . A value of 0 means no start time is configured. An output limit or deadline can independently reject an otherwise ready pool's swap.

The entry vault needs its own readiness check before input funds move. A native vault reports readiness when its contract is active. A jetton vault additionally checks its is_ready flag after activation. Funding an inactive contract can cause irretrievable loss. Pool readiness therefore cannot stand in for checking the vault that receives the input asset.

Pool fees and TON funding measure different costs

Each pool can report its trading fee as a numerator divided by a denominator, giving a fraction for that specific pool. Its output estimator also reports a fee amount denominated in the input asset. Successive pools may charge fees in different assets because each hop spends the preceding hop's output.

Raw fee amounts in different tokens cannot be added into a meaningful total without a common valuation basis. Comparing a direct route with a linked route therefore requires the same starting amount and destination asset, plus consistent treatment of execution funding. More hops alone establish neither a better quote nor a worse one.

A jetton-led route still needs TON to fund message execution. The SDK separates a native swap's trading amount from its gas allowance and a jetton transfer's token amount from its attached TON. Adjusting the execution budget does not change those token quantities.

A later rejection concerns the asset at that hop

The asset entering a rejected step is the asset whose return needs to be identified. On a later hop, that input is the preceding pool's output asset. Return transfers establish which asset moved and where it went. A rejection message alone cannot establish that the wallet recovered its original input. A pool-level success event describes that pool's exchange, not necessarily delivery of the route's final asset. Keep the successful hops, any subsequent rejection and the eventual token transfers distinct when interpreting a partially executed message chain.

Path selection needs more than a hop count

A route's hop count describes its shape, while its quoted destination amount and costs determine the meaningful comparison with another path. Direct and linked alternatives need equivalent input amounts and output assets. A linked route can remain relevant when the direct pair lacks liquidity, yet an available intermediate asset alone does not establish a competitive quote. The SDK's continuation structure describes the chosen path. It does not reveal which other paths a particular interface considered, whether a different route would quote better or how the interface ranked candidates.

Swap events show which assets each pool exchanged

Pool swap events identify the input and output assets, along with exchange amounts and post-swap reserves. These records help distinguish intermediate execution from the final transfer. A matching wallet payout establishes receipt separately from a pool's output calculation.

Open full-size image

The event's sender_addr identifies the contract that initiated that pool's swap. It need not be the wallet chosen to receive the final output. In a DUST-to-BOLT route through TON, the intermediate asset is TON and the destination asset is BOLT.

Quick answers about Dedust routing