A user connects their wallet to a new DeFi protocol and receives tokens as rewards or liquidity provider compensation. These assets appear nowhere in their portfolio view. The token address exists on the blockchain, but the wallet does not recognize it—either because it is too new, too obscure, or issued by a protocol the wallet’s developers have not yet indexed. This is where automatic token detection becomes critical infrastructure rather than a convenience feature. Rabby Wallet’s approach to identifying and displaying tokens across 141 EVM chains addresses a practical problem: how to surface legitimate assets while filtering out scams, spam, and worthless tokens that clutter a user’s interface and potentially trick them into unsafe transactions.

Token management in a Web3 wallet is not simply a matter of displaying whatever exists at an address. The wallet must distinguish between established tokens with real liquidity, newly deployed assets that may be legitimate, and outright fraudulent contracts designed to steal funds or exploit automated approvals. A non-custodial wallet like Rabby cannot rely on centralized gatekeeping, because that would contradict the principle of user sovereignty. Yet complete permissionlessness creates its own dangers: showing every token address without filtering enables scams that masquerade as legitimate projects. Rabby’s design attempts to balance these tensions through a combination of automatic detection, risk labeling, user whitelisting, and transaction simulation—all without requiring the user to manually add every token they receive.

How automatic token detection works across EVM chains

Rabby Wallet monitors blockchain events across its supported networks to identify tokens added to a user’s address. When a user receives tokens through a transfer, liquidity provision, or protocol reward, Rabby can detect the incoming asset without requiring the user to manually search for or import the token contract. This detection is powered by indexing transfers to the user’s address and cross-referencing token contract addresses against known token metadata. The system tracks ERC-20 transfers, which are the standard for fungible tokens on Ethereum and compatible chains, and can recognize tokens across Polygon, BNB Smart Chain, Arbitrum, Avalanche, and dozens of other EVM-compatible networks.

The detection process relies on two data sources: curated token lists maintained by trusted projects and services, and on-chain analysis of the token contract itself. When a new token arrives, Rabby queries its contract for basic information—the token symbol, decimal places, and total supply—to construct a usable display in the wallet. This metadata is cached locally once retrieved, so repeated interactions do not require constant re-querying of the blockchain. However, the cache must be reliable; displaying incorrect metadata could lead a user to confuse one token for another or to approve a malicious contract thinking it is legitimate.

The architecture also handles tokens that exist on multiple chains. A token symbol like “USDC” appears on Ethereum, Polygon, Avalanche, and other networks, but the actual contract addresses differ. A user receiving “USDC” on Polygon should not see a balance transfer credited to their Ethereum USDC holdings. Rabby maintains chain-specific token registries to prevent this confusion. When a user adds a token manually or when automatic detection triggers, the wallet stores the association with the specific network, ensuring that portfolio calculations remain accurate and transaction previews show the correct asset.

For users who want to download and begin exploring token management immediately, rabby wallet download provides access to the browser extension and mobile application. Once installed, the wallet begins monitoring the user’s addresses across all connected networks, and tokens are detected in real time as they arrive.

Risk assessment and filtering out scams and spam

Automatic detection without filtering would create a new problem: scammers could send fake tokens to large numbers of addresses, cluttering interfaces with worthless assets or creating phishing opportunities. A common scam involves sending a token with a misleading name or symbol—for example, a contract called “USDC Wrapped” or “Ethereum” (when the real token is called “ETH”)—that tricks users into approving it or swapping for it. Rabby addresses this through a combination of token reputation scoring and explicit risk labeling.

The wallet assigns risk categories to tokens based on multiple factors. Established tokens with high trading volume, long deployment history, and recognition on major token lists receive a low-risk classification and display prominently. Tokens that are newly deployed, have low liquidity, or lack external verification receive a higher-risk label or a warning when the user attempts to interact with them. The system does not prevent interaction; it surfaces information that would otherwise require the user to manually investigate the token contract on a block explorer.

Rabby’s scam transaction filtering extends to detecting suspicious operations beyond token transfers. When a user signs a transaction, the wallet simulates its execution and shows a human-readable preview of what will happen: “You will send 10 USDC to address 0x1234…” or “You will approve unlimited spending of your DAI by MaliciousProtocol.sol.” If the simulation detects an unusual operation—such as approving a token to a contract with no known function, or a transfer that would drain an unusual amount—Rabby labels it as suspicious and warns the user before signing.

The filtering logic is also transparent in its limitations. A newly deployed token that is legitimate will sometimes trigger a warning because it lacks reputation history. This is intentional: false positives (warnings on legitimate tokens) are preferable to false negatives (missing a scam). A user who understands the risk can proceed; a user who ignores warnings despite them do so with full awareness of the choice.

Manual token addition and address whitelisting

Despite robust automatic detection, there are cases where a user needs to manually add a token. A token might be so new that it has not yet appeared in any transaction to the user’s address. A user might want to monitor a token balance before receiving it. An older token might be delisted from public token lists due to inactivity, even if it retains real value. In these cases, Rabby allows manual token import by contract address.

Manual import requires the user to provide the token contract address and, if necessary, verify the token metadata. The burden is intentional: by requiring active confirmation rather than defaulting to display, the wallet ensures that the user has made a conscious choice to add the token. This is particularly important for tokens with high scam risk, where an attacker might try to convince a user that a fake token is legitimate. A user who has manually verified the contract address on the official project website, checked the deployer address, and confirmed the symbol and supply is much less likely to fall for a lookalike scam.

