Transaction Simulation APIs: Coverage, State Drift and Pricing

Four different products are often called transaction simulation

The market uses one phrase for several technically different capabilities. A useful buying process starts by separating them.

The simplest layer is eth_call. It executes one call against a selected block state without publishing a transaction. It is excellent for contract reads and basic dry runs, but it does not inherently model a sequence of dependent future calls or provide a human interpretation of asset changes.

The next layer is standardized stateful simulation such as eth_simulateV1. The Ethereum Execution API specification defines it as a method that executes a sequence of message calls where later calls can build on state produced by earlier calls. It also allows state and block overrides, which makes it useful for hypothetical balances, contract storage and future-like block conditions.

A dedicated platform such as Tenderly adds a much larger analysis layer around execution. It can decode traces, expose state and balance changes, replay historical transactions, impersonate accounts, build bundles and preserve a virtual environment that continues from a modified state.

Account abstraction infrastructure introduces another specialized category. Pimlico's simulation-related RPC is centered on a UserOperation entering an ERC 4337 EntryPoint. The endpoint estimates pre-verification, verification and call gas while applying EntryPoint validation rules. This is highly valuable for a smart-account product, but it is not the same interface as simulating an arbitrary EOA transaction and receiving a decoded nested call tree.

Tenderly: strongest general purpose simulation surface

State overrides and virtual environments

State overrides are useful when the real wallet does not yet have the balance, allowance or contract storage required to explore a scenario. Tenderly currently exposes balance and storage overrides in its simulation environment and supports impersonation, time manipulation and virtual networks that can remain synchronized with mainnet.

This enables a different class of test from a one-shot preview. A team can modify a governance parameter, execute a transaction, continue from the resulting state, then run another transaction. For protocol engineering, incident response and treasury planning, that is often more useful than a stateless API response.

Bundles and nested calls

Simulation bundles let several transactions execute in order so state changes from the first become inputs to the second. This is relevant to approval plus swap sequences, protocol migrations, treasury rebalancing and wallet batches. It also maps naturally to increasingly common wallet batching patterns discussed in TokenToolHub's ERC 5792 wallet batch transaction guide.

The important distinction is that a transaction bundle is not automatically atomic on the real network merely because the simulator executed the sequence together. Your production submission mechanism determines whether users can experience partial completion. Treat simulation order and execution atomicity as separate properties.

Pricing needs a sales quote for API-heavy team use

Tenderly's current public pricing page no longer presents one fixed self-serve API tier for teams. It says the team offering is composed from Console, Simulator, Monitor and Node capacity according to the workload. The free individual plan includes browser-based single-transaction simulation but explicitly does not include API access.

This means a serious cost comparison needs a quote based on expected monthly simulation count, chain coverage, history depth, virtual environments, team size and support requirements. Older public Tenderly unit allowances can be useful historical context, but they should not be used as a current procurement price.

Pimlico: specialized simulation for ERC 4337 transaction infrastructure

Pimlico state overrides

Pimlico currently supports a third state-override parameter on eth_estimateUserOperationGas for supported EntryPoint versions. The documentation specifically demonstrates overriding an account balance and storage so estimation can proceed under a hypothetical state.

This is useful when a smart account has not yet received enough native gas, when deployment state is incomplete, or when a test needs a known storage value. It should still be treated as a hypothetical scenario. If the real chain does not have that override when the UserOperation is submitted, execution can differ.

Pimlico pricing can be modeled from API credits

Pimlico's current pay as you go plan has no monthly subscription fee, requires a payment card for mainnet access and includes 10,000,000 API credits per month. Usage beyond that allowance is currently priced at $1 per additional 100,000 credits. The documented cost of eth_estimateUserOperationGas is 200 credits.

If the only Pimlico call in your model were gas estimation, 50,000 estimates per month would consume the included 10 million credits. At 250,000 estimates, the monthly total would be 50 million credits, leaving 40 million billable credits, which is roughly $400 for that month at the published overage rate. One million monthly estimates would consume 200 million credits and produce about $1,900 in monthly overage after the included credits.

