Rabby Wallet Extension’s Risk Scanner: How It Detects Malicious Transactions Before You Sign

A user connects their wallet to what appears to be a legitimate decentralized exchange, approves what looks like a standard swap, and within seconds discovers that their entire balance has been drained to an attacker’s address. The transaction was signed, broadcast, and executed before any warning appeared. This scenario repeats thousands of times across Ethereum and EVM chains because most wallet interfaces show only the destination address and a confirmation prompt—not the actual consequences of signing. Rabby Wallet’s pre-transaction risk scanning addresses this specific failure by analyzing contract interactions, approval mechanics, and historical patterns before the user ever commits their signature.

The distinction matters because traditional wallets treat every transaction as equally safe once the user initiates it. A Rabby wallet extension, by contrast, operates on the principle that signing should not happen without explicit visibility into what is actually changing on the blockchain. This includes detecting whether an approval might drain an entire token allowance, whether a transaction targets a known phishing contract, or whether the contract being called behaves differently than its declared interface suggests. Understanding how this risk scanner works—and its boundaries—is essential for any Ethereum or EVM user who wants to participate in DeFi, NFT trading, or token swaps without accidentally authorizing a theft.

How the pre-transaction scanning architecture works

Rabby’s risk scanning operates at the moment of maximum leverage: when the user has already committed to an action but before the transaction is signed and becomes irreversible. The wallet extension intercepts the transaction request, extracts the encoded contract function call, and submits it to a simulation engine that runs the transaction in a local, isolated environment. This simulation does not broadcast anything to the blockchain; it simply executes the code and reports what would change if the transaction were real.

The simulation layer provides several critical outputs. First, it shows the balance changes that would occur—which tokens or NFTs would enter or leave the user’s address, and in what quantities. A swap that claims to exchange 1 ETH for 100 USDC should show exactly that; if the simulation reveals a zero-value transfer to an unknown address, or a balance reduction with no corresponding receipt, that mismatch becomes visible before the signature. Second, the simulation identifies contract function calls embedded in the transaction. A single transaction may call multiple contracts in sequence; the user needs to understand the entire chain.

Third, Rabby cross-references simulation results against threat intelligence databases. These databases include addresses flagged by security researchers as phishing targets, rug-pull contracts, and known exploit vectors. If a transaction targets a contract that has a history of stealing funds, the warning appears before the user signs. Fourth, the wallet checks approval patterns. An approval transaction grants permission to a contract to spend tokens on the user’s behalf. Most users treat approval as a one-time permission, but the actual ERC-20 standard allows a contract to spend an unlimited amount once approved. Rabby flags approvals that request unlimited allowance or that exceed the transaction’s stated need.

This architecture also accounts for the fact that a contract’s actual behavior may diverge from its public interface or declaration. A rabby wallet extension can decode what a contract claims to do—based on its published ABI (Application Binary Interface)—and compare it to what the simulation shows it actually does. If the contract transfers tokens to an address that is not mentioned in the function definition, that discrepancy is highlighted. This detection catches a class of exploits where a contract’s code is deliberately obscured or where the user is connecting to a fake version of a legitimate service.

Detecting approval exploits and token allowance risks

Approvals are among the most dangerous transactions in Ethereum because they create a standing authorization. When a user approves a decentralized exchange contract to trade their USDC, they typically sign one approval that allows the contract to spend a specific amount or an unlimited amount going forward. Many users approve with an unlimited allowance for convenience, assuming the contract is trustworthy. That assumption has proven catastrophic when contracts have been hacked, compromised, or when users accidentally approved a counterfeit contract.

Rabby wallet extension analyzes every approval request by answering three questions before the user signs. First, is the requesting contract known and reputable? The wallet maintains a list of verified contracts for major protocols: Uniswap, Aave, Curve, OpenSea, and others. A known contract receives a green checkmark, while an unknown or suspicious contract receives a warning. Second, what is the allowance amount? If the user is swapping 1 USDC but the approval requests an unlimited allowance, that mismatch is explicitly flagged. Third, has this contract been used before from this address, and was it approved safely last time? This historical context helps detect if a user is re-approving the same contract with an increased limit, or if they are approving a new contract that mimics a legitimate one’s address by a single character.

