ERC-20 Token Spam and Dusting in Trezor Suite: Why Unknown Tokens Appear in Your Ethereum Wallet and How to Safely Ignore Them

An Ethereum wallet holder using Trezor Suite notices several unfamiliar tokens suddenly appearing in their portfolio—often with names resembling legitimate projects or bearing cryptic symbols. The balances show nonzero holdings, yet the user never requested or purchased these assets. The immediate reaction is often concern: whether the wallet is compromised, whether these tokens represent hidden value, or whether clicking on them might trigger some form of attack. In reality, this experience reflects a long-standing problem in the Ethereum ecosystem: unsolicited token transfers, sometimes called airdrops or dusting attacks, are a common and largely unavoidable consequence of how the blockchain works.

The underlying issue is not a flaw in Trezor Suite or a sign of wallet vulnerability. Rather, it illustrates the difference between what a blockchain records and what a user should trust. Because Ethereum is permissionless, any address can send ERC-20 tokens to any other address without consent, confirmation, or prior relationship. Trezor Suite displays these transfers faithfully because the tokens are genuinely present on the ledger. However, the presence of an unknown token in a wallet does not mean it is legitimate, valuable, or safe to interact with. Understanding why these tokens appear, how to distinguish benign spam from malicious contracts, and what actions are genuinely risky—and which are not—is essential for anyone managing Ethereum holdings in a non-custodial wallet.

Why airdrops and token transfers are permissionless on Ethereum

The Ethereum protocol itself does not prevent a contract from sending tokens to an address without that address’s prior approval. This design choice enables several legitimate use cases: rewarding users for participation in decentralized finance, distributing governance tokens, issuing dividends, or conducting promotional campaigns. The ERC-20 standard, which defines how fungible tokens work on Ethereum, includes a transfer function that contracts can call to move tokens from their own balance to a destination. No signature from the receiving address is required. The receiving wallet simply observes the event on the blockchain and, through wallet software, can calculate the balance and display it to the user.

This permissionless design means that a wallet address is essentially a public mailbox. Anyone can send funds or tokens to it. From a security perspective, receiving an unwanted token does not grant control over other assets in the wallet, does not expose private keys, and does not require any action from the user. The tokens are genuinely stored on the blockchain under that address—they are not a phishing attempt or a remote exploit. However, the permissionless nature of Ethereum also creates an opportunity for abuse: actors can use token airdrops as part of a spam campaign, a phishing scheme, a honeypot contract, or a dusting attack aimed at de-anonymizing address clusters.

Trezor Suite displays unknown tokens because they represent real on-chain balances. The application faithfully reflects the state of the blockchain, including any unwanted transfers. This transparency is a security feature, not a liability. A wallet that silently hid unknown tokens might conceal important information or lull a user into a false sense of privacy. Instead, Trezor Suite shows what is actually present, allowing the user to investigate, decide whether to hide the token from the display, or take additional steps if the token appears suspicious.

Token spam, airdrops, and the range of motivations

Not all unsolicited tokens are created equal. The spectrum ranges from harmless marketing to directed attacks. On the benign end, a legitimate project might airdrop tokens to wallet addresses meeting certain criteria—holders of another asset, participants in a community, or users of a protocol. These airdrops are intended as rewards or incentives, even if individual recipients did not explicitly opt in. The token is real, has genuine utility within the project’s ecosystem, and may be tradeable or stakeable. A user can accept it, ignore it, or, depending on terms, claim additional benefits by interacting with the project.

In the middle ground lie tokens created primarily to drive engagement or visibility rather than to deliver value. A startup might airdrop tokens to thousands of addresses, hoping to build an audience, create network effects, or bootstrap liquidity for a decentralized exchange listing. The token exists, but its utility may be limited, its price may be highly speculative, and the project may not have a sustainable business model. These tokens often accumulate in wallets and may become worthless.

At the problematic end of the spectrum are spam tokens designed to impersonate legitimate projects. An attacker might create a token with a name nearly identical to a well-known coin—for example, “Tether USDT (Fake)” or “OpenAI GPT”—and airdrop it to thousands of addresses. The intent is often to confuse holders, drive traffic to a phishing website, or create an opportunity to execute a scam. Another variant is the honeypot contract: a token that appears to hold value and can be purchased, but whose contract includes hidden code preventing the buyer from selling or withdrawing funds. This is a direct theft mechanism, not just spam.

Honeypot contracts and the risk of interaction

