Rabby Wallet Dust and Spam Token Filtering: How to Hide Unwanted Assets

A user opens their Rabby Wallet and finds dozens of unfamiliar tokens cluttering the asset list—many worth fractions of a cent, others with suspicious names and no associated project. These tokens arrived without explicit permission through airdrop mechanisms, contract interactions, or direct transfers to the wallet address. The clutter obscures legitimate holdings, creates visual confusion during transactions, and raises an immediate security question: did these tokens arrive through a legitimate protocol interaction, a common airdrop campaign, or something more intentional like a scam or reconnaissance mechanism designed to track wallet activity.

The problem is fundamental to how Ethereum and EVM-compatible blockchains work. Any contract can send any token to any address. There is no permission gate, no “accept token” dialog, and no way to prevent an unwanted transfer at the protocol level. Wallet software can only filter what users see after the fact, and filtering choices create their own risks. A feature designed to hide dust tokens can accidentally hide legitimate claims, create false security by removing visible warnings, or encourage users to ignore incoming tokens altogether—a dangerous habit if one of those tokens ever carries actual value or transaction requirements.

Why spam tokens arrive and why blocking them matters

Spam tokens serve several purposes, none of them beneficial to the recipient. The most obvious category is simple clutter—low-value or zero-value tokens sent to large numbers of addresses as part of airdrop campaigns, promotional stunts, or network congestion demonstrations. These impose a minor cost on the sender but create friction for the receiver by requiring additional UI space, slower asset loading, and confusion during wallet operations. Some tokens are sent explicitly to test whether an address is active; receiving one signals that the wallet exists and may be worth targeting with follow-up spam or phishing attempts.

A second category is more deliberately malicious. Fake tokens impersonating legitimate projects—often with similar names or slight spelling variations—are sent to addresses associated with known holders of the real token. When a user sees a token named “USDC” or “USDT” that they did not actively acquire, curiosity or habit may lead them to approve its use in a transaction or check its balance. Some fake tokens are designed to trigger phishing by linking to fraudulent websites; others contain smart contract logic that executes when approved or transferred, potentially draining the user’s wallet through a false contract interaction. This attack vector relies on the fact that receiving a token costs nothing, but interacting with it can be expensive or destructive.

A third category involves reconnaissance and address tagging. Threat actors send tokens to large numbers of addresses, then monitor which ones eventually interact with the token or transfer it to an exchange. This reveals which addresses are active, who controls them, and what their behavior patterns are. Over time, such data can be correlated with on-chain activity, exchange records, or public information to build profiles of wallet holders. Even a useless token becomes a tracking device if the recipient engages with it.

The core security lesson is that ignoring spam is not a realistic strategy. Users must therefore find a way to filter or hide unwanted tokens without creating a false sense of safety or accidentally removing legitimate warnings. Rabby’s approach includes token hiding, risk alerts for suspicious contracts, and transaction simulation—each with limitations that require understanding.

Rabby’s filtering and hiding mechanisms

Rabby allows users to hide tokens at multiple levels. The simplest method is to hide individual tokens directly from the asset list. A user can open a token’s details and select an option to hide it from the main view. This removes it from the visual list without deleting any data; the token remains on the blockchain and can be recovered if the user later changes their preferences or needs to interact with it. Hidden tokens appear in a separate section or can be toggled back into view, providing a recovery path that is important given how often airdrop campaigns suddenly become valuable.

A second layer involves risk detection and warnings. Rabby simulates transactions before signing and flags contracts with suspicious characteristics. A token contract that exhibits red flags—such as unusual permission requirements, balance manipulation logic, or patterns consistent with known attack templates—will trigger a pre-sign alert. This does not automatically hide the token; instead, it warns the user that interaction carries elevated risk. The warning persists even if the token is hiding from the asset list, creating an important checkpoint before approval. A user should never approve a transaction simply to dismiss a warning or restore visibility to an unwanted token.

Some users also employ a different strategy: importing trusted token lists or using wallet software that selectively displays only tokens above a minimum balance threshold. Rabby’s interface can be configured to show or hide tokens based on value, reducing visual clutter without completely removing unwanted assets from view. A token worth $0.0001 may disappear, but a token worth $10 will remain visible even if the user does not recognize it. This balances usability against the risk of completely forgetting about an asset that might eventually matter.

