Transaction Body

Overview

The transaction body contains the substantive data that a transaction asks the network to process. In different protocols it can include a sender or input references, Transaction Recipient, value, contract instructions, nonce, fee parameters, and validity constraints. Some formats define the body explicitly, while others use the phrase informally to distinguish core content from signatures or an outer Transaction Envelope.

The body is often part of the data committed by the transaction signature, but the exact signing preimage may add chain identifiers, type bytes, or transformed fields. In UTXO systems, signature-hash flags can determine which inputs and outputs are covered. In account-based systems, transaction type and network domain are commonly included to prevent replay. Developers should not assume that serializing a body alone produces the signed message.

A valid body can still be incomplete for submission. Required signatures, witness data, authentication proofs, or envelope fields may be missing. Conversely, a body decoded from a signed transaction should match the intent shown to the signer. Wallets should display human-readable recipients, amounts, assets, and contract methods rather than only raw body bytes.

APIs and databases should version the body schema and retain the original Serialized Transaction for audit. When comparing transactions, field normalization must not erase meaningful differences such as access lists, fee caps, or instruction order. Precise separation of body, signatures, and envelope helps signing services avoid authorizing data that can later be altered.

For production use, retain the schema version, normalized fields, signing preimage, and relationship to signatures and envelope data. That evidence matters because a field treated as mere metadata may still alter authorization, fees, or replay protection. Monitoring should compare the body shown for approval with the body represented in the final serialized transaction.