A user approves a token swap on Uniswap, confident in the quoted rate of 100 USDC per token. The transaction lands in the mempool. Within seconds, a bot observes the pending trade, executes a larger purchase of the same token to drive the price upward, then places the user’s transaction behind it. After the user’s swap executes at a worse rate, the bot sells its position at the higher price it engineered. The user received fewer tokens than expected. This is a sandwich attack, and it costs Ethereum users millions annually. The difference between spotting it before signing and discovering it after confirmation can be the difference between prevention and loss.

The Rabby wallet extension addresses this vulnerability through transaction simulation and balance change preview—features that render the expected outcome of a transaction before the user broadcasts it to the network. Unlike wallets that show only gas estimates and function calls, Rabby simulates the actual state change: the exact amount of tokens received, the new wallet balance, slippage realized, and whether the transaction would revert or succeed under current network conditions. This capability transforms sandwich detection from a post-transaction analysis into a pre-signing verification step, giving users a practical window to compare simulated outcomes against their intentions.

How transaction simulation reveals mempool manipulation

When a user initiates a swap or complex DeFi interaction, the transaction must be validated by the network before execution. The mempool is the holding area where pending transactions wait for miners or validators to include them in a block. During this waiting period, the transaction details—the token amounts, slippage tolerance, and recipient address—are visible to bots and other observers. A sandwich attack exploits this visibility by placing transactions before and after the target transaction to manipulate prices or extract value.

Rabby’s transaction simulation works by running the transaction through a local copy of the blockchain state without broadcasting it. The wallet calls the smart contract methods that would be executed, calculates the exact outputs based on current prices and liquidity, and displays the result to the user before they approve. This is fundamentally different from showing a quoted rate or a theoretical maximum slippage. The simulation reflects real-time conditions: if the price has moved since the quote was generated, if liquidity has shifted, or if front-runners have already begun positioning, the preview will show a different outcome than the original estimate.

The critical detail is that the simulation occurs on the current blockchain state, not on a prediction of what the state will be when the transaction eventually lands. If a sandwich attack is already in flight or if a bot’s transaction has already changed the price, the user sees that reflected outcome in the preview. If the expected return falls below the user’s threshold—say, the swap would return 95 tokens instead of the 100 originally quoted—they can cancel before signing rather than broadcasting a transaction they would reject if they knew the real cost.

This preventive power depends on the user understanding what the preview represents. The balance change shown is not a guarantee; it is a forecast based on conditions at the moment the simulation ran. Between simulation and broadcast, prices can move further, additional transactions can land, or network congestion can delay confirmation. What the preview does guarantee is that if those conditions do not change, the outcome will match what was shown. For users evaluating whether to proceed, that clarity is far more useful than an approximate rate or a vague “slippage may occur” warning.

The role of pre-sign security checking in DeFi wallet protection

Pre-sign security checking is the process of validating a transaction before the user approves it—examining the smart contract being called, the parameters being passed, and the state changes being requested. A traditional DeFi wallet extension might show a user a raw contract call: “Call 0x1111… with data 0xabcd…” That tells the user almost nothing about what will actually happen. Rabby’s security checking layer decodes that call, displays what the contract will do in plain language, and compares it against known attack patterns.

For a token approval, this means showing the exact amount being approved, which spender address receives the approval, and whether the amount is unlimited or capped. Many exploits begin with a user approving an arbitrary amount to a malicious or compromised contract, then the attacker drains the entire wallet. Rabby warns if an approval is unlimited or suspiciously large, and simulates what happens if that approval is used. For swaps, it displays the input and output tokens, the ratio being offered, and whether the transaction would fail if executed.

The Rabby wallet extension also checks against known malicious contracts and unusual transaction patterns. If a user is about to call a contract that has been flagged as a scam or phishing vector, or if the transaction requests access to tokens or assets the user did not intend to expose, Rabby surfaces that risk. This is not foolproof—new scams are created constantly, and sophisticated attacks can masquerade as legitimate interactions—but it closes the most common vulnerability: users approving transactions without understanding what they approve.

The combination of transaction simulation and pre-sign checking creates a cascading verification. First, the security check decodes the contract call and alerts the user to suspicious patterns. Second, the simulation shows what the transaction would actually do to the user’s balances. Third, the user compares the simulated outcome against their intention. Only if all three elements align should the user sign. This workflow is not instantaneous—simulation takes a few seconds—but the time cost is negligible compared to the cost of recovering from a sandwich attack or an approval exploit.

Why balance change preview prevents more losses than slippage warnings

Conventional slippage protection works by setting a threshold: “execute the swap if I receive at least 95 tokens; reject if I would receive fewer.” This is useful as a last line of defense, but it does not help the user decide whether to approve the transaction in the first place. By the time slippage is calculated, the transaction is already broadcast and committed to the network. If the realized slippage is unacceptable, the user has already paid gas fees and exposed themselves to front-runners.

