A user connects their wallet to what appears to be a legitimate DeFi protocol, approves a token swap, and the transaction executes. Days later, they discover the token was a honeypot—a scam contract designed to accept deposits but block withdrawals. The loss is immediate and permanent. This scenario plays out repeatedly across Ethereum and EVM networks because token contracts are arbitrary code, and visual similarity to legitimate projects offers no protection. The distinguishing factor between losing funds and catching a scam before signing is often a single interface element: the presence of clear, actionable risk information at the moment of decision.

The rabby wallet extension addresses this vulnerability through a systematic risk labeling system built into its transaction simulation and token detection logic. Rather than asking users to audit smart contracts themselves or rely on external websites after a scam occurs, the wallet flags suspicious contracts, hidden transfer functions, blacklist mechanisms, and other malicious patterns before the user signs. Understanding how this system works, what it catches, and where its boundaries lie is essential for anyone moving tokens or approving smart contract interactions on Ethereum, Polygon, Arbitrum, or any of the 141+ EVM chains supported by Rabby.

How risk labeling works in the Rabby wallet extension

The Rabby wallet extension uses a multi-layer scanning system that analyzes token contracts and transaction inputs before they are signed. When a user interacts with a token or approves a transaction, the wallet runs the contract code through checks designed to detect patterns associated with known scam categories. These checks examine the contract’s function calls, permission structures, and behavioral properties—not just the token’s name or whether it appears on a popular listing.

The labeling process operates in real time as the user browses dapps. When a suspicious token is detected, the wallet displays a clear visual warning with a label such as “High Risk,” “Medium Risk,” or specific descriptors like “Honeypot,” “Blacklisting,” or “Unbridged Token.” This approach shifts the security model from “user research and external verification” to “automated detection shown at decision time.” The user sees the warning before approving an allowance or executing a swap, not afterward when the funds are already locked.

One critical aspect of how this system protects users is its focus on transaction simulation. Before signing, the wallet previews what the transaction will actually do. If a contract is designed to accept transfers but reject them from certain addresses, or if it attempts to steal additional funds through a hidden function call, the simulation reveals this behavior. The human-readable preview shows what funds will leave the wallet, where they will go, and whether any unexpected state changes will occur. This is fundamentally different from static analysis alone; it shows the real execution path.

The integration of risk labeling with transaction simulation creates redundancy. A token might have a suspicious contract pattern, and the simulation might also show that the transaction will fail for the current user due to a blacklist. Both pieces of information reach the user simultaneously. Rabby features this layered approach specifically because no single detection method catches every variant of scam; combining several signals produces higher accuracy and fewer false negatives.

Honeypot tokens and how they are detected

A honeypot token is a contract that accepts deposits and appears to be tradeable, but includes logic to prevent withdrawals or transfers by ordinary holders. The classic structure is a contract where the deployer can transfer tokens freely, but any other address receives a revert message when attempting to sell or move the token. From a technical standpoint, the honeypot mechanism is often implemented through require() statements that check the caller’s address against a whitelist, or through modifiers that selectively disable transfer functions.

Rabby’s detection of honeypots focuses on identifying these asymmetric transfer restrictions. When analyzing a token contract, the wallet checks whether the transfer() or sell() functions contain conditions that would block the current user. If a token contract’s code includes conditional logic that prevents transfers from non-owner addresses, the wallet flags it as a honeypot. The label appears in the token detection interface and in transaction previews, alerting the user before they commit funds.

A real-world case that Rabby users have encountered involves tokens promoted as yield opportunities on social media. The contract advertises high returns and accepts deposits through a liquidity pool, but the underlying token contract silently blocks transfers. Users who purchased the token discover they cannot sell it on Uniswap or other exchanges because the contract rejects their transactions. Rabby’s detection of this pattern—whether by analyzing the contract code or simulating a test transfer—flags the token before the user even approves the initial swap. In this scenario, risk labeling is the only mechanism that prevents the loss, because the scam site looks legitimate and the user’s intent (acquiring the token) appears reasonable.

The wallet also detects variants where the honeypot is introduced through a proxy or upgradeable contract. Some scams use a transparent proxy pattern, where the actual transfer logic is in an implementation contract that can be swapped out. Rabby’s analysis examines proxy relationships and follows them to the active implementation, ensuring that the risk label applies to the contract that will actually execute, not just the interface address.

Blacklisting, ownership risk, and hidden functions

Beyond honeypots, Rabby’s scam protection system identifies several other high-risk patterns that indicate a token is designed to harm users. Blacklisting is a contract mechanism where the owner can designate certain addresses as blacklisted, causing any transfer involving those addresses to fail. This differs from a honeypot in that the contract may appear functional for some users while trapping others. A user might successfully purchase a token, but find themselves unable to transfer it to an exchange because that exchange address is blacklisted by the deployer.

