Can you trust a transaction simulation in MetaMask?

When a dapp — a website or app connected to your wallet — sends a request to MetaMask, the wallet opens a confirmation screen. A MetaMask transaction simulation can show you, before you sign, how the transaction is expected to change your balance: for example, “+1,240 USDC” and “-0.5 ETH.” It is a prediction based on the current state of the network.

That preview is useful for catching the wrong token, an unexpected amount, or a transfer you did not intend to make. But it is still only a prediction: a simulation does not prove that a contract is safe, and it does not guarantee that the onchain result will be identical. Network state can change, a malicious contract can deliberately behave differently during simulation, and some signatures or permissions do not move funds at the moment you approve them. That is why Estimated changes should be treated as one check, not the final verdict.

What a MetaMask transaction simulation shows before you sign

MetaMask calls this feature estimated balance changes. In the confirmation screen, you will see it as Estimated changes. MetaMask simulates the transaction before it is submitted and shows the asset movements it expects.

There are two details worth knowing before you rely on that preview:

• The simulation uses MetaMask infrastructure. MetaMask says the feature may send transaction data and/or your IP address to a centralized MetaMask server. In Extension, privacy-related settings are under Settings → Privacy; in Mobile, they are under Settings → Security & Privacy. Turning off Estimated balance changes also disables Added protection.
• Estimated changes focuses on asset movement. It can show ERC-20 balance changes, ERC-721 and ERC-1155 NFT transfers, and changes involving ETH or another network’s native asset. It does not explain every effect a smart contract can have.

Standard transaction simulations are enabled by default. MetaMask also makes the limitation clear: the simulated result may differ from what ultimately happens onchain. The blockchain can change between the moment MetaMask runs the preview and the moment your transaction is included in a block.

Why the preview can differ from the final result

A simulation sees the network as it exists at that moment. Your transaction may not be included for another few seconds or minutes. In the meantime, someone else can trade against the same liquidity pool, an oracle can update a price, liquidity can change, or the contract itself can move into a different state.

Swaps are the easiest example. MetaMask may show one output amount in the preview, while the transaction ultimately receives a slightly different amount within your slippage limit. A simulation cannot freeze the market state until your transaction lands onchain.

There is also a more dangerous reason for a mismatch: a contract can be designed to behave safely during simulation and execute different logic once the real transaction runs onchain.

When a contract deliberately fools the simulation

MetaMask refers to this as a red pill attack. The malicious contract tries to detect whether it is being simulated. If it is, the contract returns a harmless result. When the same transaction executes in a real block, a different branch of the code runs.

A July 2026 paper, “Blockchain Transaction Simulation Phishing”, describes six technical ways attackers can build this behavior. For a wallet user, they boil down to three broad ideas:

• Contract state. After the simulation, the attacker changes data in the malicious contract or a connected contract so the transaction follows different logic later.
• Gas-related values. The contract can react to the available gas or gas price if those values differ between simulation and real execution.
• Block data. Block number and timestamp keep changing, so a contract can use them as conditions for choosing a different path.

The researchers found all three of those patterns in real phishing contracts and reproduced additional variants experimentally. A green “plus” in Estimated changes only tells you what the simulation saw. It does not prove that the contract itself is safe.

How much users lost

To find these contracts onchain, the researchers built a detector called SimGuard and analyzed Ethereum, BNB Smart Chain, Avalanche, and Polygon. For the period from August 2024 through June 2025, they reported:

• 4,224 phishing contracts: 3,136 on Avalanche, 480 on Ethereum, 315 on Polygon, and 293 on BNB Smart Chain;
• 5,742 victim addresses and 6,223 loss-making transactions;
• about $3.48 million in estimated losses, including $3.19 million on Ethereum;
• more than 143.4 ETH lost in the largest single transaction.

The most common contracts were those that keyed off gas-related values, but they accounted for only about 6% of the estimated losses in the sample. Most of the money came from 16 contracts whose state could be changed after simulation: roughly $2.97 million, or more than 85% of the total.

