Tooling
Transaction Simulation Security: State, Signatures and Unknown Results
A preview is an execution result under selected assumptions, not a promise about a future transaction. Transaction simulation security depends on the exact request, state reference, validation mode and authority being granted, including effects that do not move assets immediately.
Key facts
- Original census
- 92 eth_simulateV1 fixture files in the recorded repository tree
- Overlapping signals
- 12 validation, 14 override and 7 nonce filename signals
- Execution boundary
- Fixture inventory only; no wallet or provider pass rate measured
- Authorization boundary
- A simulated caller and successful execution do not prove a valid signature
What simulation executes
Transaction simulation security concerns what a preview establishes about a proposed action and which assumptions remain outside that preview. A simulator executes a call or sequence against selected state and configuration. It can expose a revert, a transfer or another effect under those conditions. It does not guarantee that the eventual transaction will encounter identical conditions or that the requested authority is appropriate.
The retrieved Geth documentation contains a useful qualification: its simulation validation mode excludes contract-sender and signature checks. A preview labeled validated therefore needs a narrower interpretation than a claim that every condition of a real signed transaction has been established. The document trail begins with that exception and continues through the request, state reference and wallet explanation.
The Ethereum JSON-RPC documentation describes eth_call as executing a message call without creating a transaction on the blockchain. Geth's documentation also describes eth_simulateV1, which can simulate sequences across block-state call groups. These are execution mechanisms. A wallet's human-readable summary is another layer that interprets their output.
| Layer | What it can report | Question still open |
|---|---|---|
| Call execution | Return data or an execution failure under selected state | Did the selected state match the intended review? |
| Sequence simulation | Effects of ordered calls within the supported model | Will the real transaction order and dependencies match? |
| Transfer interpretation | Recognized asset movements or logs | Are all meaningful permissions and effects represented? |
| Wallet explanation | A human-readable summary of the proposed action | Does the summary accurately describe the target and authority? |
| Committed transaction | The actual included execution result | Was the resulting behavior acceptable to the user? |
A simulation can allow a caller to specify an address without possessing its signing key. That is useful for analysis, but it means the simulated caller is not proof of authorization. Geth's documented validation mode still excludes contract-sender and signature checks. A successful validated simulation should therefore not be described as proving that a real signed transaction is authorized and includable in every respect.
Read the output at the level the method actually supplies. A raw return value, a recognized token transfer and a wallet warning are different observations. If the interface reports no recognized asset change, ask whether the action changes an allowance, installs authority or updates state that enables a later transfer. Immediate balance movement is only one kind of consequence.
The security tools hub can help distinguish supporting analysis methods. For a specific wallet or provider, verify the implemented method and its configuration rather than transferring every capability of the underlying node documentation to the product interface.
State and block assumptions
The state reference is part of the result. A call evaluated at a selected block answers a question about that state. A request using a moving label such as latest can produce different results at different times. Preserve the resolved block identity where the provider exposes it, along with the chain, target address, calldata and caller context.
Pending state introduces another uncertainty. A node's view of pending transactions is not a universal promise about the order that will be included. A simulation based on that view can be informative, but its assumptions should remain visible. Reordering, replacement or a different block context can change the eventual execution.
Geth documents state overrides and block-context overrides for supported calls. These features deliberately modify the environment being simulated. They are useful for controlled analysis, such as evaluating a path with a specified balance or storage value. An override-assisted success is not evidence that those conditions exist on the live chain.
| Input | What to record | How a mismatch can matter |
|---|---|---|
| Chain and block | Network identity and resolved state reference | The same address can represent a different target or state |
| Caller and value | Simulated sender and native-asset amount | Permissions and balance-dependent behavior can change |
| Calldata | Exact function selector and encoded arguments | A summary can conceal a different operation or recipient |
| State overrides | Every modified account or storage field | The preview can rely on conditions absent from production |
| Block overrides | Changed time, number or fee context | Time and environment checks can take another branch |
A contract upgrade can create a particularly important mismatch. A proxy address may stay constant while its implementation changes between review and execution. A saved preview should identify the implementation or relevant code state where possible. The upgrade review guide explains why address identity alone does not establish behavior identity.
For a sequence, order is an input too. Simulating an approval followed by a transfer is different from simulating either call alone. The first action can change the state used by the second. Document whether the product simulates the whole intended sequence and whether it includes only the user's calls or additional assumed setup operations.
- The simulator starts from an identified chain state and any declared overrides.
- The exact caller, arguments and sequence define the simulated action.
- Other transactions, upgrades or timing can alter the execution context.
- The included transaction produces the actual state transition and receipt.
A useful comparison after an unexpected outcome preserves both records. Compare the simulated and committed inputs, block context, implementation and relevant state changes. This can distinguish a stale preview from a decoding error, a changed target or a behavior the interface never displayed. Without the saved inputs, several different explanations can look like the same "simulation failed" complaint.
Approvals and signatures
An approval can create authority without transferring an asset immediately. A preview that focuses on current balance changes may therefore understate the significance of the action. Identify the spender, asset, amount and any expiry or revocation mechanism. The relevant question is what the authorized party can do later, not only what happens in the approval transaction.
A signature request can be even further removed from immediate execution. The user may sign an authorization that another party submits later. The contract consuming the signature, its domain checks and its replay state determine the effect. A wallet that shows no current transfer has not established that the signature carries no financial or administrative authority.
EIP-712 defines typed structured data and domain separation, while leaving replay protection to the application. Read the actual signed fields and the verifying contract. A recognizable domain name is not enough: the chain, contract, nonce, expiry and operation-specific fields need to match the intended authorization scheme.
| Action | Authority to inspect | Follow-up question |
|---|---|---|
| Token approval | Named spender and permitted amount | Can that spender exercise the allowance later through another call? |
| Permit signature | Typed payload, domain and consumption rule | Where and when can the signature be used? |
| Operator approval | Scope of assets or operations granted | Does the authority extend beyond the single item shown? |
| Administrative action | Role or configuration changed | Which future behavior becomes possible after the change? |
| Account extension or module | Additional execution authority under the account design | Can another path act without the same visible approval flow? |
Do not treat a simulation of a signature's consuming transaction as a complete analysis of the signature's lifetime. The authorization may remain valid under another state until it expires or is consumed. A replay rule that appears harmless in one preview can matter later. The signature replay guide explains the separate questions of domain binding and one-time consumption.
When the wallet cannot decode the payload, preserve that uncertainty. An unknown method or typed-data structure should not be presented as an ordinary transfer merely because the destination is a token-related address. The reader needs a verified interpretation of the operation before the preview can support a meaningful decision.
An exact amount can reduce one form of exposure while leaving others. A spender with a narrow allowance may still be the wrong recipient, and an administrative signature may not have a meaningful token amount at all. Review the authority in the contract's own terms rather than applying a single warning rule to every signature type.
The authority and backdoor analysis is useful when an operation grants a less obvious execution path. It separates the existence of a power from claims about malicious intent, which a simulation alone cannot establish.
Failure and unknown results
A simulator can fail before it evaluates the intended action. The provider may not support the method, the requested state may be unavailable or the request may exceed a resource limit. These are different from a contract revert under a valid request. The interface should preserve the distinction because the next investigation step differs.
A contract revert is also conditional. It can reflect an invalid operation, insufficient balance, an expired authorization, a paused dependency or state that changed since a quote was prepared. The revert reason may help identify the path, but it is not always complete or trustworthy as a human explanation. Read the target and the inputs alongside it.
| Result class | What is known | What remains unknown |
|---|---|---|
| Successful simulated execution | The call completed under the selected environment | Future inclusion and the suitability of the granted authority |
| Contract revert | The call rejected under the selected environment | Whether another state or corrected input changes the result |
| Provider or method error | The intended evaluation did not complete | The contract's behavior for that request |
| Missing historical state | The requested context could not be reconstructed | The result under the intended historical conditions |
| Partial interpretation | Some output was obtained but not fully decoded | Undisplayed permissions or application-specific effects |
Geth's validation setting changes the question being asked. With validation disabled, the documented behavior is closer to eth_call. With it enabled, additional normal execution checks apply, with the documented exceptions for contract-sender and signature checks. Record the setting rather than describing all successful simulations as equivalent.
Our fixture census found 92 published eth_simulateV1 fixture files in the Ethereum execution API repository. Their filenames include validation, override and nonce scenarios. This shows that the reference test inventory distinguishes those concerns. It does not establish that a wallet or remote provider implements the method completely or has passed those fixtures.
A product should avoid turning an unavailable result into a positive badge. If the provider times out or the method is unsupported, the correct state is unknown for that attempted evaluation. The honeypot detection guide discusses a related problem: failed or incomplete simulation is not the same observation as a tested clean result.
When two providers disagree, compare the exact method, block state, overrides and validation settings. If those match, preserve both responses and investigate the implementation or interpretation difference. Do not average the results into a new confidence score without a defined model and evidence for it.
A preflight review workflow
Begin by confirming the action independently of the preview. Identify the intended chain, application, contract and operation from a trusted source. Then compare that intent with the exact transaction or signature request. A simulator can faithfully execute a maliciously substituted request; correctness of execution is not correctness of the user's intent.
Save the request and the relevant context before signing. A useful record includes target, caller, calldata, value, chain and the state reference used for the preview. For typed data, preserve the structured payload and domain. Do not publish sensitive account data unnecessarily, but retain enough local evidence to compare the eventual transaction with what was reviewed.
| Step | Evidence to inspect | Condition that needs clarification |
|---|---|---|
| Confirm identity | Application source, chain and deployed target | An address or implementation cannot be verified |
| Decode intent | Function or typed-data fields and recipient | The request cannot be interpreted confidently |
| Inspect authority | Allowance, role or signature scope | The effect extends beyond the intended action |
| Read simulation context | State reference, validation and overrides | The result depends on unexplained assumptions |
| Check output | Transfers, state effects, errors and unknowns | The interface omits a material permission or failure |
| Verify execution | Included transaction and resulting state | The committed action differs from the reviewed request |
For a time-sensitive operation, rerun the preview after a material input change. A different amount, route, recipient or target is a different request. If the application rebuilds the transaction after the preview, compare the final payload rather than assuming the earlier result still applies. An updated quote does not automatically imply an updated authority review.
Use slippage and deadline controls where they are part of the application's supported design, but understand their scope. They can constrain particular execution outcomes without proving that the target, spender or token is appropriate. The token behavior guide explains why transfer restrictions and privileged changes need separate evidence.
A team integrating simulation into a product should commission review of the full data path: request construction, provider call, output decoding and final signing payload. The Pharos Production member profile provides one technical service reference. Ask for evidence that the displayed preview corresponds to the exact request the user ultimately authorizes.
After execution, verify the receipt and the resulting state appropriate to the action. For an approval, that may mean checking the allowance rather than looking for an immediate balance change. For a cross-chain operation, a source receipt may leave a destination effect pending. Preserve these distinctions in the user-facing status.
The strongest conclusion a preview can support is conditional and specific: this request produced these effects under this recorded environment. That is useful evidence. Keeping the conditions visible makes the preview more reliable as a decision aid without promising control over future state or transaction ordering.
Original fixture census: the reference scenarios are distinct
Method
- Source and selection
- Select every .io fixture under tests/eth_simulateV1/ in the complete Ethereum execution-apis tree at the recorded commit. Classify case-insensitive filename signals for validation, override and nonce. Categories overlap.
- Retrieved
- Observation
- Complete repository tree at the recorded commit; all files outside tests/eth_simulateV1/*.io excluded.
Results
| Fixture-name signal | Files | Interpretation |
|---|---|---|
| All eth_simulateV1 fixtures | 92 | Complete .io file inventory under the method directory |
| Validation signal | 12 | Filename contains a validation-related string |
| Override signal | 14 | Filename contains override |
| Nonce signal | 7 | Filename contains nonce |
| Fixtures executed here | Not run | Inventory inspection only |
The categories overlap: a single fixture name can mention both nonce and validation. Their counts must not be added to infer unique scenario coverage. We retained every selected path and its repository blob identifier so another reviewer can reproduce the inventory.
The result is an index for further testing, not a compatibility certification. A product team can use the named scenarios to decide which provider behaviors to verify, then run appropriate tests in its own controlled environment. Our research did not send transactions or claim that any wallet passed the suite.
Limits
- Filename classification only; it does not establish every assertion inside a fixture.
- No client, wallet or remote RPC service was tested against the fixture set.
- The selected repository commit fixes the inventory; later revisions can add or rename scenarios.
The reproducible record is kept in the repository: seo/research/articles-42-51-2026-09-06/surveys.py and seo/research/articles-42-51-2026-09-06/survey-51.json. These file paths are not public downloads.
Frequently asked questions
Can a hardware wallet replace transaction simulation?
It protects signing keys under its design, while simulation analyzes a proposed execution. Review the device's displayed request and the simulation assumptions separately; the two controls answer different questions.
What if a multisignature proposal executes much later than its preview?
Reassess the final payload and relevant state near execution, especially after upgrades or parameter changes. Preserve the earlier review as history rather than treating it as a current execution guarantee.
Can a read-only simulation leak information to its provider?
The provider receives the request and context sent to it. A team should account for that data flow when handling private strategy or account information, even though the call does not itself commit a blockchain transaction.