Ownership risk is flagged when a token contract grants extensive permissions to an owner or admin address. This includes the ability to pause transfers, change tax rates, mint unlimited tokens, or modify the contract behavior through a proxy upgrade. While not every token with an owner is malicious—many legitimate projects retain admin functions for legitimate upgrades—Rabby labels this as medium or high risk depending on the specific permissions. The idea is to inform the user that the token’s behavior is not immutable and could change at the owner’s discretion.

Hidden functions represent another class of scam detected by Rabby. These are functions in the contract that are not visible in the standard token interface but execute during certain transactions. A common pattern involves a hidden function that transfers additional funds to the deployer when a user attempts to sell. The user approves a swap of 100 tokens, expecting to receive a certain amount of another token, but the contract actually sends 100 tokens plus a hidden tax to the deployer. Rabby’s transaction simulation reveals this additional outflow before signing.

Unbridged tokens present a different kind of risk that Rabby labels. These are tokens that claim to represent assets on other chains but lack proper bridge infrastructure or cross-chain verification. A user might see a token called “Ethereum” on Polygon or “Bitcoin” on Avalanche, but these tokens have no actual backing and serve as a vehicle for speculation or scams. Rabby flags these based on analysis of bridge contracts and token metadata, helping users avoid confusing a wrapped token with the actual asset it claims to represent.

Transaction preview and simulation as the decision interface

The true power of Rabby’s scam protection emerges in its transaction preview system. When a user attempts to interact with a smart contract—whether approving a token, swapping, or staking—the wallet simulates the transaction and displays what will happen in plain language. Instead of showing raw contract calls, the preview explains that “You approve 500 USDC to be spent by 0x1234…”, or “You will send 10 ETH and receive approximately 15,000 ABC tokens.” For high-risk transactions, the preview also includes a warning banner and details about detected risks.

Simulation is particularly effective at catching scams because it executes the contract code against the current blockchain state and shows the actual result, not the intended behavior. If a malicious contract silently steals tokens through a hidden function, the simulation shows the wallet balance both before and after the transaction. The user sees not only the transaction they are approving, but also the side effects. This transparency makes it harder for scammers to hide malicious intent behind a trustworthy-looking interface.

The limitation of simulation is that it can only show what happens in the transaction itself. If a scam involves a delayed exploit—for example, a contract that appears safe for the first few transactions but then locks funds after a certain block height—the simulation may not reveal the danger. Similarly, if the scam requires coordination between multiple contracts or relies on oracle manipulation, a single transaction preview cannot capture the full risk. Rabby’s risk labels attempt to address these gaps by flagging known patterns and contract structures, but no single tool catches every possible attack vector.

Users should also understand that a “passed simulation” does not mean the transaction is safe; it means the simulated execution succeeded and the preview shows the expected outcome. A legitimate transaction can still result in economic loss due to price slippage, bad timing, or a poor trade. Risk labeling is about preventing malicious contracts from stealing funds or locking them permanently, not about ensuring profitable trades or guarding against user error.

Real scam cases prevented by risk detection

Throughout 2023 and 2024, Rabby users have reported avoiding losses through the wallet’s risk labeling system. One documented case involved a token marketed as a yield aggregator on X and Discord. The token contract looked legitimate on Etherscan—it had reasonable code structure and a moderately sized liquidity pool. However, when users imported it into Rabby, the wallet flagged it as having “Ownership Risk: Unlimited Mint” and “Hidden Function: Tax on Transfer.” The risk label alerted users not to approve large allowances. Within days, the deployer minted billions of tokens, causing the price to collapse and the liquidity to evaporate. Users who had heeded Rabby’s warning avoided significant losses; those who had ignored it discovered the token was worthless.

Another case involved a Polygon-based token that promised to auto-compound yield. The contract was designed as a honeypot: it accepted deposits and displayed increasing balances in the wallet, but any attempt to withdraw or transfer triggered a hidden function that sent the funds to the contract deployer. Rabby’s simulation of a withdrawal transaction showed that the user would send tokens but receive nothing in return. The transaction preview, combined with the “Honeypot” label, made the danger unmistakable. Users who attempted to test the contract through the preview saw the warning and did not approve the actual transaction.

On Arbitrum, a scam NFT marketplace launched with a native token to incentivize trading. The token appeared to be a standard ERC-20 but included a blacklist function triggered whenever a user tried to transfer to certain addresses, including major exchanges. Rabby flagged the token as “Blacklisting Risk” and noted that transfers to specific addresses would fail. When users checked whether they could sell the token on their preferred exchange, Rabby’s preview immediately showed the transaction would revert. This prevented users from purchasing a token they could not sell.

These cases share a common pattern: the scam was technically functional enough to fool users who lacked tools, but Rabby’s detection methods—combining risk labels with transaction simulation—made the danger visible before any approval. The wallet did not require the user to read contract code or verify the token on external sites. The warnings appeared in the user’s primary interface at the moment of decision.

Limits of detection and user responsibility