Scam Sniffer documented one such case in January 2025. The site offered a supposed reward through a Claim function, and the simulation showed a profitable outcome. After the check, the attacker changed the contract state, so the real transaction followed different logic and drained more than 143 ETH from the address. The important part is not the exact function name: the malicious transaction looked safe at the moment the user had to decide whether to approve it.

The researchers also tested 11 popular wallets, including MetaMask, Rabby, and Phantom. Most showed a misleading or inaccurate preview in at least part of the test set. In one MetaMask test, the wallet displayed a small positive balance change even though the transaction sent 0.5 ETH to a phishing contract and returned only 1 wei — the smallest unit of ETH.

When your balance does not change, but you still grant permission

Not every dangerous request moves tokens immediately. Sometimes you are granting permission that can be used later while the funds stay exactly where they are for now. In that case, the important questions are who receives the permission, how much they can spend, and how long the permission remains valid.

Permit and Permit2: a signature can authorize future spending

With EIP-2612 Permit and Permit2, you can authorize future activity by signing a message instead of first sending a separate approve transaction. No funds move when you sign. Depending on the request, that signature can later be used to create spending permission or move tokens.

MetaMask can already decode some Permit requests and show permission details and amounts in the confirmation. That is useful, but the screen cannot tell you when someone will use a valid signature later. If an attacker gets the signature before it expires or is revoked, the actual token movement can happen afterward. We explain the differences between approve, Permit, Permit2, and WalletConnect in more detail in “Approve, Permit and WalletConnect: How Permissions Can Drain Your Tokens”.

Permit requests are commonly represented as structured EIP-712 messages, so MetaMask can display some fields in a more readable form. MetaMask also uses Security Alerts to flag suspicious requests. For EVM networks, transaction and signature checks are handled through MetaMask infrastructure; for supported non-EVM networks, MetaMask uses Blockaid and other security providers. These alerts can identify known threats, but they do not guarantee that every malicious request will be caught, and the user can still choose to proceed.

Approve: permission to spend tokens later

An approve transaction sets or changes an allowance: the amount of tokens that a specific address or contract is allowed to spend later. In technical fields, that party is called the spender. The tokens do not move during the approval itself, so the key thing to review is who gets access and how large the limit is.

MetaMask shows a spending cap for these requests. Check who you are authorizing and how much they will be allowed to spend. If the cap is much larger than the current transaction needs, that address or contract may be able to move far more tokens later — up to the full available balance while the permission remains active.

How “Added protection” works

A standard simulation only shows a preview. Added protection adds an onchain check during execution: if the real result does not match the protected simulation, the transaction reverts and the state changes are not applied. In other words, if a contract tries to switch to a different outcome onchain, the transaction is supposed to fail instead of silently doing something else. You still pay the network gas fee for the reverted transaction.

There are a few limits to keep in mind:

• Added protection is not available for every request. MetaMask only shows the option where enforced simulation is supported. If there is no toggle in the confirmation screen, that protection is not available for that transaction.
• Network support is limited. As of September 2026, MetaMask lists 15 networks for onchain simulations: Ethereum, Optimism, BNB, Polygon, Monad, HyperEVM, Sei, Tempo, MegaETH, Robinhood, Arc, Base, Arbitrum, Avalanche, and Linea.
• The network fee can be higher. The extra onchain verification requires more gas. MetaMask does not charge a separate fee for the feature.
• Since version 13.48.0, the toggle is not always on by default. If MetaMask’s internal risk checks do not detect clear warning signs, Added protection can start disabled. It remains enabled when the request is classified as warning or malicious.

What a hardware wallet adds

The simulation, MetaMask warnings, and dapp data are all shown on your computer. If the website or interface is compromised, the screen can show one thing while different data is sent for signing. A hardware wallet gives you a separate screen where you can verify what actually reached the device before you approve it.

The Bybit hack on February 21, 2025 is a useful example. Bybit used Safe{Wallet}, a multisig wallet in which several signers must approve an operation. According to Sygnia, the attack began with the compromise of a Safe developer’s workstation. The attackers later injected malicious JavaScript into the Safe web interface, so the signers saw the expected transaction while different data was submitted for signing. One Bybit cold wallet ultimately lost about $1.46 billion in assets, including 401,347 ETH.

