A user connects their wallet to a DeFi protocol they have never interacted with before. The interface shows a transaction ready to sign: it promises a token swap, a liquidity deposit, or a yield opportunity. The user sees the button, recognizes the name of the protocol, and prepares to approve. But something is wrong. The smart contract has been compromised, or the interface itself is displaying false information. By the time the transaction is confirmed on-chain, the user’s tokens are gone—either drained directly or locked in a contract that demands a ransom to unlock them.

That scenario plays out daily across DeFi. Most wallet software simply displays what the user is about to sign without interpreting the actual consequences. The rabby wallet extension approaches the problem differently. Before a signature is broadcast, it simulates the transaction against the current blockchain state, calculates the exact balance changes, and flags suspicious contract behavior. This preview layer sits between the user’s decision and the irreversible ledger entry, creating a moment to verify that what they intended to do is actually what the transaction will do.

How transaction simulation works in a DeFi wallet

Transaction simulation is not a new idea in blockchain engineering. It has existed in Ethereum nodes and block explorers for years. The technical step involves executing the transaction’s bytecode against a copy of the current blockchain state—a process called a “dry run”—without actually committing the result to the ledger. The simulation returns what would happen: which balances would change, what error would occur, or what side effects would trigger. The Rabby wallet extension brings that capability into the user-facing wallet interface, making it visible and actionable before signing.

When a user arrives at a smart contract interaction, Rabby intercepts the transaction request before it reaches the signing screen. The wallet decodes the contract call, identifies the affected token or protocol, and runs the transaction through a simulation engine. That engine typically connects to public Ethereum RPC endpoints or other EVM-compatible networks depending on which blockchain the user is interacting with. The simulation executes the exact bytecode that would run if the transaction were broadcast, using the current nonce, gas parameters, and account balance as they exist at that block height.

The result is a list of expected balance changes. If the user is swapping 10 USDC for ETH, the simulation will show: “You will send 10 USDC and receive approximately 0.0065 ETH.” If the transaction would fail—because slippage is too high, or the contract has already been exploited—the simulation catches the error before the user pays gas fees for a failed transaction. If the transaction would succeed but trigger an unexpected secondary action—such as minting a reward token or claiming a referral bonus—the simulation surface that information too. The precision matters because it distinguishes between intended outcomes and hidden side effects.

Detecting malicious smart contracts and rug-pull patterns

Not all transactions that succeed are transactions that should succeed. A malicious smart contract can be designed to drain an account, transfer ownership of an NFT, or authorize unlimited token spending with a single click. The transaction simulation feature cannot reverse engineer intent, but it can detect structural red flags that suggest the contract is not doing what the user expects.

One common pattern is the “infinite approval” trap. When a user interacts with a decentralized exchange, lending protocol, or staking contract, the protocol typically asks for permission to move tokens on the user’s behalf. The permission is represented as an ERC-20 allowance—a smart contract function that says “this address can spend up to X of my tokens.” Many protocols request a very large number, sometimes 2^256 – 1 (the maximum value representable in Ethereum’s data types), to avoid asking for re-approval every time the user makes a transaction. That is often legitimate. But it can also be a malicious contract’s way of gaining authority to drain the account later. Rabby’s simulation flags when an allowance being set is disproportionate to the transaction’s intended use, alerting the user to review the approval carefully.

Another red flag is the “blind approval” where a transaction is asking for permission but not showing what will be done with it. If the user signs a transaction that transfers NFTs or authorizes spending without a clear corresponding action on-chain, Rabby’s simulation will highlight the mismatch. This is particularly valuable in DeFi because many exploits depend on the user not understanding what permissions they are granting. The secure wallet approach that Rabby takes is to force that understanding by making the contract’s actual behavior visible before the user is asked to commit.

Rug-pull detection is more subtle. A rug pull occurs when a protocol’s creators withdraw liquidity, steal deposited funds, or disable withdrawals after collecting user deposits. Simulation alone cannot predict future developer behavior, but it can expose certain structural indicators. If a user is depositing into a contract that has no withdrawal function, or where the withdrawal logic immediately transfers funds to a hidden address, simulation may reveal that. Real-time visibility into what happens to funds at each step of the contract interaction is the first line of defense.

