Agave 4.2 Breaking Changes: Eight Migration Items for Solana Developers Before Transaction V1 Activates

Solana SOL$91.07+4.4% Solana's Agave 4.2 validator client is rolling out on mainnet this week, the same release that cut slot times to 350ms. It also ships the code for Transaction V1, a new format that expands maximum transaction size from 1,232 to 4,096 bytes under SIMD-0296 and SIMD-0385. Triton One Triton One published an eight-point migration guide on August 21 that documents the changes indexers, RPC consumers, and streaming clients must address before the v1 feature gate activates.

That framing captures the real risk: several changes will cause incorrect data or silent failures rather than immediate crashes, making them harder to catch without targeted audits.

Transaction V1 and getBlock: Set maxSupportedTransactionVersion Now

The most time-sensitive migration item concerns getBlock and getTransaction calls. Transaction V1 ships in Agave 4.2 but activates through a separate feature gate; the code is live on mainnet before the gate fires. Once the gate opens, any getBlock or getTransaction call that has not declared maxSupportedTransactionVersion: 1 will fail when it encounters a v1 transaction.

Kendra Ross's guide describes the correct order: upgrade the SDK, confirm the decode path handles v1 transactions, then set maxSupportedTransactionVersion: 1 on every getBlock and getTransaction call. Setting the parameter early is safe: it works against the current mainnet state and positions integrations for the gate activation. Indexers that decode raw transaction bytes also need to recognise the new v1 wire format.

Token-2022 Confidential Transfer Field Removal

The jsonParsed output for depositConfidentialTransfer and withdrawConfidentialTransfer instructions is changing. Agave 4.2 removes the source and destination fields and replaces them with a single account field. The original field names were incorrect; both instructions operate on one token account, not two, so the replacement label is accurate.

Any parser that reads source or destination from those instruction objects must be updated to read account instead. Beyond the field rename, Anza Anza's Token-2022 3.x interface brings broader instruction parsing: permissioned burn (initialize, burn, burnChecked), unwrapLamports, confidentialBurn, and batch operations now parse correctly. Mints with previously unrecognised extensions will produce populated extension arrays rather than empty ones.

Fewer Account Updates and the Liveness Signal Problem

Validators running Agave 4.2 skip writing account state for accounts a transaction locked for writing but did not modify. Those accounts no longer emit updates in getBlock responses or gRPC account streams. The fee payer always changes and always emits an update, but other writable accounts that go unmodified will be absent from the response.

Transaction-to-account matching logic that assumes a write lock implies an account update will produce incorrect results: a missing update now means "unchanged," not an error. Any liveness or volume monitoring built on account update frequency will also see reduced notification rates; the guide recommends removing liveness checks based on update frequency and re-baselining volume alerts to avoid false incidents.

New deactivated Reward Type in Block Responses

The rewardType field in getBlock and blockSubscribe reward objects gains a new value: deactivated. It identifies final payout events when stake accounts deactivate. Reward objects are otherwise unchanged from Agave 4.1; only the set of values expands.

Closed enum parsers that treat an unrecognised rewardType as an error or silently drop the record will miss these payouts. The fix is to treat rewardType as an open set and explicitly decide whether deactivation payouts belong in staking-yield totals.

Replace Hardcoded 400ms Slot Duration Assumptions

Agave 4.2 is the release that moved slot times from 400ms to 350ms. The Solana SDK's own slot duration constant had not caught up to 350ms at the time of the release, per Ross's guide. Any indexing pipeline or timing logic with a hardcoded 400ms assumption will produce incorrect estimates for time-based queries, slot ranges, and rate calculations.

Streaming Clients: Go and Rust Minimum Versions

For Rust consumers of Dragon's Mouth, the minimum required versions are yellowstone-grpc-client 12.0.0 with a recommended upgrade to 13.3.0, and yellowstone-grpc-proto 12.6.0. Go clients need to regenerate from the latest protobuf definitions and solana-storage-proto to pick up the new data structures.

Dragon's Mouth subscription requests, filters, tokens, and endpoints require no changes; the protobuf already carries the new reward types and account update semantics as correctly typed data.

The full migration guide with implementation detail for each item is published on the Triton One blog, authored by Kendra Ross.