Solana v1 Upgrade Bug Poses Network Freeze and Fee Limit Bypass Risks

Solana’s v1 transaction format increases maximum payload size more than threefold, but unprepared RPC clients, indexers, relayers, and fee sponsors may encounter two distinct failure modes: some halt entirely, while others continue operating with incorrect resource limits.

As of September 4, Solana’s live upgrade page still shows v1 as inactive on mainnet. Testnet is live, and devnet is active in epoch 1140. A Solana changelog from August 28 indicated v1 transactions were “coming soon,” providing infrastructure operators with a pre-activation window to prepare.

V1 raises the maximum transaction payload from 1,232 bytes to 4,096 bytes—a roughly 3.3-fold increase. Legacy and v0 transactions retain their existing limits and behavior, so users and applications continuing to use those formats do not need to migrate.

RPC consumers must include the integer maxSupportedTransactionVersion: 1 when calling getTransaction, getBlock, or blockSubscribe. Without this opt-in, a v1 getTransaction request returns error -32015, a single v1 transaction causes getBlock to fail for the entire block, and blockSubscribe emits block: null and ceases advancing at the first affected slot.

This parameter only informs the RPC service of the highest format the client can decode; it does not request v1 data or alter how legacy and v0 transactions are returned.

Other failures are more subtle. V1 relocates compute-unit limits, loaded-account data limits, and priority fees into a transactionConfig object, replacing ComputeBudget instructions. An indexer that continues scanning for those instructions will report a zero compute budget for every v1 transaction without triggering an error.

Geyser and gRPC consumers face a similar trap: the protobuf’s versioned flag is true for both v0 and v1, so a stale consumer may mislabel v1 as v0 and retain an empty budget. The fix is to regenerate protobuf stubs and check for Message.config (field 7) before reading the flag.

Relayers, paymasters, and other server signers must also update their policy checks. A sponsor that enforces a fee cap by scanning ComputeBudget instructions loses its binding cap because those instructions may appear in v1 but execute as no-ops. Servers must identify the 0x81 v1 prefix and enforce fee and resource limits within transactionConfig. This is an application-control failure, not a consensus flaw, and it does not indicate that funds are automatically at risk.

Onchain programs face a tougher constraint: Solana states that no current sysvar or syscall exposes the v1 message configuration. Programs that gate behavior on introspected ComputeBudget instructions must cease relying on that check once 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.

Source link