Solidity HTTP API overview

Solidity HTTP API is the read-only JSON-over-HTTP interface provided by java-tron nodes over solidified blocks. Its paths usually start with /walletsolidity/. It returns data from the latest solidified block and is suitable for exchange deposit crediting, custodial balance confirmation, accounting, bridge monitoring, and indexer backfills.

Solidity HTTP API uses the same request and response shapes as FullNode HTTP API, but serves a different block height. FullNode HTTP serves the latest head, while Solidity HTTP serves solidified blocks.

Entry point and served height

On TRON mainnet, a block usually becomes solidified in about 1 minute. The solid height only moves forward and never rolls back. For the mechanism, see Consensus and DPoS — Block solidification.

API categories

Common use cases

Confirm deposits

Exchanges, custodial wallets, and payment systems should use Solidity HTTP to query transactions and receipts. A transaction is suitable for final crediting only after the block that contains it is solidified.

Common endpoints include:

POST /walletsolidity/gettransactionbyid
POST /walletsolidity/gettransactioninfobyid
POST /walletsolidity/getblockbynum

Reconcile balances and resources

Accounting systems, custody systems, and backend ledgers should prefer Solidity HTTP for account and resource state. This avoids writing unsolidified head state into final ledgers.

Read contract state

When you need read-only contract queries based on final state, use Solidity HTTP contract APIs. They are suitable for Token balances, contract settings, and business state. Contract calls that change on-chain state still need FullNode HTTP to construct, sign, and broadcast transactions.

Difference from FullNode HTTP API

Both interfaces read from the same TRON chain. The difference is served height and API capability, not a different data source.

What Solidity HTTP does not provide

Solidity HTTP is read-only and does not provide:

• Transaction construction that changes on-chain state, such as transfers, staking, voting, resource delegation, or contract triggers.
• Transaction broadcast, such as /wallet/broadcasttransaction and /wallet/broadcasthex.
• APIs that depend on temporary local-node state, such as pending pool queries.

Use FullNode HTTP API for all write operations.

Request and address formats

Solidity HTTP uses the same JSON request and response format as FullNode HTTP. Most endpoints support the visible parameter:

Request example:

curl --request POST \
  --url 'http://127.0.0.1:8091/walletsolidity/getaccount' \
  --header 'Content-Type: application/json' \
  --data '{
    "address": "TXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "visible": true
  }'

Response format

Solidity HTTP returns the same protobuf-derived JSON shape as FullNode HTTP and follows the same proto3 default value omission behavior. A missing field usually means the field carries its default value, not that the node returned invalid data.

For the full rule and examples, see FullNode HTTP API overview.

XSS protection guidance

Although TRON APIs reduce XSS risk by setting the HTTP API Content-Type to application/json, developers should still be aware that certain API endpoints may not perform complete input validation.

To keep user data safe, escape data retrieved from APIs before rendering it in the user interface (UI), especially string fields returned when visible=true.

For complete XSS protection practices, see the OWASP XSS Prevention Cheat Sheet.

Related resources

• Confirmation semantics — distinguish broadcast success, block inclusion, receipt execution result, and solidified state
• FullNode HTTP API — standard TRON node HTTP read/write interface
• JSON-RPC API — Ethereum-compatible JSON-RPC interface
• TronGrid V1 API — account history, event logs, and aggregate data queries
• Consensus and DPoS — Block solidification — TRON block solidification mechanism