Background

In the TRON network, the triggerconstantcontract interface is widely used for off-chain simulation calls (dry-runs). However, this interface is constrained by the execution time limit of the TVM (mainnet, 80ms). When simulating complex contract logic or intensive state access, this can lead to out_of_time exceptions, affecting the reliability of development tools and analysis services.

While running the FullNode with the --debug flag can remove the TVM timeout restriction for triggerconstantcontract calls, this setting also removes the timeout limit for transactions within blocks during normal block processing. This can introduce potential instability or denial-of-service risks to the node, making it unsuitable for production environments.

Related issues: #6266

Rationale

Why should this feature exist?

Allowing users to configure a custom TVM timeout in dry-run calls would:

• Improve the stability of off-chain analysis tools

• Prevent false negatives for complex contracts

• Reduce misleading error codes that confuse developers

What are the use-cases?

• Data services performing bulk state queries via contract calls

• Deep cross-contract call simulation

• Simulating complex logic (e.g., loops or mappings) that exceed the default execution window

Specification

Introduce a new optional field in the triggerconstantcontract request body:

{
    ...
    "timeout_ms": 200
}

timeout_ms: Allows the caller to specify a custom timeout (e.g., 200ms). Default behavior remains unchanged (e.g., 80ms).

A maximum cap (e.g., 500ms) should be enforced to prevent abuse.

Test Specification

TODO

Scope Of Impact

• Backward-compatible API change

• TVM executor must support receiving the custom timeout

• SDKs and documentation need to be updated accordingly

Implementation

TODO

Do you have ideas regarding the implementation of this feature?

• Extend the interface parser to accept and pass the timeout_ms field

• Update the TVM executor to handle the custom timeout logic

• Enforce a reasonable upper limit to avoid long blocking operations

Are you willing to implement this feature?

Yeap, happy to do it.