Does removing a token from a dust sweep cancel its earlier allowance?

Removing a token from the selected sweep or choosing individual swaps leaves that token’s existing allowance for the execution proxy unchanged. An ERC-20 allowance belongs to the token owner and specified spender, independently of the current selection. Changing that permission requires an allowance update on the token contract. An excluded balance can therefore remain unswapped while its earlier spending permission remains active.

Why might a visible dust token have no executable route?

A visible wallet balance can lack an executable route because liquidity, supported providers or amount limits prevent the proposed conversion. Routing may also reject excessive price impact. A token appearing in a wallet does not establish an available market for the requested amount. Dust Sweeper can omit an unroutable input, allowing the remaining eligible selection to be considered separately.

What does a partial Composer response mean before a dust sweep?

A partial Composer compilation response means that the service produced a transaction while simulation reverted under its allow-revert simulation policy. It contains diagnostics that the application must interpret. This is a preparation result, not evidence that tokens have moved or that a sweep has partly settled. The reported failure needs to be resolved or the affected operation excluded before accepting an executable selection.

Can revoking approval reverse a completed dust sweep?

Revoking an ERC-20 allowance changes future spending permission and does not reverse completed swaps. A confirmed conversion has already exchanged the included tokens for native output. Recovering the original token would require a separate available swap at its own pricing and costs. Approval revocation neither restores the original balances nor refunds gas already spent on the completed execution.

Which details distinguish dust balances that share a ticker?

For ERC-20 inputs, the chain and token contract address distinguish balances that share a ticker. The ERC-20 symbol field is descriptive and optional; it does not establish token identity. Separate contracts can use the same symbol, and balances on different chains belong to different network contexts. Matching the actual input to its route therefore requires more than the displayed ticker.

Does Composer’s sweepTo setting perform the dust swaps by itself?

Composer’s sweepTo setting directs the flow’s terminal resources, meaning tokens remaining in the execution proxy after execution, to a specified address. It does not itself define token conversions. Dust Sweeper’s consolidation relies on swap operations that produce the common native output; the final transfers deliver the resulting resources. Confusing this transfer setting with the complete feature would omit the routing and conversion operations that make the dust usable.

Jumperexchange

Jumperexchange dust sweeper combines selected token swaps into a native asset through Composer

Jumperexchange dust sweeper scans small wallet balances and uses Composer to batch selected swaps into a supported EVM chain’s native currency. Should you batch these conversions or execute swaps individually? Tokens with insufficient allowance require approvals, while unroutable inputs can be excluded before the final sweep.

October 14th, 2026 · updated

Individual swaps and a shared native output

Swapping dust tokens individually gives each input its own execution transaction; Dust Sweeper groups the selected swaps into a shared flow. Both approaches need an executable route for each included balance. Comparing them means keeping the selected chain, input amounts and intended output the same. Otherwise, a difference in received value might reflect different assets or routing conditions rather than batching. The sweeper’s advantage is the combined execution, while individual swaps allow each conversion to be reviewed separately.

The native asset is the chain’s own currency, which also pays transaction gas. Dust Sweeper consolidates selected balances into this asset on the chosen chain. An ordinary supported token swap can target a different destination token. Dust Sweeper’s native output remains on the chain selected for that sweep. Moving assets between networks involves a bridge route with a different settlement process.

Costs before committing the selected balances

Sweep costs reflect the selected balances, their routes and the approvals that those tokens require. A first-use comparison includes approval gas alongside execution gas and any applicable swap fees. Existing allowances can change that comparison on a later visit. Composer also provides an upfront price-impact estimate, describing how the proposed conversions affect received value. Packaging swaps together does not establish a fixed price or make every small balance economical to recover. A wallet paying its own gas needs native currency before submission; the expected sweep output cannot fund that earlier charge.

A marginal balance deserves attention because its contribution to native output may be small relative to its added costs. Including a new token can require another approval as well as another routed swap. Leaving that token out changes both the inputs and the expected recovery. Market conditions can change before submission, so an earlier preview describes its earlier selection and pricing. The relevant comparison is the native value recovered against the costs of the proposed selection, with required approvals included.

First-use approvals and later sweeps

ERC-20 approvals give a specified spender permission to transfer a token up to an allowance. Dust Sweeper uses persistent allowances for its per-user execution proxy. Permission and swap execution remain separate actions, even when the interface presents consolidation as one task.

The per-user execution proxy

The execution proxy is a user-specific contract that runs Composer’s instructions. Each input token has its own allowance for that spender. The token contract records the allowance, allowing later sweeps to reuse permission that remains sufficient.

Spending permission

Inputs without sufficient allowance need approval before execution. A revoked permission requires a new approval if the token returns to a later sweep.

The execution transaction

The prepared sweep combines the included swap operations into one execution transaction. A return visit can use that single transaction when the required token allowances remain sufficient. Adding an unapproved input creates an additional authorization requirement. Counting only the final execution would leave out that first-use commitment.

Unroutable inputs and atomic execution

Jumper reports unroutable operations and asks for confirmation of a reduced sweep that leaves those inputs out.