The wallet also implements a critical defense called approval revision. When a user approves a contract for the first time, or when they wish to increase an existing allowance, Rabby suggests a more restrictive alternative: approving the exact amount needed for the current transaction rather than an unlimited allowance. This shifts the default from maximum convenience to maximum safety. For a 1 USDC swap, the wallet recommends approving exactly 1 USDC (plus a small buffer for slippage or fees). If that user later needs to trade a different amount, they sign a new approval for that new amount. The slight friction—one additional approval step per transaction—is a worthwhile trade-off against the total loss that occurs when a contract goes rogue and drains all approved tokens.

Real-world rug pulls have exploited exactly this pattern. A team launches a token, users approve it for trading, and then the team transfers all liquidity to their own address and disappears. The approval mechanism is not the vulnerability; it is the user’s blindness to what they are actually permitting. By making approval consequences transparent before the signature, the risk scanner converts an asymmetric situation—where only the contract developer knows the true intent—into a symmetrical one where the user must consciously choose to authorize an unrestricted allowance.

Identifying phishing and contract impersonation

Phishing in Web3 is rarely about convincing a user to type their recovery phrase into a fake website anymore. Modern phishing targets the approval workflow itself. An attacker will create a nearly identical clone of Uniswap or OpenSea, purchase similar domain names, or use search engine advertising to promote a fake link. The user arrives at the interface, connects their wallet, and is prompted to approve a token transfer or a contract interaction. From the user’s perspective, everything looks legitimate—the interface, the branding, even the domain name if they do not look carefully. But the contract address being called is controlled by the attacker.

Rabby’s detection addresses this by maintaining a known contract registry and by flagging unknown contracts that are being called for the first time. When a user connects to a dApp and approves a transaction, the wallet checks whether the receiving contract is in its trusted list. If not, it alerts the user that they are about to interact with an unverified contract. This is not a guarantee that the contract is malicious; new legitimate protocols exist constantly. But it shifts the burden: instead of assuming every contract is safe until proven otherwise, users are forced to make a conscious decision to trust an unknown contract.

The phishing detection also uses domain reputation scoring. The domain name in the browser address bar is more visible than the contract address in a transaction, so attackers buy domains that are nearly identical to legitimate ones—uniswap-v3.io instead of uniswap.org, or opensea-trade.com instead of opensea.io. Rabby monitors the domain certificate, the domain registration date, and historical reports of phishing attempts targeting that domain. An obviously new domain requesting approval for a major token transfer receives a prominent warning. Users may still proceed if they believe the site is legitimate, but they cannot claim surprise; they were explicitly warned that the request came from an unusual source.

Impersonation also occurs at the contract level. An attacker deploys a contract that mimics the interface of Uniswap’s router, accepting the same function calls and replicating the same return values, but forwarding user funds to a different address. Rabby detects this by simulating the transaction and comparing the declared output (what the function claims will happen) to the actual output (what the simulation shows actually happens). If a swap is supposed to send 100 USDC to the user but the simulation shows 0 USDC received, that discrepancy is visible before the signature.

Balance change previews and transaction simulation accuracy

The most straightforward protection that a rabby wallet extension provides is the balance change preview: showing the user exactly which tokens will leave their wallet and which will arrive. This feature exists in theory in all modern wallets, but Rabby’s implementation is distinguished by its precision and its refusal to hide edge cases behind a simplified UI. A complex transaction that swaps ETH for USDC, stakes the USDC in a protocol, and receives back a receipt token should show all three balance changes. Many wallets show only the headline swap and hide the staking and receipt token in fine print.

