Node Types and the API Data Surface

Nothing about the chain reaches you directly. Every balance, every transactionA signed instruction ("tx" for short) that changes on-chain state — transferring value, calling a contract, or updating an account's settings. Once it is included in a block and that block reaches finality the record is permanent: later transactions can supersede its effects, but the entry itself can never be edited or deleted. Before finality, a freshly included transaction can still be reversed if its block is reorganized out., every event is served by a node answering an API query, and nodes do not all answer the same way. The data surface has two depths, the latest state and the solidified state, and reading the wrong one is how a confident finding ends up built on a transaction that no longer exists.

This article is about where on-chain data comes from: the node roles, the two query surfaces a Full Node exposes, and why the same question can have a provisional answer and a final one. The mechanism that makes a block final — solidification through consensus — is the subject of the field-book chapter Block Finality and Solidified Blocks; here the concern is the data surface that mechanism produces.

Three kinds of node

The work is divided three ways.

Node	Role
Super RepresentativeOne of the 27 elected block producers on the TRON network, chosen every six hours from a wider candidate pool by TRON Power voting (one vote per staked TRX); candidates ranked 28th–127th, called SR partners, earn voting rewards without producing blocks. SRs collect block and vote rewards and pass a share to their voters after deducting a self-set commission. TRON's protocol code also calls these producers "witnesses" — a term other DPoS chains such as Steem and Hive use for the same role. (Witness)	The 27 elected block producers. They run the consensus that appends blocks to the chain.
Full Node	Holds full historical data and is “the entry point into the TRON network” — it accepts and broadcasts transactions and serves the complete, latest state.
Solidity Node	Stores “irrevocable blocks, a few blocks behind Full Nodes,” which makes it “more suitable for the confirmation of transfer.”

Blocks come from the Super Representatives. Most queries go to a Full Node, which holds everything and answers fast. A Solidity Node deliberately lags: it holds only blocks that have become irreversible, which is what you want when an answer has to hold up.

In practice these are not always three separate machines. A Full Node “already supports the query of solidified blocks,” so the solidified data is available from the Full Node itself — “there is no need to build a solidity node.” In day-to-day use the distinction is which endpoint you ask.

Two answers to the same question

Both depths are served by the same Full Node, through two families of endpoints.

The /wallet/* endpoints return the latest state. A transaction shows up there as soon as it is included in a block — but, in the documentation’s words, these are “transactions that have been on the chain but not necessarily confirmed.” The /walletsolidity/* endpoints return only solidified data: “transactions that have been on the chain and solidified, that is, the transactions have been confirmed.”

So the same request — is this transaction on the chain, what is this account’s balance — can return one result from /wallet/* and a different one from /walletsolidity/*. The gap between them is the handful of most recent blocks that are on the chain but not yet irreversible. A transaction that appears on the latest surface and not on the solidified surface is real — its block just has not finished settling.

Confirmed versus unconfirmed data

What separates the two surfaces is solidification. A freshly produced block is on the chain, but it is not yet irreversible — it becomes so only after enough subsequent blocks are built on top of it by enough different producers. Until a block reaches that point, the transactions in it can, in principle, still be displaced.

The solidified surface exists to hide that uncertainty. It withholds a transaction until the block carrying it can no longer be reversed, which is why the documentation calls the Solidity data “suitable for the confirmation of transfer” — an exchange crediting a deposit, or an analyst recording a movement as fact, wants the version that will not be walked back. The exact rule for when a block crosses into irreversibility, and how many producers it takes, is the substance of block finality; the data-surface consequence is that /walletsolidity/* shows you only the settled chain.

The event surface

Queries are not the only way data leaves a node. Through event subscription, a node streams the event logs that contract executions emit — the same Transfer and Approval records that carry tokenA unit of value recorded inside a smart contract rather than in the chain's native ledger — the contract keeps the balance table, and moving tokens means asking the contract to update it. Not to be confused with a coin, which is the chain's built-in asset (TRX on TRON) used to pay for the network itself. movement — as they are produced, with no query per transaction. The underlying data is the same on-chain log layer; the subscription only changes how it arrives. Indexers and monitors depend on this stream to keep up with contract activity in near-real time.

What this means for a reader

The practical discipline is knowing which surface a fact came from.

A latest-state answer is provisional. Anything from /wallet/* is true as of now and could still change. That is fine for watching activity as it happens, and wrong as the basis for a conclusion.

A solidified answer is final. Anything from /walletsolidity/* describes the irreversible chain. For a finding you will stand behind — a trace, a labeled addressA public identifier, derived from a key pair, at which an account receives funds and is looked up on-chain. Anyone can view an address's history, but only the matching private key can spend from it. TRON addresses are 34-character Base58Check strings beginning with "T"., anything you will put your name to — this is the surface to read.

And a discrepancy between the two carries information of its own. When the surfaces disagree, the difference is exactly the not-yet-final tip of the chain, so a transaction present on one and absent from the other is sitting in a block that has not solidified. Give it a few blocks and the gap closes.

The chain is one thing, but the data surface shows it at two confirmation depths, and the reader chooses which. For live monitoring, read the latest surface. For anything you intend to build on, read the solidified one.

Sources

• Deploying a Node — TRON Developer Hub — the Full Node as the network’s entry point with full historical data, serving HTTP and gRPC APIs for external queries.
• FAQ — TRON Developer Hub — the Solidity Node as storage of “irrevocable blocks, a few blocks behind Full Nodes,” making it “more suitable for the confirmation of transfer.”
• Transactions — TRON Developer Hub — the /wallet/* versus /walletsolidity/* distinction (on-chain-but-not-necessarily-confirmed versus solidified/confirmed), both served by the java-tron node itself.
• Deploy the FullNode or SuperNode — TRON Developer Hub, archived 2022 revision — the note that a Full Node “already supports the query of solidified blocks,” so “there is no need to build a solidity node.” The current page no longer carries the note; the mechanism it describes is current java-tron behavior (see the deployment reference below).
• Deploying a java-tron Node — java-tron documentation — a SolidityNode only synchronizes solidified blocks from a trusted FullNode, and since java-tron 4.8.1 is started from the FullNode binary with --solidity.
• Event Subscription — java-tron documentation — the node event surface that streams emitted contract event logs to subscribers.