Real applications also call eth_sendUserOperation, paymaster endpoints, status methods and other APIs. Those calls have their own credit costs, so the simulation-only model should never be presented as the final Pimlico bill for a production smart-account application.

eth_simulateV1: the standard RPC primitive to watch

The Ethereum Execution APIs specification defines eth_simulateV1 as a stateful simulation method rather than a branded analysis product. It can execute one or more simulated blocks, each containing one or more message calls. Calls inside the sequence build on previous state without writing to the real blockchain.

The method supports account and contract state overrides as well as block overrides. Balance, nonce, code or storage can be changed for a simulation. Block parameters such as number, timestamp, gas limit, fee recipient and base fee can also be altered. Validation mode can make execution more closely resemble real block inclusion rules, while transfer tracing can expose native ETH transfers as log-like data.

This standard is valuable because it reduces dependence on proprietary simulation APIs. A wallet or backend can build its own interpretation layer on top of a common execution primitive when its RPC provider and execution client support the method.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_simulateV1",
  "params": [
    {
      "blockStateCalls": [
        {
          "stateOverrides": {
            "0x1111111111111111111111111111111111111111": {
              "balance": "0x56BC75E2D63100000"
            }
          },
          "calls": [
            {
              "from": "0x1111111111111111111111111111111111111111",
              "to": "0x2222222222222222222222222222222222222222",
              "value": "0x16345785D8A0000"
            }
          ]
        }
      ],
      "validation": true,
      "traceTransfers": true
    },
    "latest"
  ]
}

The example intentionally changes the sender balance inside the simulated state. It does not fund the real address. The response describes what the execution client predicts under those supplied conditions.

What standard RPC simulation does not give you automatically

eth_simulateV1 returns execution results, logs, gas data and simulated block information. It is not a complete clear-signing product. It does not automatically tell a retail user that a call grants an unlimited token allowance to an unfamiliar spender or that a nested delegatecall reaches upgradeable logic.

Your application must decode ABIs, map contracts to identities, interpret token transfers, recognize approvals, calculate human-readable amounts and decide which warnings deserve prominence. TokenToolHub's clear signing guide explains why execution data and human-readable transaction intent are related but different layers.

Alchemy's custom Simulation APIs are a migration case, not a new buying target

Alchemy's legacy custom simulation endpoints provided several useful capabilities. alchemy_simulateAssetChanges returned native, ERC-20 and NFT asset effects. alchemy_simulateExecution returned decoded logs and either flat or nested execution traces. Bundle variants simulated several transactions sequentially.

Those endpoints are scheduled for deprecation on September 30, 2026. That is the immediate procurement fact that matters now. A team already using them should verify Alchemy's recommended migration path. A team selecting a new provider should not build a fresh dependency on endpoints scheduled to disappear.

The deprecation is also a useful reminder that proprietary simulation interfaces create migration cost. Store your internal transaction model separately from the provider response so another backend can replace it without forcing a redesign of the wallet UI.

Coverage matrix: what each option can actually answer

State drift is the central limitation of every transaction preview

Simulation is deterministic only relative to the state and environmental assumptions provided to the EVM. Production execution can occur several blocks later. In that interval, the state the transaction reads can change.

A token balance can move. An allowance can be revoked. A Uniswap pool can receive a large trade. An oracle can update. A lending position can cross a liquidation threshold. A nonce can be consumed by another transaction. An upgradeable proxy can change implementation. A contract can pause. A time-dependent check can cross a deadline.

When any of those values influence control flow or output, the preview can diverge from execution even though the simulator behaved correctly.

How to test preview versus execution differences

The most informative benchmark is not latency alone. Create a small corpus where you know which cases should stay stable and which should drift if state changes between preview and execution.

Use a safe test environment such as a local fork, testnet, Tenderly virtual environment or contracts specifically deployed for the exercise. Do not create deliberately risky mainnet transactions merely to test a simulator.

