Simulating a transaction on Ethereum means running it against the blockchain’s current state to see exactly what it would do, without spending gas or broadcasting anything to the network. You find out whether it succeeds, how much gas it needs, and which balances move, before you commit to anything irreversible.
That matters because a failed transaction on Ethereum still burns real gas, and a malicious approval can drain a wallet with a single signature. Developers test contract calls this way before deployment, wallets flag dangerous transactions before you sign them, and traders check a swap’s outcome before it hits the mempool.
Here’s the short version: eth_call handles a basic read-only check, debug_traceCall and trace_call show what happens inside the call step by step, and a newer method called eth_simulateV1 can model a whole sequence of transactions at once. The rest of this guide covers how each one works and when to reach for it.
What Is a Dry Run of an Ethereum Transaction?
A simulated transaction runs the exact same code a real one would trigger — same sender, same contract, same input data — but the result never gets written to the blockchain. Think of it as a rehearsal: the Ethereum Virtual Machine (EVM) processes the call in full, then the result gets returned to you instead of committed to a new block.
Transaction simulation is executing a transaction’s logic against a blockchain’s current or hypothetical state to preview its return value, gas use, and success or failure, without publishing it to the network. See ethereum.org’s JSON-RPC documentation for where these read-only calls sit in the wider API.
The distinction that trips people up is state. A simulation reads live state — current balances, current contract storage — and calculates what would happen if your transaction executed right now. It doesn’t reserve or lock that state for you — somebody else’s transaction can still land first and change the very numbers your simulation just used.
Why Test a Transaction Before You Broadcast It?
The short answer: to avoid paying for a failure. Every Ethereum transaction, successful or not, uses gas the moment it’s included in a block — a plain ETH transfer costs a fixed 21,000 units, and a failed contract call can burn far more than that before it reverts, according to ethereum.org’s gas documentation. This is critical: that gas fee is gone whether your transaction achieves anything or not.
Failures aren’t rare edge cases, either. Etherscan’s support documentation lists running out of gas, reverted execution, and non-compliant ERC-20 transfers as routine causes, and in each case the sender’s funds stay put while the fee still gets deducted, per Etherscan’s Information Center. Simulating first catches the failure before it costs anything at all.
The stakes get larger with market volatility. During the May 2023 PEPE token frenzy, several failed transactions each burned more than $38,000 and $17,000 in gas as spiking prices pushed underpriced transactions to revert anyway — based on data shared by Blockstream’s Fernando Nikolić and reported by CryptoRank. Multiply that pattern across thousands of transactions during a busy hour, and simulation stops being optional.
There’s a security angle too. A simulation shows every balance and allowance change before you sign, which is exactly how modern wallets catch a malicious “approve” request trying to drain your tokens instead of doing what the interface claims.
Who Tests Transactions Before Sending Them?
Different people run this check for different reasons, but they’re all trying to avoid the same thing: an expensive surprise. The list below runs from casual wallet users to teams moving serious money.
- Wallet users get the most invisible version of this. MetaMask, Rabby, and most major wallets simulate a transaction the moment you click confirm, showing you the tokens you’re about to send or approve before you actually sign.
- DeFi traders check a swap’s simulated output before it executes, since slippage and thin liquidity can turn a good-looking trade into a bad fill.
- Smart contract developers run calls against forked mainnet state while building and testing, long before a contract goes anywhere near a security audit.
- Multisig signers and DAO treasuries simulate every transaction before multiple people sign off on it, since a treasury transaction is expensive to get wrong and hard to reverse once it’s out.
That last group is where usage gets genuinely heavy. Safe, the multisig wallet protocol used by a large share of DAO treasuries, sees its users run roughly 67,000 transaction simulations a month through Tenderly’s infrastructure. “Our users quite like the Simulator feature,” says Richard Meissner, co-founder of Safe. “Normally, every second or minute somebody is simulating transactions,” he noted in a Tenderly case study. For a team about to move millions in treasury funds, that habit is cheap insurance.
How Do You Preview a Transaction’s Outcome?
Under the hood, checking a transaction in advance usually means reaching for one of four JSON-RPC methods, each pulling a different lever: a quick yes/no answer, a gas estimate, a full execution trace, or a batch of hypothetical calls. Here’s what each one actually does, and when it earns its place over the others.
eth_call — The Baseline Read-Only Check
eth_call is the simplest and most widely supported way to simulate a transaction on Ethereum. It executes a transaction’s logic immediately against a chosen block — usually the latest one — and returns the result without ever creating a real transaction, per the official Geth documentation.
Because it’s read-only, eth_call also does double duty as a general-purpose query tool — it’s one of the Ethereum JSON-RPC methods used to check a token balance or contract state, not just to preview a pending transaction. Modern implementations also accept optional state and block override sets, letting you test a call against a hypothetical balance before it’s real.
The trade-off is depth. eth_call tells you whether a call succeeds and what it returns, but not the internal calls a complex contract interaction makes along the way.
eth_estimateGas — Pricing the Transaction Before You Commit
eth_estimateGas answers a narrower question: how much will this cost? It runs the transaction the same way eth_call does, then returns a gas figure instead of a return value.
That number feeds the fee calculation directly. Total cost works out to gas used × (base fee + priority fee) under EIP-1559, so a transfer using the standard 21,000 gas at a 10 gwei base fee and a 2 gwei tip costs 252,000 gwei, or 0.000252 ETH.
One honest caveat: it’s an estimate, not a guarantee. Geth’s own documentation notes the gas figure “could change when the transaction is actually mined,” since state can shift between your estimate and your broadcast.
debug_traceCall and trace_call — Seeing Inside the Execution
When eth_call’s pass/fail answer isn’t enough, debug_traceCall and trace_call open up the execution itself: every internal call and state change a contract makes while processing your transaction. That level of detail is what lets a developer find exactly where a complex DeFi transaction reverts, instead of just knowing that it did.
The two methods split along client lines. debug_traceCall runs on Geth, Erigon, and Reth and supports an onlyTopCall option to skip sub-call tracing when you don’t need it; trace_call is Erigon’s equivalent and can return several trace types, like call data and state diffs, in a single request.
Both fall under what node providers usually call Debug and Trace access — deeper method support that lets a team replay a transaction, analyze its gas use, and diagnose exactly where it failed. NOWNodes offers Debug and Trace API access alongside standard RPC on supported networks, including Ethereum, which is one way to reach these methods without running a self-hosted node with tracing enabled — a heavier setup than a standard read-only endpoint.
eth_simulateV1 — Chaining Multiple Calls Into One Request
The newest addition to the toolkit solves a problem the older methods don’t: what happens when several dependent transactions need checking in a row, not just one. eth_simulateV1 accepts an array of calls grouped into blocks, plus optional state and block overrides, and returns the result of each step as if they’d executed in sequence.
That’s a meaningfully different capability. Instead of calling eth_call three times and manually tracking how each result affects the next, eth_simulateV1 runs the whole chain in one request — useful for previewing a multi-step DeFi action like approve-then-swap before any of it goes live. The method has already shipped in Geth, Nethermind, and Reth, with multiple RPC providers exposing it on Ethereum and other EVM networks, per its specification discussion on Ethereum Magicians.
For most day-to-day checks, eth_call is still all you need. eth_simulateV1 earns its keep once a single transaction stops being the right unit of analysis.
Dry Run vs. Testnet: What’s the Difference?
These two solve overlapping but different problems, and it’s worth knowing which one you actually need. A quick check like eth_call runs against real, live mainnet state in milliseconds. A testnet deployment puts your actual contract on a persistent test network where you can run a full sequence of transactions over time, exactly like production, just with worthless test ETH.
| Factor | Simulation (eth_call, debug_traceCall) | Testnet deployment |
|---|---|---|
| Speed | Instant, single request | Minutes to set up, ongoing to run |
| State used | Real mainnet state, right now | Separate test-network state |
| Cost | Free, no gas spent | Free test ETH, but real time to deploy |
| Best for | Pre-flight checks on one transaction | Full contract lifecycle testing |
| Persistence | Nothing is saved | Contract stays live for further testing |
Neither replaces the other. Most teams simulate constantly during development and reach for a testnet at the milestones that need a realistic, repeatable environment — a full pre-launch rehearsal of a protocol, not a single function call.
What a Pre-Broadcast Check Can’t Tell You
This kind of check catches a lot, but it isn’t a guarantee. Three limitations are worth knowing before you rely on it completely.
State moves between your check and your broadcast. You’re testing against the chain as it exists right now, but by the time your real transaction reaches a block, other transactions may have already changed the balances, prices, or contract storage it depends on — which is exactly how sandwich attacks and failed swaps still catch people who checked first.
Gas estimates are still estimates, not guarantees. eth_estimateGas and eth_simulateV1 both calculate their numbers against current state, and Geth’s documentation is explicit that the result “could change when the transaction is actually mined.” Adding a safety margin on top of any estimate is standard practice for exactly this reason.
State overrides can mislead you, too, if you’re not careful. eth_call and eth_simulateV1 both let you fake a balance or storage value to test a scenario — genuinely useful for development — but a check built on an unrealistic override tells you how a contract behaves in a world that doesn’t exist, not what will actually happen on mainnet.
How to Test a Transaction Through an RPC Provider
Running this check directly means sending a JSON-RPC request to a node that supports the method you need. The process has the same shape regardless of which provider sits behind the endpoint.
- Get RPC access to Ethereum. Sign up with a node provider and generate an API key for an Ethereum endpoint — mainnet for real-world state, testnet if you’re still building.
- Build the transaction call object. Set the
from,to,value, anddatafields the same way you would for a real transaction, just without a signature. - Choose your method. Use
eth_callfor a quick success/failure check,eth_estimateGasfor cost, ordebug_traceCallwhen you need to see inside the execution. - Send the request with a block reference. Most methods accept
latestorpendingas the block parameter, depending on whether you want current or in-mempool state. - Read the result before you sign anything. A revert reason, an unexpected balance change, or a gas figure far higher than expected are all reasons to stop before broadcasting for real.
Here’s a minimal eth_call request against an Ethereum endpoint, with no signature attached since nothing gets sent. The data field carries the encoded function call, the same way it would in a real transaction:
json
{
"jsonrpc": "2.0",
"method": "eth_call",
"params": [
{
"from": "0xYourAddress",
"to": "0xContractAddress",
"data": "0xEncodedFunctionCall"
},
"latest"
],
"id": 1
}Send that to any Ethereum RPC endpoint — including a NOWNodes endpoint authenticated with YOUR_API_KEY — and the response carries the call’s return value instead of a transaction hash. Nothing gets broadcast, so the same request can be sent again and again while you adjust the inputs.
Conclusion
Checking a transaction on Ethereum before you send it comes down to one habit: preview it while it’s still free to change your mind. Whether that means a fast eth_call before a wallet signature, a full debug_traceCall while debugging a contract, or a batch eth_simulateV1 request across several dependent steps, the goal stays the same.
The tools scale with the job. A trader checking a single swap needs little more than eth_call; a team shipping a multisig treasury transaction or a complex DeFi integration gets more value from tracing and multi-call simulation. What doesn’t change is the underlying requirement — reliable RPC access to current Ethereum state, whether that node runs in-house or through a provider.
None of this replaces good judgment. A pre-broadcast check catches errors and previews outcomes, but it can’t promise nothing changes between your test and your real transaction. Treat it as the check before the decision, not the decision itself.
FAQ
Does Checking a Transaction First Cost Any Gas?
No. Methods like eth_call, debug_traceCall, and eth_simulateV1 run against node state without broadcasting anything, so there’s no gas fee and no on-chain footprint. You only pay gas once you actually sign and send the real transaction.
Do Wallets Like MetaMask Preview Transactions Automatically?
Yes, most modern wallets — MetaMask, Rabby, and others — run this kind of check behind the scenes before showing the confirmation screen. That’s how they warn you about an unusual token approval or a transfer larger than expected, before you ever sign it.
Can You Dry-Run a Transaction on Chains Other Than Ethereum?
Yes. Any EVM-compatible chain — BNB Smart Chain, Polygon, Arbitrum, and others — supports the same eth_call and debug_traceCall methods, since they all run compatible virtual machines. The request format barely changes; only the endpoint does.
What’s the Difference Between eth_call and eth_estimateGas?
eth_call returns the transaction’s actual result — the data it would send back, or the reason it reverts. eth_estimateGas skips the return value and instead reports how much gas the same call would need, which is what a wallet uses to set a gas limit.
Do You Need ETH in Your Wallet to Simulate a Transaction?
No. eth_call and eth_simulateV1 don’t require a real signature, so you can run either from an empty or hypothetical address, and state overrides let you test as though that address held a specific balance. That’s what makes simulation useful for checking contract behavior before a wallet is even funded.
