Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
LABS
Glossary

Simulation Result

A simulation result is the output of a transaction simulation, detailing whether the call would succeed, the expected state changes, gas used, and any revert reason.
Chainscore © 2026
definition
BLOCKCHAIN GLOSSARY

What is a Simulation Result?

The definitive output of a transaction simulation, detailing the predicted state changes and execution outcomes before the transaction is confirmed on-chain.

A simulation result is the comprehensive data output generated by a transaction simulator when it virtually executes a proposed blockchain transaction. This result predicts the transaction's outcome—including success or failure, final state changes, gas consumption, and emitted events—without broadcasting it to the network. It is a critical tool for developers to debug smart contracts, for wallets to provide accurate fee estimates, and for protocols to assess risk before signing. The simulation is performed on a local or remote fork of the blockchain's current state, ensuring the prediction is accurate and does not incur real gas costs.

The core components of a simulation result typically include the transaction's execution status (e.g., success, reverted), the precise amount of gas used, any revert reason or error message if the transaction fails, a list of state diffs showing changes to account balances and contract storage, and the logs (events) that would be emitted. Advanced simulators may also return trace calls, which provide a step-by-step breakdown of the internal execution path, including all internal calls and opcode-level details. This granular data is essential for understanding complex interactions, such as those involving DeFi protocols or cross-contract calls.

In practice, simulation results are foundational for several key workflows. Wallet providers and dApps use them to present users with a preview of an action's outcome, a concept known as transaction preview or simulated execution. Security tools and auditors run simulations to detect vulnerabilities or unintended behaviors in contract logic. Furthermore, MEV searchers rely on high-fidelity simulations to model the profitability of their strategies before submitting bundles. The reliability of a simulation result depends entirely on the accuracy of the simulated state, which is why services often use a recent, pinned block to create the execution environment.

key-features
SIMULATION RESULT

Key Features of a Simulation Result

A simulation result is the deterministic output of a transaction simulation, providing a detailed, pre-execution forecast of on-chain state changes, gas usage, and potential errors.

01

Deterministic State Changes

The core output is a deterministic forecast of the blockchain's state after the transaction. This includes:

  • Balance changes for all involved accounts (ETH, ERC-20 tokens, NFTs).
  • Storage slot modifications for smart contracts.
  • Event logs that would be emitted.
  • New contract deployments with their predicted addresses. This allows developers to preview the exact outcome before committing to the chain.
02

Gas Estimation & Cost Analysis

A simulation result provides a precise gas usage breakdown, which is critical for user experience and fee optimization. It details:

  • Total gas used for the transaction.
  • Gas used by internal calls (e.g., calls to other contracts).
  • Revert gas (if the transaction fails).
  • An estimated transaction cost in the native currency (e.g., ETH, MATIC). This prevents users from submitting transactions that will fail due to insufficient gas.
03

Error & Revert Detection

Simulations proactively identify execution failures and their causes, acting as a pre-flight check. The result will specify:

  • Revert status (success or failure).
  • The exact revert reason string (e.g., "Insufficient balance").
  • The program counter and opcode where execution halted.
  • Whether the failure occurred in the main transaction or a nested internal call. This is essential for debugging and building robust applications.
04

Trace & Call Tree

Advanced simulations produce an execution trace or call tree, which is a step-by-step log of the EVM's operation. This trace includes:

  • A hierarchical view of all internal message calls (CALL, DELEGATECALL, STATICCALL).
  • Opcode-level execution for deep debugging.
  • State accesses (SLOAD, SSTORE) and their values.
  • Precompiled contract interactions. This granular data is invaluable for security analysis, gas optimization, and understanding complex contract interactions.
05

Simulation Context & Inputs

The result is meaningless without its execution context. A complete simulation is defined by:

  • Block context: Block number, timestamp, base fee, coinbase.
  • Transaction context: msg.sender, msg.value, calldata, gas limit.
  • Account state: The exact state (balances, storage, code) of all involved accounts at the simulated block.
  • Chain ID: The specific network being simulated (e.g., Mainnet, Sepolia). This context ensures the simulation is an accurate replica of real execution.
06

Use Cases & Applications

