Dust thresholds and swap minimums solve different problems

A deposit can clear a chain’s dust threshold and still be too small to swap economically. The distinction matters because the first limit is about whether a transaction or inbound amount can be recognised and processed; the second is about whether the resulting trade can cover its costs. Treating them as one cutoff can leave users with deposits that reach a route but cannot complete the intended swap.

For a cross-chain route, there are several separate steps: sending the asset, having the source chain and route recognise the deposit, executing the swap, and paying to send the output or a refund. THORChain’s developer documentation describes both a dust-threshold error, where an inbound amount is too small to be observed, and a minimum-swap error, where the amount cannot cover fees. The distinction is useful beyond one protocol: “processable” and “worth processing” are different tests.

A route-check guide on thor swap covers the destination-chain choice in more detail; the same route-first thinking applies to amount limits. A quote should be checked for the selected source and destination, since the route determines which network costs and output conditions matter.

What does a dust threshold mean for a crypto deposit?

A dust threshold marks an amount that a chain or route will not accept or observe as a usable inbound transaction. Its purpose depends on the chain’s transaction model and the route’s own processing rules. On Bitcoin, for example, Bitcoin Core defines dust in relay policy by comparing an output’s value with the estimated cost to spend it; the threshold depends on the output type and fee policy. That is a network-policy concept, not a universal dollar value shared by every coin.

For an integrator, the practical question is whether the intended deposit can be detected and attributed by the route. The THORChain Swap Guide documents an error for amounts below the inbound chain’s dust threshold and says those transactions will not be observed. If an interface accepts an amount below that boundary and generates deposit instructions anyway, the user may pay the source-chain transaction fee without creating a deposit the route can process.

Dust is not the same as “small balance” in a wallet. A balance can be visible and transferable in one context but unusable for a particular route because the route uses a stricter threshold, a different asset representation, or a chain-specific minimum. The relevant amount is therefore the amount being sent to the route, in the asset’s native units, not a general portfolio value.

How is a swap minimum different from dust?

A swap minimum asks whether the deposit can cover the costs of carrying out the requested trade. Those costs can include the source-chain transaction, the pool’s liquidity or slip fee, any optional affiliate fee, and the destination-chain outbound fee. THORChain’s fee documentation separates these charges, while its developer guide explains that the recommended minimum is based on the fees relevant to the requested route.

Unlike dust, this minimum can change with the route and current network conditions. A destination chain with more expensive outbound transactions can make a small swap uneconomic even when the source deposit is clearly above its dust threshold. Pool depth and trade size also affect the output through liquidity costs. In THORChain’s quote flow, the recommended_min_amount_in is a route-specific estimate intended to help avoid amounts that are insufficient to pay fees; the guide advises a buffer because fees can move.

That is why a single static “minimum deposit” can mislead. It may be a conservative product rule, but it is not necessarily the dust threshold, nor does it guarantee a positive or acceptable output. The swap quote is the better test for economic feasibility, while the dust check is a prerequisite for technical processability.

How should a deposit flow check both limits?

Check the chain threshold first, then compare the amount with a fresh quote for the exact route. The first check prevents an unobservable deposit; the second determines whether fees and expected output make the swap viable. A useful flow keeps these results distinct in both its logic and its explanation to the user.

• Validate the inbound amount. Use the source chain’s and route’s current dust or minimum-observation rule, with correct decimal conversion and rounding.
• Request a route-specific quote. Include the chosen destination, asset and relevant output constraints; use the quote’s fee breakdown and recommended minimum where available.
• Refresh before sending. A displayed quote can expire or become stale as gas prices, pool conditions and route availability change.
• Explain the failure point. Say whether the amount is too small to be observed or too small to cover the trade’s costs, and avoid presenting either condition as a universal token minimum.

The trade-off is between rejecting too much and accepting amounts that cannot finish. A high fixed minimum is simple and can provide a buffer, but it excludes deposits that might work on cheaper routes. A low fixed minimum admits more users, but risks deposits reaching a route that later refunds or fails. A live quote paired with a separate inbound threshold gives a more precise answer, at the cost of requiring route data to be refreshed and interpreted correctly.

What should users and operators watch next?

Users should compare the amount they plan to send with both the inbound threshold and the current route quote, rather than assuming that a successful wallet transfer means the swap is viable. Operators should watch changes to chain dust policy, route availability, outbound fees and quote recommendations, then make sure interface limits track those changes. THORChain’s documentation notes that fee parameters can be adjusted, and its quote endpoint is designed to return current route details.

The practical rule is simple: dust answers whether the deposit can enter the process; the swap minimum answers whether the route can afford to complete it. Keep both checks visible, refresh the quote at the point of action, and the user is less likely to confuse a technically accepted deposit with an economically workable swap.