Recompute a TRON TxID from raw_data_hex

TRON TxID verification can be performed offline by applying SHA-256 to the bytes represented by a transaction body’s raw_data_hex, then comparing the complete result with txID. Do not hash the JSON text or the hex characters themselves. A match establishes a relationship between the supplied bytes and identifier; it does not establish that the supplier is trustworthy, the signatures are valid, or the transaction succeeded.

This tutorial is for readers who already have an exported TRON transaction body and want a reproducible consistency check. It does not connect a wallet, create a transaction, sign anything, or broadcast data. Start with the Tronscan News guides if you need the wider record-reading workflow. The success criterion here is narrow: an exact byte input produces a complete 64-character digest and an explicit match or mismatch.

1. Understand which object the identifier describes

The transaction body contains a raw payload and signatures. TRON’s transaction protocol documentation describes the signing digest as SHA-256 of the protobuf-serialized raw payload. The check below uses the serialized bytes already supplied in raw_data_hex. It does not attempt to reconstruct protobuf bytes from the accompanying parsed JSON object.

That distinction matters when two files show the same human-readable fields. JSON permits differences in spacing and object-key order. A plain JSON dump is not the protocol’s binary serialization. Likewise, a JSON file can contain additional metadata, execution results, or application fields that are outside the raw payload used by this calculation.

Use the existing TRON TxID lookup guide when the task is finding a transaction on the correct network. This page adds an offline byte comparison after retrieval. It does not provide another explorer search box or replace the lookup guide’s network and status checks.

2. Obtain a complete body from the intended network

1. Record the network, source host, endpoint, transaction identifier and collection time. Keep this provenance beside the response rather than relying on the filename alone.
2. Request or export the transaction body. The official GetTransactionById reference distinguishes the body from the execution receipt. Its displayed example base URL is Shasta testnet; choose the actual network deliberately.
3. Inspect the response content. A successful HTTP transport response is not enough: the reference documents that an API error can be returned in an Error object even with HTTP 200.
4. Confirm that the object includes the complete txID and raw_data_hex. A receipt containing fees and logs is not a substitute for this input.
5. Save the body locally, using UTF-8, without manually rebuilding the raw byte field. Stop if the export truncates a value or substitutes an ellipsis.

For a public blockchain record, no private key, seed phrase, account password or wallet connection is required. If a support message contains private correspondence or account details, remove those from any public example. The script itself does not upload the file or make a network request.

A browser display may wrap a long value across lines without changing its content. A copied value can also acquire literal spaces or line breaks. The validator below rejects whitespace inside the hex string so that it cannot silently reinterpret an altered export. Re-export a malformed field from the documented source instead of deleting characters until the tool accepts it.

3. Run the offline TRON TxID verification code

Save this code as verify_txid.py and place your saved response in body.json. It uses Python’s standard library only. Run python verify_txid.py body.json from a local command prompt with Python available. The path names are local examples, not downloadable files hosted by this website.

import hashlib
import json
import re
import sys


def verify_txid(body):
    if not isinstance(body, dict) or 'Error' in body:
        raise ValueError('Expected a transaction body, not an API error')
    txid = body.get('txID')
    raw = body.get('raw_data_hex')
    if not isinstance(txid, str) or not re.fullmatch(r'[0-9a-fA-F]{64}', txid):
        raise ValueError('txID must contain exactly 64 hexadecimal characters')
    if not isinstance(raw, str) or not re.fullmatch(r'(?:[0-9a-fA-F]{2})+', raw):
        raise ValueError('raw_data_hex must be nonempty, even-length, unprefixed hex')
    payload = bytes.fromhex(raw)
    computed = hashlib.sha256(payload).hexdigest()
    return {
        'raw_bytes': len(payload),
        'supplied_txid': txid.lower(),
        'computed_txid': computed,
        'matches': computed == txid.lower(),
        'scope': 'Supplied serialized raw bytes only; no signature or JSON-field validation'
    }


