Skip to main content
Tenderly supports single transaction simulations via RPC and API. By default, simulations execute on the latest state of the chosen network. The Simulation API can also pin a historical block and a position within it (see Block number and transaction index). Dapps and wallets can use single simulations to give their users a way to dry-run transactions before committing real assets. This gives them a preview of the transaction execution along with the detailed balance and asset changes that have occurred. Transaction previews can help users build trust in dapps, approve only successful transactions, and prevent costly failures.

Simulate via RPC

Node RPC allows you to read blockchain data and send transactions. But you can also simulate transactions on the Node. The advantage of simulating via RPC is that you can perform all these operations through a single RPC URL.
Simulations via RPC or API are only available on supported networks. Check out the list of supported networks.
Retrieve your RPC URL and the access key from the Dashboard. Go to Node > Copy HTTPS URL of the desired network.
example
To simulate a single transaction via RPC, call the tenderly_simulateTransaction method. See RPC reference. Example
request

Simulate via API

Use the simulate API endpoint to simulate a single transaction with different parameters.
To use Simulations on Virtual Environments, we recommend the Simulate RPC and Bundle Simulate RPC. Otherwise, you may use Virtual Environments Simulation API.
The URL must contain your account slug and the project slug. Follow this quick guide to find the slugs.
Simulation API endpoint on public network
Simulation API endpoint on a Virtual Environment
You also need to receive the API access token, which is sent with the headers. Learn how to generate the API access key here.

Request payload

Send a POST request to the API endpoint. For full details on the request payload, see the See API reference. The simulated payload is similar to the eth_call JSON RPC call. The fields below are required:
  • network_id (string): ID of the network where you want to run the simulation.
  • to (string): The recipient address of the transaction.
  • from (string): Address initiating the transaction.
  • input (string): Encoded contract method call data.
  • gas (number): Amount of gas provided for the simulation.
You can specify any sender address in the from field. Since Tenderly simulates unsigned transactions, you don’t need to own an account’s private key to simulate transactions from a specific sender.
You can also specify the simulation_type, which can be full, quick, or ABI. This field is not required since the default is set to full. Learn more about Simulation Modes.

Block number and transaction index

block_number and transaction_index select the state the transaction executes on. Both are optional integers. Validation rules:
  • block_number is an integer. Block tags such as "latest" or "pending" are rejected with a 400 Bad request input parameters error.
  • transaction_index requires an explicit block_number. With the block omitted, a non-zero index is rejected with 400 Transaction index is not allowed when block number is pending.
  • An index greater than the block’s transaction count fails with transaction index too high: invalid transaction simulation. The index is not clamped, and there is no keyword for the end of the block.
To simulate on the post-state of the most recent block, read the block first and pass its transaction count as the index:
post-state of the latest block
The same fields drive the Tx Index control in the Simulator UI: At start of block is index 0, At tx is the chosen index, and At end of block is the block’s transaction count. When making API requests, add the X-Access-Key header with the value being the access token. Example Make sure to store the access key securely in a .env file.
request.ts

Explore use cases

Where to go next

Bundled simulations

Simulate via SDK