A successful simulation tells an institution something useful about a proposed transaction under the simulated conditions. It does not establish that the transaction is authorised, that the beneficiary is correct or that the same conditions will hold when execution occurs. A signing policy should use the preview as evidence with a stated scope.
The strongest question is not whether the result is green. It is whether the preview evaluated the same instruction, account path and state assumptions that the institution plans to submit. A realistic simulation of the wrong payload can be technically sound and operationally irrelevant.
Identify what was simulated
Ethereum's JSON-RPC reference describes eth_call and eth_estimateGas as operations that do not add the transaction to the blockchain. That boundary is the starting point. The response is an evaluation of supplied inputs, not evidence of an executed chain movement.
The simulation record should contain the network, source account, destination, value, full calldata, gas settings where relevant, block reference and provider. Retain the exact payload in a form that can be compared with the signing instruction. A screenshot of an asset summary alone does not establish what inputs produced it.
The tool may provide traces, decoded calls or balance changes. Tenderly's simulation documentation describes these outputs as well as single and bundled simulations and state overrides. The institution should choose the evidence needed for its workflow instead of treating every tool response as equivalent coverage.
A native transfer, a router call and a multisig execution have different paths. The integration should specify which path it evaluates and where it simplifies the process. Simplification can be useful for analysis, but the reviewer should see the boundary.
State assumptions can change the answer
A transaction depends on the state against which it executes. Balances, permissions, contract configuration and market conditions can differ between the preview and inclusion. The simulation should record its state reference and any freshness threshold applied by the institution.
A preview against an identified historical block can be reproducible without being current. A preview against latest may be current at the moment of the request without remaining applicable later. Neither option resolves the business decision by itself. The policy should say when the transaction must be checked again.
If the preview uses overrides, record them prominently. A simulated balance increase or pre-set allowance can answer whether a later step would work after prerequisites are satisfied. It does not prove those prerequisites have already been completed onchain. A signing review should not inherit hypothetical authority as actual authority.
For a multi-step workflow, distinguish a simulation of the intended sequence from separate calls that each assume another step has already happened. The institution should understand which ordering was tested and whether the production route preserves it. A collection of successful isolated previews can leave the overall process unresolved.
Simulate the account execution path
Safe's account concepts documentation distinguishes owner-signed execution from module execution and describes relevant transaction parameters. A simulation of a target contract call alone may omit the account checks associated with the real execution route.
For a multisig or other smart account, determine whether the preview includes the account envelope, authorisation requirements and relevant checks. The result should explain any assumed signatures or replaced validation. This is not a demand that every analytical simulation contain live signatures; it is a demand that its scope be visible.
The same principle applies to a bundled instruction. If one operation approves a spender and another transfers assets, inspect both the immediate movement and the authority left after execution. A simulation that emphasises balance changes can understate a permission that matters to assets arriving later.
The existing discussion of smart accounts explains the broader account model. Simulation review needs to follow the actual route selected for this instruction rather than assume all accounts behave like a direct externally owned account call.
Successful execution is different from approved intent
A simulation can show that an operation transfers exactly the amount encoded in its inputs. It cannot know that the input differs from the approved settlement instruction unless the institution supplies that comparison. The approval system should check the destination, asset, quantity and purpose independently.
Consider a hypothetical payment whose recipient was copied from an unverified history entry. A preview may accurately show a transfer to that address. The problem remains at beneficiary verification. Asking the simulation tool whether the transaction succeeds does not ask whether it pays the intended counterparty.
Likewise, an approval operation may succeed without moving tokens. That can be expected behaviour and still create standing authority the institution did not intend to grant. Review the decoded operation and relevant state changes, not only a net balance summary.
This should be part of institutional wallet transaction policy: simulation evidence supplements the authorised instruction. It does not replace the approved beneficiary record, spending limit or separation of duties.
Inspect interpretation as well as execution
A human-readable summary is an interpretation of the underlying call and resulting data. The institution should know how the tool identifies token contracts, quantities and functions. If it cannot decode a call, the workflow should show that limitation rather than label an unknown operation routine.
For important operations, compare expected asset and authority changes with the trace or other available evidence. An unfamiliar intermediate call may be legitimate routing, or it may need investigation. The owner should have a path to specialist review instead of being expected to approve based on a green success flag.
A balance summary also needs a measurement scope. It may show selected assets or selected addresses. Determine whether the account, recipient, fee payer and relevant vault or router are covered. An omitted quantity should not be assumed unchanged merely because it is absent from the displayed report.
The integration should retain raw results sufficient to investigate an interpretation error later. A user-facing summary is useful for approval; the supporting record explains how that summary was produced. Keep the two linked without asking a signer to read every trace for a routine transaction.
Bind the preview to the final instruction
Before signing, compare the final payload with the simulated payload. Changes in amount, destination, calldata, route or relevant account parameters should trigger the appropriate renewed check. An approval of the initial draft should not automatically attach to an edited instruction.
Define a renewal policy for time and state changes as well. A long signing queue, relevant contract upgrade or changed allowance can make earlier evidence stale. The institution should identify which changes require a new preview and which remain within its approved tolerance.
Where multiple signers review a proposal, preserve the evidence associated with the version they approved. If the system refreshes a preview automatically, it should show whether the payload is unchanged and how the observed conditions differ. Silently replacing the original report can weaken the audit trail even when the new report is more current.
If the simulation service is unavailable, the fallback should already be defined. Some routine operations may have another approved check; other instructions may need to wait for specialist review. The institution should decide this by operation type and exposure, rather than let an outage create an informal exemption from the signing policy.
Record every fallback use with the reason, alternate evidence and approver. Reviewing those cases can reveal whether the simulation integration is becoming an unreliable dependency or whether a particular workflow needs a more suitable checking method.
Compare execution with the preview afterward
Once executed, reconcile actual movements and relevant state changes against the approved expectation. A difference may reflect changed conditions, an incomplete preview scope or an incorrect instruction. The investigation should identify the cause rather than assume the simulation provider failed.
Retain the actual receipt, account-level result where relevant and asset movements. For Safe, the execTransaction reference documents a success return value and distinct ExecutionSuccess and ExecutionFailure events. Check that account-level result rather than relying on the outer receipt alone. The closeout should establish the intended outcome using the deployment's actual execution model.
Test the control with a changed destination, stale state, missing allowance, overridden balance and a successful operation that creates an unwanted permission. Each case should produce a meaningful explanation or an escalation. A test suite consisting only of successful transfers does not establish the policy's usefulness.
The value of simulation is that it makes assumptions and consequences inspectable before the institution releases a signature. Its limitation is the same boundary: it evaluates the modelled transaction under modelled conditions. Institutions should preserve those conditions, compare them with authorised intent and verify the eventual result.