The difference between simulation and static analysis

Understanding what Rabby’s simulation does and does not do is essential for realistic security expectations. Simulation executes the contract code as it currently exists, using the live blockchain state. It is a dynamic process that accounts for the contract’s actual behavior, external dependencies, and oracle prices at that moment. Static analysis, by contrast, reads the contract’s source code without executing it, looking for known patterns or vulnerabilities that have been pre-classified as dangerous.

Simulation catches mistakes and straightforward exploits: if the contract logic is broken, if it will revert due to insufficient balance or failed external calls, or if it will execute unexpected side effects, simulation will reveal that. It will show the exact tokens transferred, the exact amounts, and any errors in the call chain. What simulation does not do is predict attacks that depend on timing, sandwich attacks that exploit transaction ordering, or contract logic that is intentionally deceiving but technically valid. It also does not catch vulnerabilities in the smart contract code that only become exploitable under specific future conditions.

The simulation is therefore best understood as a transparency tool rather than a guarantee. It tells the user what will happen if the transaction executes under current conditions. That is valuable. But it does not eliminate the need for the user to verify that they are interacting with the correct contract address, that the protocol itself is trustworthy, or that the counterparties involved are acting in good faith. A well-designed contract that is interacting with a malicious oracle, or a legitimate contract that has been compromised by a hacked admin key, may still pass simulation checks while producing harmful results downstream.

Real-world examples of simulation catching scams

Consider a user who visits a website claiming to be a popular DEX. The design looks correct. The interface prompts the user to swap tokens. But the site is actually a phishing page that directs transactions to a malicious smart contract. The contract’s code says: “Transfer any tokens the user tries to swap directly to the attacker’s address, and return nothing to the user.” This is a direct theft attack. When the user opens Rabby wallet extension and attempts to confirm the transaction, the simulation runs the contract code. The result is clear: “You will send 1 ETH and receive 0 tokens.” The balance change shows a massive loss. Most users will halt immediately upon seeing that preview.

In a second scenario, a legitimate-looking yield farming protocol promises annual returns and asks users to deposit their stablecoins. The contract code has a subtle flaw: while the deposit function works correctly, the withdrawal function has a logic error that sends the withdrawal to the wrong address. Rabby’s simulation catches this because it traces the entire call path. When the user simulates a transaction to withdraw their funds, the simulation reveals that the funds would go to an external address they do not control, not back to their wallet. The alert surfaces before the user signs.

A third scenario involves token approvals. The user connects to a new protocol and signs a transaction to approve unlimited spending of their USDC. The protocol claims this is normal practice. But Rabby’s simulation flags the disproportionate allowance and shows that the transaction would grant spending authority to an address that is not associated with the protocol’s known deployment. The user can then manually verify the contract address against official sources before proceeding.

Integration with hardware wallets and import from MetaMask

The secure wallet design of Rabby extends beyond software features. The wallet supports hardware wallet integration, allowing users to sign transactions using a Ledger, Trezor, or other hardware device. That means the transaction simulation happens in Rabby, but the actual signature approval happens on the hardware device. The user can review the simulated balance changes in Rabby, then be prompted to physically confirm on the hardware device itself. This two-layer review process—digital simulation plus hardware approval—reduces the attack surface because a compromised computer cannot forge the signature.

For users migrating from MetaMask, Rabby offers direct import. The wallet can recognize MetaMask’s locally stored accounts and allow the user to load them into Rabby without exposing private keys or seed phrases during the import process. This is significant because it reduces the likelihood of accidentally pasting recovery information into a compromised clipboard or unsafe import dialog. Once imported, the same transaction simulation features apply. The user’s existing accounts benefit from Rabby’s pre-sign security checking immediately.

The import process preserves the user’s transaction history context, allowing them to see previously interacted addresses and protocols. This is a DeFi wallet’s way of helping users avoid re-approving unknown contracts. However, users should be aware that the import creates a second instance of the same accounts. The MetaMask installation and the Rabby installation will each have their own local copy of the account’s data. They do not automatically sync. If the user makes transactions in one wallet, the other wallet’s cached balances may become stale until they refresh.

Automatic network selection and the limits of multi-chain support

