CryptoSlate
Solana's v1 transaction format lifts the per-transaction payload ceiling from 1,232 bytes to 4,096 bytes, roughly a 3.3-fold jump, and it is already running on testnet and devnet (epoch 1140). Mainnet activation remains pending on Solana's live upgrade page, with an Aug. 28 changelog noting v1 transactions were "coming soon." That window is the run-up to two very different compatibility traps for the surrounding infrastructure: RPC clients that are not upgraded can freeze outright on encountering a v1 transaction, while indexers, relayers and fee sponsors can keep running and silently report the wrong resource limits.
Why it matters
The headline payload bump is the upgrade's selling point, but the failure modes sit in the plumbing most users never see. RPC clients that fail to pass maxSupportedTransactionVersion: 1 will receive error -32015 on v1 getTransaction requests, see getBlock fail entirely when a v1 transaction lands in a block, and watch blockSubscribe emit block: null and stop advancing at the first affected slot. The quieter risk lives in ComputeBudget handling. V1 moves compute-unit limits, loaded-account data limits and priority fees into a transactionConfig object, so any indexer still scanning ComputeBudget instructions will report a zero budget with no error raised, and any relayer enforcing a fee cap by reading those instructions will see them execute as no-ops, stripping the binding cap it thought it was enforcing. Geyser and gRPC consumers face a related version-label trap because the protobuf's versioned flag is true for both v0 and v1, letting stale stubs persist an empty budget.
Market impact
Solana frames this as application-control failure rather than a consensus flaw, so funds are not automatically at risk. The blast radius, though, covers every paymaster, explorer, custody stack and on-chain program that introspects ComputeBudget, since no current sysvar or syscall exposes the v1 message configuration.
Frequently asked questions
-
What is Solana's v1 transaction format?
It is an upgraded transaction format that raises Solana's per-transaction payload ceiling from 1,232 bytes to 4,096 bytes, roughly a 3.3-fold increase. Legacy and v0 transactions keep their existing limits and behavior, so applications that stay on those formats do not need to migrate.
-
How does the v1 freeze bug affect RPC clients?
RPC clients that do not pass maxSupportedTransactionVersion: 1 receive error -32015 on v1 getTransaction requests, break getBlock entirely when a v1 transaction lands in a block, and watch blockSubscribe emit block: null and freeze at the first affected slot.
-
Why are v1 fee cap checks silently breaking?
V1 moves compute-unit limits, loaded-account data limits and priority fees into a transactionConfig object. Relayers and paymasters that enforce fee caps by scanning ComputeBudget instructions see those instructions execute as no-ops in v1, so the cap no longer binds without raising any error.
-
Are user funds at risk from the Solana v1 upgrade?
No. The breakdown frames this as an application-control failure rather than a consensus flaw, and user funds are not automatically at risk. The risk sits in relayers, explorers, custody stacks and on-chain programs that introspect ComputeBudget and need upgrades before v1 goes live.
-
Which software versions handle Solana v1 correctly?
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, solana-go 1.23.0, yellowstone-grpc-proto 12.6.0, geyser plugin 15.1.1 and gRPC client 12.0.0, depending on the stack.
WatcherGuru
Crypto News
TheBlock
WuBlockchain
CoinTelegraph