For each case, run a preview against a pinned block, save the response, then execute the benign transaction in the test environment. Compare status, logs, balance changes, gas and return data. For the drift case, deliberately change one relevant state variable between simulation and execution and confirm that your application identifies the preview as stale rather than blaming the simulator.

A simulation result needs an evidence envelope

If a wallet tells a user “you will receive 1,000 USDC,” that statement should be traceable to more than one API response. At minimum, save the chain ID, simulation block number, block hash, sender, destination, value, calldata hash, state overrides, simulator version or provider, response timestamp and any minimum output encoded in the transaction.

For a protocol integration, also save the implementation address of relevant proxies, important oracle observations and the contract identities used to decode nested calls. The purpose is not to create an enormous permanent log for every consumer transaction. The purpose is to make a high-value simulation reproducible when the eventual receipt differs from the preview.

An independent RPC source can strengthen that process. A team can use NOWNodes or Chainstack to retrieve the referenced block, contract code, storage or receipt through ordinary RPC as a second evidence path. These services are infrastructure sources, not transaction audit products, and they should not be presented as guarantees that a simulated action is safe.

Nested call support matters because dangerous behavior often happens below the top level

A wallet may call a router that calls a proxy that delegatecalls an implementation that finally invokes a token. Looking only at the top-level to address hides most of the execution.

Dedicated trace-oriented simulation is valuable because it can reveal those internal frames, emitted events and balance changes. Tenderly is especially strong here because tracing and debugging are core product surfaces. Alchemy's legacy execution simulator also offered nested call output, but its deprecation makes that feature unsuitable as a long-term procurement reason.

Standard eth_simulateV1 should be viewed as an execution primitive. It gives you call results and logs for the simulated calls, but a production wallet that needs a human-readable nested execution tree should plan for additional trace, ABI and labeling infrastructure.

This is also where contract baseline research helps. TokenToolHub's Token Safety Checker can provide contract-side context for supported EVM tokens before a transaction is simulated. The simulation then answers what the proposed transaction does against current state. Neither layer replaces a full audit.

Upgradeable contracts create a simulation continuity problem

A preview can be correct at block N and irrelevant after an implementation upgrade at block N+1. If the target uses a proxy, store the implementation address observed during simulation. If execution occurs after the implementation changes, the original preview should be considered stale even if calldata and sender are unchanged.

For systems where implementation changes are material, use TokenToolHub's Smart Contract Diff as a separate change-detection layer. A source or bytecode change can explain why a previously understood call no longer behaves the same way. Simulation predicts one state; contract-diff evidence helps determine whether the code itself changed.

Batched wallet transactions need sequence-aware simulation

Wallet batching creates a failure mode that single-call previews miss. Consider a sequence that approves a token, swaps it and deposits the output into another protocol. Simulating only the final deposit against current chain state can fail because the simulated wallet does not yet own the output token. Simulating only the first approval says nothing about the economic result.

A sequence-aware simulator executes the steps in order. Tenderly bundles and eth_simulateV1 both support state progression across multiple actions, although their interfaces and outputs differ. Smart accounts can also encode several calls into one UserOperation, which is where Pimlico's account-abstraction-specific path becomes relevant.

ERC 5792 makes batch-oriented wallet behavior increasingly important because applications can request groups of calls through wallet interfaces. The simulator must model the same ordering and atomicity assumptions that the wallet will ultimately use.

Unsupported behavior should be an explicit product state

A simulation system becomes dangerous when unsupported behavior silently looks successful. Build a specific unsupported category into your integration.

Potential examples include chain-specific precompiles that the simulator does not implement, external off-chain dependencies, native bridge state not mirrored into a fork, proprietary oracle mechanisms, private mempool conditions, sequencer-specific behavior or a new transaction type that the backend has not yet adopted.

Cross-chain behavior deserves particular care. A simulation on chain A can show that a bridge deposit succeeds. It cannot automatically prove that a relayer, validator set or destination contract on chain B will complete later unless the product explicitly models the full cross-chain system.

