Phishing Protection in Rabby: How Balance Change Previews Stop Malicious Transfers

A user receives a link from what appears to be a trusted service and connects their wallet. The interface looks legitimate. A transaction sits ready to sign. Without a preview of what the signature actually approves, the user might authorize a transfer that drains their entire balance to an attacker’s address. This scenario plays out thousands of times daily across Ethereum and other EVM networks, and it remains one of the most profitable attack vectors in cryptocurrency because the signature itself is cryptographically valid—the user did approve it, but they did not understand what they approved.

Rabby Wallet addresses this asymmetry through transaction previews that display expected balance changes before the user signs. Rather than showing only technical transaction data, Rabby simulates the transaction outcome and communicates the result in terms a user can verify: your ETH balance will decrease by 5.2, your USDC will increase by 12,400. That simple comparison between intent and actual transaction effect creates a critical friction point where phishing attacks fail. The mechanism is not absolute protection, but it reframes the signature moment from “approve this hexadecimal string” to “confirm that you expect this specific outcome.”

Why standard wallet UX leaves users vulnerable to signature forgery

Ethereum and EVM-compatible blockchains use cryptographic signatures to authorize transactions, but the signature is attached to encoded transaction data that most users cannot read directly. A standard wallet interface might display a contract address, function selector, and parameters in hexadecimal, trusting that the user will recognize whether they intended to approve a token allowance or transfer their entire portfolio to an unknown address. In practice, very few users decode hex or audit smart contract interactions at that level. Phishing attacks exploit this gap by replicating the visual appearance of a legitimate dApp, presenting a transaction that looks reasonable in isolation, and relying on the user’s time pressure or inattention to pass the signing moment without careful review.

The traditional mitigation strategy has been to educate users about the risks and to encourage them to verify URLs and check transaction details. This advice is correct but insufficient. Users under time pressure, distracted, or simply unfamiliar with blockchain data formats will miss warnings. Additionally, once a signature is broadcast to the network, no amount of user regret can reverse it. The transaction is already valid and the transfer is already executed. Prevention must therefore occur at the pre-sign moment, when the user still has agency to refuse.

Rabby’s approach is to simulate the transaction before the user signs and to display the outcome in terms of asset balance changes. This transforms the cognitive task from “do I recognize this contract function call” to “does this asset movement match what I intended.” The simulation runs the transaction logic against the current blockchain state and reports what will happen if the signature is approved and the transaction is mined. If a phishing site is trying to trick the user into transferring USDC to an attacker’s wallet, the preview will show that USDC is leaving the user’s address. If the user expected a swap that would increase USDC while decreasing ETH, a transaction that only decreases USDC without a corresponding increase will signal an error immediately.

Transaction simulation and the balance change display

Rabby’s pre-sign security checking works by intercepting the transaction before the user presses the final approval button and running a simulation against the latest blockchain state. The simulation executes the transaction logic in a read-only environment, calculating the result without actually broadcasting anything to the network. The wallet then extracts the asset balance changes—how much of each token the user’s address will gain or lose—and displays these changes prominently to the user.

This display includes not just the raw token amounts but also the value context. If a user is about to lose 2 ETH, Rabby can display the USD value equivalent based on current price data. If the transaction involves complex interactions with multiple smart contracts, the preview aggregates the net change across all those interactions and reports the final position change. A user might interact with a liquidity pool contract that simultaneously receives USDC, sends USDT, receives protocol fees in a governance token, and executes a flash loan repayment, but the preview will reduce that complexity to “you will gain 100 USDC, lose 101 USDT, and gain 0.5 ADMIN tokens.”

The simulation is not perfect. It depends on current blockchain state, so rapid price movements, front-running, or network conditions between preview and broadcast could cause the actual outcome to differ from the preview. However, for the overwhelming majority of phishing attacks, the simulation will catch the discrepancy immediately. An attacker directing a user to sign a transaction that transfers the user’s tokens to the attacker’s address cannot hide that balance change in a simulation. The user’s balance in that token will decrease; the attacker’s will increase. That outcome is incompatible with a legitimate swap or approval and should trigger immediate suspicion.

