Add Support for eth_simulateV1 Method in Tron JSON-RPC

Background

Currently, Ethereum provides the eth_simulateV1 method, which allows developers to simulate transactions before broadcasting them. This is useful for estimating gas usage, detecting potential reverts, and debugging smart contract interactions. However, Tron Protocol does not currently support this method, which limits the ability of developers to perform pre-execution checks efficiently.

Rationale

Why should this feature exist?

Enhances developer experience by allowing transaction simulation before execution.
Reduces the risk of failed transactions due to insufficient resources or contract failures.
Aligns Tron’s JSON-RPC API with Ethereum’s, improving compatibility for developers building cross-chain applications.

What are the use-cases?

Gas and Energy Estimation: Developers can estimate energy consumption and fees before executing a transaction.
Smart Contract Debugging: Allows developers to test interactions with contracts without submitting real transactions.
Transaction Outcome Prediction: Helps applications check whether a transaction will succeed before submitting it to the network.

Specification

The eth_simulateV1 method should be implemented in the Tron JSON-RPC API, following Ethereum’s standard behavior. The method should:

Accept transaction input parameters similar to eth_call.
Return execution results, including status, logs, and estimated energy used.
Handle different contract call scenarios, including internal calls and delegate calls.
Provide error messages if the transaction would fail.

Scope Of Impact

Requires changes to the Tron JSON-RPC API.
May require modifications to the execution engine to provide accurate simulation results.
No backward compatibility issues, as this is a new method.

Status

Blocked by:

Implementation of Archive Node on TRON #6289

+1, I am also interested in this feature

https://docs.chainstack.com/reference/ethereum-simulatev1

Two questions about this proposal:

What is the approximate error between simulated transaction and real transaction. Is there any statistical data on ethereum?
After what interval, it is necessary to re simulate. Is there a recommended time for this interval?

As you say, eth_simulateV1 is a very versatile new interface.

Of course on TRON you can implement a similar simulation via /wallet/triggerconstantcontract, but the implementation details and return values are not the same as eth_simulateV1.

We will look into eth_simulateV1 as soon as possible and will continue to report back here as we make any progress.

Thank you for your suggestion.

We will look into eth_simulateV1 as soon as possible

Thanks so much

How can we prevent users from abusing this feature? I assume there should be a fee associated with calling this API. If so, how is the fee calculated?

a fee associated with calling this API

Fee for the calling 'get' request ? Why needed?

Fee for the calling 'get' request ? Why needed?

Compared to other interfaces, eth_simulateV1 incurs significantly higher computational resource consumption due to its capability to provide in-depth simulations and detailed state change information. To prevent resource abuse and ensure the stability of node services, providers typically impose restrictions(eg:resource limit/access control/additionnal fees) based on the complexity of the simulated execution(Gas consumption,Call depth,Number of contracts accessed).

Got it, thanks, it seems like the big question is how to deal with it

Background

Currently, Ethereum provides the eth_simulateV1 method, which allows developers to simulate transactions before broadcasting them. This is useful for estimating gas usage, detecting potential reverts, and debugging smart contract interactions. However, Tron Protocol does not currently support this method, which limits the ability of developers to perform pre-execution checks efficiently.

Rationale

Why should this feature exist?

Enhances developer experience by allowing transaction simulation before execution.

Reduces the risk of failed transactions due to insufficient resources or contract failures.

Aligns Tron’s JSON-RPC API with Ethereum’s, improving compatibility for developers building cross-chain applications.

What are the use-cases?

Gas and Energy Estimation: Developers can estimate energy consumption and fees before executing a transaction.

Smart Contract Debugging: Allows developers to test interactions with contracts without submitting real transactions.

Transaction Outcome Prediction: Helps applications check whether a transaction will succeed before submitting it to the network.

Specification

The eth_simulateV1 method should be implemented in the Tron JSON-RPC API, following Ethereum’s standard behavior. The method should:

Accept transaction input parameters similar to eth_call.

Return execution results, including status, logs, and estimated energy used.

Handle different contract call scenarios, including internal calls and delegate calls.

Provide error messages if the transaction would fail.

Scope Of Impact

Requires changes to the Tron JSON-RPC API.

May require modifications to the execution engine to provide accurate simulation results.

No backward compatibility issues, as this is a new method.

Status Update: This feature implementation requires completion of prerequisite Issue 6289. Until Issue 6289 is fully implemented, there will be no major updates on this issue.

However, all discussions on the following topics(Not limited) are welcome.
• Alternative implementation proposals that bypass Issue 6289 dependency
• Related technical discussions

Please continue the conversation here if you have innovative approaches. We appreciate your understanding.

+1

@halibobo1205

@halibobo1205 @yanghang8612 @Benson0224
I did implemented eth_simulateV1 method for the case, when user need simulation over head state. This might solve biggest portion of use-cases for this method.

Please take a look and share your thoughts.

Also I'm considering on adding new HTTP API endpoint simulatetriggersmartcontract that will do same simulation and provide similar output. This is required to handle case, when we have token_id and call_token_value in our transaction. EVM based JSON-RPC api doesn't handle this and can't accept those params

UPDATE: I implemented simulatetriggersmartcontract in separate branch based on proposed PR. You can check it here APshenkin#1

example of input outputs:

