A DeFi trader or NFT collector using Ethereum and its compatible networks faces a practical problem: the number of legitimate tokens across 141 EVM chains exceeds 10,000, and the number of fraudulent, abandoned, or worthless tokens grows daily. A wallet must either display every token in a user’s wallet—creating visual noise, confusion, and risk—or develop a filtering system that is both permissive enough to show real assets and restrictive enough to prevent scam exposure. Rabby, a non-custodial Web3 wallet developed by DeBank, handles this complexity by combining automatic token detection with multilayered spam and scam protection, keeping portfolio views clean while maintaining access to legitimate but obscure assets.

The challenge is not merely technical. A user may hold an ERC-20 token that is perfectly legitimate but trades on no major exchange, has minimal community visibility, and looks identical on screen to a honeypot or rug-pull variant. Another user might receive an airdrop of a new token minutes after it was deployed, with no established reputation or trading history. The wallet’s token detection system must identify real assets, filter out obvious fraud, and avoid censoring tokens simply because they are unfamiliar. Understanding how Rabby manages this balance—and where the boundaries of protection actually lie—matters for anyone managing multiple assets across multiple chains.

How token detection works across 141 EVM chains

Rabby’s core function is to index and identify tokens held in a connected wallet address, whether stored locally or on a hardware device. When a user adds an account or connects to a dApp, the wallet queries the blockchain to retrieve token balances. Rather than preloading a static list of all tokens across all chains—a task that would be incomplete before completion—Rabby uses dynamic token detection. The system checks the user’s address for token contract interactions, identifies the contract addresses involved, and retrieves metadata such as name, symbol, decimal places, and logo.

This approach scales across a fragmented ecosystem. Ethereum mainnet has thousands of tokens, but so do Polygon, Arbitrum, Optimism, Avalanche, Binance Smart Chain, and dozens of other EVM-compatible networks. A token contract on one chain does not exist on another; a symbol like “USDC” might refer to different contract addresses with different properties on different networks. Rabby must therefore track not just token names but the specific contract address and chain pairing. A user holding USDC on Ethereum, Polygon, and Arbitrum simultaneously is holding three different tokens, each with its own balance and transfer history.

The technical process begins with transaction history. When a user’s address interacts with a token contract—whether sending, receiving, or approving—that contract address is identified. Rabby then queries the contract to extract the ERC-20 standard properties: the token’s name, symbol, decimal places, and total supply. Token detection also relies on external data sources. Services like CoinGecko and specialized token aggregators maintain databases of verified tokens, including pricing information and metadata. By combining on-chain queries with these off-chain datasets, Rabby can display not just that a token exists, but what it is worth, when it last traded, and whether it appears on recognized token lists.

The automatic nature of token detection is what makes Rabby practical for users managing dozens or hundreds of assets. Without it, a user would need to manually add each token’s contract address, symbol, and decimal places—a process that would be both tedious and error-prone. The wallet avoids this friction while accepting that the system must also filter aggressively to prevent displaying every possible token variation, including scams and duplicates.

Distinguishing spam and scam tokens from legitimate assets

Not every token that Rabby can technically detect should be displayed by default. Spam tokens fall into several categories: exact duplicates of well-known tokens using different contract addresses, tokens with manipulated or misleading symbols, tokens designed to trick users into approving transfers, and tokens deployed as part of airdrop fraud or phishing schemes. Scam tokens, a narrower category, are designed with malicious intent—honeypots that allow buying but not selling, contracts with hidden transfer fees that siphon value to creators, or tokens created solely to lure users into approving malicious smart contracts.

Rabby’s scam protection filters operate at multiple levels. The first is blacklist matching: comparing detected tokens against known scam databases maintained by security firms, community contributors, and Rabby itself. If a token’s contract address appears on an established scam list, the wallet will flag it or hide it by default. The second level is heuristic analysis. The wallet examines token properties such as transfer functions, fee structures, and contract logic for red flags. A token that claims to be “USDC” but was deployed yesterday, has no trading history, and is not on any major DEX or exchange is very likely a scam variant. A token whose contract contains functions that prevent transfers to certain addresses or impose per-transaction fees is worth investigating before approval.

The third level is reputation and community data. Rabby integrates with multiple sources to assess whether a token is actively traded, has a meaningful community, and appears on recognized token lists like Uniswap’s default list or CoinGecko’s verified tokens. A brand-new contract with zero trading volume, no exchange listings, and no mention in community channels may be legitimate—it could be a startup’s initial deployment—but the absence of reputation signals should be treated as a warning rather than a recommendation.

Rabby also allows users to manually hide tokens they do not wish to see and to enable or disable automatic spam filtering through settings. This creates a balance: the wallet protects by default without preventing a user from accessing a legitimate token that has not yet been widely recognized. A developer launching a new token on a small chain, an early participant in an airdrop, or someone holding a community token with limited trading activity can still access and manage those assets. The protection system does not deny access; it manages visibility and adds friction to prevent accidental interactions with known dangerous contracts.

The role of token lists and external data sources

Behind Rabby’s token detection capability lie integrated data sources that maintain curated token lists. These lists serve different purposes and have different trust models. The Uniswap default list, for example, is maintained by the Uniswap community and includes tokens that have met certain community and market standards. CoinGecko’s token database is curated by security researchers and includes pricing, market cap, and trading information. Opensea and other NFT platforms maintain lists of verified collections. Rabby consumes these lists to populate its token database, display pricing information, and compare detected tokens against known fraud patterns.

The advantage of this approach is speed and coverage. Rather than Rabby independently verifying 10,000 tokens across 141 chains—an impossible task—the wallet leverages existing community and corporate infrastructure. The disadvantage is dependency: if an external data source includes a scam token or misses an emerging legitimate token, Rabby’s visibility is affected. Token lists are not perfect. They are updated asynchronously, may reflect the preferences of their maintainers, and can lag during rapid market events or new token deployments.

Rabby mitigates this by supporting multiple independent sources and allowing users to add custom token lists. A trader working with a specific protocol or community can configure the wallet to include tokens from that ecosystem’s verified list, ensuring that obscure but legitimate assets appear in the portfolio. Custom token lists can also be shared within teams or communities, creating a distributed approach to token verification rather than centralizing the decision with a single provider.

The transparency of this system is important. Unlike a wallet that silently delists or hides tokens without explanation, Rabby’s token detection can be inspected. A user can view which tokens are hidden, why they might be flagged, and manually override the filtering if desired. This transparency places responsibility on the user to understand what they are holding—a necessary trade-off in a system that refuses to be paternalistic about what is “allowed” in a Web3 wallet.

Practical implications for DeFi traders and NFT collectors

For a DeFi trader managing positions across multiple protocols, token detection and spam filtering directly affect workflow efficiency. A trader monitoring Uniswap, Aave, Curve, and other lending or trading protocols will interact with many tokens. Without robust detection, the portfolio view becomes cluttered with small dust balances, newly airdropped tokens, and test contracts. Rabby’s filtering reduces this noise while preserving the ability to access real assets. When a new governance token or incentive token is airdropped as part of a liquidity mining program, the wallet will detect and display it. The trader can then decide whether to hold, sell, or delegate it without needing to manually add it to their tracking list.

NFT collectors face a parallel challenge with token portfolios. While managing NFT collections, a collector also holds ERC-20 tokens used for gas fees, marketplace interactions, and staking. New tokens from completed transactions, received airdrops, or experimental contracts accumulate. Spam filtering prevents the portfolio from becoming dominated by worthless test tokens or obvious scams, allowing the collector to focus on legitimate holdings and opportunities.

The scam protection aspect is equally practical. A user might receive a token in their wallet that looks like a familiar asset—perhaps labeled “USDC” or “ETH”—but is actually a scam. Rabby’s duplicate detection and reputation filtering will flag this, alerting the user to the mismatch between what the token claims to be and what the blockchain records show. A user might also encounter a malicious link or advertisement promoting a fake token, then try to import or view it. The wallet’s heuristic analysis can prevent accidental approval of dangerous contracts by requiring explicit confirmation and displaying risk warnings.

To get started with these protections, users can download the wallet extension for your browser, configure it for their preferred chains, and customize token detection settings based on their specific use case. The initial setup allows choosing which chains to track, whether to use aggressive spam filtering, and whether to enable or disable specific security features like transaction simulation and address whitelisting.