The critical limitation of these mechanisms is that they are UI-level controls. They do not prevent a hidden token from being transferred, do not revoke any permissions already granted to it, and do not protect the user from smart contract logic that executes automatically. If a hidden token contract contains a function that drains balances when a certain condition is met, hiding it from the wallet display will not prevent that drain. The token is still there, still executable, and still dangerous if any approval has been granted to it.

The distinction between hiding and revoking permissions

Hiding a token and revoking permissions to a token are not the same operation, and confusion between them can create security vulnerabilities. Hiding affects visibility in the wallet interface. Revoking permissions affects what a contract is authorized to do with the user’s assets. A user can hide a suspicious token and still have granted it unlimited spending rights over their stablecoin balance, or they can unhide a token and discover that approval was granted during an earlier transaction.

Rabby includes a method to revoke token approvals separately from hiding. Users can navigate to the token’s details, find active approvals or allowances, and explicitly revoke them. This is important for tokens that the user had interacted with before learning they were suspicious or for tokens that arrived with pre-written contract code designed to execute after approval. The revocation process costs gas (a network fee) but permanently removes the authorization, preventing future automated transfers regardless of whether the token is visible in the wallet.

The recommended workflow is therefore: first, hide tokens that serve no purpose and will not be used. Second, separately audit active approvals for any token that exhibits risk flags or was involved in questionable transactions. Third, revoke approvals for tokens the user does not intend to interact with further. Hiding without revoking is cosmetic; revoking without hiding is safer but leaves unwanted visual clutter. Both together provide defense in depth: the token remains blocked from performing actions even if the user accidentally unhides it or encounters it in another context.

An important edge case involves tokens received from legitimate airdrop campaigns or airdrops from projects the user intends to use. Hiding these tokens too quickly can mean missing claim windows, losing value, or forgetting that the tokens exist when suddenly they become relevant. A safer approach is to identify high-risk tokens first—those with known scam associations, malformed contracts, or suspicious permission requests—and hide only those, while leaving ambiguous tokens visible until their legitimacy can be verified.

How spam affects NFT management and collection visibility

The spam problem extends beyond tokens to the NFT wallet feature. Just as unwanted ERC-20 tokens can be sent to any address, unwanted NFTs can be transferred to a wallet without consent. Unlike tokens, NFTs are often designed to be unique or visually distinctive, which makes spam NFTs even more obvious in the interface. A user might see hundreds of identical or near-identical NFT images in their collection, each one a piece of spam generated by an automated airdrop, a phishing attempt, or a scam project.

Rabby NFT support includes the ability to hide or hide entire collections, providing a mechanism similar to token filtering. However, the same risk applies: hiding an NFT does not prevent it from executing code or triggering unwanted transactions if the user ever approves it. Some scam NFTs are designed to appear as popular projects—fake versions of Bored Ape Yacht Club or Pudgy Penguins, for example—and receive clicks or approvals from users who do not pay careful attention.

The NFT discovery process compounds the problem. When Rabby or other wallets automatically load NFT metadata—the image, name, and description associated with an NFT contract—they may inadvertently request data from servers controlled by the scam project. This reveals that the address is active and owns an NFT. Some phishing NFTs intentionally host data on servers that log all requests, creating a list of vulnerable wallets. Other spam NFTs are designed to look broken or visually alarming, triggering concern that encourages users to approve a “fix” transaction that actually grants the scam project permission to move their assets.

Rabby’s pre-sign transaction simulation helps protect against approvals hidden in remedial transactions, but it relies on the user reading the warnings before signing. An NFT that appears broken and triggers a user’s desire to fix it can override caution. The defense is to be suspicious of any request to approve NFT transfers, to use transaction simulation as a mandatory gate rather than an optional review, and to hide obvious spam NFTs quickly rather than allowing them to accumulate and create confusion during later interactions.

The risk of filtering bias and missed opportunities

One unforeseen consequence of aggressive spam filtering is that legitimate but unexpected tokens become invisible by default. A new airdrop campaign or protocol upgrade that sends tokens to historical users can be lost in the whitespace between “received” and “noticed.” If a hidden token later becomes valuable—either because the project launches, the token gains market value, or a claim period opens—the user who hid it immediately may forget it exists. Rabby’s separation of hidden tokens into a discoverable section helps mitigate this, but only if the user periodically reviews it.

