Anatomy of a Signed Transaction

Every action on TRON — a transfer, a contract call, a vote, a permission change — travels as a single object called a 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.. Most of what an on-chain reader wants to know is written on its face: who authorized it, under what authority, against which block, and how long it was allowed to live.

The object has two halves. One is a structured envelope of intent, unsigned and complete on its own. The other is an array of signaturesA cryptographic proof, produced with a private key over a transaction's exact contents, that the key holder authorized that transaction and no other. Nodes verify the signature before accepting the transaction, so a valid signature is definitive evidence the key was used — though not of who was holding it at the time. wrapped around it. The two are computed in that order, and much of the forensic signal sits right at the boundary between them.

This article works through the structure field by field, using the protocol’s own definition. It stays on the envelope and its signatures; the catalog of contract types and the mechanics of account permissionsTRON records who may act for an account directly in on-chain account state: one owner permission and up to eight active permissions, each a list of weighted keys — each key recorded as a TRON address, not a raw public key — with a threshold. Reading this structure answers, from the ledger itself, who can authorize transactions for the account right now. each have their own article, linked below where they meet the structure.

The two parts: raw_data and the signature array

In the protocol definition, the top-level Transaction message carries raw_data in field 1 and signature — a repeated bytes, meaning a list — in field 2.

A third field, ret, holds the execution result the network fills in after the fact; it is not part of what the sender builds or signs.

The raw_data envelope is where intent lives. Its fields:

Field	What it holds
contract	The action itself — a typed contract (a transfer, a TriggerSmartContract, a vote), carried as a protocol Any so one envelope shape can hold any of the roughly forty contract types.
ref_block_bytes, ref_block_hash	A reference to a recent block — the anti-replay anchor (see TAPOS, below).
expiration	The time after which the transaction “will no longer be packed.”
timestamp	The creation time set by the builder.
fee_limit	The maximum EnergyA TRON network resource that meters the computational cost of smart-contract execution, consumed whenever a transaction calls contract code — including TRC-20 token transfers such as USDT. An account obtains Energy by staking TRX or receiving a delegation from another account; if it holds too little, the shortfall is paid by burning TRX from its balance. cost the signer will allow a contract call to burn.
data	An optional memo.

The contract field also holds the Permission_id: a small integer, sitting inside the contract rather than on the outer envelope, that names which of the account’s permissions the signatures must satisfy. It defaults to 0, the owner permissionThe highest permission on a TRON account: it can authorize any transaction type and — uniquely — rewrite the account's entire permission structure. By default it is held by the account's own address with a threshold of one, and whoever satisfies the owner permission ultimately controls the account.. More on what that integer buys in the signature section below.

Everything in raw_data is chosen by whoever builds the transaction, and none of it is a signature yet. Authorization comes from the second half.

Where the txID comes from

The transaction ID is the SHA-256 hashA fixed-length fingerprint computed from data of any size by a one-way function: the same input always produces the same output, but the output reveals nothing about the input and no practical method finds a second input that matches it. Transaction IDs and block IDs are hashes, and each block embeds the previous block's hash — which is what makes tampering with history detectable. of the serialized raw_data, and of nothing else.

The protocol’s signing procedure is explicit about the order of operations: “Convert the transaction’s raw data to byte[]. Hash the raw data using sha256. This gives you the Transaction ID.” The hash is taken over the envelope. The signatures are computed from that hash and attached afterward; they are never folded back into it.

A few consequences follow for anyone reading the chain.

The ID exists before any signature does. A builder can compute a transaction’s ID, hand the unsigned envelope to a co-signer, and know the final ID in advance.

And because the hash covers only raw_data, signatures cannot change the ID. Adding a second signature for multi-sig, or replacing one signature with another valid one, leaves the txID untouched; a single envelope keeps one canonical identity no matter who ends up signing it.

The flip side is that any edit to intent produces a different transaction. Change the amount, the recipient, the fee limitA caller-set ceiling, denominated in TRX, on how much a contract call may spend on Energy — fixed at the moment the transaction is signed. If execution would cost more, it halts and its state changes are rolled back, but the resources consumed up to the stop are still charged. The fee limit is the signer's own declaration of what the call is worth to them, so habitual fee-limit values can act as a small behavioral fingerprint of the wallet software or operator constructing the transactions., the expiration — anything inside raw_data — and the hash changes, which means the ID changes. There is no such thing as the same transaction with a different amount.

The signature array and multi-signature

The signature field is a list because a transaction can require more than one signer.

Each entry is produced the same way: the signer runs ECDSA on the secp256k1 curve over the txID, and the result is “65 byte in size — r 32 bytes, s 32 bytes and v 1 byte.” The trailing v byte makes the signature recoverable: a verifier can take the txID and the 65 bytes, recover the public keyA mathematically linked pair — a private key that signs transactions, and a public key (with the address derived from it) that lets anyone verify those signatures. Whoever holds the private key controls the address: on a blockchain, ownership is key control, whatever any off-chain record says. "Keypair", "private key", and "public key" all refer to parts of this same structure. that produced them, then derive that key’s address. If the recovered 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". is one the account’s permission authorizes, the signature counts.

So the array is legible after the fact. You do not have to be told who signed; the signatures themselves yield the signing addresses.

