Versioned Transaction

Overview

A versioned transaction identifies the serialization and message rules used to interpret its fields. Nodes and wallets can support new capabilities without ambiguously reinterpreting transactions created under a legacy format. On Solana, version 0 transactions can reference address lookup tables, allowing compact indexes to stand in for full account addresses and expanding practical account access within the packet-size limit. Signatures still authorize the resolved message and instructions. Clients must declare the transaction versions they can decode and obtain every referenced lookup-table account. Hardware wallets and interfaces should display the fully resolved accounts and effects before signing. An unsupported version may be rejected by RPC or parsing software even when the network accepts it. Versioning improves compatibility only when fallback behavior is explicit.

Submission, peer acceptance, block inclusion, execution, confirmation, and finality provide different evidence, and a transaction can advance, stall, be replaced, or disappear from the canonical chain between those stages. Versioned Transaction should be represented as a sequence of observable states rather than one success flag. 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. Settlement consideration: Versioned transactions enable new formats safely, but every signer and decoder must resolve and understand the selected version’s complete message.