Rabby’s balance change preview shifts the decision point earlier in the process. The user sees the expected outcome—”you will send 1 ETH and receive 2,800 USDC”—and can compare it against the quoted rate before committing. If the expected outcome is significantly worse than the original quote, the user can cancel. If they accept the outcome, they then set a slippage threshold that matches the preview, ensuring that if conditions change between preview and execution, the transaction will revert rather than execute at a worse rate.

The practical difference is substantial. In a traditional flow, a user quotes a swap at noon, approves it at 12:05, and the transaction executes at 12:07 after waiting in the mempool. By that time, the market may have moved, other transactions may have filled the liquidity pool, or a sandwich attack may have already adjusted the price. The user has no information about these changes until after paying gas and potentially losing value. With Rabby’s preview, the user sees the current state before approving and can refresh the preview if they wait longer than expected before signing.

This feature is particularly valuable during high volatility or congestion. When gas prices spike and transaction confirmation times extend, many users face a choice between approving an older quote or waiting and re-quoting. Rabby lets users refresh the preview at any point before signing, showing them the current expected outcome without committing to any action. Users can then decide whether conditions have changed enough to warrant canceling and re-trying the transaction at a different time.

Identifying real sandwich attacks versus normal slippage

Not every transaction that receives fewer tokens than expected is a sandwich attack. Normal slippage occurs when market prices move between the time a user generates a quote and the time their transaction executes. If the user quotes a swap during low liquidity and waits several minutes before signing, the price may have moved naturally based on other market activity. The user would see fewer tokens in the preview than in the original quote, but that is not an attack—it is market movement.

A sandwich attack specifically involves a bot or attacker placing transactions to manipulate the price to their advantage and the user’s loss. The attack is successful only if: the attacker executes a large purchase before the user’s transaction (driving the price up), the user’s transaction executes at that worse price, and the attacker sells their position after the user’s transaction (capturing the profit). If Rabby’s preview shows that the swap would return significantly fewer tokens than expected, it could be due to natural price movement, a sandwich in progress, or changed liquidity conditions.

The distinction matters because the user’s response differs. If slippage is natural, refreshing the preview or adjusting the transaction size may help. If a sandwich is in progress, waiting may make it worse, because the attacker’s purchase is already pushing the price up and will continue to occupy the mempool. The practical signal is to look for sudden, unexplained changes in the preview between refreshes. If the expected output drops sharply without a corresponding change in market conditions—no other large trades visible on-chain, no major price movement in other markets—a sandwich may be occurring. Rabby cannot automatically distinguish between these cases, but the detailed preview gives users information to make that judgment.

Users can also monitor the mempool directly using tools like Etherscan or MEV-Inspect to see if large transactions related to the same token are pending. This is not a feature of Rabby itself, but savvy users may cross-reference the preview against mempool activity to confirm whether a sandwich is underway. The key insight is that Rabby’s preview is a signal to check—not a final answer about whether you are being attacked, but specific enough information to warrant investigation.

Practical workflow for confirming a transaction is safe to sign

Before signing any DeFi transaction through the Rabby wallet extension, a user should follow a sequence of checks. First, confirm the wallet address shown is the correct one if multiple wallets are connected. Second, review the pre-sign security warnings: are there approval flags, suspicious contract calls, or recognized scams? Third, examine the transaction preview: does the simulated outcome match your intention? If you expected to receive 2,800 USDC for 1 ETH and the preview shows 2,750 USDC, is that acceptable slippage or a sign that conditions have changed?

Fourth, check the slippage tolerance. If Rabby is showing 2,750 USDC received and you set a 2% slippage tolerance (2,744 USDC minimum), you are protected for normal market movement but exposed if conditions shift further. Fifth, if you have time and conditions are volatile, refresh the preview once or twice before signing. This takes a few extra seconds but shows whether the outcome is stable or deteriorating. Sixth, only then sign the transaction. After signing, the transaction is broadcast but not yet executed; users can still replace or cancel it using techniques like replacing the nonce or submitting a higher-priority transaction, though these carry their own gas costs and risks.

The entire workflow should take less than a minute for a straightforward swap. For complex interactions—supplying collateral to a lending protocol, executing a multi-step arbitrage, or interacting with a new or experimental contract—take additional time to review the contract calls and understand what permissions you are granting. Rabby’s interface is designed to be fast, but speed should not eliminate carefulness. If you do not understand what a transaction will do, not approving it is the correct choice.

Limitations of simulation and the role of blockchain finality

Rabby’s transaction simulation is powerful, but it has a fundamental boundary: it reflects the state of the blockchain at the moment the simulation runs. Once a transaction is broadcast and included in a block, it becomes subject to blockchain finality—the network’s consensus process. On Ethereum, finality takes a number of blocks; until then, reorganizations are theoretically possible, though extremely unlikely. Even more relevant for sandwich attacks is the fact that MEV (maximal extractable value) can manifest in ways that even a perfect simulation cannot prevent, because MEV exploits ordering itself, not just the execution of individual transactions.

For example, if a user approves a swap with a 1% slippage tolerance and the preview shows acceptable output, but a sandwich attack is about to execute at the exact moment the user signs, the user’s transaction may land in a block after the attacker’s purchase. The simulation cannot predict the exact block ordering because it does not have access to miners’ private information about what other transactions they are including. What the simulation does prevent is users approving transactions without seeing the current market conditions and the expected outcome.

