A TRON Merkle root check compares an ordered set of serialized transaction records with a root in a saved block header. It is a different task from recomputing one transaction’s txID. Our local reconstruction matched all 365 records in one retained public block to its header root, but it did not independently authenticate the header or the canonical chain.
This guide is for a developer or evidence reviewer who wants a reproducible consistency test. Success means preserving the source bytes, recording the serialization assumptions, matching the saved root and showing that deliberate wrong inputs fail. No key, wallet, signature creation, transaction broadcast or node upgrade was used.
Table of Contents
Four critical TRON Merkle root checks
- Choose the correct leaf. A raw-data txID and a hash of the complete transaction record are different inputs.
- Preserve order. Reordering records changes the tree comparison.
- Use the actual odd-node rule. Our checked implementation promotes an unpaired hash rather than duplicating it.
- Limit the conclusion. Matching a saved header root does not establish header authenticity, finality or exchange credit.
The actual block and matched root
The retained public source was Mainnet block 87669202, containing 365 transactions. It came from our saved getnowblock response on November 3, 2026. We did not assemble a synthetic block or create those transactions. The header’s txTrieRoot was:
7ddf3c3e97be071cee0b978307f35fc9661627f4161cc560c48148c0f377a363
Our computed Merkle root matched that exact 32-byte value. Before building the tree, we reserialized each transaction’s raw_data from its original raw_data_hex and required an exact byte round trip. All 365 passed. SHA-256 of each raw-data byte sequence also matched the provider’s corresponding txID, for another 365 identity comparisons.
Those checks catch a reconstruction problem early. If a package changes a field representation or loses an integer, the raw-byte assertion must stop this reader before a convenient-looking root is reported. They do not prove that every possible protocol field or future SDK version will serialize identically.
Why txIDs are not the Merkle leaves in this method
The pinned java-tron TransactionCapsule source distinguishes hashing raw_data for the transaction identifier from hashing the complete transaction representation for its Merkle hash. Our sample reconstruction included signatures and the returned transaction-result enum. We did not replace those complete-record leaves with the printed txID strings.
The first actual record’s txID was ce42f6a73283a53722b877990b0f500cb2558eccaa8bb3c711d7a3f5459dfeb1. Its complete-record leaf hash was 5d51f578dfdbcf4ac1570637b9e6e922eb718e258a0a2c2804bb8d57bd373b27. These values differ because they refer to different serialized inputs. Neither should be relabelled as a whole-file fingerprint or a contract-method selector.
Our serializer handled this sample’s result entries, which contained contractRet. It rejects unhandled result members instead of silently discarding them. A different block can need a reviewed adaptation. The fact that all records in this sample passed is not a claim of complete protobuf-field coverage for arbitrary blocks.
The Merkle root depends on order and the odd-node rule
The pinned java-tron MerkleTree source combines adjacent left and right hashes, while an unpaired node retains its hash at the next level. We used SHA-256 for the checked public sample. This is not a claim about every alternative cryptographic-engine configuration.
| Level in our local tree | Hash count |
|---|---|
| 0 | 365 |
| 1 | 183 |
| 2 | 92 |
| 3 | 46 |
| 4 | 23 |
| 5 | 12 |
| 6 | 6 |
| 7 | 3 |
| 8 | 2 |
| 9 | 1 |
The width sequence is evidence from our run, not a network throughput metric. Beginning with 365 leaves produces 183 hashes at the next level, then eventually one Merkle root. An odd count appears at several levels, so treating the odd-node rule as an incidental final-step detail would give the wrong result.
We tested the deliberately wrong duplicate-odd rule against the same leaves. It produced a different root. A plausible Merkle implementation copied from another protocol therefore cannot be assumed correct for this source. The comparison must identify the serialization, hash function, ordering and odd-node behavior together.
Two local paths and five negative controls
We generated membership routes for positions 0 and 364, the first and last saved records. Both reconstructed the saved header root from their corresponding complete-record leaf. The routes preserve whether a sibling belongs on the left or right and explicitly represent a promoted unpaired node.
These were paths generated from the same retained block used to build the tree. They are useful consistency fixtures, not independently obtained light-client proofs. We did not fetch an authenticated checkpoint, validate witness signatures or prove that this header is on the canonical chain.
| Local negative control | Observed outcome |
|---|---|
| Alter the first serialized record | Recomputed root differs |
| Use that altered leaf with the original first path | Path comparison rejects |
| Swap the first two ordered leaves | Recomputed root differs |
| Use txIDs as leaves | Recomputed root differs |
| Duplicate every unpaired hash | Recomputed root differs |
The modified bytes stayed local. We did not broadcast a malformed transaction or make a claim that its new contents were valid. A negative control asks whether this comparison distinguishes an altered input from its saved original. It does not measure resistance to every possible forgery or replace a cryptographic security analysis.
Download the original read-only worksheet
Download the checked Merkle worksheet ZIP. It contains check.cjs, the retained public block.json, a source-and-file manifest and a README. The reader was run locally with Node 24.19.0 and TronWeb 6.5.1. It reads local files and writes test-results.json; it contains no signing, broadcast or network request.
The package is pinned because its reader uses TronWeb’s bundled protobuf module. Another package release may move that internal module or change behavior. The README names the dependency and the scope instead of promising arbitrary-version compatibility. Installing the package is a separate environment step; running this reader does not configure a node or attach a wallet.
- Download and extract the worksheet into a separate folder, then inspect its files and README.
- Use the documented pinned dependency. Keep the supplied block.json unchanged as the original input.
- Run
node check.cjs block.jsonlocally. - Check the raw-byte and txID counts, Merkle root match, two local paths and all five negative controls.
- Save the output with the source manifest. Keep any modified fixture separately from the original block.
The expected output names block 87669202 and 365 transactions. A thrown error or mismatch is an unresolved reconstruction result, not proof that the public network is invalid. Read the error first: an unsupported result field, changed package path or missing input file can stop the local program before it evaluates a root.
Keep the download fingerprint separate from the Merkle root
The checked ZIP has SHA-256 fingerprint e3b60b4656b26b5bed34917a27008d5a4879e30d6ecd0a26f1471d9a5a4efb79. This fingerprints the exact archive bytes we prepared. It is not the block’s txTrieRoot or a transaction identifier. Repacking the same extracted files can change the ZIP fingerprint without changing the block data or the local Merkle result.
The included manifest also fingerprints block.json and check.cjs separately. Compare those entries before editing a fixture so you can retain an unchanged baseline. A failed file comparison means the copy differs from that baseline; investigate the file path or modification before interpreting a subsequent tree result.
A hash printed on the same site as a download does not independently authenticate that site. Here it makes the tested archive reviewable and distinguishes an edited copy from the retained original. Keep file integrity, local Merkle consistency and trust in the expected header as three separate evidence questions.
What this Merkle root match leaves unverified
We did not independently verify the block header hash, its witness signature, the parent chain or consensus finality. A saved response containing a self-consistent body and header can pass this local test without providing those additional trust guarantees. The source of the expected root is part of the evidence, not something the calculation authenticates by itself.
Nor does a Merkle root match establish that a token transfer has the intended economic meaning. A returned execution status, a function’s output, a token event, ownership and an exchange credit are separate questions. Preserve the exact question your evidence answers rather than expanding a successful hash comparison into a payment guarantee.
The program has no empty-tree policy and is designed for this nonempty sample. It does not monitor later blocks, compare providers or make a chainwide error-rate estimate. If you adapt it, keep your new source and cases separate so readers can distinguish the original tested worksheet from an unverified extension.
Choose the next verification task
Use our TRON block-page reading guide to identify a header and record list. Use the raw-data txID comparison method for a single transaction’s identity bytes. Use the signature-length and byte-preservation review when distinguishing a complete signed record from a raw-data identifier. This Merkle root worksheet adds the ordered full-block comparison.
Frequently asked questions
Is a TRON txID the Merkle leaf used here?
No. This method hashes the complete serialized record, while the txID comparison uses raw_data bytes.
Did all 365 records match the saved header?
Yes, under the stated serializer and SHA-256 method. That is a local body/header consistency result.
Should an odd hash be duplicated in this tree?
The checked source promotes it. Our deliberate duplicate-odd control did not match the saved root.
Does the Merkle root match prove finality or exchange credit?
No. We did not authenticate the canonical chain, witness signature or a service ledger.
Does the downloadable reader contact a node or wallet?
No. The tested reader processes local files only. Dependency installation and input provenance remain separate responsibilities.
Independent Tronscan News tutorial with AI assistance, checked November 3, 2026. Original evidence: one public block, 365 raw-byte round trips, 365 txID comparisons, one Merkle root match, two local paths, five negative controls and two diagrams. The Tronscan News homepage links to standards and corrections.
Leave a Reply