Real attack scenario: The fake airdrop token swap

A phishing attack typically begins with a link shared on social media, Discord, or email, purporting to be from a legitimate protocol or service. The user clicks through and lands on a page that mimics a known dApp interface. The page prompts them to connect their wallet, and once connected, it displays a transaction that claims to be a token swap or governance vote. Without transaction preview, the user sees only technical details or a vague description like “approve contract interaction” and signs based on the premise that they are interacting with a known service.

Suppose the attack targets a user who recently bought a new token listed on a legitimate exchange. The phishing page claims to be that token’s official staking or farming portal. It displays a transaction that appears to call a staking contract and promises high returns. The actual transaction, however, contains hidden logic that transfers the user’s entire wallet balance in multiple token types to the attacker’s address. The signature the user provides is cryptographically valid and authorizes this transfer. The transaction broadcasts and executes within seconds.

With Rabby’s transaction preview, the outcome changes. The user connects their wallet to the phishing site and sees the transaction prompt. Before signing, Rabby simulates the transaction and displays the expected balance changes. The user sees: “You will lose 10 ETH, 5,000 USDC, 20,000 of the farming token, and 0.5 WBTC.” Beneath that, Rabby displays risk alerts because the transaction is calling an unknown or malicious contract. The user realizes that the transaction will drain almost all of their assets, not stake them. They refuse to sign and close the tab. The attack fails before any funds are lost.

Risk alerts and automatic network detection as secondary controls

Balance change previews provide the primary defense because they make the attacker’s intent visible to the user. However, Rabby layers additional controls that reduce the likelihood of an attack reaching the signature stage at all. Automatic network detection prevents a user from accidentally signing a transaction on the wrong blockchain. If a phishing site claims to be Ethereum-mainnet-based but actually switches the user to a different EVM chain, Rabby will warn the user that the network has changed and display which chain is now active. A malicious actor could theoretically use a different chain to execute a similar attack, but the additional friction and visual warning reduce the number of users who will proceed without realizing the change.

Risk alerts flag transactions that interact with contracts outside a curated list of known legitimate addresses. If a transaction is calling a contract that Rabby has not recognized as legitimate, the wallet displays a warning that the interaction is unverified. This is not a guarantee that the contract is malicious—many legitimate, low-profile projects will not be on any pre-approved list—but it signals to the user that this is not a routine swap or approval. Combined with the balance change preview showing an unexpected outcome, the risk alert reinforces the user’s suspicion that something is wrong.

These secondary controls are important because they catch cases where the balance change preview might be ambiguous. A complex transaction involving flash loans, multi-hop swaps, or protocol governance mechanics might produce a balance change that seems reasonable in isolation but is actually the result of manipulated pricing or exploited slippage. Risk alerts and network warnings provide additional friction that encourages the user to pause and reconsider before signing.

How users can maximize this protection when installing and using Rabby

The effectiveness of Rabby’s phishing protections depends entirely on the user obtaining the genuine wallet software and using it consistently. A compromised or counterfeit version of Rabby would undermine all its security features. Users should download Rabby only from the official source at rabby.io and verify that the browser extension is installed from the legitimate marketplace. When considering installing Rabby as a browser extension, users should confirm the publisher and verify the extension ID to ensure they are installing the correct version.

Once Rabby is installed, users should develop the habit of reading every transaction preview before signing, even when interacting with services they trust. A legitimate protocol’s interface might be compromised, or a user might accidentally click a phishing link that appears to be legitimate. The preview is the final checkpoint. If the balance changes shown in the preview do not match the user’s intent, the answer is always to refuse the transaction and investigate further. This habit is more important than memorizing technical details because it provides a reliable rule: every signature should correspond to a previewed outcome that the user can articulate and verify.