The practical implication is that Rabby’s preview is a necessary but not sufficient defense against sandwich attacks. It prevents the most common vulnerability—users blindly approving transactions without understanding the cost—but it does not eliminate MEV entirely. For critical transactions, users should also consider private mempools or MEV-protection services that bundle transactions in ways that hide them from public observation until execution. These are offered by protocols like MEV-Blocker or MEV-Hide on certain networks; not every transaction requires them, but high-value swaps may warrant the additional protection and cost.

Additionally, the preview depends on the state of the blockchain being accurately reflected. If the node that Rabby queries is behind or unreliable, the simulation may show an outdated state. Users should ensure they are connected to a reputable RPC endpoint, which Rabby provides by default but which users can customize. A malicious or slow RPC could return incorrect state, leading to a preview that does not match reality when the transaction executes. This is a risk for any wallet that relies on RPC providers, not specific to Rabby, but worth understanding as part of the complete security model.

When to refresh the preview and when to cancel

The decision to refresh a preview or cancel a transaction depends on how long you have been waiting and how volatile market conditions are. If you generate a preview and sign within 30 seconds, refreshing is probably unnecessary unless market conditions are visibly chaotic. If you wait 5 minutes or longer, the preview is likely outdated and should be refreshed to see current prices and conditions. If you refresh and the expected output has dropped more than your stated slippage tolerance, the transaction should not proceed—either cancel and try again later, or accept that current conditions are not favorable for this transaction.

Canceling is always safe if the transaction has not yet been signed. After signing but before confirmation, canceling is more complex and may require paying gas to bump the nonce or replace the transaction. Most users should not reach that point if they follow the preview-and-verify workflow. If a signed transaction is pending and you want to cancel, the safest approach is to submit a new transaction with the same nonce and a higher gas price that sends 0 value to yourself; this is faster and cheaper than letting the original transaction linger in the mempool.

One scenario where canceling is especially important: if you refresh the preview and the output has dropped significantly—more than 10-20% from the original quote—something has changed materially. Either the market has moved against you, a sandwich attack is underway, or liquidity has been depleted by other transactions. In any of these cases, proceeding with the transaction is accepting a much worse deal than you originally considered. Canceling and trying again at a different time, with different parameters, or on a different network is often the right choice.

Security implications of the browser extension architecture

The Rabby wallet extension runs as a browser extension, which means it operates with whatever privileges and security context the browser provides. This is more isolated than a web-based wallet that requires visiting a website, but less isolated than a dedicated hardware wallet. A browser extension can be compromised by a malicious software download, a browser vulnerability, or social engineering that installs a fake version. Rabby emphasizes the importance of downloading only from rabby.io and installing only verified, official extensions; fake versions that mimic Rabby have been used in phishing attacks.

The extension architecture is also subject to browser-level threats. If the browser is compromised by malware or if a user visits a malicious website that exploits a browser vulnerability, the extension’s stored data could be exposed. Rabby stores wallet data locally and encrypted (assuming the user sets a strong password), but the encryption key is derived from the user’s password; a weak password can be brute-forced offline if data is extracted. For high-value wallets, using a hardware wallet connected through Rabby, or using a dedicated device for wallet operations, provides additional isolation.

The transaction simulation and preview features themselves are secure in the sense that they do not require sending transaction data to external servers; the simulation happens locally. However, Rabby does query blockchain state from RPC providers, which can reveal to those providers which addresses you are interacting with. For privacy-conscious users, this is a consideration, though it is typical of all self-custodial wallets that interact with public blockchains. Using a personal node or a privacy-respecting RPC service can mitigate this, but most users rely on Rabby’s default providers.

Comparing Rabby’s preview against other DeFi wallet security tools

Other wallets and security tools offer sandwich attack protection through different mechanisms. MetaMask has added basic simulation and warnings in recent updates, but Rabby’s preview is generally more detailed and shows expected balance changes more explicitly. MEV-Blocker and similar services protect entire transactions by routing them through private pools; they offer strong privacy but at a cost and with limited liquidity. MEV-Protect and similar services propose to share MEV profits with users, though this is still an emerging area with limited adoption and unclear long-term economics.

The advantage of Rabby’s approach is that it is free, immediate, and requires no additional configuration beyond the wallet itself. The preview shows whether a transaction is worth approving right now, without requiring the user to trust an external service or pay additional fees. This makes it accessible to most users and suitable for everyday transactions. For very large transactions or privacy-critical operations, combining Rabby with MEV-protection services or hardware wallets may be appropriate.

Rabby also stands out for supporting multiple EVM-compatible networks with consistent preview and security checking across all of them. Whether you are swapping on Ethereum, Arbitrum, Optimism, or any other EVM chain, the workflow and preview details remain consistent. This reduces the risk that users will relax their verification process when moving between networks. The limitation is that rabby wallet extension does not support non-EVM networks like Bitcoin or Solana natively, so users with diverse portfolios may still need multiple wallets.