FAQ: Simulations

Dashboard shows simulations you’ve done via the Simulator UI, Simulation API (with save or save_if_fails set to true). RPC simulations do not get persisted and are not shown in the dashboard.

No, simulations cannot be deleted. Feel free to contact support via the in-app chat or support@tenderly.co should you have additional questions.

Yes, you can advance the block number or timestamp in a simulation. To do this, please follow these steps.

In simulations, all addresses are unlocked by default. This means you can simulate transactions from any address to any address.

Learn more about how to use Transaction Simulator in development and testing here.

The format for tuples is JSON. Here’s an example of a tuple:

{
  "tokenIn": "0x3Df2f692132f55b97cc9DA04A1fFFEA82F511333",
  "tokenOut": "0x31254874432f55b97cc9DA04A1fFFEA82F5d7122",
  "fee": 100,
  "recipient": "0x3D555552132f55b97cc9DA04A1fFFEA82F5d7122",
  "deadline": 1630403200,
  "amountIn": 10000,
  "amountOutMinimum": 9000,
  "sqrtPriceLimitX96": 7894561250
}

An example from Simulator UI:

You can simulate token transfers by running a single simulation with the Simulation API. This will allow you to verify how tokens move between addresses and ensure the contract logic is correct before deploying.

You can integrate Tenderly’s Simulation API or Simulation RPC into your dApp UI by calling the API to simulate transactions and display the resulting state changes, asset movements, and gas estimates to users before they confirm transactions.

Yes, bundled simulations allow you to test multiple contract interactions in one simulation. The state is updated after each transaction, allowing you to verify complex contract interactions.

You can also simulate bundles of transaction using tenderly_simulateBundle RPC

When a transaction reverts during a simulation, the API provides detailed error messages to help debug the cause of the revert. This can be used to correct the logic before broadcasting the transaction.

The Tenderly Simulation API returns asset balance changes as part of the simulation result. You can use this data to show users how their token balances will change after the transaction.

Yes, the gas estimation feature in Tenderly allows you to simulate contract functions and get an accurate gas estimate before the transaction is executed. This helps ensure the transaction will succeed and minimizes gas costs.

Besides Simulation API, you can use tenderly_estimateGas and tenderly_estimateGasBundle.

Bundled simulations allow you to simulate multiple transactions in sequence, preserving the state from one transaction to the next. This is useful for testing complex workflows, such as multi-contract interactions or dApp user flows.

When a simulation fails, the Tenderly API provides detailed error messages. You can use these messages to display meaningful error feedback to users in the dApp UI, helping them correct their transaction before retrying.

You can trigger simulations programmatically by making a POST request to the /simulate REST API endpoint or tenderly_simulateTransaction RPC, passing transaction details. This helps verify the success of a transaction in a controlled environment before it’s sent to the network.

Yes, you can use state overrides to modify contract storage variables, account balances, and other on-chain data for the simulation.

Yes, you can integrate the gas estimation feature of Tenderly’s API into your UI to show users the estimated gas cost for their transactions before they confirm.

Alternatively, you can use tenderly_estimateGas and tenderly_estimateGasBundle.

You can simulate transactions from multiple wallets by running individual simulations with different from addresses. This allows you to test how your contract behaves in multi-user scenarios.

You can simulate function calls with invalid or out-of-bound inputs by setting custom input values in your simulation requests. This allows you to test how your contract handles edge cases and prevents potential vulnerabilities.

Yes, you can simulate complex transactions such as flash loan attacks or interactions across multiple contracts by bundling the transactions in one simulation. This is helpful in testing for vulnerabilities in DeFi protocols.

By bundling transactions in a single simulation, you can test cross-contract interactions and verify that the transaction flow behaves correctly across multiple contracts. This is critical for dApps that rely on complex contract interactions.

You can bundle multiple user actions by simulating them as part of a single bundled simulation. This allows you to provide feedback on complex transaction flows that involve multiple interactions in your dApp.