A second risk involves the compounding effect of filtering across multiple wallets and interfaces. If Rabby hides tokens below a certain threshold, a hardware wallet or desktop application may display them, creating inconsistency that confuses the user about what they actually own. Worse, a user may believe they have hidden a token in Rabby only to see it in the mobile app or on a block explorer, and then wonder if the hiding actually worked or if data was lost.

The most serious bias comes from over-reliance on reputation lists and automated risk scoring. If Rabby’s warnings are based on a blacklist of known scam contracts or patterns learned from previous attacks, new attacks that deviate slightly from known templates may slip through without warning. A token that is genuinely spam but does not match any known signature will be treated as neutral, while a token from a new or unfamiliar project may be incorrectly flagged as suspicious even if it is legitimate. Users should treat automated warnings as useful input rather than definitive verdicts.

The practical consequence is that filtering mechanisms work best alongside user judgment, not as a replacement for it. Before hiding a token permanently or revoking its approvals, a user should do basic research: check the contract address on a block explorer, verify that it matches the official project website, confirm whether any approvals are actually active, and confirm that the token was not received as part of a legitimate airdrop the user intended to participate in. This takes more time than hitting a “hide all” button, but it prevents the common mistake of hiding something valuable or actively damaging something useful.

Configuring Rabby for different risk tolerances

Different users have different threat models and different tolerance for visual clutter. A user managing a large portfolio across many addresses may hide more tokens to reduce confusion and focus on significant holdings. A power user actively participating in DeFi protocols may hide fewer tokens to catch new opportunities quickly. Rabby works with multiple Chromium browsers, and the wallet’s settings can be customized independently in each browser context, allowing users to maintain different filtering profiles for different purposes.

For conservative users, the configuration should include: hiding all zero-balance tokens, hiding tokens below a value threshold (such as $1), enabling pre-sign transaction simulation as mandatory rather than optional, enabling risk alerts for suspicious contracts, and regularly auditing active approvals. This reduces exposure to phishing approvals while still allowing the user to interact with intended protocols and tokens.

For users managing funds across multiple wallets, hardware wallets, or devices, consistency is more important than minimalism. Hiding tokens on one wallet while they remain visible on another creates cognitive friction and increases the risk of forgetting about significant balances. In these cases, hiding only obviously malicious tokens and relying more on address organization and labeling may be safer than aggressive filtering.

An intermediate approach involves using Rabby’s risk simulation as the primary defense. Rather than hiding tokens preemptively, the user leaves them visible but relies on transaction preview and risk alerts to prevent dangerous interactions. When the user attempts to approve or send an unwanted token, Rabby will flag the transaction and allow them to cancel. This preserves visibility of all assets while still protecting against careless approvals. The trade-off is that the user must actively dismiss or ignore warnings for each unwanted token, which can become tedious if spam accumulates.

Blockchain-level considerations and why protocol change is limited

The root cause of spam tokens is a design choice at the Ethereum protocol level: tokens are contracts, and contracts can transfer assets to any address without permission. No wallet-level filtering can change this fundamental behavior. Some proposals for future blockchain versions have suggested permission layers or recipient authentication, but these would require hard forks or layer-2 architecture changes that are years away from adoption. Until then, filtering remains a wallet responsibility.

This means that NFT wallet features and token management in Rabby and other wallets will always be playing catch-up to new spam techniques. As filtering improves, spammers develop new ways to disguise contracts, exploit transaction interactions, or hide malicious code. A token hiding feature released this year may be circumvented by a new attack template next year. Users should expect that no single filter is permanent and that periodic review of wallet activity will remain necessary.

The most durable defense is behavioral: treat incoming tokens and NFTs with skepticism regardless of how they appear, always use transaction preview before signing, and maintain a clear separation between tokens the user actively holds and uses versus tokens that accumulated passively. Hiding is a convenience tool, not a security boundary. Revoking approvals is a real security action, worth the gas cost if any suspicious tokens have been interacted with.

For users concerned about future attacks, exporting wallet data periodically and reviewing it against block explorers provides a secondary verification method. A user can confirm their actual balance on Etherscan or another block explorer independent of what the wallet interface displays, catching both bugs in wallet filtering and cases where the wallet has been compromised. This is more work than trusting the interface, but for high-value holdings it is worth the effort.