That incident matters here because it shows the limit of relying on browser-based information alone. A hardware wallet adds a second display, but even there a complex smart-contract call may still be hard to understand. A contract address and a handful of technical fields are not always enough to understand what a signature will actually authorize. EIP-712 structures the message, but by itself it does not explain the meaning of a nested smart-contract action.

For a normal transfer, verify the recipient address, amount, and network on the hardware wallet itself. If the browser and the device show different details, reject the request. For smart-contract interactions, check the action and its parameters as well. If the device only shows a long hexadecimal string or fields you cannot interpret, you do not have enough information to know what you are approving.

ERC-7730 defines a JSON format that can turn technical call data — including calldata or EIP-712 messages — into a human-readable description of the action and its parameters. As of September 2026, ERC-7730 is still a Draft standard.

On May 12, 2026, the Ethereum Foundation announced that its Trillion Dollar Security Initiative would take an active role as a credibly neutral steward of the Clear Signing registry. ERC-7730 v2 also expanded the format to cover cross-chain use cases and software wallets.

Clear Signing helps only when a correct descriptor exists for the contract and the wallet applies it correctly. New or unknown contracts may not have one yet. A readable confirmation screen can greatly reduce the chance of approving opaque data, but you still need to verify the domain, contract, and action.

If you are choosing a device for DeFi, we compare current models and their transaction-review features in “Best Hardware Wallets in 2026: Which One Should You Choose?”.

What to check before you confirm

Before confirming anything, first identify what MetaMask is asking you to approve and what that request can do. A normal transfer, an approve transaction, and a Permit signature are different actions, so they need different checks.

In MetaMask:

1. Understand what the dapp is asking for. Is this a transfer, an approve, or a message signature? For Permit and Permit2, check the token, amount, the address or contract receiving spending authority (spender), and the expiration. Field names vary, but those are the four things that matter.
2. Read Estimated changes all the way through. Check the asset, direction, and amount. If you see an outgoing transfer you did not expect or an unfamiliar token, do not confirm until you understand why it is there.
3. If Added protection is available, check whether it is enabled. MetaMask recommends extra caution for unfamiliar dapps, complex transactions, and large amounts. Since version 13.48.0, the toggle may start disabled when MetaMask’s internal checks do not detect clear warning signs.
4. For approve requests, check who gets permission and review the spending cap. An unnecessarily large allowance can let that address or contract spend far more tokens than the current action requires.

On a hardware wallet:

1. For a transfer, verify the full address, amount, and network. Checking only the first and last few characters is weak protection against address poisoning, where an attacker deliberately tries to get a lookalike address into your history.
2. For a smart-contract interaction, check the action and its parameters. The contract address alone does not tell you what the transaction will authorize.
3. Do not approve a request you cannot understand. If the device shows a long hexadecimal string, a data field with no readable explanation, or unfamiliar parameters instead of the action you expected, stop and find out what you are being asked to sign.

If MetaMask and your hardware wallet show different information, reject the request and re-check the domain, contract, and source of the transaction. If you have already granted an overly broad or suspicious permission or signed a questionable Permit2 request, review your approvals and revoke them if necessary through revoke.cash. If there are signs that your private key or recovery phrase has been exposed, revoking permissions is not enough — move the remaining funds to a new wallet with a new backup.

If your hardware wallet is new, go through our first 30 minutes hardware wallet checklist before moving a significant balance. It covers device checks, backup verification, and a test transaction.

Can you trust a MetaMask transaction simulation?

A MetaMask transaction simulation is useful before you confirm. Estimated changes can show the expected movement of assets and often catches obvious mistakes before you sign. But it does not prove that a contract is safe or guarantee that the final onchain result will be identical. A red pill attack can make the same contract behave differently in simulation and real execution, while approve, Permit, and Permit2 can grant future spending authority without an obvious balance change at the moment you confirm.

Added protection adds an onchain verification layer for supported transactions, while a hardware wallet gives you a separate screen for reviewing what is actually being signed. Before you confirm, make sure you understand what action you are authorizing, where funds can go, who receives spending authority, and how much access you are granting.