Whether one signature is enough depends on the permission named by Permission_id. Id 0 is the owner permission, the default and the account’s highest authority. Ids 2 and up are active permissionsA delegated permission on a TRON account that can authorize only the transaction types enabled in its operations field, a bitmask with one bit per contract type. An account may configure up to eight active permissions, so an owner can grant, for example, transfer rights to an operational key without surrendering the power to change permissions. — up to eight custom permission groups, each scoped to a chosen set of operations. The id of an active permission “is automatically assigned by the network in sequence starting at 2.” Id 1, the witness permission, is reserved for a Super Representative’sOne 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. block production and cannot be used to sign an ordinary transaction.

Each key inside a permission carries a weight, and the permission sets a threshold. The rule is a sum: the operation is allowed only when the combined weight of the participating signatures meets or exceeds the threshold. A single key whose weight meets the threshold signs alone. A permission that spreads weight across several keys needs several signatures, gathered one at a time — one signer signs the envelope and passes it on, the next adds a signature, until the collected weight clears the bar.

For a reader, the array and the Permission_id together answer more than the “from” address alone can: which account acted, under which of its permissions, and with how many keys. A transaction signed under an active permission looks different from one signed under the owner key, and that difference is on-chain. The account model covers how those permissions are structured and changed; here the point is narrower. A signed transaction is a permission being exercised, and the signature array records it.

TAPOS: the reference block and the expiration

Two fields tie a transaction to a specific, recent moment on the chain. Together they are TRON’s implementation of TAPOS — Transaction as Proof of Stake.

ref_block_bytes and ref_block_hash are a compact pointer to a recent block: a slice of that block’s height and a slice of its hash. Their job is anti-replay. As the protocol puts it, the reference block “is used in the TRON TAPOS mechanism, which can prevent a replay of a transaction on forks that do not include the referenced block.” A transaction built against a block that a given fork never saw is invalid on that fork — it cannot be lifted out of one history and replayed into another. The valid reference is “the latest 65536 blocks, and generally, the latest solidified block is used.”

expiration puts the transaction on a clock. Past that time, it “will no longer be packed” — block producers refuse it. When a transaction is built through a node’s API, the node sets the expiration “to the value of adding 60 seconds to the timestamp of the node’s latest block.” That window is configurable, but “the maximum value cannot exceed 24 hours.”

The practical result is that a TRON transaction is a perishable object. It is bound to a fork by its reference block and to a clock by its expiration. If it is not included before the window closes — network congestion, a fee limit set too low for the contract to complete, a co-signer who never signs — it does not queue for later. It expires, unbroadcast to the ledger, and the sender has to build a fresh one with a new reference block, a new expiration, and therefore a new txID.

One field on that clock is easy to misread: timestamp is the builder’s creation time, not the confirmation time. The protocol notes it “does not need to be set, because the timestamp of the block which the transaction is included in is the actual on-chain timestamp.”

What the structure tells a reader

Taken apart, the envelope and its signatures answer questions the summary view of a transfer never surfaces.

Start with who actually authorized it. The signature array recovers to real addresses, so a transaction can be from one account and yet reveal, in its signatures, the set of keys (one, or several) that satisfied a permission. The count and the recovered addresses are evidence about control, independent of the sender field.

A Permission_id other than 0 adds the authority the signers acted under: an active or custom permission rather than the owner key. That is a standing arrangement made visible in a single transaction — someone delegated signing authority, and this is it being used.

The reference block and expiration bracket the transaction in time and fork. They record when it was built and that it was built against a specific recent block, which helps when the confirmation timestamp and the creation timestamp disagree, or when placing an action relative to a chain event.

On a contract call, fee_limit shows how far the signer was willing to go. It is a ceiling the signer chose before broadcasting, visible even when the call reverts, and it reads as intent: how much Energy value the author was prepared to spend on the attempt.

None of this requires trusting a label or a block explorer’s rendering. It is all recoverable from the transaction’s own bytes: an envelope that fixes intent and a name for it, and an array of signatures that records exactly which authority was exercised to send it.

Sources

• Transactions — TRON Developer Hub — official reference for the raw_data fields, TAPOS reference-block semantics, and the expiration window (default +60s, 24-hour maximum). The live page no longer states the 65,536-block validity range; the archived revision below is cited for that.
• Transactions — TRON Developer Hub, archived 2025-06-20 — the revision carrying the TAPOS and expiration wording quoted in the body: the reference block “is used in the TRON TAPOS mechanism, which can prevent a replay of a transaction on forks that do not include the referenced block”, a transaction past its expiration “will no longer be packed”, the node setting that expiration “to the value of adding 60 seconds to the timestamp of the node’s latest block,” the valid reference being “the latest 65536 blocks, and generally, the latest solidified block is used”, and “the maximum value cannot exceed 24 hours.” TRON has since rewritten the live page in place, so the last archived revision carrying this wording is cited alongside it.
• Tron.proto — tronprotocol/protocol — the protobuf definition of the Transaction message: raw_data (field 1), signature (field 2, repeated bytes), and the Contract sub-message with its type, parameter, and Permission_id; also the authoritative ContractType enumeration behind the “roughly forty” contract-type count.
• Procedures of transaction signature generation — tronprotocol/documentation — the signing procedure: hash raw_data with SHA-256 to get the txID, sign with ECDSA/secp256k1, 65-byte (r, s, v) recoverable signature.
• Multi-Signature — TRON Developer Hub — permission IDs (owner 0, witness 1, active 2+), the Permission_id field on a contract, and the weight-versus-threshold rule for validating a set of signatures.
• smart_contract.proto — tronprotocol/protocol — the protocol definition of TriggerSmartContract (owner_address, contract_address, call_value, data, call_token_value, token_id) — the message type this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.