if __name__ == '__main__':
    with open(sys.argv[1], encoding='utf-8') as source:
        body = json.load(source)
    result = verify_txid(body)
    print(json.dumps(result, indent=2))
    sys.exit(0 if result['matches'] else 1)

The program accepts only a nonempty, even-length sequence of hexadecimal byte pairs for raw_data_hex. It rejects a 0x prefix, embedded whitespace, missing fields, non-string values and a malformed transaction identifier. Uppercase and lowercase hexadecimal encode the same bytes, so case differences alone do not create a mismatch.

On a valid input, the output states the byte count, supplied identifier, computed identifier and Boolean result. A matching result exits with status 0; a validly shaped but mismatching pair exits with status 1. An invalid input raises an error before a comparison is reported. Do not treat an exception, an empty response or a stopped process as a negative blockchain result.

The algorithm is SHA-256. Substituting SHA3-256, hashing a UTF-8 string containing hexadecimal characters, or applying a second hash produces a different operation. The contract function selector has its own encoding rules; it is not the transaction identifier’s input. For the next, separate block-body consistency task, our TRON Merkle root worksheet reconstructs 365 complete records, checks two local paths and supplies a tested download. A matched saved root does not independently authenticate the header. Link checked November 3, 2026.

4. Reproduce our dated observation

We reused a public Mainnet body collected on October 29, 2026 at 01:11:35 UTC. Reusing the saved response made this calculation independent of a fresh API call. The observation used transaction 530fe4aa80f9427cb25a469abc5ebb08230db6dff8adcb97ce0ec895d3ad4a8e. The receipt associated with the original collection placed it in block 87520996, but the offline hash calculation itself does not verify that block membership.

The byte count is an observation, not a fixed TRON transaction size or a fee estimate. Another transaction type, memo or contract payload can produce a different length. Do not multiply this number by a resource price to infer the receipt fee: this program neither measures the entire serialized signed transaction nor applies network billing rules.

Our source and result files are retained in the editorial working record. This article does not offer a hosted download of that archive. You can reproduce the method against your own complete body, or retrieve the same public identifier using an appropriate Mainnet source and compare the input you actually receive. Availability, gateway limits and historical access can differ between providers.

5. Check the method with controlled failure cases

We tested the published function against the real saved body and deliberately altered copies. These altered copies are synthetic test fixtures. They are not new valid transactions, evidence of a network attack, or claims that an explorer changed an on-chain record.

The last row is intentional. A script that hashes only raw_data_hex cannot establish that every displayed raw_data field agrees with those bytes. An untrusted supplier could pair a correct raw byte field with misleading parsed fields. Full structural checking would require decoding the protocol representation and comparing its contents, using an implementation and schema appropriate to the transaction type.

Do not “fix” that limitation by serializing JSON with sorted keys. That would test a new text representation, not decode the protocol payload. Keep the reported claim aligned with the work the code actually performed. For an audit that needs independent authenticity, obtain a second trusted record or validate against your own node and a broader verification procedure.

6. Interpret a mismatch without guessing its cause

First preserve the original file. Then compare the full requested identifier, returned identifier and source network. Check for truncation, an API error, or a receipt saved where the body was expected. If fields are missing, obtain the complete body through the documented route; do not invent raw bytes from partial display text.

Next verify the exact algorithm and input. The most common methodological differences are hashing the hex text, hashing the entire JSON file, or hashing only the contract call’s data value. These are distinct inputs even if each value came from the same transaction screen. A hash mismatch establishes disagreement in this comparison; it does not, by itself, identify a malicious party or prove a chain reorganization.

If a fresh export still disagrees, keep both dated responses and escalate with the source host, endpoint, complete public TxID, network, raw byte count and computed digest. Include the error output if validation failed. Exclude account credentials and signing secrets. A concise reproducible input is more useful than screenshots of shortened addresses or a claim that “the blockchain is wrong.”

After a raw-data hash match, retain the complete signed record. Our TRON signature-length and byte-preservation worksheet checks the current TIP-935 draft, one public 65-byte observation and local boundary fixtures. Length, recovery and authorization remain separate checks; a matching txID does not authorize silently trimming stored signature bytes. Link checked November 3, 2026.

