A user approves what appears to be a straightforward token swap on Base or Arbitrum. The Rabby Wallet interface displays a clear simulation preview showing expected balance changes: tokens sent, tokens received, new portfolio value. Everything looks correct. Yet when the transaction reaches the blockchain, the smart contract behaves differently than the simulation predicted. The swap fails, the approval gets stuck, or the final amounts diverge sharply from the preview. The user then faces a choice: repeat the transaction, investigate the underlying contract logic, or abandon the operation entirely. The core problem is that transaction simulation, while powerful for detecting obvious errors, has structural limits.
Simulation happens off-chain, using a local or remote copy of the blockchain state at a specific block height. The wallet calls the smart contract code with the user’s intended inputs and observes what the code returns. If the simulation succeeds, the wallet displays the results. If it fails, the user sees an error. The mental model is straightforward: simulation predicts reality. Yet that model breaks in several important ways. State changes between the simulation block and the actual broadcast, contract logic depends on external data that the simulator cannot predict, market prices shift, liquidity evaporates, or the simulation tool itself has blind spots. Understanding when simulation cannot be trusted is as important as understanding what a successful simulation means. Users of Rabby crypto wallet who rely on simulations without grasping these limitations can confidently approve transactions that will fail or produce wildly different results.
How simulation works and what it cannot capture
When a user initiates a transaction in Rabby Wallet, the browser extension submits the transaction details to a simulation engine. That engine typically uses a forked or synced copy of the blockchain state, executes the contract code with the user’s inputs, and reports the result. For simple transfers or basic token swaps with stable liquidity, simulation is reliable. The contract logic is straightforward, the state is unlikely to change between simulation and broadcast, and the external conditions are predictable.
The weakest point is time. Simulation happens immediately; broadcast happens moments later. In that gap, other transactions may execute on the same blockchain, changing state variables, draining liquidity pools, updating prices, or triggering contract-level restrictions. A user simulating a DEX swap at one price may broadcast when the price has moved 5% or more. An arbitrage transaction simulated when a certain token balance exists may fail if another user withdrew that balance first. A smart contract that enforces rate limits or daily caps may reject the transaction if it has already processed a similar one in the recent past.
The second limitation is incomplete information. Smart contract approval visibility in Rabby helps users understand which contract can access which tokens. Yet simulation cannot always predict how a contract will use that approval. A contract that swaps tokens may also have the ability to stake them, bridge them, or send them to an arbitrary address. The simulation shows what the contract does in the specific function call being approved, but not all possible behaviors the contract could perform in the future. Approval persistence means that once granted, the permission remains unless the user explicitly revokes it. Simulation of the initial approval will show zero tokens moving, which is correct; but the real-world risk comes from how that approval might be used later.
External data feeds represent another blind spot. If a contract reads prices from an oracle—such as Chainlink for asset prices, or an on-chain DEX for exchange rates—the simulation uses the state at the simulation block. The actual transaction may execute at a different block where the oracle price has changed. A liquidation bot, for example, depends entirely on oracle prices. Simulating a liquidation at one price may succeed, but the transaction might fail or liquidate different collateral at a later price. The simulation was correct for its moment in time; it was not a prediction of future execution.
The gap between simulation block and execution block
Every transaction on an EVM-compatible chain—Ethereum, Polygon, Arbitrum, Optimism, Base, BNB Chain, or Avalanche—is mined into a specific block at a specific time. Simulation operates on a snapshot of the state at a chosen block height, usually the latest available when the simulation runs. By the time the user’s transaction actually gets included in a block, several seconds to several minutes may have passed. On a busy network like Ethereum mainnet, that gap can encompass thousands of other transactions.
Consider a liquidity pool on Uniswap. The user simulates a swap: deposit 10 tokens, receive 9.8 of another token, accounting for slippage. The simulation is accurate for the pool state at block 19,000,000. The user approves and broadcasts. While waiting in the mempool, a whale executes a large swap that moves the price significantly. The transaction then lands in block 19,000,050. At the new block’s state, the same 10-token input might yield only 8.5 tokens instead of 9.8. The simulation did not lie; it accurately predicted what would happen if nothing else occurred. But something else did.
Some contracts protect against this with slippage limits. A user can specify: “I will accept 9.0 tokens or more, but if the output falls below that, revert the transaction.” This is why slippage tolerance, when configurable, appears prominently in the Rabby Wallet interface. A simulation at 9.8 with a slippage tolerance of 8% might still succeed, but the actual result could be closer to 9.0. Without a slippage limit, the contract accepts whatever the state provides, and simulation provides no protection against price movement.
Flash loans and arbitrage also operate in this time gap. A large flash-loan transaction can alter multiple pools, prices, and balances in a single block. If a user’s transaction simulates when one pool has 1,000 tokens and broadcast when that pool has 100, the results diverge entirely. The simulation engine cannot know about transactions that will be included in the same block or future blocks. It can only know about the state it sees now.
Approval visibility and the limitations of permission transparency
Rabby Wallet’s approval visibility feature shows the user which smart contract is being granted permission to spend tokens. This is a significant improvement over wallets that hide this information, because users can see when a DeFi protocol is requesting access, when a bridge contract is getting approval, or when an unfamiliar contract is trying to use their tokens. The feature directly addresses one category of risk: the user can refuse a suspicious approval.
Yet the approval screen displays only the immediate action. If a user approves a contract to spend 1,000 USDC, Rabby shows that the contract can now transfer up to 1,000 USDC. The wallet does not show what the contract will do with that approval, nor does it show whether the contract has been hacked, whether its permissions are overly broad, or whether it will later attempt to move more tokens than the user intended. A contract might be designed to spend the approved amount gradually, or it might spend it all in the first transaction. Simulation of the approval shows the immediate cost (zero tokens move on approval itself) but not the future risk.
The second subtlety is infinite approval. Many DeFi contracts ask for approval to spend an unlimited amount of a token. This simplifies future transactions because the user doesn’t need to re-approve every time. But it also means one successful hack of the contract’s code could drain all tokens of that type held by all users who granted approval. Rabby shows the approval amount prominently, making it possible to spot unlimited approvals. Yet the decision to grant or refuse still rests with the user, and simulation cannot predict whether the contract will actually drain approvals in the future.
A practical example: a user approves a bridging contract to move 100 tokens from Polygon to Ethereum. Simulation shows the tokens leaving one chain and arriving on another. The approval visibility shows that the bridge contract has permission to spend the tokens. The transaction simulates successfully, so the user broadcasts it. But what Rabby cannot show is whether the bridge contract has a backdoor, whether its multisig has been compromised, or whether a recent code update changed its behavior. Simulation would have executed the legitimate code path; but if the code path itself has been altered maliciously, even a correct simulation is meaningless. The approval visibility screen shows what permission was granted, but not whether that permission will be misused.
When to distrust a simulation result
A successful simulation does not guarantee a successful broadcast. Users should treat simulation as a sanity check, not a guarantee. Specific conditions warrant skepticism. First, if the simulated transaction outcome is unusual—for example, receiving far more tokens than expected from a swap, or a liquidation that clears all collateral when the usual pattern is partial—the simulation may be running on stale or manipulated state. An arbitrage opportunity that looks too good is often a simulation that does not reflect actual market prices.
Second, if the transaction involves a less-known or newly deployed contract, the simulation may be executing code that is poorly audited, contains bugs, or has been frontrun by another transaction that changed the contract state. A low-liquidity token swap on a new DEX may simulate successfully when the actual pool has been drained. The simulation cannot know whether the contract’s owner has introduced a fee or a transfer hook that will affect the result.
Third, if the user is aware that the network is congested, the simulated block was several seconds old, or several other transactions related to the same smart contract or liquidity pool are pending, the actual execution environment may differ significantly. A transaction that simulates on a quiet network may fail when broadcast during high traffic.
Fourth, if the transaction involves external oracles or price feeds, and the simulation result depends heavily on a specific price, the user should understand that the actual oracle price at execution time may differ. Liquidations, synthetic asset rebalancing, and algorithmic stablecoin transactions are particularly sensitive to this. Simulation shows the outcome at one oracle price; execution may occur at a different price.
Fifth, if the transaction includes a delegatecall or passes execution to another contract, the simulation may not capture the full state change. Some contracts decompose logic across multiple contracts or use proxies. A simulation might show the expected result of one layer while missing the effect of a subsequent layer. This is rare but possible with complex DeFi strategies that chain multiple protocols.
Interpreting simulation failures and what they reveal
When a simulation fails, Rabby displays an error message. The error can indicate a missing token balance, a contract revert, a permission issue, or insufficient gas. A failed simulation is usually informative: it signals that the transaction will fail on-chain and should not be broadcast. The user can then correct the issue—send more tokens, adjust the amount, check the smart contract approval—and resimulate.
However, not all failures are equally meaningful. A simulation failure on one network or at one block height might not predict failure on another network or a moment later. If a user is trying to swap across multiple chains or to interact with a contract that uses a rate limiter, a failure in the simulation might just mean the contract state has changed. The user can attempt the transaction anyway, understanding the risk, or can wait and resimulate when conditions change.
More subtly, a simulation may fail because the simulation engine itself has a bug, uses an outdated state, or does not support the contract code. Complex contract patterns, such as certain assembly-level operations or contracts that depend on msg.sender being a specific address, can confuse simulators. A transaction might fail in simulation but succeed on-chain, or vice versa. This is uncommon but more likely with cutting-edge or non-standard contracts.
A best practice when a simulation fails is to examine the error message, understand the stated reason, correct the obvious issues, and resimulate. If the same failure persists across multiple attempts, the transaction is likely genuinely broken, and broadcasting it will waste gas without providing any benefit. If the failure seems transient or related to state changes, the user can wait a few moments and try again. Repeatedly broadcasting a failing transaction hoping it will eventually succeed is a sign of either a broken smart contract or a misunderstanding of the transaction’s requirements.
Transaction reverts and the cost of failed broadcasts
When a transaction broadcasts but the contract reverts—rejects the execution—the blockchain still records the transaction, still consumes gas, and still deducts network fees. A failed swap that simulated successfully but reverted on-chain wastes the user’s gas without moving any tokens. On Ethereum mainnet, a failed ERC-20 transfer might cost 25,000 gas ($1-5 USD equivalent depending on network congestion). A complex DeFi transaction that reverts might consume 200,000+ gas with significant cost.
The simulation should have caught this, and usually it does. But if it did not, or if the simulation was stale, the user can retrieve transaction details from a block explorer, verify that the revert occurred, and investigate the reason. Some contracts provide detailed revert messages; others simply emit a generic “execution reverted” event. Understanding why a transaction failed guides the decision to adjust parameters and retry or to abandon the operation.
Importantly, a revert is different from a failed broadcast. A revert means the transaction reached the blockchain but was rejected by the contract. A failed broadcast means the transaction never reached the blockchain at all—it was dropped from the mempool, rejected by the node, or the user cancelled it. A revert still incurs gas costs; a failed broadcast may not, depending on whether the fee was already deducted. Users should check the transaction status in their wallet and on a block explorer to distinguish between these outcomes.
Practical steps to verify simulation accuracy before approving
Users should develop a habit of verifying simulation results rather than trusting them blindly. First, check the simulation block number. If Rabby displays the simulated block height and the current block height, a gap of more than a few blocks suggests the simulation may be outdated. Resimulate if the difference is large.
Second, cross-check the result with external sources when possible. For a token swap, check the spot price on a DEX aggregator or price feed. For a borrowing or lending transaction, verify the rates and pool state on the protocol’s web interface. If the simulation shows dramatically better terms than the external source, the simulation is likely using stale data.
Third, set explicit limits on the transaction. Use slippage tolerance for swaps, specify a minimum or maximum price for limit orders, and set gas limits that reflect current network conditions. These limits create boundaries that prevent a transaction from executing if conditions are too far from what the simulation predicted.
Fourth, before approving a smart contract approval, research the contract address and the protocol. Verify that the contract address on Rabby matches the official address from the protocol’s website. A slight typo or a phishing attempt could direct the approval to the wrong contract. Rabby’s approval visibility helps, but manual verification is still worthwhile for high-value approvals.
Fifth, for multi-step transactions or complex DeFi strategies, simulate each step independently before broadcasting the entire sequence. If step one simulates but step two fails, the issue is with step two, not with the initial approval. Breaking a complex operation into discrete simulations makes troubleshooting easier and reduces the risk of wasted gas on a partially failed sequence.
The future of simulation and realistic limitations
As EVM wallets and simulation tools mature, features like transaction simulation will improve. Better state data, faster simulation engines, more accurate gas estimation, and clearer error messages will reduce confusion. However, the fundamental limitations of simulating future state changes on a decentralized network will remain. No simulation tool can predict the exact moment a transaction will be included in a block, what other transactions will be in that block, or how those transactions will alter the state.
What users can expect is better transparency. Rabby Wallet’s emphasis on showing balance changes, approval permissions, and gas costs is a step in that direction. As more wallets adopt similar clarity, users can make more informed decisions even when simulations are imperfect. The wallet’s automatic network selection, support for multiple EVM ecosystems including Base, Arbitrum, Optimism, Polygon, BNB Chain, and Avalanche, and real-time gas tracking all contribute to a clearer picture of what a transaction will cost and what it will do.
The deeper lesson is that simulation is not a substitute for understanding. A user who grasps what a transaction does, why it might fail, and what the simulation is actually checking will make better decisions than a user who trusts the green checkmark. Simulation should inform the user, not replace judgment. The wallet’s job is to show the simulation result clearly; the user’s job is to interpret it skeptically and decide whether to approve.
Frequently asked questions
Why did my transaction pass simulation but fail on-chain?
Simulation uses a snapshot of the blockchain state at a specific moment. By the time your transaction broadcasts and is included in a block, other transactions may have altered that state—prices may have moved, liquidity may have been consumed, or contract state may have changed. This is especially common during network congestion or with volatile assets. Set slippage limits, use recent simulations, and verify current conditions before broadcasting to reduce this risk.
What does a successful simulation guarantee?
A successful simulation means that if the blockchain state remains identical to the simulated state and your transaction executes immediately, the transaction will produce the simulated results. It does not guarantee that these conditions will hold when the transaction actually broadcasts. Simulation is a sanity check, not a promise. Use it to catch obvious errors, but understand that state changes, price movements, and timing can alter the outcome.
How can I reduce the risk of failed transactions in Rabby Wallet?
Set slippage tolerance for swaps, use gas limits appropriate to current network conditions, verify contract addresses before approving, cross-check simulated prices with external sources, and resimulate if the simulation is more than a few blocks old. For high-value transactions, test a small amount first. Check the block number and network conditions before broadcasting. These practices reduce failure rates without eliminating all risk.