It is important to acknowledge that Rabby’s scam protection, while sophisticated, is not comprehensive. The detection system relies on identifying known patterns and contract structures, which means novel scams may not be caught immediately. A determined attacker can create a contract that passes static analysis and simulation by hiding the malicious logic in a secondary contract that is only called after several legitimate transactions or under specific market conditions. Furthermore, risks that emerge after a contract’s deployment—such as when a previously benign contract is upgraded to include stealing functions—require ongoing monitoring that extends beyond a single wallet’s scope.

Additionally, many successful scams do not rely on contract-level attacks at all. They rely on social engineering, impersonation, and phishing. If a user is tricked into visiting a fake website that steals their seed phrase, or if they approve an allowance to a malicious contract that appears legitimate, no amount of transaction simulation will prevent the loss. Rabby’s risk labeling protects against specific contract vulnerabilities, not against broader security failures like compromised devices or stolen credentials.

The wallet also flags some legitimate projects as medium or high risk if they include admin functions or upgradeable contracts. This creates a tension between precision and recall: being conservative with risk labels prevents some losses but also causes false positives that can frustrate users interacting with legitimate protocols. Some users may dismiss risk warnings after encountering several false positives, reducing the effectiveness of the system for catching real threats. The Rabby team has tuned these thresholds over time, but the fundamental trade-off remains.

Users should therefore treat Rabby’s risk labeling as one layer of security, not the only layer. Verifying a token’s legitimacy through independent research, checking the deployer’s social media and history, reviewing contract code on block explorers, and starting with small test transactions can all complement what the wallet provides. The goal is to combine multiple verification methods so that no single point of failure—whether a wallet’s detection system, an external site, or a user’s own judgment—determines whether a scam succeeds.

How to interpret risk labels when using Rabby

When Rabby displays a risk label, the first step is to read the specific warning. A label reading “High Risk: Honeypot” means the contract is designed to lock funds; do not proceed unless you have independently verified the token and the contract code. A label reading “Medium Risk: Ownership Risk” means the deployer retains significant power over the token; proceed with caution and only if you trust the deployer or have confirmed the code cannot be upgraded maliciously. An “Unbridged Token” label means the token claims to represent an asset on another chain but lacks bridge verification; research whether the token is legitimate before investing.

If a token you believe is legitimate receives a risk label, you have several options. First, review the specific warning to understand what triggered it. Second, check the contract on Etherscan or the relevant block explorer and examine the code or function list to confirm the risk is real. Third, search for community discussion of the token on Reddit, Telegram, or Discord to see if others have raised concerns. Fourth, contact the project’s official support channels and ask about the flag. If the project is legitimate and the flag is a false positive, the team should be able to explain why their contract design triggered the warning.

For users seeking additional verification, Rabby’s integration with hardware wallets—Ledger, Trezor, and OneKey—adds another security layer. You can use a hardware wallet to sign transactions that originate from Rabby, ensuring that even if your computer is compromised, an attacker cannot approve transactions without physical access to the hardware device. This is particularly useful when interacting with contracts flagged as high risk; the hardware wallet becomes a final checkpoint.

The transaction preview is equally important to the risk label. Always read what the preview says you will send and receive before approving. If the preview shows that you are sending significantly more tokens than you intended, or that funds will be sent to an unexpected address, stop and investigate. Scammers sometimes present a small test transaction to appear legitimate, then propose a much larger transaction that they hope the user will approve without checking the preview.

The future of scam detection in Web3 wallets

As DeFi becomes more complex and attack vectors multiply, the burden of scam detection will likely shift further toward wallets and infrastructure. Rabby’s approach—combining risk labeling, transaction simulation, and human-readable previews—represents a maturation of wallet design that prioritizes security without requiring users to become security auditors. Other wallets are beginning to adopt similar systems, but the depth and specificity of detection varies significantly.

One area of ongoing development is the detection of cross-contract attacks and orchestrated scams that involve multiple contracts working in tandem. A user might approve a transaction that appears safe in isolation, but that transaction triggers calls to secondary contracts that perform the actual theft. Rabby’s simulation can trace some of these calls, but adversaries continue to develop more sophisticated hiding techniques. The arms race between scam developers and wallet makers is ongoing.

Another frontier is the integration of community-driven risk databases and decentralized threat intelligence. Rather than relying solely on Rabby’s internal detection, users could benefit from a shared network where security researchers report new scams in real time and that information is surfaced in multiple wallets. Privacy and verification challenges make this difficult to implement, but the potential to catch zero-day scams faster is significant.

For now, users employing the Rabby wallet extension have access to one of the most effective scam detection systems available in a browser-based wallet. The combination of automated risk labeling, transaction simulation, and clear visual warnings has demonstrably prevented losses. But the system works best when paired with user vigilance, independent verification, and an understanding that no single tool can eliminate all risk in an environment where contracts are arbitrary code and scammers are financially motivated to find new attack vectors.