Solana v1 Transaction Upgrade May Disrupt RPC Clients and Indexers

Solana’s v1 transaction format, which increases the maximum payload from 1,232 bytes to 4,096 bytes, is still pending activation on mainnet as of early September. While the upgrade is live on testnet and devnet, infrastructure that reads or processes transactions must be updated before the first v1 transaction appears on mainnet.

Impact on RPC Consumers

RPC services must include the integer maxSupportedTransactionVersion: 1 when calling getTransaction, getBlock or blockSubscribe. Without this flag, a v1 request returns error -32015, a single v1 transaction can cause getBlock to fail for an entire block, and blockSubscribe will emit block: null and stop advancing at the first affected slot.

Silent Failures for Indexers and Relayers

In v1, compute‑unit limits, loaded‑account data limits and priority fees move into a transactionConfig object instead of ComputeBudget instructions. Indexers that continue to scan the old instructions will see a zero compute budget for every v1 transaction without raising an error. Similarly, gRPC consumers that rely on the protobuf’s versioned flag may mislabel v1 messages as v0, preserving an empty budget.

Fee Sponsor and Paymaster Adjustments

Fee sponsors that enforce caps by scanning ComputeBudget instructions will lose those caps, because the instructions become no‑ops in v1. Sponsors must detect the 0x81 v1 prefix and enforce limits based on the transactionConfig fields.

Program Compatibility

No current sysvar or syscall exposes the v1 message configuration, so on‑chain programs that rely on ComputeBudget introspection must stop using that check when v1 goes live.

Required Library Updates

• @solana/kit ≥ 8.0.0
• @solana/web3.js ≥ 3.0.0‑rc.3 (v1 reading from 1.99.0‑beta.0)
• Rust solana‑* 4.2.x
• Python solders ≥ 0.29.0
• solana‑go ≥ 1.23.0
• Yellowstone stack: yellowstone‑grpc‑proto ≥ 12.6.0, geyser plugin ≥ 15.1.1, gRPC client ≥ 12.0.0 or @triton‑one/yellowstone‑grpc ≥ 6.0.0

Migration Checklist

1. Set compute‑unit and loaded‑account data limits explicitly (defaults are zero).
2. Remove no‑op ComputeBudget instructions.
3. Avoid address lookup tables for v1 transactions.
4. Use base64 encoding for payloads larger than 1,232 bytes.

Creating v1 transactions remains optional; the immediate deadline is a compatibility test for any service that may read, index or sponsor a v1 transaction.