Solana v1 incompatibility can freeze RPCs, hide fee limits

Solana is rolling out a v1 transaction format that raises the maximum transaction payload from 1,232 bytes to 4,096 bytes. The format is active on testnet and devnet; mainnet activation is pending. Operators have a pre-activation window to update infrastructure that reads, indexes or sponsors transactions.

RPC clients must explicitly opt in to v1 by including maxSupportedTransactionVersion: 1 on calls such as getTransaction, getBlock and blockSubscribe. Without that opt-in, getTransaction requests for v1 transactions return error -32015. A single v1 transaction can cause getBlock to fail for the entire block, and blockSubscribe can emit block: null and stop advancing at the affected slot.

v1 moves compute-unit limits, loaded-account data limits and priority fee settings into a transactionConfig object instead of ComputeBudget instructions. Indexers and relayers that continue scanning for ComputeBudget instructions will observe a zero compute budget for v1 transactions without producing an explicit error. Fee sponsors that enforce caps by reading ComputeBudget instructions may no longer apply binding caps because those instructions can be present but treated as no-ops in v1.

Servers and relayers must detect the v1 message prefix (0x81) and enforce limits from transactionConfig. TransactionConfig defaults compute-unit and loaded-account data limits to zero if teams do not set them explicitly. Teams that opt in to create v1 transactions must set those limits, remove no-op ComputeBudget instructions, avoid address lookup tables for v1 transactions and use base64 encoding for payloads larger than 1,232 bytes.

Geyser and gRPC consumers face a related protobuf issue. The versioned flag in the protobuf is set to true for both v0 and v1 messages, which can let stale consumers mislabel v1 payloads as v0 and preserve empty budgets. The recommended fix is to regenerate protobuf stubs and check for the presence of Message.config (field 7) before reading the versioned flag so the consumer correctly interprets the v1 configuration block.

Onchain programs cannot read the v1 message configuration because no current sysvar or syscall exposes that config. Programs that gate behavior on seeing ComputeBudget instructions must change those checks before v1 activation, because those instructions may not reflect the executed resource limits in v1 transactions.

Upgrades to create v1 transactions are optional, but upgrades are required for any service that reads, indexes or sponsors other people’s transactions. 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 yet build, sign or send v1 transactions. Yellowstone stack components also need updates, such as 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 setup.

Solana maintainers note these are application-level compatibility issues rather than consensus or ledger flaws. Services that do not update may halt when encountering v1 traffic or apply incorrect resource limits once v1 transactions begin circulating on mainnet.