Users should also be aware that the preview depends on the wallet’s ability to simulate the transaction, which requires access to accurate blockchain data and current state. If a user is behind a network filter, connecting through a compromised VPN, or accessing through a malicious node, the preview data itself could be manipulated. For high-value transactions or when connecting from unfamiliar networks, users should verify the transaction result on a block explorer after broadcasting, confirming that the balances changed as expected. This post-broadcast check is particularly important when dealing with wrapped tokens, bridge transactions, or cross-chain interactions where the simulation might miss state updates on other chains.

The limits of preview-based phishing defense

Rabby’s balance change previews are a significant improvement over opaque transaction signing, but they are not absolute protection against all attack vectors. An attacker who gains control of the user’s device through malware can potentially intercept or manipulate what the user sees on screen, including the preview data. Similarly, if a user’s browser or operating system is compromised, an attacker might present a fabricated preview or hide the real one while the user signs a malicious transaction. The wallet can only protect against threats that exist at the wallet application layer; threats at the device level require device security practices.

Additionally, complex DeFi transactions might produce balance changes that are technically correct but economically harmful due to price manipulation, sandwich attacks, or slippage that the user did not anticipate. A DEX swap might show that the user will lose 1 ETH and gain a certain amount of a new token, and that preview might be accurate at the moment of signing. However, if the transaction is then pending in the mempool while the token’s price moves dramatically, the user might receive significantly less than the preview suggested. The preview prevents the user from unknowingly signing a transaction that sends their entire balance to the attacker, but it does not protect against unfavorable price discovery or MEV exploitation.

Rabby also cannot protect users who willingly accept unfavorable or malicious transactions. If a user is under duress, coerced by a support scammer who has convinced them to connect their wallet and sign transactions in exchange for promised help, or is simply careless and ignores the preview warnings, the wallet’s security features become irrelevant. The preview alerts the user; it does not prevent a user from deliberately ignoring those alerts and signing anyway. User awareness and skepticism remain the outer layer of defense that no technical feature can replace.

Integration with hardware wallets and MetaMask imports

Rabby’s phishing protection extends to users who store their private keys on hardware wallets or who import wallets from other applications. When a hardware wallet is connected to Rabby, the transaction preview still displays before the user interacts with the hardware wallet’s signing interface. This means the user sees the expected balance changes on their computer screen, can verify that the outcome matches their intent, and only then approves the signing on the hardware device itself. The additional step of approving on a separate device increases friction, but it also reduces the impact of device-level malware that might try to manipulate what the user sees on screen.

For users migrating from MetaMask or another wallet, Rabby allows importing the recovery phrase or private keys directly. This is convenient, but it concentrates access to the user’s funds in the new wallet application. The security benefit is that Rabby’s preview and risk alert features will now protect all transactions from this imported wallet. However, the user should understand that importing a recovery phrase into any application transfers the security properties of that import. If Rabby is installed on an unsafe device, or if a malicious version of Rabby is installed, the imported keys could be compromised regardless of the original wallet’s design.

Toward a standard expectation of transaction transparency

Rabby’s transaction preview feature represents a shift in user interface design for self-custodial wallets. The feature takes technical transaction data and converts it into a format the user can verify without expertise in smart contracts or hexadecimal encoding. This is not a novel cryptographic innovation, but it is a critical usability improvement that changes the economics of certain attacks. Phishing becomes less profitable when every user can see the attacker’s intent reflected in a balance change preview.

The broader implication is that users should expect this standard from any wallet they use. A wallet that presents a transaction without showing the expected balance changes, or that obscures the outcome under layers of technical detail, is forcing the user to sign without informed consent. Over time, as users become accustomed to previews and risk alerts, wallets without these features will become harder to justify. The attack surface of Ethereum and EVM chains will not disappear, but moving the verification step from post-broadcast (where nothing can be undone) to pre-sign (where the user can refuse) is a material reduction in risk.