Solana’s v1 transaction format promises more than three times as much room per transaction, but RPC clients, indexers, relayers and fee sponsors that are not ready for it can fail in two very different ways: some systems stop, while others keep running with the wrong resource limits.
Solana’s live upgrade page still lists v1 as not activated on mainnet as of Sept. 4. Testnet is active and devnet is live in epoch 1140. A Solana changelog published Aug. 28 said v1 transactions were “coming soon,” leaving infrastructure operators a pre-activation window to update.
V1 raises the maximum payload from 1,232 bytes to 4,096 bytes, about a 3.3-fold increase. Legacy and v0 transactions keep their existing limits and behavior, so users and applications that continue using those formats do not need to migrate.
RPC consumers must pass the integer maxSupportedTransactionVersion: 1 when using getTransaction, getBlock or blockSubscribe. Without that opt-in, a v1 getTransaction request returns error -32015, one v1 transaction makes getBlock fail for the entire block, and blockSubscribe emits block: null and stops advancing at the first affected slot.
The parameter only tells the RPC service the highest format the client can decode. It does not request v1 data or change how legacy and v0 transactions are returned.
Other failures are quieter. V1 moves compute-unit limits, loaded-account data limits and priority fees into a transactionConfig object instead of ComputeBudget instructions. An indexer that keeps scanning those instructions will report a zero compute budget for every v1 transaction without raising an error.
Geyser and gRPC consumers face a related trap. The protobuf’s versioned flag is true for both v0 and v1. A stale consumer can therefore label v1 as v0 and preserve an empty budget. The fix is to regenerate the protobuf stubs and check for Message.config, field 7, before reading the flag.
Relayers, paymasters and other server signers must change their policy checks too. A sponsor that enforces a fee cap by scanning ComputeBudget instructions no longer has a binding cap because those instructions may appear in v1 but execute as no-ops. Servers must identify the 0x81 v1 prefix and enforce the fee and resource limits in transactionConfig. This is an application-control failure, not a consensus flaw or evidence that funds are automatically at risk.
Onchain programs face a harder constraint: Solana says no current sysvar or syscall exposes the v1 message configuration. Programs that gate behavior on introspected ComputeBudget instructions must stop relying on that check when v1 goes live.
Who needs to upgrade for Solana v1
The minimum reader-capable releases include @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. The 1.x web3.js line can read v1 from 1.99.0-beta.0 but cannot build, sign or send it.
Yellowstone users need at least yellowstone-grpc-proto 12.6.0, geyser plugin 15.1.1, gRPC client 12.0.0 or @triton-one/yellowstone-grpc 6.0.0, depending on their stack.
Creating v1 transactions is optional. Teams that opt in must set compute-unit and loaded-account data limits explicitly because both default to zero, remove no-op ComputeBudget instructions, stop using address lookup tables and use base64 for payloads larger than 1,232 bytes. The immediate deadline is not a universal wallet migration. It is a compatibility test for every service that may read, index or sponsor somebody else’s v1 transaction.
Featured,Technology,Solana,Solana foundationSolana,Solana foundation#Solana #halt #RPC #readers #break #fee #caps1788560715