When a feature is unavailable, say unavailable. Do not substitute a generic eth_call and label the result equivalent.

Simulation API pricing and annual operating cost

Pricing models differ too much for one universal cost-per-simulation table. Tenderly currently scopes team API capacity through a quote. Pimlico publishes credit pricing. Standard RPC simulation inherits the RPC provider's request accounting and method support. Alchemy's custom simulation endpoints are being retired.

The Pimlico numbers isolate one RPC method so the arithmetic remains auditable. A production smart account uses additional endpoints. Paymaster sponsorship also has a separate on-chain gas surcharge under Pimlico's current terms. Use dashboard exports or a recorded method mix to calculate the full operating cost.

For standard RPC simulation, ask the provider whether eth_simulateV1 is supported on every required chain, how the method is weighted, what historical state is available and whether there are per-request gas or payload limits. The Ethereum specification explicitly allows clients to set their own limits for simulated blocks, total gas and request payload size.

How RPC infrastructure fits the workflow

A simulation provider and an RPC provider can be the same company, but they solve different procurement questions. RPC gives access to blockchain state. A simulation platform adds execution modeling, decoding and workflow controls. Keeping those layers conceptually separate makes migration easier.

For reproducibility, it can be useful to maintain an independent RPC endpoint for evidence collection even when Tenderly handles simulation. NOWNodes currently offers request-based shared access and dedicated infrastructure across many chains. Chainstack offers request-based plans plus flat-capacity Unlimited Node and dedicated options. Either can support block, code, storage and receipt collection where the specific chain and method are available.

Do not buy a second RPC provider because an article says redundancy is always necessary. Add it when the cost of an unresolved discrepancy or single-provider outage justifies the extra infrastructure.

A repeatable provider test methodology

Use three groups of cases: benign, known-risk and unsupported. Define the expected classification before submitting anything so the review is not biased by whichever provider returns the prettiest output.

The benign group should contain a native transfer, simple ERC-20 transfer, standard approval and known swap on a test environment. The known-risk group can contain an intentionally excessive approval to your own harmless test spender, a transaction designed to revert, a price-sensitive swap near its minimum output and an upgradeable proxy where the implementation is known. The unsupported group should contain at least one chain-specific or cross-chain behavior that you know the product cannot fully model.

Measure semantic coverage, not only response time

A simulator that returns in 120 milliseconds but fails to expose an approval can be worse for a wallet than one that returns in 300 milliseconds with a complete asset and call interpretation. Define coverage requirements before latency targets.

For a clear-signing product, count how many expected transfers, approvals, NFT movements and nested calls were correctly surfaced. For a protocol engineering product, count whether revert locations, storage changes and call paths match the known test contract. For account abstraction, compare estimated gas and validation errors with the eventual UserOperation receipt.

Migration and exit constraints

Provider-specific response schemas are the main source of lock-in. If your front end reads Tenderly fields directly in twenty components, moving to another simulator becomes expensive. Normalize every provider response into an internal model such as calls, asset changes, approvals, errors, gas, state anchor and warnings.

Store raw provider responses separately for debugging, but keep application decisions based on your normalized schema. That lets you run two providers side by side during migration and compare output field by field.

Keep simulation policy separate from provider selection as well. A rule such as “warn when allowance exceeds requested spend by 10x” belongs in your application policy. It should not disappear because a provider changes.

Alchemy's September 30, 2026 deprecation is a live example of why this architecture matters. A stable internal schema can migrate from a discontinued custom simulation endpoint to standard RPC or another platform without rewriting the user experience from scratch.

Simulation is not audit assurance

A transaction simulator explores a concrete execution path. An audit asks a much larger question about the code and its possible behaviors. Simulation can show that one transfer succeeds, but it does not prove that a privileged owner cannot mint later, that every reentrancy path is safe or that a proxy admin cannot upgrade the implementation.

