Understanding Balance Change Previews in Rabby: See Before You Sign

A user initiates what appears to be a straightforward token swap on a decentralized exchange. The interface displays an exchange rate, a destination amount, and a confirmation button. Without seeing the actual impact on their wallet balance until after signing, they approve the transaction. Slippage consumes 15 percent of the expected output. The trade executes, but the result is far worse than anticipated. This scenario repeats across thousands of DeFi transactions daily because most wallet interfaces show quoted rates and interface numbers rather than the concrete change to a user’s actual holdings.

Rabby Wallet addresses this friction through balance change previews, a feature that calculates and displays the precise before-and-after state of a user’s assets before any transaction is signed. Rather than trusting a dApp’s displayed estimate or a market maker’s quoted rate, users can see exactly which tokens will decrease, by how much, which will increase, and whether the exchange arithmetic makes sense. This mechanism operates consistently across supported EVM chains, whether a user is interacting with Uniswap, Curve, a lending protocol, or any other on-chain application. The feature integrates directly into Rabby Wallet’s transaction signing flow, making it possible to catch dangerous slippage, unexpected token transfers, or contract interactions that would deplete holdings more severely than intended.

How balance change previews work in Rabby Wallet

The balance change preview mechanism operates at the transaction simulation stage, before any data reaches the blockchain. When a user connects to a dApp and constructs a transaction—whether a swap, liquidity provision, token approval, or contract call—Rabby intercepts the signing request and performs a static analysis. This analysis simulates the transaction execution against the current blockchain state, calculating the precise token balance modifications that would result if the transaction were confirmed.

The preview is not a guess based on interface estimates or dApp-supplied numbers. It is a deterministic calculation derived from the actual smart contract logic and the user’s current token holdings. If a user is swapping 10 USDC for ETH on Uniswap, the preview calculates the exact ETH output based on the liquidity pool state, routing, and fees at that moment. If the user is depositing collateral into a lending protocol, the preview shows the reduction in the deposited token and the increase in the derivative token received.

This simulation capability requires that Rabby Wallet can access the blockchain state and execute contract bytecode without modifying it. Ethereum and EVM-compatible chains provide this through the eth_call RPC method, which allows read-only execution of contract functions. The wallet therefore does not depend on dApp-supplied data or third-party price feeds for this calculation. It derives the result directly from the protocol, making the preview applicable across any EVM network—Ethereum mainnet, Arbitrum, Optimism, Polygon, Avalanche, or any other chain where Rabby operates.

The preview is also dynamic. If market conditions change or a user modifies the transaction parameters before signing, the preview recalculates. This responsiveness is crucial because liquidity pools shift constantly. A swap quote that was accurate thirty seconds ago may now result in greater slippage. A balance change preview that updates in real time allows a user to decide whether to proceed, adjust the amount, set a stricter slippage tolerance, or wait for better conditions.

Why balance previews prevent high-slippage mistakes

Slippage occurs because decentralized exchanges match trades against liquidity pools that are continuously depleted and refilled. A large swap relative to a pool’s size will move the price paid per unit of the output token. The quoted rate shown by a dApp interface assumes a specific pool state at a specific moment. By the time the transaction is mined—which could be seconds or minutes later—that state has changed, and the actual output is lower. If network congestion is high or a user sets a low gas price, the delay between quote and execution widens, and slippage deepens.

A user relying only on the dApp’s interface quote has limited visibility into this risk. They see an expected output of, say, 1.95 ETH for their 10,000 USDC. They sign the transaction and hope it executes at that rate. If slippage is severe, they might receive only 1.65 ETH instead—a 15 percent loss. The dApp does not flag this as unusual; it is simply the market result. However, Rabby’s balance change preview displays the actual before-and-after state. The user sees 10,000 USDC decrease and only 1.65 ETH increase. Confronted with the concrete outcome, they can refuse to sign, adjust the swap size to reduce price impact, or use a different liquidity source.

This prevention mechanism is not a guarantee against slippage; slippage is inherent to decentralized liquidity. Rather, it is a visibility mechanism that forces the user to acknowledge the true cost before signing. The preview also reveals whether a dApp’s quoted rate was realistic or wildly optimistic. If a dApp quotes 1.95 ETH but the preview shows 1.65 ETH available, the gap is visible and measurable. The user can then decide whether to proceed or switch to a different protocol where the price impact is lower.

