A dusting attack is the broadcast of a very small amount of cryptocurrency to many wallet addresses at once, either to break the privacy of those addresses by tracking how the dust later moves or to bait the recipient into a malicious token contract. The pattern is older than most retail holders realise and still active in 2026.
This article walks the dust-attack threat model end-to-end, the 2018-2019 Bitcoin-era pattern Samourai Wallet first flagged, the 2024-2026 EVM fake-airdrop trap that turns dust into a phishing front end, the chain-clustering side, the chain-by-chain identification routine across Bitcoin, EVM, and Solana, the do-and-don't response routine, and the layered 2026 posture.
What is a dust attack, and why does it threaten on-chain privacy?
A dust attack threatens on-chain privacy because a small unsolicited transfer turns into a tracking marker once the recipient consolidates the dust with the rest of their balance, and on EVM chains the same dust event can also bait the recipient into a malicious token contract. The two threat models share the starting move and split where the recipient touches the dust.
The privacy framing is the older of the two. The crypto privacy basics primer covers the broader privacy stack on Bitcoin and other public chains, and dust attacks sit inside that stack as one of the specific attack patterns that target wallet unlinkability. On Bitcoin, a wallet's privacy depends on the analyst not being able to tie multiple addresses to one owner. Dust sent to many addresses owned by the same wallet only becomes a clustering signal when those dust outputs get spent alongside other UTXOs in the same transaction; the act of consolidation reveals that the dust-receiving addresses and the consolidation inputs share an owner. The attacker pays nothing except network fees to seed the signal across thousands of addresses at once.
The second threat is the EVM-era version. On Ethereum, Polygon, Arbitrum, Base, BNB Chain, and other EVM networks, a malicious actor can deploy a token contract and broadcast a transfer event that credits unsolicited token balances to thousands of wallets at once. The credit costs the attacker only the deployment and broadcast gas, and the token shows up in the recipient's wallet UI as if it were a real airdrop. The trap is not the credit itself, which sits inert on-chain, but the call the recipient makes when they try to interact with the token. That second pattern is the one that has driven most of the 2024-2026 retail losses attributed to dust, and is why the playbook below covers both.
How did Bitcoin-era dust attacks evolve into the EVM dust-trap pattern?
The Bitcoin-era dust attack and the EVM dust-trap pattern share the same low-cost broadcast move but optimise for different outcomes: the Bitcoin version aims for analytics value through subsequent consolidation, while the EVM version aims for a malicious-contract interaction that lands an approval signature against the victim's actual assets. The terminology stayed the same; the threat model moved.
The Bitcoin pattern surfaced publicly in October 2018, when the privacy-focused Samourai Wallet team disclosed a coordinated dust transaction broadcast across thousands of addresses and added a dust-alert feature to flag the incoming UTXOs for users. The clearest later example landed on August 9 2019, when a coordinated dust transaction broadcast a tiny LTC amount to nearly 300,000 Litecoin addresses; the Litecoin Foundation later attributed the event to a mining-pool promotion rather than a clear malicious campaign, but wallet vendors still issued dust alerts because the same broadcast pattern is what a clustering attack would look like (source: Cointelegraph on the Litecoin 2019 dust event). The textbook definition that crystallised in this period is the one Binance Academy still uses for the dusting-attack concept: a small-value transfer broadcast to many addresses with the intent of breaking the recipient's privacy by tracking the subsequent UTXO consolidation. The crypto wallet glossary entries on UTXO, dust, and spam token give the terminology a single reference point before the EVM material lands.
The EVM evolution kicked in once token-contract deployment became cheap enough to spam thousands of recipients at once. On BNB Chain through 2021, mass-airdropped spam tokens became a visible feature of wallet histories on BscScan; the same pattern then spread to Polygon, Arbitrum, Base, and other EVM networks. The 2024-2026 wave added an active-attack layer on top of the spam clutter: the spam token's contract is itself malicious, and any interaction with the token (a send, a swap attempt, an approval, even a "claim" prompt rendered by the contract's metadata) routes the wallet into a malicious flow that requests a separate signature against the victim's actual assets. The dust is no longer just a privacy probe; it is a phishing landing page rendered inside the wallet's own UI.
What does a fake-airdrop dust attack actually do to your wallet?
A fake-airdrop dust attack does nothing on its own; the harm comes from the interaction the victim performs after the dust appears, which is almost always the call that triggers the malicious contract logic. The dust credit is bait, and the wallet UI is the lure surface, but the attack only completes when the victim signs something the attacker can use.
The EVM trap usually arrives as an unsolicited token credit from a contract address the victim does not recognise. The token name and symbol are crafted to read like a known airdrop (an "ARBI", "OPTI", "ETH2" lookalike, or sometimes a copy of a real token's ticker with a different contract address) and the wallet UI renders the credit alongside the victim's real assets. The victim's mistake is reading the credit as legitimate and trying to interact with it: a send attempt routes through the malicious contract's transfer function, a swap attempt routes through a malicious approval flow, or a "claim full amount" prompt rendered by the token's metadata requests a SetApprovalForAll or approve(spender, uint256.max) signature against a different asset the wallet actually holds. The wallet drainers explained deep-dive covers the named-kit lineage including Inferno, Angel, and Pink Drainer, and the operators running those kits ship fake-airdrop dust-trap variants alongside the fake-mint landings. Scam Sniffer's 2024 phishing year-in-review attributed a substantial share of retail EVM drainer losses to phishing landings of this class, with the dust trap acting as one entry point among several for a wallet-stack the victim never recognised as malicious (source: Scam Sniffer 2024 phishing report).
The overlap with address poisoning is worth flagging without duplicating the clipboard hijacking and address poisoning coverage. Some dust events are themselves the address-poisoning bait: the dust comes from a sender address crafted to visually resemble a counterparty the victim has paid before, with the goal of getting the victim to copy the lookalike address out of their transaction history on a later payment. The smart-contract layer applies on either path, which is why the smart contract wallet risks primer is the reference point for the contract-interaction surface the trap exploits.
How do attackers use dust to cluster wallets and deanonymize on-chain activity?
Dust enables wallet clustering because public chains expose every transfer in the clear, and a dust transaction sent to many addresses creates a controlled set of markers that later transactions can co-spend with other UTXOs the analyst is trying to link. The clustering only works when the recipient consolidates the dust with other inputs in a transaction the analyst can read on-chain.
Blockchain-analysis firms including Chainalysis use dust transactions among many other heuristics to cluster addresses into entities for compliance, exchange-side risk scoring, and forensics work (source: Chainalysis on blockchain intelligence and clustering accuracy). The dust UTXO is not a magic deanonymizer on its own; it is one input to a clustering model that also reads common-input ownership heuristics, change-output patterns, exchange-deposit fingerprints, and timing correlations. The dust attacker's contribution to that model is the controlled broadcast: by sending dust to thousands of addresses at once, the attacker creates a set of marked outputs whose co-spend with other UTXOs later becomes a strong signal that the marked address and the co-spent address share an owner. The deeper privacy problem is that the receiving wallet's address reuse privacy risks compound the clustering: a wallet that reuses addresses across counterparties is already easier to cluster, and dust attacks specifically amplify what address reuse already gives up.
The EVM clustering side runs on a different mechanic but reaches a similar conclusion. EVM accounts are reused by design, so the clustering question is less "which addresses share an owner" and more "which off-chain identity sits behind this address." Dust on EVM chains feeds entity attribution by tying the address into a known distribution campaign whose recipient set is a starting point for analyst pivots. The 2024-2026 dust-trap pattern shifts the attacker's incentive toward direct theft, but the clustering signal is still emitted as a side-effect of the broadcast.
How do you identify dust in your wallet and on what blockchain?
Dust identification depends on the chain, the wallet, and the dust type, but the same three questions answer the routine in every case: where did the credit come from, does the asset match a known on-chain token list, and does the transaction history show any pattern of mass distribution from the same source. The chain-by-chain tools below produce the answers.
On Bitcoin, dust shows up as small unspent transaction outputs in the wallet's coin-control view or the address detail on a public explorer like Mempool.space. A wallet that sees an unexpected sub-1,000-satoshi UTXO from an address the user does not recognise should treat it as dust by default. The software wallets guide Bitcoin-specific section covers the coin-control discipline that makes dust visible at the UTXO level; the discipline applies to Sparrow, Electrum, BlueWallet, and any other Bitcoin wallet that exposes per-UTXO control. On EVM chains, dust shows up as a token credit in the wallet's asset list. Etherscan, Polygonscan, BscScan, Arbiscan, and Basescan all expose the contract address that issued the token and the transaction that broadcast the credit; the contract verification page indicates whether the contract has been verified and audited, and the holders count typically shows the unusual mass-broadcast distribution that flags spam. MetaMask, Rabby, and Trust Wallet all support a hide-token or hide-spam routine that removes the credit from the wallet UI without signing any transaction against the token. On Solana, dust shows up as spam NFTs and spam SPL tokens that Phantom and Solflare render alongside real assets; both wallets provide a hide-or-burn workflow that does not require signing a transaction against the spam asset, and Solscan exposes the issuing program and the broadcast distribution for any user who wants to verify before hiding.
The cross-chain identification pattern is the same in every case: do not assume a credit is legitimate just because the wallet UI rendered it, do not assume the token symbol matches the canonical token of that ticker, and do not interact until the contract address has been checked against a known-token list. The dust identification step is read-only; the response step is where the technical reasoning matters.
What should you do (and not do) when you receive unexpected dust?
The right response to unexpected dust is to leave the dust alone, hide the asset from the wallet UI, and revoke any standing approvals that exist on the same wallet for unrelated reasons. The wrong response is any interaction that signs a transaction touching the dust, and that split is where most retail losses happen.
The first rule is do not consolidate. On Bitcoin, consolidating the dust UTXO with other inputs in a single transaction creates the exact co-spend signal a clustering attacker is hoping for. On EVM chains and Solana, consolidation is not the threat, but the underlying principle applies: do not send the dust anywhere from the receiving wallet, because the send transaction is the call the malicious contract is waiting to intercept. The second rule is do not interact. Specifically, do not click any "claim" prompt rendered by the token, do not swap the dust on a DEX, do not approve the dust token for any spender, and do not try to send the dust back to the sender. The send-back attempt is the most common path into the trap on EVM chains because the victim assumes returning the asset is the polite response; the contract's transfer function is the malicious call that triggers the wallet-drain flow. The third rule is do not approve. If the wallet UI ever prompts for a SetApprovalForAll or approve(spender, uint256.max) signature in connection with a dust token, refuse the signature and disconnect the session; the revoke token approvals workflow covers the standing-approval audit that should run regardless of whether the dust signature was clicked or not.
The fourth rule is do hide and do audit. Hiding the spam token in the wallet UI removes the temptation to interact with it on a later session, and a standing-approval audit on Etherscan Token Approval Checker, Revoke.cash, or the equivalent tool for the chain in question confirms that no prior session left a usable grant in place. The audit is read-only until the user signs a revoke transaction, and the revoke transaction is the only signature the wallet should produce in a dust-response routine. The dust itself stays where it sits.
The walkthrough below shows the response to a typical EVM dust-attack scenario from the moment the user notices it through the closing audit.
Scenario. You wake up and open MetaMask. Under the token list there is a new line: 1.0000 "USDC_REWARDS" (or a similar lookalike to a real token) you do not remember acquiring. Hovering the row shows a "Claim" button. The wallet has been quiet for two weeks.
Do not click "Claim." That button is the malicious call. The token contract's transfer() function is the entry point into the drainer flow; the moment your wallet signs against it, the attached calldata can request approvals against the legitimate tokens you actually hold.
Identify the spam token's contract address. Open Etherscan, paste your wallet address into the search bar, scroll to the "Tokens" tab, find the spam token row, click into the token's contract page. The contract page typically shows a recent creation date (often less than a week before the dust arrived), zero verified holders before the dust wave, and no audit history.
Cross-check on a second tool. Plug your wallet address into Revoke.cash or the chain's token-approval checker. If the spam token has somehow already obtained an approval (rare but possible if you previously clicked through a phishing site on the same wallet), the row appears here. Note it for revocation in step 6.
Hide the spam token in MetaMask. Click the three-dot menu on the token row and select "Hide token." This removes the row from your wallet UI so a future absent-minded session does not interact with it. Hiding is local-only and does not touch the chain.
Run a full standing-approval audit on the same wallet across all chains it has touched. Even if no approval exists for the spam token specifically, the dust receipt is a useful prompt to clean up any forgotten approvals from real DApps the wallet used six months or a year ago. Follow the seven-step revoke procedure in the revoke token approvals primer.
Revoke any approvals the spam token does hold (if step 3 surfaced any) using the same procedure. The revoke transaction signs against the legitimate token contract whose approval was granted, not against the dust token itself.
Do not send the dust back. The "return to sender" instinct is the most common path into the trap. The sender address is either a contract or a wallet the attacker controls; either way the return-send is a chain-recorded co-spend that helps cluster your other wallets.
Document the contract address in a personal note (or a wallet-hygiene log if you keep one). When the next dust wave arrives from the same operator, recognising the pattern saves time.
The eight-step response holds across EVM chains. On Bitcoin the response is shorter (steps 1, 7, and 8 apply; the approval-audit steps are EVM-specific) but the underlying rule is the same: do not move the dust, do not co-spend it, do not respond to it.
How should you set up a hardened anti-dust posture in 2026?
A hardened 2026 anti-dust posture has five layers: a separate hot wallet for any chain with active marketplace or DeFi exposure, a cold vault holding the long-term position on a hardware device, a hide-and-audit routine that runs without consolidating dust UTXOs, a network-side privacy layer beneath the wallet, and a quarterly standing-approval audit across every chain the user has touched.
The everyday-wallet layer holds only the active position and the gas needed for routine operations, with separate hot wallets per chain so that an EVM dust-trap interaction on one chain cannot reach the holdings on another. The cold-vault layer holds the long-term position on a hardware device referenced in the hardware wallet guide, and the cold vault never signs an interaction with a dust token; transfers in or out of the cold vault are direct, fee-aware transactions to addresses the user already trusts. The hide-and-audit routine treats every unsolicited credit as spam by default, runs the chain-specific hide step (MetaMask hide token, Phantom hide spam NFT, Bitcoin wallet coin-control exclusion), and runs the standing-approval audit on the chain-appropriate tool before the next active session. The network-side privacy layer is the routine covered in the VPN and network security primer that prevents IP and DNS leaks from compounding the on-chain analytics surface, and the browser security discipline beneath that covers the browser-profile separation that keeps dust-trap landings out of the wallet-active session.
From Blofin's operational perspective, the platform sees dust-related withdrawal-flow heuristics surface at the linked-wallet history layer: withdrawal-pattern review escalates when an off-platform wallet that has received unsolicited dust subsequently shows post-dust consolidation patterns matching known sweep wallets, and device-trust prompts trigger more often on sessions whose linked wallet history includes recent unsolicited token credits from contract addresses outside the standard known-token list. The baseline operator-side observation Blofin treats as standard is that users who do not consolidate or interact with dust UTXOs reach a noticeably lower dust-trap-incident rate than users who try to clean up the unknown balances. Refresh the posture after every disclosed dust-distribution campaign on a chain the user holds positions on, after any disclosed drainer-kit campaign that ships a fake-airdrop variant, and after any change to the chain mix or wallet activity profile.
Frequently asked questions
Is receiving a dusting attack dangerous on its own?
No, receiving dust on its own is not dangerous; the dust UTXO or token credit sits inert in the wallet until the recipient does something with it. The danger comes from any interaction the recipient performs afterward, including a consolidation on Bitcoin or a send, swap, or approval on an EVM chain. The right response is to leave the dust alone, hide the token in the wallet UI, and treat the receiving address as flagged for the privacy-clustering risk.
What is the difference between a dust attack and an address-poisoning attack?
A dust attack broadcasts a small-value transfer to many addresses with the goal of clustering wallets or baiting a malicious-contract interaction. An address-poisoning attack uses a sender or recipient address crafted to visually resemble a counterparty the victim has paid before, with the goal of tricking the victim into copying the lookalike address from their history. The two vectors overlap because a dust event can also act as address-poisoning bait, but the response routines differ.
Should I send the dust back to the sender?
No, never send the dust back to the sender on any chain. On Bitcoin, the send transaction creates the co-spend signal a clustering attacker wants. On EVM chains, the send-back attempt is the most common path into a wallet-drain flow because the malicious token contract intercepts the transfer call. The right response is to leave the dust alone and hide the asset in the wallet UI.
Why do I keep receiving spam tokens in my MetaMask wallet?
Spam tokens land in EVM wallets because token-contract deployment is cheap, addresses are public, and mass-airdropped spam is one of the highest-volume phishing entry points across Ethereum and the major Layer 2 chains. The fact that the wallet UI renders the credit does not mean the token is legitimate. The hide-token routine in MetaMask removes the credit from view without signing anything, and the routine is the standard response.
Can a dusting attack drain my Bitcoin wallet?
A pure Bitcoin dusting attack cannot directly drain the wallet because Bitcoin's transaction model does not include approval signatures or malicious-contract interactions. The Bitcoin risk is privacy-clustering rather than direct theft, with the harm landing on subsequent transactions whose co-spend pattern ties the dusted address to the rest of the wallet's holdings. The EVM dust-trap pattern is what carries the direct-theft risk on Ethereum and the Layer 2 chains.
Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the Samourai Wallet blog disclosure of the October 2018 Bitcoin dust attack at blog.samouraiwallet.com, Cointelegraph's coverage of the Litecoin Foundation response to the August 9 2019 Litecoin dust event, Binance Academy's reference primer on dusting attacks, Scam Sniffer's 2024 phishing year-in-review reporting on the modern EVM fake-airdrop dust-trap vector, the Etherscan and Mempool.space block explorers for chain-by-chain dust visibility, the Chainalysis 2024 Crypto Crime Report on entity-clustering methodology, and Revoke.cash for cross-chain operator-grant audit and revocation. All facts independently verified against cited documentation current as of May 2026.
This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making investment decisions. Blofin Academy content reflects the state of public information at time of publication; protocol parameters, fees, and platform data change frequently.