Transaction simulation and risk labeling as extension of token detection

Token detection is most useful when paired with broader transaction security. Rabby’s transaction simulation feature previews what will happen when a transaction is signed: which tokens will move, where they will go, and what the net result on the user’s portfolio will be. This is particularly important for complex interactions like approving a contract to spend tokens, providing liquidity, or minting an NFT. The simulation shows not just the primary transaction, but secondary effects and potential risks.

Risk labeling is integrated into this process. When a user is about to sign a transaction that involves a newly detected token with low reputation signals, the wallet will flag it. If the transaction attempts to transfer a large percentage of the portfolio or interact with a contract on a scam list, the user receives a warning. These labels are not absolute blocks; they are friction designed to prevent hasty or confused decisions. A user can override the warning and proceed, but only after consciously confirming that they understand what they are authorizing.

This integration matters because token detection by itself cannot prevent all fraud. A user might understand that a token is obscure and choose to interact with it anyway. A new protocol might deploy a legitimate token that has no reputation history yet. The combination of automatic token detection, spam filtering, and transaction simulation creates a defense in depth: the wallet identifies assets, filters obvious fraud, previews what will happen, and asks the user to explicitly confirm risky actions. No single layer is foolproof, but together they raise the bar for accidental damage.

Balancing protection with access in a decentralized ecosystem

The philosophical challenge of token detection in a Web3 wallet is reconciling two competing principles. The first is protection: preventing users from accidentally losing funds to scams, honeypots, or fraudulent tokens. The second is access: ensuring that legitimate tokens, even obscure or new ones, remain available to users who need them. A wallet that errs too far toward protection becomes censorious, preventing access to legitimate assets. A wallet that prioritizes access without filtering becomes a playground for scammers.

Rabby attempts to thread this needle by making filtering a user choice. The default configuration applies reasonable scam protection without blacklisting tokens simply because they are unpopular. Users can tighten the filters if they want maximum protection, or relax them if they are comfortable managing higher risk in exchange for broader asset access. The ability to add custom token lists allows communities, protocols, and teams to define what they consider legitimate for their specific context.

The open-source nature of Rabby contributes to this balance. Because the wallet’s code is publicly auditable, users, developers, and security researchers can examine how token detection works, propose improvements, and verify that the filtering is not secretly censoring assets for non-technical reasons. The transparency also allows the community to identify and address filtering errors—instances where legitimate tokens are incorrectly flagged or scams slip through the detection system.

For users managing portfolios across 141 EVM chains and potentially thousands of tokens, this approach to token detection represents a practical middle ground. It is neither a walled garden that pretends only pre-approved tokens exist, nor a laissez-faire system that displays every contract variant regardless of risk. Instead, it is a system that detects automatically, filters intelligently, explains its decisions, and respects user agency when they choose to override the defaults.

Common scenarios and how token detection responds

Consider a user who receives an airdrop from a newly launched protocol. The token appears in their wallet within minutes of deployment. Rabby’s token detection identifies it automatically—the wallet fetches the contract details from the blockchain and begins displaying the balance. Initial spam filters may apply caution flags because the token is new and has no reputation history yet. However, the token remains visible and accessible. The user can check the protocol’s official website, verify the contract address, and then decide whether to hold or trade the token. Token detection made this possible without manual setup.

Now consider a user who clicks a malicious link promoting “official USDC airdrop” and receives a token in their wallet that claims to be USDC but has a different contract address than the real USDC on that chain. Rabby’s detection system will identify the token, but its scam filters will immediately flag it as a duplicate or fraud variant. The wallet might gray out or hide the token by default, preventing accidental interaction. If the user manually overrides this and attempts to approve the contract, the transaction simulation will show that they are granting transfer permissions to an unrecognized contract, and the wallet will display a risk warning. Multiple layers of protection catch the same basic mistake from different angles.

A third scenario involves a legitimate but obscure token from a community project or startup. Token detection will identify it, but reputation filters might not recognize it. The user will see the token in their portfolio, possibly with a “new” or “unverified” label, but the token remains fully accessible. The wallet is not censoring it; it is simply declining to vouch for it. The user can research independently, use the token if they choose, and adjust their own filtering preferences if they plan to hold similar tokens regularly.