A honeypot token represents a category of risk that requires clarification: the token itself does not harm the wallet by existing in it, but attempting to sell or transfer it activates the scam. A honeypot contract might allow a user to buy tokens freely, building up a visible balance, but when the user attempts to sell or transfer those tokens back, the contract’s code rejects the transaction, consumes the gas fee, or transfers the tokens to an attacker’s address. Some honeypots are designed to allow purchases through a web interface but block sales through decentralized exchanges, trapping capital.

The critical distinction is that holding a token is passive, while interacting with a token contract is active. Trezor Suite’s security model enforces this boundary strictly: any action that writes to the blockchain—approving spending, transferring tokens, staking, or calling contract functions—requires confirmation on the physical hardware device. This means that even if malicious code is running in the Trezor Suite application itself, the user has a final opportunity to see what is being signed and refuse if the transaction is suspicious. Merely displaying a honeypot token in the wallet does not activate it. The risk begins only when the user attempts to sell, transfer, or interact with the contract.

This is why clicking on an unknown token to view its details is not inherently dangerous. Trezor Suite will fetch information from a blockchain explorer or token database to display the contract address, supply, transaction history, and other metadata. This is read-only data gathering, not an approval or transaction. However, clicking a link embedded within that token listing—such as a “Visit Website” button that redirects to an external site—does carry risk. A phishing site designed to look like a legitimate project website might display a fake wallet interface, request a recovery phrase, or ask for permission to connect a web3 wallet. The safety rule is clear: never enter a recovery phrase, never approve suspicious wallet connections, and never interact with external links unless you have independently verified the destination.

Identifying legitimacy without clicking suspicious links

The first step in evaluating an unknown token is to gather information within Trezor Suite itself without following external links. The contract address is the canonical identifier of an ERC-20 token; two tokens with different contract addresses are different tokens regardless of their names. Users can copy the contract address from Trezor Suite and search it on Etherscan, a decentralized blockchain explorer run by a third party, to see the contract code, transaction history, number of holders, and trading activity. This search uses the immutable on-chain record and does not require trusting the project’s website.

Etherscan displays the total supply, number of token transfers, and whether the contract has been flagged by community members or security researchers. If a contract is marked as a scam or honeypot, the information is visible without needing to click through to a promotional site. For legitimate projects, the token’s contract will typically be verified on Etherscan, meaning the source code is visible and can be reviewed by developers or security auditors. A verified contract is not a guarantee of safety, but it is transparency that scammers rarely provide.

A second check is to verify whether the token appears on reputable token aggregators or exchanges. Tokens listed on major decentralized exchanges like Uniswap, or included in mainstream token lists like the Uniswap default list or CoinGecko’s database, have undergone some level of screening. These platforms do not vet every token exhaustively, but they do exclude the most obvious scams and honeypots. If a token with a professional-sounding name does not appear on any major platform after several months, that is a signal that it may not be legitimate. Conversely, trading volume, liquidity, and a history of consistent updates suggest a more established project.

A third approach is to examine the token holder distribution. Etherscan shows the top 100 holders of any ERC-20 token. If one address holds 99% of the supply and never transfers it, the token is likely designed as a honeypot or abandoned project. If the top holders are known exchanges, liquidity pools, or institutional entities, the distribution is more typical of a real token. Additionally, if a token has been airdropped to millions of addresses but trades on no exchange and has no meaningful activity, it is probable spam without malicious intent—just an unsuccessful promotion.

Why Trezor Suite shows unknown tokens and how to manage the display

Trezor Suite’s commitment to displaying all on-chain balances, including unknown tokens, reflects the security principle of transparency. The wallet does not make assumptions about which tokens are important or legitimate; instead, it shows the user the actual state of their address on the blockchain. This approach prevents a common vulnerability: a wallet that hides low-balance or suspicious tokens might cause a user to overlook a legitimate airdrop, miss an exploit, or fail to notice if an address has been compromised.

In practice, Trezor Suite allows users to hide tokens from the portfolio display without deleting them from the wallet. A user can mark a token as “hidden” or place it in an ignore list, removing it from the dashboard while the balance remains on the blockchain. This preserves the security model—the user controls the display, not the other way around—while reducing visual clutter. Hidden tokens can be unhidden at any time, and the actual tokens remain recoverable as long as the wallet is accessible. This is different from deleting the tokens, which Ethereum users cannot do; tokens can only be transferred out, left to sit unused, or ignored.

The feature is particularly useful when a large airdrop creates hundreds of token entries in a wallet. A user can quickly review each token using the methods described above, mark obvious scams or spam as hidden, and focus on legitimate holdings and transactions. For tokens that may become valuable in the future—such as an airdrop from a project still in early development—leaving the token visible or checking it periodically is reasonable. The choice remains with the user, not with the wallet publisher.