Simulation results power critical infrastructure and user-facing features:

  • Wallet Transaction Previews: Showing users balance changes and costs before they sign.
  • DeFi Risk Management: Checking for slippage, liquidation risks, or sandwich attacks.
  • Smart Contract Testing: Running transactions against mainnet state in a CI/CD pipeline.
  • MEV Analysis: Identifying profitable arbitrage or liquidation opportunities.
  • RPC Provider Services: Enhanced APIs like eth_call and eth_estimateGas are built on simulation engines.
how-it-works
TECHNICAL OVERVIEW

How Transaction Simulation Works

Transaction simulation is a core blockchain development tool that predicts the outcome of a transaction without broadcasting it to the network, enabling developers to build safer and more efficient applications.

A simulation result is the complete, structured output generated by a blockchain node or specialized service when it executes a transaction in a virtual, isolated environment. This result contains a detailed forecast of the transaction's effects, including its success or failure state, any state changes it would cause, the precise amount of gas consumed, and a log of all emitted events. By analyzing this result, developers can preemptively catch errors, estimate costs, and verify the intended logic of their smart contracts before committing real assets or incurring on-chain fees.

The simulation process involves the node creating a temporary fork of the blockchain's current state. It then executes the transaction against this forked state exactly as it would on the live network, but discards the changes afterward. This execution captures every nuance, from internal contract calls and token transfers to complex DeFi interactions. Crucially, the simulation engine also validates the transaction against the latest mempool and checks for common failure modes like slippage violations in swaps or insufficient liquidity, providing a robust safety net for user-facing applications.

For developers, the most critical components of a simulation result are the status (success or revert), the gasUsed, and the logs. A revert status, accompanied by a revert reason or error code, immediately flags a problem in the transaction's logic or inputs. The gas estimate allows for accurate fee calculation and helps prevent out-of-gas errors. The event logs are essential for understanding the side-effects of the transaction, such as which tokens were transferred or which liquidity pool was interacted with, enabling applications to update their user interfaces predictively.

Advanced simulation services enhance these basic results with additional security and optimization features. They can run dry-run simulations that test multiple transaction parameters in parallel to find the most efficient path, or execute bundle simulations to predict the outcome of a sequence of dependent transactions. Furthermore, tools like MEV simulation can analyze a transaction's vulnerability to front-running or sandwich attacks by modeling its behavior in a competitive block-building environment, offering crucial protection for end-users.

Integrating transaction simulation is a best practice in modern dApp development. Wallets use it to present clear, pre-transaction approval prompts showing exact balance changes. DeFi aggregators simulate swaps across dozens of protocols to guarantee the best price for users. By relying on simulation results, these applications can move from a model of "hoping it works" to one of deterministic verification, significantly improving security, user experience, and operational reliability across the Web3 ecosystem.

ecosystem-usage
APPLICATIONS

Where Simulation Results Are Used

Transaction simulation results are a critical data source for multiple blockchain applications, enabling proactive security, optimized execution, and enhanced user experience.

03

Gas Estimation & Fee Optimization

Simulation is the foundation for accurate gas estimation. By executing the transaction against a recent state, services can predict the exact gas used and recommend an optimal gas price or priority fee (maxFeePerGas, maxPriorityFeePerGas) for timely inclusion.

  • Prevents: Out-of-gas errors and failed transactions.
  • Tools: Used by RPC providers, wallets, and block builders.
04

MEV Protection & Bundle Validation

Searchers and block builders simulate arbitrage and liquidations bundles to verify profitability before submitting them to the network. MEV relays and user-protection services (like Flashbots Protect) also simulate bundles to ensure they do not harm end-users.

  • Validation: Ensures bundles are valid and economically rational.
  • Protection: Filters out malicious front-running or sandwich attacks.
06

On-Chain Analytics & Risk Scoring

Analytics platforms and risk engines simulate transactions to score wallet addresses, token contracts, or protocol interactions. They assess potential exposure to hacks, rug pulls, or insolvency risk based on simulated stress scenarios and historical data.

  • Output: Generates a risk score or threat classification.
  • Use Case: Informing investment decisions and protocol parameter tuning.
KEY DIFFERENCES

Simulation vs. Actual Execution

A comparison of the characteristics and guarantees of a simulated transaction versus its final on-chain execution.