A leg is an individual operation within the proposed flow. Identifying a failing leg during preparation lets the application omit that input before commitment. The omitted balance remains unswapped. Confirming the reduced selection accepts a different set of conversions, so its expected output should reflect that set.

Composer executes the included calls atomically within a single chain. Atomic execution means that those calls succeed together or their state changes revert together. Selecting a smaller executable batch does not imply that its contract will freely skip unexpected failures during execution.

Simulation evaluates the proposed calls against chain state during preparation. Execution occurs later, when prices or liquidity may differ. A transaction that reverts can still consume gas, even though its included token conversions do not settle. An omitted input and a reverted execution therefore have different consequences.

A skipped balance against the expected sweep

A reduced sweep can convert the routable selection after the excluded input is disclosed and confirmed. In this hypothetical case, a reader selects a routable balance and another balance without an executable path on the same supported chain. Existing allowance covers the routable input, and the wallet holds enough native currency for submission gas. The live preview supplies its expected native output and execution gas; the aim of converting both balances is no longer achievable with that selection.

Before submitting the execution transaction, the reader can decline the reduced sweep and leave both balances unswapped. Submitting the signed transaction requests conversion of only the included input. Comparing its expected recovery with its gas cost determines whether that narrower conversion serves the original cleanup task. The missing route cannot be replaced by the excluded token’s displayed wallet value.

After the reduced sweep executes successfully and confirms, the included amount has been converted, native output has arrived and the excluded balance remains. Reconciliation compares those changes with the accepted selection. Because execution gas uses the same native asset, the wallet’s net native-balance increase can be smaller than the swap output. The confirmed output and charged gas explain that difference without treating the untouched token as a failed included swap.

Dust conversion and a yield deposit

Dust Sweeper produces native currency, while Quick Deposit creates a supported protocol position. Sharing Composer infrastructure does not make those outcomes interchangeable. A yield deposit also involves the destination protocol’s requirements, and a cross-chain deposit adds bridge settlement. These belong to a different functional path from consolidating small balances on one chain. Jumper Earn’s Morpho integration illustrates the distinction: a completed deposit produces a vault position, while a completed dust sweep produces the selected chain’s native asset.

Composer’s flow behind the wallet transaction

Composer represents the proposed consolidation as swap operations feeding a common output. Its compiler turns the resolved flow into instructions for an onchain virtual machine, the contract engine that executes those instructions through the user’s proxy. Runtime value passing connects outputs from earlier calls to later calls. This lets dependent operations use actual amounts produced during execution. The shared transaction carries the selected conversions, even though each input still needs its own usable route.

View image file

The preparation response separates the ready-to-sign transaction, simulated output amounts and required approvals. A simulated amount describes an expected outcome before settlement. The receipt’s execution status and resulting balances establish whether the sweep succeeded and what changed. Authorization has its own record: the ERC-20 Approval event records a successful allowance change, without establishing that the subsequent sweep executed.

Still wondering about Jumperexchange dust sweeper?

Does removing a token from a dust sweep cancel its earlier allowance?: Removing a token from the selected sweep or choosing individual swaps leaves that token’s existing allowance for the execution proxy unchanged. An ERC-20 allowance belongs to the token owner and specified spender, independently of the current selection. Changing that permission requires an allowance update on the token contract. An excluded balance can therefore remain unswapped while its earlier spending permission remains active.
Why might a visible dust token have no executable route?: A visible wallet balance can lack an executable route because liquidity, supported providers or amount limits prevent the proposed conversion. Routing may also reject excessive price impact. A token appearing in a wallet does not establish an available market for the requested amount. Dust Sweeper can omit an unroutable input, allowing the remaining eligible selection to be considered separately.
What does a partial Composer response mean before a dust sweep?: A partial Composer compilation response means that the service produced a transaction while simulation reverted under its allow-revert simulation policy. It contains diagnostics that the application must interpret. This is a preparation result, not evidence that tokens have moved or that a sweep has partly settled. The reported failure needs to be resolved or the affected operation excluded before accepting an executable selection.
Can revoking approval reverse a completed dust sweep?: Revoking an ERC-20 allowance changes future spending permission and does not reverse completed swaps. A confirmed conversion has already exchanged the included tokens for native output. Recovering the original token would require a separate available swap at its own pricing and costs. Approval revocation neither restores the original balances nor refunds gas already spent on the completed execution.
Which details distinguish dust balances that share a ticker?: For ERC-20 inputs, the chain and token contract address distinguish balances that share a ticker. The ERC-20 symbol field is descriptive and optional; it does not establish token identity. Separate contracts can use the same symbol, and balances on different chains belong to different network contexts. Matching the actual input to its route therefore requires more than the displayed ticker.
Does Composer’s sweepTo setting perform the dust swaps by itself?: Composer’s sweepTo setting directs the flow’s terminal resources, meaning tokens remaining in the execution proxy after execution, to a specified address. It does not itself define token conversions. Dust Sweeper’s consolidation relies on swap operations that produce the common native output; the final transfers deliver the resulting resources. Confusing this transfer setting with the complete feature would omit the routing and conversion operations that make the dust usable.