Address whitelisting provides another layer of security for users who want to limit which addresses can trigger approvals or transactions. By creating a whitelist of trusted contract addresses and user addresses, a user can configure Rabby to reject or warn about any transaction that does not involve a whitelisted counterparty. This is not a default setting, because it would severely restrict normal DeFi usage; but for a user holding a large balance or managing a shared account, whitelisting can prevent mistakes or reduce the consequences of a compromised signing device.

The whitelisting feature also integrates with transaction simulation. If a user attempts to interact with an address that is not whitelisted, the simulation shows the full preview before signing. The user can review the destination, the amount, and any approvals being requested. Only after understanding what will happen can they proceed or cancel. This design preserves the user’s agency while making careless mistakes more difficult.

Portfolio tracking and token visibility controls

Managing 10,000+ tokens across 141 EVM chains requires more than detection—it requires visibility controls. A user might own a small amount of fifty different tokens and want to focus on the ten that matter most. Rabby provides controls to hide, show, or sort tokens by balance, percentage of portfolio, or recency. Tokens below a certain threshold can be collapsed or excluded from the headline balance, reducing visual clutter without losing the information.

The multi-account portfolio view is essential for users managing multiple wallets or addresses. A single view aggregates balances across accounts, wallets, and networks, allowing a user to see their total exposure to a token without switching between interfaces. This is useful for users who hold assets across hardware wallets, hot wallets, and different browser instances. However, it also requires explicit permission and clear disclosure: the wallet must ask which accounts to include, and it should make clear that aggregating multiple addresses into one view could have privacy implications if that view is shared or observed by another party.

Token detection settings can be customized per network or globally. A user might want to enable automatic detection for Ethereum but disable it for less-familiar chains where they are less likely to receive rewards or transfers. The wallet respects these preferences and does not surface tokens on networks the user has explicitly excluded. This granular control is a Rabby feature that distinguishes it from wallets that either detect everything or require manual management everywhere.

Transaction simulation and human-readable previews

Token management is incomplete without understanding how tokens will behave in transactions. A user might see a token in their wallet, but they do not know what will happen if they approve it for spending or swap it. Transaction simulation bridges that gap by executing the transaction in a local or test environment before the user signs it. Rabby’s implementation shows what will happen to each token balance, what addresses will receive what amounts, and what approvals will be granted.

The human-readable preview is crucial because raw transaction data is opaque to most users. A low-level Ethereum transaction contains encoded function calls, hex-encoded parameters, and contract addresses that convey no obvious meaning. Rabby decodes these and presents them in natural language: “Approve spending of 1000 USDC,” “Swap 10 ETH for 15,000 USDC,” or “Deposit 5 WETH and 10,000 USDC into Uniswap V3.” The user can then verify that the operation matches their intent before signing.

Transaction simulation also catches errors that would otherwise be discovered only after the transaction is broadcast and confirmed. If a user attempts to swap for a token that has insufficient liquidity, the simulation may show a reduced output or failure. If the user has not approved a token for spending, the simulation will indicate that the approval transaction must happen first. These previews prevent wasted gas fees and reduce the likelihood that a user will create a failed transaction due to misunderstanding the operation.

Hardware wallet integration and key security

Token management extends to how tokens are controlled. Rabby supports hardware wallets including Ledger, Trezor, and OneKey, where private keys never leave the device itself. When a user manages a large or valuable token balance, hardware wallet integration provides an additional security boundary: the token cannot be moved without physical confirmation from the hardware device. The wallet interface still shows all 10,000+ tokens and provides full portfolio tracking, but signing transactions requires the connected device.

This integration is transparent from the token perspective. Whether a token is held in a software wallet or a hardware-backed account, Rabby detects and displays it the same way. The difference emerges at the transaction signing stage. A transaction involving a hardware wallet shows a prompt: “Confirm on your Ledger device.” The user must then physically press buttons on the hardware device to approve the transaction. This workflow is slower than a software-only wallet, but it prevents malware or browser extensions from exfiltrating the private key and signing unauthorized transactions.

For users with moderate token holdings, local key storage with device-level encryption offers a middle ground. Rabby stores encrypted private keys locally on the device, protected by a PIN or biometric authentication. The keys are never sent to Rabby’s servers, and the wallet does not collect or store transaction history. This preserves user privacy and control while still providing the speed of local signing. For the highest-value holdings, hardware wallet integration remains the recommended approach.

Future challenges in token proliferation and detection limits

The number of EVM chains and tokens continues to grow. New layer-2 networks, application-specific blockchains, and token deployments occur daily. Rabby’s detection system must scale to handle this proliferation without becoming unreliable or inefficient. As the number of tokens indexed grows, caching metadata locally becomes more practical; downloading gigabytes of token information would be impractical for a mobile wallet or browser extension. The trade-off is that detection latency increases for very new tokens until they appear in updated lists or are added manually.

Scam token volume also increases with adoption. New scam tactics emerge constantly: tokens designed to exploit approval mechanisms, contracts that masquerade as legitimate projects, and phishing campaigns that target specific user cohorts. Rabby’s risk labeling system depends on external data sources and community reporting, which can lag behind sophisticated scams. The wallet can improve detection by adding more data sources, crowdsourcing scam reports, and updating risk algorithms, but the fundamental tension remains: perfect filtering would require centralized gatekeeping, which conflicts with the wallet’s decentralized ethos.

Users who are considering whether to take on managing tokens across multiple networks should understand the tradeoffs. Automatic detection and risk filtering reduce friction, but they cannot guarantee complete safety. A user who receives a token and does not recognize it should investigate before approving or trading it, regardless of what Rabby’s interface shows. Transaction simulation and previews make investigation easier, but they do not replace critical thinking. The wallet is a tool that makes token management safer and more convenient, not a substitute for user responsibility.