Feature / CharacteristicSimulation (Dry Run)Actual Execution (On-Chain)

State Mutability

Read-Only

Read-Write

Gas Cost

Estimated

Actual (Paid)

Block Context

Static / Historical

Live / Mempool-Dependent

Finality Guarantee

MEV & Frontrunning Risk

Simulated / Estimated

Real

Revert Detection

Possible (Costs Gas)

Primary Use Case

Pre-flight validation & debugging

Settlement & state change

security-considerations
SIMULATION RESULT

Security Considerations & Limitations

While simulation is a powerful tool for risk assessment, its results are not guarantees. Understanding these limitations is critical for secure protocol interaction.

01

State Dependence & Timing

A simulation result is only valid for the exact blockchain state (e.g., block number, mempool) at the time it was run. A transaction executed seconds later may fail due to state changes like price oracle updates, liquidity shifts, or a preceding transaction. This creates a race condition vulnerability.

02

Simulation vs. Execution Gap

The execution environment for a simulation (e.g., a node's EVM) can differ from the actual network's execution at the target block. Differences in gas costs, opcode behavior, or access to private mempool transactions can cause a simulated success to result in an on-chain failure or reversion.

03

Sandbox Limitations

Simulations often run in an isolated sandbox. This environment may not perfectly replicate:

  • MEV bot behavior and frontrunning
  • Cross-chain or layer-2 interactions
  • Real-time oracle price feed volatility
  • Interactions with permissioned or upgradable contracts that change post-simulation.
04

Assumption of Honest Nodes

Simulation services typically rely on the responses from one or a few nodes. This assumes those nodes are honest and providing correct state data. A malicious or compromised RPC provider could return falsified simulation results, leading to financial loss.

05

Incomplete Risk Modeling

Simulations primarily check for transaction reverts and profit/loss outcomes. They may not detect:

  • Approval phishing risks
  • Logic errors that don't cause reverts
  • Long-term economic attacks like slow drains
  • Governance or rug pull risks from privileged roles.
06

Mitigation Strategies

To reduce risk, combine simulation with:

  • Multi-source simulation using different providers
  • State overrides to test edge cases
  • Time-delayed execution to avoid mempool sniping
  • Formal verification and audits for critical logic
  • Treating simulation as a probabilistic tool, not a guarantee.
SIMULATION RESULT

Common Misconceptions About Simulation

Simulation results are foundational for blockchain development, yet their interpretation is often misunderstood. This section clarifies the technical realities behind common assumptions about what a simulation result does and does not guarantee.

No, a successful simulation does not guarantee transaction success. A simulation is a prediction based on a specific snapshot of the blockchain state at a given moment. Between the time of simulation and the actual transaction execution, the state can change due to other transactions, causing race conditions or slippage. Key factors that can invalidate a simulation include:

  • State changes: Another transaction alters a token balance, NFT ownership, or pool liquidity.
  • Gas price volatility: The maxFeePerGas used in simulation may be insufficient by the time of broadcast.
  • Mempool competition: A front-running or sandwich attack can alter the execution path. A simulation result is a high-confidence estimate, not a final guarantee.
SIMULATION RESULT

Frequently Asked Questions (FAQ)

A simulation result is the detailed output of a transaction simulation, showing the predicted state changes, costs, and potential failures before a transaction is broadcast to the network. These FAQs address common questions about interpreting and using these results.

A blockchain transaction simulation result is a detailed report generated by a simulation engine that predicts the outcome of a transaction without executing it on-chain. It works by creating a temporary, isolated fork of the blockchain's current state, executing the transaction's bytecode against it, and recording all resulting changes. The result includes key data points such as the estimated gas used, the final state changes (e.g., token balances, contract storage), any revert reason if the transaction would fail, and a list of accessed addresses and storage slots. This allows developers to preview execution, debug logic, and optimize costs before committing real funds or causing unintended on-chain effects.

ENQUIRY

Get In Touch
today.

Our experts will offer a free quote and a 30min call to discuss your project.

NDA Protected
24h Response
Directly to Engineering Team
10+
Protocols Shipped
$20M+
TVL Overall
NDA Protected Directly to Engineering Team
Simulation Result: Blockchain Transaction Preview | ChainScore Glossary