![\"A](\"https:\/\/lh3.googleusercontent.com\/sitesv\/AG8ngQUuJK67ZbqkhboUeZW5ZEPq-xoURXYZ7Op7a90OwTGU8kAOtTeIOO609ZaAD8lx18U5ZCVPPLXH28Uku7wsfcjkw6xdbU65IRPIwalYwMQbLy1k0mtWMtAWMRmYtpqFpFvBQMH9CGC4BDsE1rq1utuPdobUHrpW-SEh-WA9vCIyydmPV7D2xf3zYSL8wZMn53b3Zc6e9mEBCV3GYmL7\")
<\/p>\nA user approves a token swap on Uniswap v3, and Rabby’s transaction simulation displays the exact balance change: send 10 USDC, receive 9.85 ETH. The transaction executes, confirms on-chain, and the wallet refreshes. But the final balance is 9.81 ETH, not 9.85. The discrepancy is small enough to ignore casually, yet large enough to matter if the user is managing a significant position or relying on the preview to determine whether a trade is worth executing. This scenario is not a wallet bug. It reflects a fundamental tension between what Rabby can predict before a transaction enters the mempool and what actually happens when multiple transactions, price movements, and protocol mechanics converge on-chain.<\/p>\n
Transaction simulation in Rabby Wallet provides real value: it shows expected balance changes, reveals smart contract approvals, and warns of common mistakes before confirmation. Yet the preview is a snapshot taken at a specific block height, using historical state data and assumed network conditions. The actual execution occurs in a different mempool, block, and market environment. Understanding why predictions diverge from results is essential for active DeFi users who depend on accurate balance tracking and for anyone evaluating whether Rabby’s simulation features are trustworthy enough to inform trading decisions. The answer is not binary: the simulation is useful precisely because it catches major errors, but it cannot guarantee that minor slippage, rebasing behavior, or flash loan interactions will match the preview.<\/p>\n
Rabby’s simulation engine operates by executing a transaction against a snapshot of the blockchain at a specific block height. The wallet retrieves the current state\u2014token balances, smart contract logic, price oracles, liquidity pools\u2014and reruns the transaction through that frozen state to calculate what the balance changes would be. This approach is computationally practical and generally accurate for straightforward transfers and simple swaps. The user sees the amount they will send, the amount they will receive, and the network fee, all derived from real protocol logic rather than an estimate or a formula.<\/p>\n
The critical limitation is timing. Between the moment Rabby simulates the transaction and the moment it actually executes on-chain, the blockchain state has advanced. Other transactions have altered balances, changed liquidity pools, updated oracle prices, and triggered contract state changes. Rabby cannot know which transactions will be included in the same block, how network congestion will affect transaction ordering, or how market prices will move during the transaction’s journey through the mempool. The preview is therefore always conservative in one sense and potentially optimistic in another: it reflects the true result given the assumptions embedded in that particular historical state, but those assumptions will nearly always diverge from the real execution context.<\/p>\n
For a simple USDC transfer to another address, this divergence is meaningless. The balance change is determined by the amount sent and the network fee, neither of which depends on external state. For a Uniswap swap or any protocol that depends on oracle prices, liquidity, or permissioned logic, the divergence can be material. A Rabby user sees the preview, sees that the trade is favorable, and approves. By the time the transaction reaches the blockchain, Uniswap’s price has shifted, the liquidity composition has changed, or the transaction ordering has placed it after other trades that moved the market. The slippage tolerance set in the swap contract may prevent execution at an unfavorable price, or it may allow the transaction to succeed with less favorable results than the preview suggested.<\/p>\n
Slippage is the difference between the expected price and the actual price at execution. Most DeFi protocols allow the user to set a maximum acceptable slippage\u2014typically 0.5% to 2%\u2014as a safeguard. Rabby’s simulation calculates the expected output and the slippage tolerance as if they were interdependent, which they are in theory but not always in practice. The preview shows a trade that receives 9.85 ETH with 0.5% slippage tolerance. That means the contract will revert if execution results in less than 9.787 ETH (9.85 \u00d7 0.995). If actual execution produces 9.81 ETH, the transaction succeeds and the balance change reflects the actual result, not the preview.<\/p>\n
The user might interpret this as a minor win: they set a safety threshold and the transaction succeeded. But they also received 0.04 ETH (about 0.4%) less than the preview predicted. If they were relying on the preview to decide whether the trade justified the gas fee and the execution cost, they made the decision based on incomplete information. They might have rejected the trade if the preview had shown 9.81 ETH instead of 9.85 ETH. This is not a failure of Rabby’s simulation logic. It is an inherent property of predicting prices in a changing market. The simulation cannot improve beyond the information available at the block it queries.<\/p>\n
The practical consequence is that slippage tolerance and preview accuracy are different protections<\/strong>. Slippage tolerance prevents catastrophic failure; it does not prevent disappointment. A user who habitually approves transactions with the assumption that Rabby’s preview is guaranteed will eventually discover systematic underperformance on high-volatility trades or large swaps that substantially move liquidity pools. Conversely, a user who is aware of this limitation can use Rabby’s preview as a sanity check\u2014catching major errors and egregious price impact\u2014while maintaining realistic expectations about the final result.<\/p>\n Some tokens, such as AAVE staking rewards or Lido staking derivatives, automatically increase the balance of holders without requiring any action. These are called rebasing tokens. Their balance changes based on time and protocol mechanics rather than transfers or approvals. Rabby’s simulation runs at a specific block height, so it calculates rebasing based on the state at that moment. If the user approves the transaction and it executes five minutes later, the token may have rebased again in the interim, changing the actual balance differently than the preview predicted.<\/p>\n This interaction is particularly subtle because the rebasing usually happens invisibly. The user sees a balance of 100 stETH in Rabby, approves a swap, and the preview shows they will receive 50 USDC in exchange. If stETH rebases upward before execution, they may actually have 100.5 stETH, and the swap executes with the higher amount, producing slightly more USDC than expected. Conversely, if the rebasing is downward (as can happen during network slashing on proof-of-stake systems) or if the user is sending a rebasing token, the actual amount sent may differ from what the preview showed.<\/p>\n The challenge is that rebasing is not a transaction simulation problem per se; it is a feature of the token’s protocol that operates independently of Rabby’s logic. Rabby cannot predict future rebases because they are determined by external factors: staking rewards, slashing events, inflation parameters, or governance changes. The wallet’s preview is therefore guaranteed to diverge from reality for rebasing tokens whenever any time passes between simulation and execution. This is one reason why Rabby’s balance change preview<\/strong> includes an explicit timestamp or block number in the interface for users who need to verify currency data.<\/p>\n Flash loans are uncollateralized borrows that must be repaid within a single transaction. A user can borrow a large amount of capital, execute a series of swaps or arbitrage trades within that single transaction, and repay the loan plus a small fee in one atomic operation. The balance change preview in Rabby calculates the net result of all those steps as if they have already occurred. The user sees: send 1 USDC, receive 50 USDC (net profit from a flash loan arbitrage). That result is correct if and only if the flash loan executes successfully, the intermediate trades execute at the expected prices, and the loan repayment succeeds.<\/p>\n If any intermediate step fails\u2014a DEX lacks sufficient liquidity, a price oracle moves, or a governance parameter changes\u2014the entire transaction reverts, and the user receives nothing. Worse, the user may have already paid the network gas fee. Rabby’s preview cannot predict failures that occur during execution because it simulates the happy path: all transactions succeed, all prices remain favorable, and all contract calls execute as intended. For complex smart contract interactions that involve multiple protocols, the preview is optimistic by design. It assumes success rather than calculating the probability of failure or displaying a comprehensive list of dependencies.<\/p>\n A more practical issue is that Rabby’s preview may show the net result of a flash loan transaction but not the intermediate steps or the loan fee. A user may see that they are borrowing 1000 USDC via a flash loan and receiving 50 USDC profit, without understanding which protocols the borrowed capital moves through or whether the fee (typically 0.05% or higher) is already deducted. If the profit margin is thin, the fee could eliminate the gain, yet the preview might not make this transparent. This is an information design problem as much as a technical one: the simulation is accurate, but the presentation obscures important details.<\/p>\n Most DeFi protocols use oracle services\u2014Chainlink, Uniswap TWAP, or others\u2014to fetch external price data because direct real-time market prices are not available on-chain. An oracle provides a price feed, and the protocol uses that price to execute swaps, calculate collateral ratios, or determine liquidation thresholds. Rabby’s simulation uses the oracle price available at the block it queries. By the time the transaction executes, the oracle has been updated with new prices, potentially reflecting market movement or a multi-block TWAP recalculation.<\/p>\n The divergence can be small or large depending on market volatility and how frequently the oracle updates. During normal market conditions, oracle prices move gradually, and slippage tolerance absorbs the difference. During high volatility, flash crashes, or large liquidations on another platform, oracle prices can move significantly between blocks. A Rabby preview might show a token’s price as $100, with the simulation calculating a result based on that price. If the oracle updates to $98 before the transaction executes, the actual result will reflect the lower price, even though the user approved based on the $100 preview.<\/p>\n One additional complication is that some protocols use different oracles or have delayed oracle updates. Rabby’s simulation typically uses the oracle that the protocol uses, so the prediction should be accurate at the simulated block. However, if the protocol’s oracle has a lag\u2014updating only once per minute or once per hour\u2014the preview may reflect a stale price, and the real execution may occur at a different oracle price. This is particularly relevant for less-liquid tokens or smaller protocols that use batch oracle updates rather than continuous price feeds.<\/p>\n When a user initiates a large swap through a DEX aggregator\u2014a service that combines liquidity from multiple DEXs to find the best route\u2014Rabby’s preview calculates the expected route and output at the moment of simulation. The aggregator might determine that the best path is 70% Uniswap v3, 20% Curve, 10% Balancer. The preview shows the result of that split. If the transaction sits in the mempool and network conditions change, a different route might become optimal. The aggregator’s re-routing logic might adjust the split to 60% Uniswap, 30% Curve, and 10% SushiSwap to achieve a better execution price.<\/p>\n Rabby cannot anticipate these dynamic changes because the re-routing decision occurs at execution time, not at simulation time. The user approves a transaction expecting a certain split across protocols, but the actual execution uses a different route with a different price impact and slippage distribution. The final amount is often better than the preview (because the aggregator finds a superior route), but it can occasionally be worse if the route becomes fragmented across less liquid venues due to network congestion.<\/p>\nRebasing tokens expose the gap between prediction and execution<\/h2>\n
Flash loan interactions and atomic transaction dependencies<\/h2>\n
Oracle price discrepancies between simulation and execution<\/h2>\n
Automatic slippage and re-routing in DEX aggregators<\/h2>\n