Serialized Transaction
Pronunciation: SEER-ee-uh-lyzd tran-ZAK-shun
Definition
A serialized transaction is a transaction converted from structured fields into the exact ordered byte representation defined by a blockchain protocol. Serialization allows the transaction to be hashed, signed, transmitted, and decoded consistently by different implementations. The byte format is consensus-sensitive: changing a field, order, encoding rule, or version can alter the transaction identifier or invalidate signatures. Practical use requires recognizing that a one-byte difference can change the identifier, signing digest, or consensus interpretation.
Overview
A transaction begins as logical fields such as sender, inputs, recipients, amounts, fees, nonce, and instructions. Serialization encodes those values into a deterministic byte sequence according to protocol rules. The resulting Raw Transaction can be passed to a signer, broadcast across the peer-to-peer network, or stored for later decoding. Nodes reverse the process to validate and execute it.
Serialization formats vary. Bitcoin uses a defined binary transaction layout with integer encodings and optional witness data. Ethereum uses typed envelopes and encoding rules associated with each transaction type. Solana serializes a signatures array and a message containing account keys, a recent blockhash, and compiled instructions. A library for one network cannot safely interpret another network’s bytes.
The exact bytes matter because a Transaction Signature usually commits to a hash derived from the serialized content or a defined signing preimage. Mutating the recipient, amount, fee, nonce, or instruction after signing invalidates the signature or creates a different transaction. Some protocols intentionally omit or transform fields in the signing preimage, so implementations must follow the specification precisely.
Secure workflows retain the serialized bytes that were reviewed and signed, then compare them with the bytes submitted to the network. Decoding should reject non-canonical or malformed encodings where the protocol requires uniqueness. APIs should identify the chain, network, transaction type, and encoding format rather than accepting an unlabeled string. This prevents cross-network confusion and makes audit records reproducible.
Audit and recovery workflows should preserve the serialization version, network, type byte, original bytes, and decoded field values. These records help because a one-byte difference can change the identifier, signing digest, or consensus interpretation. Production safeguards need to reject ambiguous encodings and compare signer input with the bytes ultimately broadcast.
Key Takeaway
Serialization turns transaction intent into consensus-defined bytes, so exact encoding is essential for stable identifiers, valid signatures, and interoperable processing.
Sources
- Bitcoin Transaction Reference — Bitcoin.org (2026-08-02)
- EIP-2718: Typed Transaction Envelope — Ethereum Improvement Proposals (2026-08-02)
- Solana Transaction Structure — Solana Foundation (2026-08-02)