Balance change previews are equally valuable for non-swap interactions. If a user is depositing tokens into a liquidity pool and the preview shows only 0.8 of the expected LP tokens minted, it signals that slippage or pool conditions are unfavorable. If a user is borrowing against collateral and the preview shows a lower borrowing power than expected, it prompts reconsideration before signing. The preview therefore extends beyond swaps to any transaction that affects token balances.

Rabby Wallet transaction signing and risk detection integration

Balance change previews do not exist in isolation within Rabby. They integrate with the wallet’s broader transaction risk scanning and approval flow. When a user attempts to sign a transaction, Rabby Wallet’s risk scanning engine evaluates multiple dimensions: whether the contract being called is a known scam, whether the transaction requests an unusually high token approval, whether the balance changes make sense for the stated action, and whether there are red flags in the contract bytecode or interaction pattern.

The balance change preview contributes to this risk assessment by making the outcome explicit. If a user intends to swap 1 token for another but the preview shows a third, unexpected token being transferred, Rabby can flag this as suspicious. If the preview shows that a token approval is being requested with unlimited allowance and a swap is occurring in the same transaction, Rabby can highlight that as a potential vulnerability. The preview therefore acts as both a transparency tool and an input to the risk detection system.

This integration is particularly important for complex interactions, such as flash loan attacks, sandwich transactions, or disguised approvals. A user might connect to what appears to be a legitimate dApp, but the actual transaction being signed approves the dApp’s contract to transfer all tokens from their wallet. The risk scanner combined with balance change preview will reveal that the transaction requests unlimited approval without a corresponding token input, a dangerous asymmetry.

How to use Rabby Wallet effectively therefore requires understanding that the balance preview and risk scanner work together. A transaction that passes the risk check should still be reviewed through its balance change preview. Conversely, a transaction flagged as suspicious should not be approved simply because the balance preview looks reasonable on one dimension. The two tools are complementary: the preview shows what will happen, and the risk scanner evaluates whether that outcome is appropriate for the stated action.

Platform consistency: browser extension, mobile, and desktop

Rabby Wallet operates across multiple platforms—Chrome, Brave, and Microsoft Edge as browser extensions; Android and iPhone for mobile; and Windows and macOS for desktop. A critical design question is whether balance change previews function identically across these interfaces. The answer is substantially yes, with platform-specific constraints.

On the browser extension, balance previews display inline during the transaction approval flow. A user clicks “Sign” on a dApp, the extension opens, and the preview is shown prominently alongside risk warnings. The extension has direct access to the user’s RPC provider configuration and can call eth_call to simulate the transaction. Mobile apps face a similar architecture but with the added complexity of smaller screens and different interaction patterns. The preview must be readable and actionable on a phone display, which Rabby addresses by prioritizing the most critical balance changes and offering expanded views for complex transactions.

Desktop applications provide the most screen real estate and can display comprehensive previews with detailed token-by-token breakdowns. However, all platforms share the same underlying simulation engine, so the numerical accuracy of the preview is consistent. The differences are primarily in presentation and user interaction rather than the underlying calculations.

One platform-specific consideration is connectivity. A browser extension has immediate access to the user’s configured RPC endpoint, but a mobile app must connect to a remote node. If that node is slow or unavailable, the preview may be delayed or fail to load. Rabby handles this gracefully by allowing the user to proceed with reduced information rather than blocking the transaction indefinitely. However, this means that on slower connections, the user may have less time to review the preview before signing. For high-value transactions, using the desktop or browser extension on a fast connection is advisable.

Common scenarios where balance previews reveal critical differences

A user intends to swap stETH for ETH on a decentralized exchange to capture an arbitrage opportunity between Lido’s derivative and the underlying asset. The dApp quotes a 0.5 percent slippage tolerance and shows an expected output of 1.99 ETH for 2.00 stETH. The user approves. Without a balance preview, they would sign and discover after execution that the actual slippage was 8 percent, yielding only 1.84 ETH. With Rabby Wallet’s balance preview visible before signing, they see the 1.84 ETH figure and can refuse to sign, adjust the trade, or wait for better liquidity.