Use simulation alongside contract research rather than replacing it. TokenToolHub's Crypto Research Tools Stack provides a broader workflow for separating contract inspection, wallet research and execution evidence.

The strongest wallet preview can still be wrong about intent if the user is interacting with the wrong contract. Clear signing should therefore show contract identity, network, asset changes and approval scope, not simply a green simulation status.

When to reject a simulation provider for the workload

Transaction simulation API acceptance checklist

Conclusion: simulation quality is coverage plus freshness plus evidence

The market for transaction simulation API providers is easier to evaluate once the products are separated by job. Tenderly, Pimlico and standardized RPC simulation can all execute hypothetical EVM behavior, but they operate at different layers and return different kinds of evidence.

The purchasing limitation with Tenderly is current pricing transparency. Tenderly's public 2026 pricing page gives individuals free browser simulation, while team API capacity is scoped through a commercial plan rather than one fixed public per-request rate. Buyers should request pricing using their real monthly simulation count, environment count, chain list, history requirement and support level.

Pimlico should be evaluated differently. It is not primarily a general EVM transaction preview vendor. It is account abstraction infrastructure. Its eth_estimateUserOperationGas call is part of the ERC 4337 execution path and understands EntryPoint validation, smart-account deployment, paymaster behavior and UserOperation gas fields.

That specialization is exactly why Pimlico can be the better product for a smart wallet even though Tenderly exposes richer general-purpose traces. A smart-account application needs to know whether the UserOperation it will actually submit can validate under the intended EntryPoint rules. Generic transaction simulation does not automatically answer that.

Standard eth_simulateV1 is the most strategically important infrastructure development. It gives execution clients and RPC services a common method for stateful multi-call simulation, including state and block overrides. A team willing to build its own decoding layer can reduce dependence on one proprietary simulator.

That control comes with engineering work. The standard method does not automatically transform logs into a wallet-ready explanation, identify contract reputation, label a token approval as suspicious or present a rich nested debugger. Execution and interpretation remain separate systems.

Reduce the preview-to-execution gap by simulating as close to signing as practical. Store the state block and hash. Capture relevant balances, approvals, implementation addresses and oracle values for important transactions. For high-value workflows, re-simulate immediately before submission if the original preview is older than your freshness policy allows.

After execution, reconcile the receipt with the prediction. This is how a simulation system becomes measurable. Record false positives, false negatives, unsupported cases and state-drift incidents. A provider should be evaluated on how often its output was useful, not only on API uptime.

Independent RPC evidence can strengthen the investigation when results differ. NOWNodes or Chainstack can provide a separate source for block state, contract code and receipts on supported networks. That does not make either provider an audit service. It gives the team another evidence source from which to reproduce what the simulator saw.

For contract-side risk, preserve a baseline before execution. TokenToolHub's Token Safety Checker can add supported EVM contract context, while Smart Contract Diff can help identify meaningful contract changes. Simulation then answers the narrower question of how a proposed transaction behaves under a particular state.

Then treat every preview as state-bound evidence. A good simulator tells you what its model predicts, preserves enough context to reproduce that prediction and makes unsupported behavior visible. That is more valuable than a claim that every transaction can be known perfectly before the blockchain decides the final state.

FAQs

References and primary documentation

• Tenderly documentation
• Tenderly current pricing and product scope
• Pimlico documentation
• Pimlico API credit pricing
• Ethereum Execution APIs eth_simulateV1 specification
• Ethereum eth_simulateV1 design and override notes
• ERC 4337 account abstraction specification
• Alchemy Transaction Simulation deprecation documentation
• Chainstack RPC pricing
• NOWNodes RPC pricing

Simulation products, RPC method support, chain coverage and pricing change over time. Verify current documentation before procurement. State overrides describe hypothetical execution and do not modify the production chain. No fabricated provider latency, accuracy or success-rate measurements are presented here. TokenToolHub automated checks and simulation providers can improve research and transaction understanding but do not provide audit, custody or incident-response assurance.