Rabby is optimized for Ethereum and EVM-compatible networks—chains that use the same virtual machine and smart contract language as Ethereum. This includes Polygon, Arbitrum, Optimism, Avalanche, BSC, and dozens of others. The wallet can detect which network the dapp is requesting and automatically switch to that network, or prompt the user to switch if Rabby’s configuration requires it. This eliminates a common source of user error: accidentally signing a transaction on the wrong network and having it broadcast to an unexpected blockchain.

The transaction simulation feature works consistently across all supported EVM chains because they all execute the same bytecode logic. However, the security implications vary. Some networks have faster block times, which can reduce the time an attacker has to sandwich a transaction between other users’ transactions. Some networks have lower gas costs, which may reduce the financial motivation for certain types of exploits. The simulation itself is network-agnostic—it runs the contract code—but the real-world severity of different attack vectors changes based on the network’s properties.

Rabby does not support Bitcoin or Solana natively. This is a deliberate scope limitation. Bitcoin uses a different transaction model and script language; Solana uses a different runtime and state model. Supporting those networks would require fundamentally different transaction simulation and risk detection logic. By focusing exclusively on EVM chains, Rabby can offer deeper integration and more precise simulations than a general-purpose wallet attempting to support everything. Users who need multi-chain support across Bitcoin or Solana should be aware of this limitation from the outset.

What transaction simulation cannot protect against

The most important limitation is that simulation reflects current conditions only. A contract that behaves correctly today may have different behavior tomorrow if the contract is upgradeable or if it depends on external data sources. A protocol that is secure at simulation time may suffer a governance hack, an admin key compromise, or a liquidity crisis hours later. Simulation cannot predict these events because they have not happened yet. The user should treat simulation as a strong signal about the current state of a transaction, not as a guarantee that nothing will go wrong in the future.

Slippage and market conditions introduce another category of uncertainty. If a user simulates a large token swap, the simulation may be accurate, but by the time the transaction is mined several blocks later, the market price may have moved significantly. The user receives less than expected—not because the contract was malicious, but because the market moved. Most DEXs address this by allowing users to set a minimum output, which the contract will enforce at execution time. Simulation shows the estimated output based on current prices; the actual output depends on prices at the time of block inclusion.

Phishing and social engineering remain outside simulation’s scope. If a user is tricked into visiting a fake website and typing their recovery phrase into a form, simulation cannot help. If a user is socially engineered into approving a transaction they should not approve, simulation will flag the unusual activity, but the user may ignore the warning if they have been convinced it is legitimate. The simulation is a tool for informed decision-making, not a substitute for healthy skepticism about unsolicited requests and unfamiliar protocols.

Best practices for using Rabby’s simulation feature effectively

The first practice is to never ignore the simulation output. If Rabby shows a balance change that does not match your expectation, stop and investigate before signing. Close the browser tab, independently verify the protocol’s official website and contract address, and consider whether the transaction should be attempted at all. Taking a pause at that moment has prevented countless exploits because the attacker’s advantage depends on speed and user confusion.

Second, verify contract addresses independently. Rabby can show you that a transaction is calling a specific contract address, but it cannot verify that the contract is legitimate just by looking at the address string. A phishing site may request interactions with a contract that looks correct in the display but is not the real protocol. Cross-reference the address against the protocol’s official documentation, GitHub, or verified blockchain explorers. The rabby wallet extension download page and the official rabby.io site both provide links to verified resources.

Third, understand that large approvals are a trade-off. Approving unlimited spending reduces friction for future transactions, but it means you are granting significant authority to that contract. If you are uncomfortable with that, use finite approvals—specify an exact amount the contract can spend—even though it requires an extra transaction. Fourth, use hardware wallet signing when the transaction value justifies it. If you are interacting with high-value positions or unfamiliar protocols, the small extra friction of hardware signing is worthwhile insurance.

Finally, maintain healthy skepticism about new opportunities. Unusual yields, newly launched tokens, or protocols that are not widely used yet should trigger extra caution. Simulation shows what the contract will do, but a contract that promises too-good-to-be-true returns is often designed to extract value in ways the simulation cannot predict. The oldest and most effective scams in DeFi are not technical exploits; they are fundamental misalignments of incentives disguised as opportunity.