curl --location 'http://127.0.0.1:8090/wallet/simulatetriggersmartcontract' \
--header 'Content-Type: application/json' \
--data '{
    "owner_address": "4193a8ec1d0698a3873e942a4e3b65a6c20f7310d3",
    "contract_address": "41ca77e26553571dcd4e5e5377f39d49a17da4c1d2",
    "call_value": 100,
    "call_token_value": 50,
    "token_id": 1007240,
    "data": "",
    "trace_transfers": true,
    "validation": false
}'

{
    "transaction": {
        "raw_data": {
            "ref_block_bytes": "1bbb",
            "ref_block_hash": "8c3e135d6881e578",
            "expiration": 1779212577000,
            "contract": [
                {
                    "parameter": {
                        "value": {
                            "owner_address": "4193a8ec1d0698a3873e942a4e3b65a6c20f7310d3",
                            "contract_address": "41ca77e26553571dcd4e5e5377f39d49a17da4c1d2",
                            "call_value": 100,
                            "call_token_value": 50,
                            "token_id": 1007240
                        },
                        "type_url": "type.googleapis.com/protocol.TriggerSmartContract"
                    },
                    "type": "TriggerSmartContract"
                }
            ],
            "timestamp": 1779212626772
        },
        "raw_data_hex": "0a021bbb22088c3e135d6881e57840e8d1d58ae4335a6f081f126b0a31747970652e676f6f676c65617069732e636f6d2f70726f746f636f6c2e54726967676572536d617274436f6e747261637412360a154193a8ec1d0698a3873e942a4e3b65a6c20f7310d3121541ca77e26553571dcd4e5e5377f39d49a17da4c1d2186428323088bd3d70d4d6d88ae433",
        "txID": "87140944a312888d6c73e069c5253f146b45a992732076d9cc04b039ab5422c0",
        "visible": false
    },
    "txid": "68a5ecbdc2b0cefe859918233acfe9ce4a5a355bffcd47d5fabcdfe4e307450c",
    "constant_result": [
        ""
    ],
    "result": {
        "result": true
    },
    "energy_used": 38,
    "logs": [
        {
            "address": "eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee",
            "topics": [
                "ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
                "00000000000000000000000093a8ec1d0698a3873e942a4e3b65a6c20f7310d3",
                "000000000000000000000000ca77e26553571dcd4e5e5377f39d49a17da4c1d2"
            ],
            "data": "0000000000000000000000000000000000000000000000000000000000000064"
        },
        {
            "address": "eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee",
            "topics": [
                "e917b6ed800090e45df2bef0c9b375f409f3565e1ecada6f3e04aca5bb191ea0",
                "00000000000000000000000093a8ec1d0698a3873e942a4e3b65a6c20f7310d3",
                "000000000000000000000000ca77e26553571dcd4e5e5377f39d49a17da4c1d2",
                "00000000000000000000000000000000000000000000000000000000000f5e88"
            ],
            "data": "0000000000000000000000000000000000000000000000000000000000000032"
        }
    ]
}

@APshenkin

@APshenkin Thanks for the implementation and the detailed write-up — much appreciated. We're going through it carefully right now, including the head-state eth_simulateV1 path and your proposed simulatetriggersmartcontract HTTP endpoint for the token_id / call_token_value cases that the EVM JSON-RPC surface can't express. We'll follow up with detailed feedback on the PR shortly.

Status update: PR #6785 provides an initial implementation of eth_simulateV1 for simulations against the current head state.

During review, state-view consistency was identified as the main unresolved issue. A simulation request must execute against a single fixed state view while blocks and pending transactions may be updating chainbase concurrently. The subsequent discussion proposed pinning the latest committed block snapshot and retaining the existing overlay for state changes between simulated calls, but this approach has not yet been validated or implemented.

As a result, the PR cannot be merged in its current form. Historical-block simulation and state/block overrides remain separate follow-up work dependent on the archive-node capabilities tracked in #6289. The proposed simulatetriggersmartcontract endpoint should also be considered separately after the shared simulation and isolation model is settled.

This issue will remain open to track further progress.

Navigation Menu

Repository navigation

Add Support for eth_simulateV1 Method in Tron JSON-RPC #6199

Background

Rationale

Specification

Scope Of Impact

Status

Background

Rationale

Specification

Scope Of Impact

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add Support for eth_simulateV1 Method in Tron JSON-RPC #6199

Description

Background

Rationale

Specification

Scope Of Impact

Status

Activity

DmytroShalaiev commented on Feb 18, 2025

DmytroShalaiev commented on Feb 18, 2025

abn2357 commented on Feb 19, 2025

yanghang8612 commented on Feb 19, 2025

DmytroShalaiev commented on Feb 20, 2025

SeriousCoding789 commented on Feb 21, 2025

DmytroShalaiev commented on Mar 10, 2025

angrynurd commented on Mar 14, 2025

DmytroShalaiev commented on Mar 14, 2025

HamiAlyasin54 commented on Mar 28, 2025

Background

Rationale

Specification

Scope Of Impact

5 remaining items

Benson0224 commented on Jul 24, 2025

wafeishushu commented on Jan 20, 2026

jiangjinyuan commented on Jan 20, 2026

APshenkin commented on May 19, 2026

yanghang8612 commented on May 21, 2026

yanghang8612 commented on Sep 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions