What Transaction Simulation Can—and Cannot—Tell You Before You Sign
A simulation is evidence produced against a specific state. It can forecast likely effects, but it cannot prove intent, finality or downstream completion.
A wallet shows a green check beside the words Simulation succeeded.
That feels reassuring. It can also be dangerously easy to misread.
A simulation is not a verdict on whether a transaction is good, safe or aligned with your intention. It is evidence produced by running a request against a particular view of network state without broadcasting the real transaction.
That evidence can be extremely useful. It can reveal likely balance changes, approvals, contract calls and failure conditions before a signature leaves your wallet.
But a forecast and a decision are not the same thing.
Before signing, a user still needs to answer two separate questions:
- What is likely to happen if this request executes?
- Is that what I actually intend to authorise?
Simulation helps with the first question. Clear signing helps with the second.
A trustworthy wallet should show both—and make the limits of each visible.
What transaction simulation actually does
At a high level, simulation executes a transaction request against a chosen state without creating the real onchain transaction.
Go-ethereum's eth_simulateV1 documentation describes a method that can simulate blocks and transactions without creating them. It also exposes an important detail: validation is configurable. When enabled, it performs normal EVM validation with stated exceptions, including contract-sender and signature checks.
That is a useful reminder that “simulated” is not one universal condition.
The result depends on:
- which network and block state were used;
- which transactions or calls were included;
- which validation checks were enabled;
- whether the tool modelled state overrides;
- how token transfers, internal calls and logs were interpreted;
- how much time passes before real execution.
This request produced these effects under these conditions at this time.
That statement is valuable because it is specific. A generic green badge is weaker because it hides the conditions.
What a useful simulation can reveal
1. Likely balance changes
A preview can show which assets are expected to leave and enter an account. That is more useful than showing only the contract address or raw calldata. A user can compare the likely effect with the action they meant to take.
The interface should distinguish the account's starting balance, the predicted change and the expected ending balance. It should also say whether fees are included in that figure.
2. Token approvals and permission changes
Many transactions do more than transfer an asset. They may approve a contract to spend tokens, change an allowance or create a permission that remains usable after the immediate action.
A simulation can help surface those state changes. The wallet should still explain the scope in plain language: spender, asset, amount, duration and whether the authority can be reused.
3. Contract calls and likely reverts
A simulation may reveal that a request fails against the current state. That can prevent the user from signing a transaction that is already expected to revert. It can also expose which step in a batch or contract interaction caused the failure.
But a successful simulation does not create the opposite guarantee. State can change between preview and execution.
4. Multi-step effects
A batched transaction may approve, swap and transfer in one request. A useful preview should not compress those consequences into “three calls succeeded.” It should show the sequence in the language of user outcomes.
The order matters because one step may create authority that a later step uses.
5. Estimated resource use
Simulation can contribute to gas or resource estimates. The interface should label these as estimates and identify the network. It should not silently turn a modelled cost into a guaranteed final fee.
What simulation cannot prove
1. It cannot read the user's intention
A malicious request can execute exactly as designed. If the user thinks they are claiming a reward but the transaction transfers an asset to an attacker, a successful simulation may accurately forecast the transfer. The missing layer is not execution evidence. It is understandable intent.
This is where structured context matters.
ERC-7730 defines a format for enriching opaque transaction data with information needed for human verification and machine consumption. It can help a wallet turn raw values into readable actions, amounts and intent descriptions.
Simulation says what the request is likely to do. Clear signing helps the user judge whether that is what they meant.
2. It cannot guarantee future state
A preview runs against a state snapshot. Execution happens later. Balances, nonces, liquidity, oracle values, gas conditions and contract state can change in the gap. A result may become stale even when the original simulation was correct.
The wallet should show the simulation time or block reference and explain which effects are sensitive to change.
3. It cannot guarantee cross-chain completion
Cross-chain journeys contain more than one state transition. A source-chain transaction may simulate successfully while later execution still depends on quote validity, route availability, relayers or solvers, destination-chain conditions and settlement.
A wallet should not let one successful source preview stand in for the entire journey.
Before signing, the user needs the route, estimated total cost, minimum received and estimated completion time. After submission, they need distinct source, routing, destination and recovery states.
4. It cannot certify a counterparty
A simulation may show the predicted effect of interacting with a contract. It does not automatically establish that the contract, domain or requesting application is the one the user intended to trust.
Origin verification, contract identification, risk signals and readable permission scope remain separate layers.
5. It cannot turn uncertainty into safety
A clean output is still an output from a model. If the interface reduces that evidence to a green shield or the word Safe, it encourages the user to stop inspecting the transaction.
The better design is not a louder badge. It is a readable receipt.
Four evidence labels before signing
A wallet can make simulation more useful by separating four types of information.
Decoded
These are facts extracted from the request and supporting context:
- requested action;
- account and network;
- recipient or contract;
- asset and amount;
- permission parameters;
- transaction deadline.
Decoded information explains what was asked.
Simulated
These are effects produced by executing the request against a chosen state:
- predicted balance changes;
- token transfers;
- approval changes;
- contract calls;
- likely success or revert;
- estimated resource use.
Simulated information explains what was observed in the preview.
Asserted
These are conditions that must remain true for execution to be acceptable:
- minimum received;
- maximum spend;
- allowed asset;
- permitted recipient;
- expiry;
- acceptable price or route boundary.
An assertion is not a prediction. It is a rule.
MetaMask's Advanced Permissions documentation gives a current category example: permissions can be scoped by asset, amount, time window and transfer type, with enforcement rejecting activity outside the defined boundary.
Unknown
These are outcomes that the current preview cannot responsibly promise:
- future network state;
- final gas paid;
- quote movement before execution;
- downstream cross-chain settlement;
- destination readiness;
- whether an external service remains available.
Unknown does not mean unusable. It means the product is honest about what the evidence does not cover.
A cross-chain example
Imagine a user wants to move an asset from an EVM network into Solana.
Before signing, a useful receipt could show:
Decoded
- source and destination networks;
- asset and input amount;
- wallet account;
- contracts or permissions requested.
Simulated
- expected source balance change;
- approval change;
- whether the source call currently succeeds;
- estimated source resource use.
Asserted
- minimum destination amount;
- quote deadline;
- maximum source spend;
- permitted destination address.
Unknown
- exact execution time;
- final destination fee when it is variable;
- route conditions after the quote expires;
- whether a downstream action remains available after settlement.
That structure gives the user more than “simulation passed.” It gives them a decision model.
What the wallet should display
- What was simulated?
Name the request, account, network and included steps. - Against which state?
Show a timestamp or block reference and a freshness indicator. - Which checks were included?
Explain material omissions rather than hiding them behind technical detail. - What changed in the preview?
Show assets, balances, approvals, counterparties and expected outcome. - Which conditions are fixed?
Separate enforceable limits from estimates. - What can still change?
Make unknown or downstream dependencies visible. - What happens if the preview is stale?
Refresh, re-simulate or block the signature when the evidence no longer matches the request.
Where Biti.pro fits
Biti.pro is being built around clarity before signing for self-custody users moving from EVM networks toward Solana.
The approved product direction includes running transaction simulation before the request reaches the signer and showing the route, estimated fees, minimum received and estimated completion time.
The product is still pre-launch. Simulation should not be presented as a promise that a route cannot fail or that an outcome is guaranteed.
The principle is narrower and more useful:
Show the evidence. Label its limits. Let the user decide before the signature.
The green check needs a receipt
Transaction simulation deserves a prominent place in wallet UX.
It can reveal effects that raw calldata hides. It can catch current-state failures before the user pays for them. It can make approvals, balance changes and multi-step actions easier to inspect.
But the green check should never stand alone.
Before signing, ask four questions:
- What is decoded?
- What is simulated?
- What is asserted?
- What is still unknown?
A forecast becomes trustworthy when its boundary is visible.