Transaction Version

Overview

A transaction version lets a protocol introduce new capabilities without interpreting every transaction under one permanent format. The version can determine field layout, signature hashing, address references, witness behavior, or supported instruction features. Nodes reject unknown versions or handle them according to explicit forward-compatibility rules. In Solana, for example, versioned transactions can use address lookup tables, while legacy transactions embed account addresses directly.

Wallets, RPC clients, indexers, and hardware signers must agree on the version and display all authorized effects. Serializing a transaction with one library and decoding it under another version can produce failure or dangerous misunderstandings. Integrators should negotiate supported versions, preserve raw bytes for audit, and avoid silently downgrading when required security or capacity features would be lost. Implementations need idempotent processing keyed to stable transaction and business identifiers. Repeated callbacks, node disagreements, reorganization, and delayed receipts must not create duplicate credits or irreversible state transitions before the required network evidence is available.

These records allow a later rescan to reconstruct the result when an endpoint, webhook, or local index becomes unreliable. Operational records should retain the raw transaction, network identifier, sender and destination, asset and amount, block reference, execution status, and observed timestamps.

Status labels should describe what is known without overstating settlement. Unknown, pending, included, failed, replaced, and finalized conditions need separate handling, together with a recovery procedure for transactions whose observed state conflicts across providers. Technical takeaway: Transaction versions bind bytes to protocol semantics, so every signer, node, and decoder must support the exact chosen format.