The simulation engine achieves this accuracy by executing the transaction against a forked copy of the Ethereum state at the current block height. This fork is local to the wallet extension; it does not broadcast anything or consume gas. The fork includes the current state of all smart contracts, all user balances, and all existing approvals. When the transaction is simulated, it runs with the same rules, the same contract code, and the same state that it would encounter if actually broadcast. If the simulation succeeds and shows specific balance changes, those changes will occur (assuming the network state does not change significantly between the simulation and the actual broadcast). If the simulation fails—because the contract reverts, because there is insufficient liquidity, or because the user lacks the required tokens—Rabby reports that failure and prevents the signature from being created.

This approach has a critical limitation: the simulation can only see state that is on-chain at the time of checking. If a user is composing a transaction that depends on a future event—a loan that has not yet been repaid, a price that has not yet moved, or a contract that will be upgraded tomorrow—the simulation may show a false positive or false negative. Additionally, slippage tolerance and time-sensitive transactions can create mismatches between the simulation and reality. A swap simulated now might receive a different output if broadcast in five minutes due to price movement. Rabby shows the simulated amount and the slippage tolerance setting, making the risk visible, but it cannot prevent the user from accepting an obsolete quote.

The simulation also assumes the transaction runs in isolation. If multiple transactions are pending in the mempool ahead of the user’s transaction, the state might be different by the time their transaction executes. This phenomenon, called MEV (maximal extractable value), is a known risk in Ethereum but not a detection failure specific to Rabby. The wallet does flag transactions that appear unusually expensive or that are routing to known MEV-extraction contracts, but it cannot prevent MEV extraction entirely—that is a systemic protocol issue rather than a wallet issue.

Limitations and edge cases in risk scanning

Understanding what the risk scanner cannot do is as important as understanding what it can. The most significant limitation is that Rabby cannot detect unknown attack vectors—exploits that have not been seen before and are not in any threat database. A novel contract vulnerability that allows draining of a specific token under specific conditions will not trigger any warning until multiple users have been exploited and the contract address has been blacklisted. Early adopters of new protocols always accept some unknown risk. The scanner reduces the risk of known phishing and known exploits, not the risk of novel attacks.

Second, the scanner depends on accurate contract data. If a contract’s ABI (the description of what functions it offers) is incorrect, the wallet may misinterpret what the contract is doing. Some contracts deliberately obscure their ABI to prevent easy decoding. In these cases, Rabby will flag the transaction as involving an unverified or unclear contract, but it cannot prove the contract is malicious. Legitimate advanced protocols sometimes use obscured ABIs for privacy or performance reasons, meaning a flag does not always indicate a phishing attempt.

Third, the scanner operates at the transaction level, not the user intent level. A transaction that moves $10,000 worth of ETH to an address the user does not recognize might be a deposit to a new exchange, a payment to a service, or a transaction to a hardware wallet address. The scanner cannot know which; it can only flag that the user is sending to an address that has not appeared in their history before. Some false positives are inevitable, and users must develop the judgment to distinguish between a legitimate new transaction and a phishing attempt.

Fourth, social engineering and incentive exploitation remain outside the scanner’s scope. A user who is promised a 1,000% return on a staking protocol and who deliberately ignores risk warnings to pursue that promise cannot be protected by automation. The scanner can warn, but it cannot override a user’s informed decision to accept risk. This is intentional: a wallet that silently blocks transactions it deems too risky would also block legitimate advanced trading and experimental DeFi strategies.

Comparing Rabby’s scanning to other wallet security models

Most Ethereum wallets—MetaMask, WalletConnect, and others—show the destination address and a basic transaction preview but do not run simulations or maintain threat databases. They rely on the user to understand what they are approving. This approach places the entire security burden on the user and has led to billions of dollars in losses from phishing and exploit transactions that looked legitimate at approval time.

Some wallets and browser extensions use simpler blocklisting approaches: they check the destination address against a list of known bad contracts and block the transaction if it matches. This is useful but incomplete. A new phishing contract address will not appear on any list for the first few hours or days while it is actively exploiting users. A blocklist can prevent repeat victimization but not first-time exploitation.