Another scenario involves a complex protocol interaction. A user connects to a platform that promises yield farming and sees an interface showing “Deposit 100 USDC, earn 45 percent APY.” The transaction approval requests an unlimited token approval. The balance change preview reveals that signing will immediately transfer 100 USDC out and return approximately 98 USDC in a wrapped token, with no corresponding yield token received. This is a red flag: the transaction does not match the promised action. The preview, combined with the risk scanner, alerts the user before funds are lost.

A third scenario involves bridging assets across chains. A user bridges 10 ETH from Ethereum to Arbitrum using a third-party bridge. The dApp quotes a 0.1 ETH fee. The balance preview shows a reduction of exactly 10.1 ETH on Ethereum and an expected increase of 9.9 ETH on Arbitrum. The arithmetic is clear and verifiable. However, if the preview showed only 8.5 ETH arriving on Arbitrum, the user would see the bridge’s total cost upfront and decide whether it is acceptable. This visibility prevents the common complaint of “I sent 10 ETH and only received 8 ETH” without understanding why.

Mobile users face an additional complication: they may be using a hot wallet with frequent transactions and smaller screens. Balance previews become even more critical in this context because the user has less time to review dApp interfaces and is more prone to approval fatigue. An explicit, unavoidable preview that shows the concrete outcome before signing reduces the risk of accidental approvals on a phone.

How to use Rabby Wallet for maximum preview visibility

To benefit fully from balance change previews, users should first ensure they have downloaded Rabby from a trusted source. A rabby wallet download from the official rabby.io domain or from verified app stores (Google Play for Android, Apple App Store for iPhone) guarantees that the extension or app is genuine. Counterfeit extensions exist that mimic Rabby’s interface but steal private keys or approvals. Always verify the source before installing.

Once installed, a user should configure their RPC provider carefully. If Rabby is using a public or slow RPC, balance preview calculations may lag or fail. For frequent traders, configuring a dedicated or higher-priority endpoint ensures that simulations are fast and accurate. This configuration is available in the wallet’s settings on all platforms.

During transaction approval, users should make it a habit to review the balance change preview before reading any other information. The preview is the ground truth; everything else—dApp interface quotes, risk warnings, or assumed outcomes—should be validated against it. If the preview shows balance changes that do not match the intended action, the transaction should not be signed, regardless of how legitimate the dApp appears.

For transactions involving multiple tokens or complex contract interactions, expanding the preview to see every balance change is important. Some dApps construct transactions that include hidden transfers or approvals. A full preview expansion reveals these. If the preview is truncated or difficult to read on a mobile device, switching to the desktop version for that particular transaction is a reasonable precaution for high-value actions.

Finally, users should recognize that balance change previews are a tool for informed decision-making, not an automated safety guarantee. A preview that shows sensible balance changes does not mean the underlying protocol is secure or that the transaction will actually succeed. Network congestion, contract bugs, or changed conditions between preview and execution can still produce unexpected results. The preview is most valuable as a real-time check that prevents obvious mistakes and makes the transaction’s implications visible before commitment.

The broader context of self-custody and transaction transparency

Balance change previews are one component of Rabby Wallet’s design philosophy: self-custody with transparency. As a self-custody wallet, Rabby places full responsibility for key management and transaction approval on the user. There is no company holding the recovery phrase or approving transactions on the user’s behalf. This design maximizes security against platform compromise but creates obligation: the user must understand what they are signing.

Balance change previews reduce the friction between self-custody and understanding. Without them, users would need to inspect contract code, read transaction calldata, or use external simulation tools to understand the outcome. With previews built into the wallet, the information is immediate and accessible. This narrows the gap between what a user intends and what the transaction actually does.

However, previews cannot fully eliminate the inherent risks of on-chain interaction. A user could see a preview showing a sensible balance change, sign the transaction, and then discover that market conditions shifted in the intervening seconds, resulting in worse execution. A preview cannot protect against timing attacks or front-running, in which a different transaction is mined before the user’s, changing the blockchain state and altering the outcome. These risks are structural to blockchains and cannot be solved by wallet design alone.

The role of balance previews is therefore to make visible what can be made visible, and to prevent mistakes that are caused by hidden information or unclear interfaces. In that narrower but crucial domain, they are effective. For users who make it a habit to review the preview before signing, the risk of accidental high-slippage trades, unintended approvals, or transaction outcomes that dramatically differ from intention is substantially reduced.