A user opens their Rabby Wallet to check their portfolio and finds dozens of tokens they never purchased, most worth nothing or fractions of a cent. Some bear official-sounding names slightly different from legitimate projects. Others carry explicit warnings of being honeypots—contracts designed to accept deposits but reject withdrawals. This clutter is not an accident; it is the result of address harvesting and mass airdrop spam campaigns that exploit wallet visibility to create the illusion of value or to trick users into approving malicious smart contracts. Managing this noise manually is impractical at scale, especially when a user holds accounts across multiple EVM chains.
Rabby Wallet addresses this problem through a systematic token spam filter that evaluates incoming tokens against multiple heuristics before deciding whether to display them in the user’s portfolio view. Rather than relying on a single blocklist, the wallet applies a layered approach combining on-chain analysis, community reporting, behavioral patterns, and risk scoring. Understanding how this filter works—and its limitations—helps users manage portfolio visibility, recognize which warning signals matter, and make informed decisions about which suspicious tokens warrant investigation versus immediate deletion.
The core problem: Why airdrop spam and honeypots exist
Token spam campaigns exploit the open nature of EVM blockchains. Creating a new ERC-20 token or deploying a contract on Ethereum, Base, Arbitrum, Optimism, Polygon, or BNB Smart Chain requires minimal resources and no permission from any central authority. Once deployed, a contract can call the transfer function to send tokens to thousands of harvested addresses in a single batch transaction. From the attacker’s perspective, the cost is negligible; the reward comes if even a small percentage of recipients interact with the token contract.
The motivations vary. Some spam tokens are pure noise, designed to devalue attention and make users less likely to notice legitimate airdrops in their portfolio. Others are phishing vectors; a user who sees a suspicious token and curiosity-clicks to view details may be directed to a fake exchange, a website requesting wallet approvals, or a contract interaction that steals funds. Honeypot tokens represent a more direct attack: they accept deposits through a buy function, creating the false impression of tradability, then reject all withdrawal attempts. The contract may allow the deployer to extract liquidity while trapping user funds indefinitely. These contracts often appear to be legitimate tokens for popular projects, complete with cloned logos and similar names, amplifying confusion.
A multichain wallet like Rabby increases exposure because a user holding accounts on six chains is six times more likely to receive spam tokens. Each network accumulates its own pile of worthless transfers, and manual review becomes unsustainable. The token management challenge is therefore not about security alone—it is about usability. A portfolio so cluttered with junk that users cannot identify their real holdings is a wallet that fails its primary function, regardless of how secure the keys are.
How Rabby’s heuristic detection works in practice
Rabby applies a multi-layered evaluation when determining whether to display a token. The first layer is contract verification and code analysis. The wallet checks whether a token contract has been verified on block explorers, whether its source code is available for inspection, and whether the code contains common honeypot patterns. Known attack signatures—functions that block transfers under certain conditions, blacklist mechanisms that prevent specific addresses from selling, or redirect functions that send tokens elsewhere—trigger immediate flagging. A contract with these characteristics may still be displayed, but it will be marked as a honeypot rather than hidden entirely, allowing advanced users to investigate if they choose.
The second layer examines token metadata and naming patterns. Tokens that copy the name and symbol of established projects while having different contract addresses are flagged as potential impersonations. Rabby cross-references token names against known legitimate projects and maintains a list of verified token addresses. A token claiming to be USDC but deployed at an unknown address on Polygon, for instance, will be caught by this heuristic because the true USDC address on Polygon is already known and cataloged. The wallet also considers metadata inconsistencies, such as tokens with no name, blank symbols, or decimal values that do not match the stated project.
The third layer incorporates transfer and holder behavior analysis. Tokens that were sent to a massive number of addresses in a single block or within a short time window are characteristic of spray-and-pray campaigns. A token with thousands of holders but no meaningful trading activity, no liquidity pools, or zero volume on decentralized exchanges stands out. Rabby can detect whether a token has ever been traded, whether liquidity exists, and whether the contract shows signs of being actively developed or abandoned. If a token was created yesterday, sent to 5,000 addresses, and has no other activity, the heuristic weight toward spam increases substantially.
The fourth layer is community and reputation data. Rabby integrates reporting systems where users can flag tokens as spam, and it maintains feeds from security services and token databases that track known malicious contracts. This creates a feedback loop: as more users report spam tokens, the filter becomes more aggressive in hiding similar tokens in the future. However, this layer alone is insufficient because new spam campaigns appear constantly, and consensus-based reporting has a lag.
Why the filter sometimes misses tokens and occasionally over-filters
No heuristic system is perfectly calibrated. Some legitimate tokens fail to meet Rabby’s visibility threshold and end up hidden by default. This can happen to newly launched tokens that have not yet accumulated trading volume or holder diversity. A legitimate project that conducts a small, targeted airdrop to a few thousand addresses might be indistinguishable from a spam campaign during the first few hours. If the airdrop does not immediately pair with significant trading activity or if the token contract is not verified early, the wallet may hide it. The advantage is security; the disadvantage is that users must manually unhide or search for legitimate tokens they have received.
Conversely, some malicious tokens pass through the initial filter. A honeypot contract deployed by someone with significant development skill might obfuscate its attack signatures well enough to avoid detection in code analysis. A spam campaign that imitates a legitimate token but uses an address that was never part of the original project deployment might slip past name-matching heuristics if the matching algorithm uses fuzzy rather than strict logic. These gaps are inevitable and become apparent only through real-world observation and continuous filter updates.
The challenge is that each heuristic can be gamed. A token that wants to avoid being flagged as spam can slow down the airdrop distribution, spread transfers across multiple transactions, create fake trading activity, deposit liquidity (even if it is immediately withdrawn later), or create a verified contract with benign-looking code. In response, Rabby’s approach is not to create an impenetrable barrier but to make the cost of circumvention high enough that most attackers resort to other chains or tactics.
Transaction simulation and approval warnings as secondary defenses
Token spam filtering is only one layer of protection. Equally important is Rabby’s transaction simulation feature, which previews the outcome of contract interactions before they are signed. When a user attempts to interact with a suspicious token—perhaps approving it for a decentralized exchange or swapping it—Rabby simulates the transaction and displays what will happen. If the approval would transfer all holdings, if the swap would return zero tokens, or if the transaction would drain the wallet, the preview will show that result.
This is particularly effective against honeypot tokens and phishing contracts because users can see the failure or theft before it occurs. A transaction that appears to swap tokens but actually transfers the user’s USDC to an unknown address will be caught by the simulation. A user who approves a token transfer that will extract their entire Ethereum balance will see a red warning. The simulation does not prevent determined or negligent users from proceeding anyway, but it provides a clear moment to reconsider. Users who use the Rabby browser extension are most likely to encounter these warnings during DeFi interactions, where the stakes are highest.
The wallet also implements human-readable transaction previews. Instead of asking a user to approve opaque bytecode or to trust a contract’s self-reported description, Rabby decodes transactions and explains what the contract interaction will actually do. This removes ambiguity in cases where a token’s interface claims one thing but the contract does another. Over time, users who pay attention to these previews develop intuition for what normal transactions look like versus what appears unusual or suspicious.
Automatic network switching and context-aware filtering
Rabby’s token spam filter is also network-aware. Different EVM chains have different token ecosystems, different levels of spam activity, and different risk profiles. Base, Arbitrum, Optimism, Polygon, and BNB Smart Chain each accumulate different spam campaigns. Some networks are targeted more heavily because they have lower transaction costs, making mass airdrops cheaper to execute. Others have more sophisticated users and fewer engagement attempts.
The wallet adjusts its filtering sensitivity based on the network context. A token on BNB Smart Chain with identical characteristics to one on Ethereum might be filtered more or less aggressively depending on the historical spam patterns observed on each chain. This context-aware approach prevents two problems: over-filtering on networks where spam is less common, and under-filtering on networks where it is rampant. Users who hold assets across multiple chains benefit because Rabby handles the network-specific spam landscape automatically.
Automatic network switching also reduces the likelihood of users sending tokens to the wrong address on the wrong chain. When a user initiates a transaction to a token on Optimism, Rabby automatically switches the wallet’s active network to Optimism before the transaction is signed. This prevents the accidental scenario where a user approves a transaction on Ethereum while intending to interact with an Optimism token, resulting in the transaction failing or interacting with a different contract entirely. Combined with the token filtering, this creates a safety net that catches both intentional attacks and user error.
What users can control: Manual filtering and visibility settings
While Rabby’s automated heuristics handle most spam, users also have manual control. Tokens flagged as spam or honeypots are not deleted; they are hidden from the default portfolio view. Users can unhide individual tokens, mark tokens as spam themselves, or manually hide tokens they recognize but do not want cluttering their view. This granular control is important because it respects user intent while providing defaults that work for most people.
The distinction between hiding and deletion matters for security and recovery. If a token is hidden but remains in the wallet’s data, a user who later discovers it was legitimate can unhide it and access the balance. If a token were deleted, recovering it would require either recreating the token contract on the user’s account or using historical blockchain data. Rabby errs on the side of preserving data while allowing visibility to be customized. Advanced users can also use the NFT wallet functionality and other advanced features to manage their assets more precisely, categorizing holdings by use case or risk level.
Users should periodically review their hidden token list, especially after they interact with new protocols or receive targeted airdrops. Legitimate airdrops may initially be hidden if they do not meet the default visibility threshold. Spotting the difference between a legitimate airdrop that is temporarily hidden and actual spam requires understanding what the user expected to receive. If a user participated in a protocol’s community activity and knows an airdrop was planned, checking the hidden token list is worthwhile. If a token appears with no corresponding action from the user, it is very likely spam.
Limitations and when manual verification is necessary
No automated system can replace user judgment in high-stakes scenarios. A spam filter is most useful for protecting casual users from clutter and low-effort attacks. A determined attacker targeting a specific wallet, or a user who ignores warnings and proceeds with suspicious transactions, can still suffer losses. Rabby’s security features are designed to be helpful and transparent, not to create the false impression of absolute protection.
Users who receive unusual tokens, especially those offering high returns or promising exclusive access to a new project, should verify the claim independently. Checking the token’s contract address on the block explorer, examining its trading history and holder distribution, reviewing the project’s official website and social media, and confirming that the airdrop was actually announced by the project are all steps that take minutes but prevent most fraud. Many sophisticated attacks do not disguise themselves as spam; they masquerade as legitimate opportunities. The filter cannot protect against a user who is deliberately convinced to interact with a malicious contract through social engineering.
The most useful frame is to treat Rabby’s token spam filter as a convenience tool that eliminates background noise, not as a perfect barrier against all attacks. When combined with transaction simulation, human-readable previews, and hardware wallet support, the wallet provides multiple layers of defense. Each layer catches different types of problems. The filter catches spray-and-pray spam and known honeypots. The simulation catches unexpected behaviors in approved contracts. The previews catch confusion about what a transaction will do. Hardware wallet integration isolates the private key from the device where the wallet software runs. Together, these features create a practical security posture that works in real conditions where users are fallible and attackers are persistent.
The future of spam detection and emerging threats
Token spam tactics will continue to evolve. As Rabby’s heuristics become more sophisticated, spammers will invest in more convincing impersonations, longer-term campaigns that build credibility before extracting value, or attacks that target the wallet’s reputation rather than individual users. Some spam campaigns already employ techniques such as creating liquidity pools to mask the number of actual holders, using multiple addresses to distribute tokens gradually rather than instantly, or deploying tokens on newly created blockchains where detection infrastructure does not yet exist.
Future improvements to spam detection will likely involve machine learning models trained on historical spam and legitimate tokens, allowing more nuanced pattern recognition. Integration with broader security infrastructure, such as real-time threat feeds from security companies and decentralized reputation systems, could provide faster updates when new attack patterns emerge. The challenge is maintaining performance on devices where the wallet runs and ensuring that users understand that the filter is improving but not omniscient.
Another frontier is preventing spam at the source through protocol-level changes on EVM networks. Proposals for token transfer fees, reputation-based access controls, or sponsored transaction models could make mass airdrops more expensive or easier to filter. However, these changes require network consensus and often face resistance from users who value permissionlessness. Until such changes exist, wallet-level filtering remains the most practical defense, and Rabby’s approach of layering multiple heuristics represents the current practical standard.
Frequently asked questions
Why does Rabby hide tokens I received but did not ask for?
Rabby’s spam filter evaluates tokens against multiple heuristics including contract code analysis, naming patterns, transfer behavior, and community reports. Tokens that appear to be spam or honeypots are hidden by default to reduce portfolio clutter and protect users from accidental interactions with malicious contracts. Legitimate tokens that are newly launched or have not yet accumulated trading activity may also be hidden until they meet the visibility threshold. You can manually unhide tokens in your wallet settings if you recognize them as legitimate.
Can Rabby’s token filter prevent all scams?
No. The filter catches common spray-and-pray spam campaigns and known honeypots, but determined attackers can create sophisticated impersonations or social engineering schemes that bypass automated detection. Transaction simulation and human-readable previews provide additional layers of defense by showing you what a contract interaction will actually do before you sign it. The most important safeguard is manual verification: check the contract address on the block explorer, confirm the project’s legitimacy through official channels, and use caution with unsolicited offers or high-return promises.
How does Rabby filter tokens across multiple chains?
Rabby maintains network-specific filtering profiles because spam patterns differ across EVM chains like Ethereum, Base, Arbitrum, Optimism, Polygon, and BNB Smart Chain. The wallet adjusts detection sensitivity based on the historical spam activity observed on each network. When you interact with a token on a specific chain, Rabby automatically switches to that network and applies the appropriate filtering rules. This context-aware approach prevents over-filtering on safer networks and under-filtering on networks that experience more spam activity.