Rabby wallet extension’s approach combines simulation, threat intelligence, approval analysis, and domain reputation checking. This multi-layered approach catches more attacks than any single method. A phishing site might evade blocklists, but if the simulated transaction shows fund loss or unusual transfers, the warning will appear. A new exploit contract might not be on a blocklist, but if it requests an unlimited approval, that will be flagged. The redundancy matters because attackers continuously evolve their techniques, and no single detector is perfect.

The trade-off is complexity. Rabby wallet extension requires more processing power than a simple address-matching wallet, and it occasionally produces false positives when a legitimate contract’s behavior does not match its declared interface. Users must be willing to learn what warnings mean and when they can be safely dismissed. For experienced Ethereum and Web3 users, this complexity is a worthwhile price for better protection. For absolute beginners, the learning curve may be steep enough that a simpler wallet is initially appropriate—though graduating to Rabby as knowledge increases is a sound progression.

Best practices for using the risk scanner effectively

The risk scanner is a safety tool, not an automatic protection. To use it effectively, a user should develop habits that work with the scanner’s capabilities rather than against them. First, never ignore a red warning. If Rabby flags a transaction in red, do not proceed unless you have independently verified that the transaction is legitimate. A red warning indicates that either the contract is known to be dangerous, the transaction will result in unexpected balance changes, or the approval is requesting suspicious permissions. Green and yellow warnings (lower severity) can sometimes be overridden, but red should always prompt a pause and verification.

Second, verify the domain before connecting your wallet. Check the browser address bar carefully; type the URL directly rather than clicking a link in an email, chat, or search result. Attackers can buy domains that are nearly identical to legitimate ones, and a moment of verification can prevent a successful phishing attack. Rabby’s domain reputation checker will warn you, but it is better not to visit a phishing site at all.

Third, reject unlimited approvals by default. When Rabby warns that a contract is requesting unlimited approval, take the hint that the contract is designed for convenience at the expense of safety. If you trust the contract, approve the exact amount you need for the transaction at hand. Future transactions will require new approvals, but that friction is protective.

Fourth, understand balance change previews before signing. Do not sign a transaction whose simulated balance changes you do not understand. If you are swapping 1 USDC for ETH but the preview shows additional transfers or receipt of unrecognized tokens, investigate before signing. The preview is your last moment of visibility; once signed, the transaction is committed.

Fifth, stay informed about known exploits in the protocols you use. Rabby maintains threat databases, but new exploits emerge constantly. Reading security announcements from major protocols, following security researchers on social media, and joining community forums can help you recognize when a warning is relevant to a real risk versus a false positive. The more context you have, the better your judgment will be when the scanner flags something unusual.

The future of pre-transaction risk scanning

As DeFi complexity increases and attack sophistication grows, pre-transaction scanning will likely become a standard expectation rather than a differentiator. The question for wallet developers will be whether they can maintain accuracy while expanding coverage to more EVM chains and more protocols. Rabby already supports Ethereum, Polygon, Arbitrum, Optimism, and other major EVM networks, but each addition requires updating contract databases, integrating new threat feeds, and testing edge cases specific to that chain.

Emerging standards for contract security—such as verified bytecode registries and formal verification proofs—could eventually allow wallets to offer stronger guarantees. If a contract’s code is cryptographically proven safe by external auditors and stored on-chain, scanners could reference that proof rather than relying on heuristics and blacklists. Today’s approach is pragmatic and effective for current attack landscapes; tomorrow’s may offer higher certainty.

The risk scanner is ultimately a tool that shifts the asymmetry between users and attackers. An attacker banking on the user not understanding what they are approving faces a wallet that makes approval consequences explicit. An attacker relying on a new contract address not being on any blocklist faces a simulation engine that checks what actually happens, not just whether the address is flagged. No scanner can prevent all losses, but Rabby wallet security features substantially reduce the surface area of preventable attacks. For users managing significant balances, exploring complex DeFi strategies, or trading NFTs across multiple protocols, that reduction in preventable risk is material.