Dusting attacks and address clustering concerns

A dusting attack in the context of token airdrops refers to sending small amounts of a token or coin to many addresses with the intent of clustering those addresses together, possibly to de-anonymize a user or reduce privacy. The theory is that if an attacker can correlate the dust token with other known information—such as a public address, an exchange deposit, or an ip-address—they can map out a user’s wallet activity. On Bitcoin, dusting with small amounts of BTC has been researched as a potential privacy weakness, though its practical effectiveness is limited by transaction fees and blockchain analysis already being quite sophisticated.

On Ethereum, dusting with ERC-20 tokens is less concerning because Ethereum uses account-based accounting (not UTXO-based like Bitcoin), so receiving a token does not require merging addresses or revealing behavioral patterns in the same way. However, a dusting campaign still serves propaganda or signaling purposes: if an attacker sends a token branded with a political message, a scam warning, or identifying information to many addresses, it creates a record that the address received the token. This record is public and immutable.

The defense against such attacks is primarily one of awareness and operational hygiene rather than technical wallet features. Users who value privacy should understand that their addresses are public, that receiving tokens is permissionless, and that the set of tokens held reflects the on-chain history of that address. If privacy is a concern, using separate addresses for different contexts (a receiving address for deposits, a spending address for interactions, an exchange withdrawal address) can reduce linkability. Trezor Suite supports multiple accounts and address derivation, enabling this practice. The tokens themselves are not a privacy leak beyond what already exists on the public blockchain.

Practical security steps for managing token spam in Trezor Suite

The most immediate step is to avoid clicking external links embedded in token displays until you have independently verified the destination and purpose. A link that says “Visit Website” or “Claim Rewards” is particularly suspicious and should not be followed unless you have first confirmed the project’s legitimacy through independent channels. If you are curious about a token, look up its contract address on Etherscan, research the project through reputable news sources or community forums, and verify that any claim-rewards process is active and well-documented before proceeding.

Second, before attempting any transaction involving an unknown token—including a transfer, sale, or approval—use Etherscan or a similar service to review the contract code if available. Look for hidden mint functions, transfer restrictions, or ownership mechanisms that might trap your funds. If the contract is not verified (source code not publicly available), treat it with extreme caution. Many honeypots are designed with hidden functions deliberately kept private.

Third, for any token you plan to sell or transfer, test with a very small amount first if possible. Send a minimal quantity to a separate address or attempt to sell a single token on a decentralized exchange. If the transaction succeeds, the token is likely legitimate. If it fails with a vague error message or if you are unable to perform the action despite having sufficient balance, the token is likely a honeypot and you should not attempt further transactions. Because Trezor Suite requires physical confirmation on the device for any blockchain write, a failed transaction will have cost gas fees but will not have compromised your private keys or exposed them to external parties.

Fourth, use Trezor Suite’s hide or ignore features to reduce clutter and focus on tokens you genuinely care about. Regularly reviewing your token list helps you notice if a new airdrop has arrived and decide whether it merits investigation. the Trezor Suite app supports thousands of coins and tokens, and the portfolio display can become unwieldy if airdrops accumulate; managing this actively preserves usability and reduces the chance of accidentally interacting with a malicious token.

The limits of wallet responsibility and the user’s final authority

Trezor Suite cannot and should not attempt to distinguish between legitimate and malicious tokens at the display stage, because such a determination is inherently subjective and context-dependent. A token that one user considers spam another user may have intentionally received as part of a community or investment strategy. A token flagged as high-risk by one service may be legitimately used by another. By showing all on-chain balances and allowing the user to hide or investigate them, Trezor Suite respects the user’s autonomy while providing the information needed to make informed decisions.

The security model here is explicit: the hardware wallet holds the private keys and will not sign a transaction without physical confirmation, regardless of whether the transaction involves a legitimate token or a scam. The Trezor device itself cannot be compromised by the presence of unknown tokens; those tokens only become a problem if the user actively chooses to interact with them. This design places responsibility on the user while providing strong protections against passive compromise.

Users who feel overwhelmed by the presence of unknown tokens should remember that merely having them in the wallet is not an emergency. Taking time to research, using multiple independent sources to verify legitimacy, and avoiding hasty interactions with suspicious contracts are the appropriate response. Panic-selling into an obvious honeypot or approving a malicious contract in haste causes far more damage than leaving unknown tokens in the wallet indefinitely.