Jumper Dust Sweeper reuses token approvals through a persistent execution proxy.

Dust Sweeper, Composer, and the Execution Proxy

Dust Sweeper supplies balance selection, Composer coordinates the swaps, and a personal execution proxy connects the selected token inputs to their consolidated output. Composer is the execution engine that bundles the underlying operations on supported Ethereum Virtual Machine (EVM) chains. The proxy is a smart contract through which the wallet's signer runs that bundle. These components let several token conversions share one execution transaction while retaining the permissions that each input requires.

The native-token destination belongs to the selected chain. Consolidating balances within that chain and bridging assets between networks have different purposes. The sweep described here converts small balances into a common local asset. Access to DeFi yield is a separate use of composed transactions; a dust conversion alone creates no yield position.

A Persistent Proxy for the Same Signer

Composer derives an execution proxy from the signer's address on a given chain, providing a stable contract that later transactions from that signer can use again. The proxy runs shared execution logic in its own balance and storage context. Its access controls restrict execution to the owning signer. The shared execution engine and the personal proxy therefore have different roles and different contract identities.

On the proxy's first use, the execution transaction can target a factory that deploys it and runs the prepared operations together. Later execution targets the existing proxy. That deployment arrangement does not make the shared engine the token spender. The actual approval request identifies the contract that receives spending permission.

Token-Specific Spending Permission

A standard ERC-20 approval sets a spending limit for a specified spender on the token owner's balance. ERC-20 is the token interface that defines this allowance mechanism. The token contract records the permission for an owner and spender. A wallet balance says how many tokens the owner holds; an allowance says how many that spender may transfer. Sufficient allowance and sufficient balance are separate requirements for the selected input.

The spending limit uses units of the approved token. It does not describe the amount of native currency expected after conversion. Permissions also belong to the exact token contract. Similar names or symbols do not combine allowances, and an approval for one token does not authorize another token in the same wallet.

Approval Reuse on Later Sweeps

Approval reuse removes a repeated authorization transaction when the existing proxy already has sufficient permission for the amount that the next sweep will spend. A new execution bundle still specifies the selected inputs and their conversions. Reusing the allowance does not fix the exchange price, reserve liquidity, or preserve an earlier output estimate. The new quote must reflect the amounts and market conditions for the new sweep.

A bundle may mix inputs with sufficient allowances and inputs that need approval. Permission requirements apply separately to those token contracts.

What Triggers Another Dust Sweeper Approval?

Another approval is required when the intended proxy lacks sufficient allowance for a selected token, whether that permission is absent, reduced, or revoked. A newly selected token contract has its own allowance record. Authorization for the tokens used previously does not cover this additional input.

Spending can reduce a finite allowance. The amount that remains may therefore be smaller than the original approved amount. Some token implementations preserve an unlimited allowance during transfers, so consumption behavior follows the token's implementation.

A larger selected input can also exceed an unchanged cap. An existing approval covers only the amount that it still permits.

Open full-size image

Revocation removes the relevant permission. A different signing address has its own allowance records, and approvals on another chain do not supply permission here.

Spending Caps and Revocation

An exact spending cap authorizes the selected amount, while a larger cap can leave permission available for subsequent sweeps through the same spender. That convenience also widens the amount that the permission covers. An unlimited cap is broader still. Review the cap in the approval request rather than assuming that reusable permission has a particular size. Proxy access controls govern who can initiate execution; the token allowance governs the amount that the spender may transfer.

Revocation changes the permission on-chain and consumes gas. Reducing a cap can limit future spending without changing the token balance itself. These controls apply to the relevant owner, token, spender, and network. They do not retroactively reverse a completed conversion. A personal proxy's access restriction does not turn broad token permission into a narrow spending cap, so both boundaries remain relevant.

Simulation Before Execution

Composer simulates the prepared operations against current chain state to estimate outputs and identify execution problems before it returns a transaction for signing. The simulation can expose insufficient liquidity or a swap that would violate its output tolerance. It also returns information about approvals that the signer must grant. The simulator can override balances and permissions for its calculation, so a successful preview does not establish that the wallet has confirmed every required approval.

Output protection belongs to the compiled operations. A swap's minimum-output requirement constrains its execution, while the displayed estimate describes the simulated result. Approval reuse does not relax an output condition. Changes in chain state between simulation and execution can still affect whether the prepared transaction succeeds.

Unroutable Inputs and Atomic Execution

Dust Sweeper can omit an unroutable input from the bundle that the user confirms, while Composer executes the remaining prepared operations atomically within the selected chain. Omitting an input changes what the sweep attempts to convert. The output estimate applies to the included inputs that the user confirms. A token excluded from that bundle has not been converted by it.

Atomic execution means that the final transaction's operations succeed together or their state changes revert. The Composer API can return a partial response containing transaction data and a simulation error only under its allow-revert simulation policy. That response describes a problematic preview, not a completed subset of on-chain swaps. Likewise, a ready-to-sign transaction is still a proposed execution, and a submitted transaction still needs a successful on-chain result.

Network Costs and Received Value

Approval reuse avoids the gas for an unnecessary approval transaction, while the sweep still incurs the computational cost of swaps and other on-chain work. Several conversions in a batch remain several underlying operations. First-use costs can also include approvals that a later sweep can reuse, so the cost of establishing permission differs from the cost of returning with sufficient allowances.

The economics of small balances include gas and the conversion terms. Price impact describes how a trade affects the exchange price through the available liquidity. Slippage tolerance constrains acceptable execution changes. Compare the quoted native-token output with the costs that apply to the selected bundle, keeping separately paid gas distinct from the conversion output. Raw quantities of different input tokens cannot be added to calculate their combined value.

Future Balances Under Existing Permissions

An unused standard ERC-20 allowance can cover later deposits of the same token into the same wallet while the specified spender remains authorized. The allowance is contract state, separate from the wallet's current balance. Emptying a token balance does not necessarily remove unused spending permission. A subsequent deposit can therefore fall within the remaining cap even though those tokens were absent when the approval was granted.

This permission does not schedule another sweep. The personal proxy's execution controls still apply, and a new sweep requires its execution authorization. The amount potentially covered by a retained allowance can nevertheless change as balances grow. A cap chosen for occasional dust consolidation deserves attention when that same wallet later holds a larger balance of the approved token.