7. Record what remains outside the result

A valid hash comparison is not an authorization check. This program does not recover a signer, inspect account permissions, validate a signature or determine who controls an address. It also does not validate reference-block freshness, expiration, the canonical chain, execution success, emitted token transfers, or exchange deposit credit.

Changing a signature field in a synthetic copy leaves this script’s input unchanged, because signatures are not included in the byte string it hashes. That observation must not be interpreted as permission to alter authorization material or submit anything to the network. A node performs additional checks that this local utility deliberately does not implement.

Use a receipt to investigate execution and resource fields, and an appropriate confirmed-chain source to investigate finality. Those questions need evidence beyond a matching TxID. Even a correctly identified contract call can fail during execution. Similarly, a matching body cannot prove that a receiving service has credited an internal account.

8. A small synthetic input you can inspect by hand

Before using a long response, you can check the byte-decoding step with a tiny local fixture. The string 0001 represents two bytes, with numeric values zero and one. It does not represent the four text characters “0”, “0”, “0”, “1”. This fixture is deliberately not a serialized TRON transaction; it tests the utility’s declared byte-comparison behavior only.

In a separate test file, set raw_data_hex to 0001 and set txID to b413f47d13ee2fe6c845b2ee141af81de858df4ec549a58b7970bb96645bc8d2. Our executed check returned raw_bytes: 2 and matches: true. The input-format validator accepts these fields because it checks hexadecimal shape, not whether the bytes form a protocol-valid transaction.

Now change the raw value to 0002 while keeping that identifier. The program returns a mismatch. Restore 0001 and insert a literal space between the pairs: the program rejects the input rather than silently normalizing it. These two failures distinguish changed bytes from an invalid export format. Neither result describes network execution, because this fixture was never a network transaction.

This exercise also makes the command’s scope reviewable before you use a longer public record. If the two-byte input is reported as four bytes, check whether your own adaptation hashed text instead of decoding hex. If malformed input yields a confident success statement, review the validation path. Keep any modified code and its test output separately from the original function so a later reviewer knows which implementation produced the result.

For a command-line review, inspect the printed result before checking the exit status. In PowerShell, read $LASTEXITCODE immediately after running the Python command; another native command can replace it. In a POSIX shell, inspect $? immediately afterward. A nonzero exit can mean either a deliberate mismatch result or an execution error, so retain the output as well as the numeric status. For example, a missing file prevents the script from reading any transaction bytes at all. That is a local input failure, not evidence that a public TxID is invalid. This procedure does not monitor later file changes or keep a process running after it reports the result.

Frequently asked questions

Does a matching TRON TxID prove the transaction succeeded?

No. It confirms that the supplied serialized raw bytes produce the supplied identifier under this method. Read the execution receipt and relevant transfer records separately. This function does not evaluate execution status.

Can I calculate the hash from a screenshot of raw_data?

Not with this procedure. A screenshot of parsed fields is not the complete serialized byte field. Obtain an untruncated body that includes raw_data_hex, and preserve the response and source details.

Why does hashing my JSON file give a different value?

Your file includes a text encoding, whitespace and potentially fields outside the raw payload. A file fingerprint serves archive integrity. Decode the raw_data_hex bytes for this transaction identifier comparison.

Can I use the script on a testnet response?

The byte calculation has the same narrow role, but you must record the correct network and retrieve the body from that network. A local match does not establish which network included the transaction or whether it was included at all.

Does this require a wallet connection or private key?

No. It reads a local public transaction-body file and uses the Python standard library. It sends nothing to a node and cannot sign, reverse or broadcast a transaction.

Checked October 29, 2026 by the Tronscan News editorial team. AI assisted drafting; the displayed function and altered-input cases were executed locally against a retained public response. This independent publication is not TRONSCAN or TRON’s official support. Report a reproducible error through this page’s correction comment route, giving public source details and the affected step; never include signing secrets.