Solana's incoming v1 transaction format can silently disable fee and resource caps for indexers, relayers and RPC readers that are not updated. The bug does not affect consensus or user funds directly, but it can let servers enforce the wrong limits without raising an error.
A new upgrade to the Solana blockchain raises the maximum transaction payload from 1,232 bytes to 4,096 bytes, about a 3.3-fold increase. RPC clients, indexers, relayers and fee sponsors that are not ready for it can fail in two different ways: some systems stop, while others keep running with the wrong resource limits.
RPC readers can freeze on the first v1 transaction
Solana's live upgrade page still lists v1 as not activated on mainnet as of Sept. 4, while 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.
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.
Fee caps can silently stop working
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.
Relayers, paymasters and other server signers face the same trap. 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 instead identify the 0x81 v1 prefix and enforce the fee and resource limits inside 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, so programs that gate behavior on introspected ComputeBudget instructions must stop relying on that check once v1 goes live.
Who needs to update before v1 activates
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. 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, but teams that opt in must set compute-unit and loaded-account data limits explicitly, since both default to zero. They must also 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.
Source: CryptoSlate
Trading involves risk.
Risk Disclaimer
