Solana's v1 transaction format increases the maximum payload from 1,232 bytes to 4,096 bytes, or about 3.3 times more capacity. The live upgrade page listed v1 as inactive on mainnet as of Sept. 4, while testnet was active and devnet was live in epoch 1140. A changelog published Aug. 28 described the feature as coming soon, ahead of the Agave 4.2 activation target. RPC (remote procedure call) consumers must set maxSupportedTransactionVersion: 1 when using getTransaction, getBlock or blockSubscribe. Without that setting, v1 requests can return errors, cause an entire block response to fail or make block subscriptions stop advancing at the first affected slot. The setting only declares the highest transaction format the client can decode; it does not request v1 data or alter legacy and v0 responses. V1 also moves compute-unit limits, loaded-account data limits and priority fees into a transactionConfig object rather than ComputeBudget instructions. Stale indexers can therefore report zero compute budgets without an error, while outdated Geyser and gRPC consumers can mislabel v1 as v0. Relayers, paymasters and other server signers must identify the 0x81 v1 prefix and enforce fee and resource policies through transactionConfig, because ComputeBudget instructions in v1 may execute as no-ops. Solana says no current sysvar or syscall exposes the v1 message configuration, limiting onchain programs that inspect those instructions. Reader-capable software includes @solana/kit 8.0.0, @solana/web3.js 3.0.0-rc.3, Rust solana-* 4.2.x, Python solders 0.29.0 and solana-go 1.23.0, with additional minimum versions for Yellowstone users. Building v1 transactions remains optional, but teams that do so must set compute-unit and loaded-account data limits explicitly, remove no-op ComputeBudget instructions, stop using address lookup tables and use base64 for payloads above 1,232 bytes. The immediate requirement is a compatibility test for services that read, index or sponsor v1 transactions, not a universal wallet migration.