Transaction simulation is running a blockchain transaction against real chain state without broadcasting it, so a developer or agent can see balance changes, gas, and revert reasons before signing. Tools such as the Tenderly Simulator, Alchemy's simulation methods, and Foundry's Anvil fork all do this. Simulation shows what would happen at one block; it does not promise the same result at the block where the transaction actually lands.
​

This comparison scores four tools on the criteria that matter when the transaction moves real money: what state the simulation runs against, what it reports, whether it needs keys or funds, and whether it can test multi-step bundles. It then covers the gap every simulator shares and the in-transaction checks that close it. The four tools are Tenderly, Alchemy's Transact namespace, Foundry Anvil, and the sauce simulate command from Eco's Sauce SDK.
​

Key facts at a glance:

Transaction simulation executes a proposed transaction on a copy of current or historical chain state and reports the outcome without sending anything to the network. Results typically include token transfers, state changes, emitted events, gas used, and the revert reason if it fails. Nothing is signed or broadcast, so a failed simulation costs nothing.
​

Two families of tools exist. Hosted simulators, such as Tenderly and Alchemy, run the transaction on their infrastructure against live network state and return structured results. Local forks, such as Foundry's Anvil, copy chain state at a chosen block into a node on the developer's machine, so the developer can send transactions to it as if it were the real network.
​

Simulation is the first line of defense against the classic onchain mistakes: a wrong recipient, an amount off by a factor of a million because of decimals, or an approval left standing. Eco's guide on how to read a blockchain transaction explains the fields a simulation result reports.
​

Tenderly offers a dashboard and bundles with state overrides. Alchemy offers SDK and API methods that return asset changes or decoded traces. Foundry Anvil forks any EVM chain locally at a chosen block. Sauce simulate runs a compiled transaction program with an assumed balance. None of the four needs a funded wallet to run a simulation.
​

The table omits pricing on purpose. Plans and limits change often; check each vendor's current pricing page before choosing.
​

Each tool fits a different stage. Tenderly is strongest for interactive debugging and shareable results, Alchemy for programmatic checks inside an app, Anvil for test suites that need full control of a local chain, and Sauce simulate for transaction programs that compose several calls and must revert as a unit.
​

The Tenderly Simulator docs describe running transactions against live mainnet or testnet state without broadcasting anything. Users can simulate as any sender, override contract storage, fund addresses, and manipulate block context. Results include a gas profiler and call trace, and a simulation can be shared by public link, which helps when a reviewer must approve a transaction.
​

Alchemy's SDK exposes three methods in its Transact namespace: simulateAssetChanges for one transaction's asset changes, simulateAssetChangesBundle for a list simulated in sequence, and simulateExecution for decoded traces and logs. The docs note these methods do not run the transaction on the blockchain. Wallets and apps call them to show users what a transaction will do before a signature prompt.
​

Anvil is Foundry's local Ethereum node. It runs in memory and supports forking from any EVM-compatible chain at a specific block. Because the fork is local, a test suite can impersonate accounts, set balances, and replay the same scenario repeatedly. The cost is setup: someone has to run the node and write the queries.
​

Eco's Sauce SDK compiles transaction programs written in SauceScript, a TypeScript subset. Its agent docs describe sauce_simulate running the program from the account owner against the chain's current state, listing what moved or why it reverts. The assumeBalance option gives the account a balance for that simulation only, so testing a 5 USDC payment needs no USDC. The CLI command sauce simulate prints the same outcome.
​

Write the routing logic as a transaction program, simulate it against current state, then send it with hard bounds such as a minimum output written into the same transaction. This avoids a new contract deployment and audit per change. Simulation catches logic errors; the in-transaction bounds catch price moves between simulation and inclusion.
​

The Sauce launch post describes this loop as Eco's own practice: Sauce powers swap routing behind the Eco Routes API, and new routing and rebalancing logic ships as programs written, tested, and updated without a new custom contract per workflow. A typical cycle has four steps:

Teams that keep routing in contracts can follow the same loop on an Anvil fork, but each logic change then needs a deployment. Eco's guide to how intent networks handle slippage and failure covers how bounds are set in solver-based flows.
​

A simulation runs at one block, and the transaction lands in a later one. Prices, balances, and contract state can change in between, so a swap that simulated cleanly can fill worse or revert. Bounds written into the transaction itself, such as a minimum output, are the only checks that hold at the block where it executes.
​

Eco's Sauce security notes state the point plainly: a simulation runs on the chain's state at one block, prices move before the transaction lands, so a swap carries its own bounds, checked inside the program. The same page lists practical rules that apply to any swap, simulated by any tool:

This is why the strongest setups pair a simulator with in-transaction requirements. The simulator answers "is the logic right?" and the requirement answers "is the outcome still acceptable when it executes?"
​

Read a simulation result for intent, not just success. Check the recipient, the amount in the token's smallest unit, every approval the transaction leaves behind, and the minimum output on any swap. A green result means the transaction ran; it does not mean it did what the signer wanted.
​

A five-point review catches most errors that simulators cannot flag on their own:

Tenderly's shareable result links and Alchemy's asset-change output make points 1 to 3 easy to show a second reviewer. For agent workflows, the same review is the human step described in Human Approval for AI Agent Transactions.
​

Simulators share three limits: they model one block, they depend on accurate state and RPC data, and they only check what the developer asks them to show. A clean simulation of the wrong recipient is still a successful transfer to the wrong recipient. Review of intent stays a human or policy job.

These are short answers to the questions developers and operators ask most often about transaction simulation tools and what they can verify. Each answer stands on its own and points to the primary documentation used in this article, retrieved in November 2026, for readers who need the full detail.
​

Local forks such as Anvil run on the developer's machine. Hosted simulators have their own plans; check current vendor pricing pages.
​

Yes. Simulation does not sign. Tenderly lets users simulate as any sender, and Sauce simulate takes an owner address and an assumed balance, per the Sauce agent docs.
​

Yes. Tenderly bundles and Alchemy's simulateAssetChangesBundle run transactions in sequence. A transaction program can also compose several calls inside one transaction.
​

No. State can change before inclusion. Use in-transaction bounds such as a minimum output.
​

Yes, through an MCP server that exposes a simulate tool. See Claude Code vs Cursor vs Codex for onchain development.
​

Retrieved November 9 2026: Tenderly Simulator docs, Alchemy SDK Transact namespace, Foundry Anvil, and Eco's Sauce agent docs, security considerations, and launch post. No tool was benchmarked for this article and no pricing is quoted.
​

Related reading: How to Read a Blockchain Transaction, How Intent Networks Handle Slippage and Failure, Claude Code vs Cursor vs Codex, Sui PTBs and the EVM Equivalent, Human Approval for AI Agent Transactions, AI Agent Payment Errors and Debugging, When an AI Agent Sends Crypto by Mistake, Evolution of Token Approvals.
​