Dusting Attacks: Unsolicited Funds and Tokens

A dusting attack is a transfer of a very small amount of cryptocurrency or an unsolicited token to an address you control, made by someone who does not control that address. The transfer itself does not take anything from the wallet. What the sender is trying to obtain is information or a future action: a link between addresses, a signature, or a visit to a website. The two common forms sit on different chain models and have different failure modes, so they are worth separating before deciding what to do.

On UTXO chains such as Bitcoin, the attacker sends a tiny output to many addresses. If any of those addresses later spends the output together with other coins, the transaction reveals that the same person controls both. That is a privacy loss, not a loss of funds. On account chains such as Ethereum and its compatible networks, the attacker uses a token contract to record a balance against your address. The token name often contains a website address, and the site is built to request a signature that drains assets. The danger in that case is entirely in what the owner does next.

The UTXO version: linking addresses through spending

A UTXO chain does not store a balance against an address. It stores unspent outputs, each of which is a discrete chunk of value with its own spending condition. A wallet selects some of those outputs to fund a payment and returns the remainder to a change address. If the attacker’s tiny output is selected alongside outputs from other addresses, the resulting transaction proves common ownership to anyone analysing the chain.

This is why the amount matters less than the selection. A single satoshi received at an address you consider separate can be enough to collapse that separation if the wallet spends it together with the rest. The attack is cheap because the attacker pays only the network fee for each output, and it scales because addresses are public.

Coin control and labelling

Many wallets expose coin control, which lets you see individual UTXOs and choose which ones a transaction may spend. The response to a dust output is to label it and exclude it from spending, or to leave it untouched. Freezing an output is a wallet-level setting; it does not remove the output from the chain, and it does not notify the sender.

bitcoin-cli listunspent

This lists unspent outputs with their amounts, addresses and confirmations. A very small output at an address you did not expect is the signature of a dusting attempt. The output is real and spendable; the question is whether spending it links addresses you wanted kept apart.

bitcoin-cli listunspent 0 9999999 '["<address>"]'

Filtering by address shows which outputs sit at a particular address. If a tiny output appears at an address you had treated as separate from your main holdings, note it and avoid combining it with other outputs in one transaction.

The account-chain version: tokens that name a website

On account chains, an unsolicited token can appear in a wallet without any action by the owner. The token contract stores a balance mapped to the address. Wallets that display arbitrary tokens will show it, often with a name or symbol that reads like a URL or a claim to be redeemed. The token itself cannot move your other assets. A token contract has authority only over its own balances unless the owner has granted it an allowance.

The attack depends on the owner trying to interact with it. The usual path is a visit to the site named in the token, followed by a signature request. The request may be phrased as a claim, a swap, a migration or a verification step. What it actually authorises is one of two things: a transfer of a specific asset, or an approval that lets a contract spend a token on the owner’s behalf. An approval for an unlimited amount is the common pattern, because it lets the draining contract take the balance later without another signature.

What the victim actually clicks

The screen usually shows a domain, a contract address, a function name and sometimes a decoded summary. The decisive detail is the function. A request to approve grants spending authority; a request to setApprovalForAll grants authority over an entire collection of NFTs; a request to permit authorises a transfer using an off-chain signature. A request to transfer moves a specific amount. If the page describes a claim but the wallet shows an approval, the two do not match, and the mismatch is the attack.

cast call <token> "allowance(address,address)(uint256)" <owner> <spender> --rpc-url <url>

This reads the current allowance a token owner has granted to a spender. A large or maximum value for a contract you do not recognise is the residue of an approval. Revoking it is a separate transaction that sets the allowance to zero.

cast call <token> "balanceOf(address)(uint256)" <owner> --rpc-url <url>

This returns the token balance held by an address. A non-zero balance for a token you never acquired confirms that the token was sent to you rather than bought. The balance is a number in a contract; it is not evidence that the token has a market or that it can be sold.

What receiving can and cannot do

Receiving a transaction cannot move funds from your address. On a UTXO chain, spending requires a signature against the output’s condition, and the sender cannot produce it. On an account chain, moving a token requires either the owner’s signature or a prior approval, and the sender has neither. The risk is created by the owner’s later action: combining outputs, signing an approval, or visiting a site that asks for a signature.

A wallet that displays every token it finds is doing what it was asked to do. The display is not a security failure. The failure, when it happens, is at the signature screen or at the moment of spending.

What people get wrong

A natural first reaction is to assume the wallet has been compromised because an unknown token appeared. That conclusion is understandable: the wallet is the interface where the change is visible, and a change the owner did not make looks like a breach. On an account chain, no breach is required. Anyone can write a token balance to any address, and the cost is a transaction fee.

The second common mistake is to try to sell or swap the token. The reasoning is that an unwanted asset might as well be converted. This is the step the attacker is waiting for. The token often has no liquid market, and the only venue that will quote a price is the site named in the token. Interacting there produces the approval request.

A third mistake is to treat the UTXO version as harmless because no funds are at risk. The privacy loss is real and permanent once the transaction is broadcast. Addresses that were kept apart become linked in public chain data, and that link cannot be undone.

Comparison of responses

Address poisoning and how it differs

Address poisoning is a related technique that places a lookalike address in a transaction history so that a later payment is copied from the wrong entry. It targets the owner’s habit of copying an address from recent activity rather than from a saved contact. Dusting targets the linkage between addresses or the owner’s curiosity about a token. The two are often used together, and the defence overlaps: verify addresses from a saved source, and treat unsolicited activity as data rather than as an instruction.

Practical handling

For UTXO wallets, enable coin control if the wallet supports it, label incoming outputs, and keep dust outputs out of transactions that also spend main holdings. For account-chain wallets, hide unsolicited tokens rather than interacting with them, and review approvals periodically. A wallet’s approval view lists contracts that have been granted spending authority; revoking an allowance is a transaction and costs a fee.

No wallet setting can prevent someone from sending to a public address. What can be controlled is what the wallet does with the arrival and what the owner signs afterwards. The useful habit is to read the function name on every signature request and to compare it with what the page claims to be doing. When the two disagree, the request is the attack, regardless of how the token arrived.