What changes in transaction v1
Legacy and v0 transactions are unchanged. For most integrations, two things about transaction v1 matter:- You must opt in to receive it. Requests for full transaction data need
maxSupportedTransactionVersion: 1, and your client library needs a version that can deserialize v1. - The compute budget moves into the message header. A v1 message carries a
transactionConfigobject withcomputeUnitLimit,heapSize,loadedAccountsDataSizeLimit, andpriorityFee. There are no ComputeBudget program instructions in a v1 transaction.
"version": 1 and its message includes transactionConfig:
"priorityFee": 50000 means this transaction pays 50,000 lamports in total. A null field means the sender did not set it. Legacy and v0 messages omit transactionConfig entirely.
Set maxSupportedTransactionVersion to 1
Every request that returns full transaction data must declare the highest transaction version it can handle. SetmaxSupportedTransactionVersion: 1 on:
getTransactiongetBlockgetTransactionsForAddresswithtransactionDetails: "full"transactionSubscribewithtransactionDetails: "accounts"or"full"blockSubscribe
0, fails with JSON-RPC error -32015 as soon as it touches a v1 transaction:
getBlock, one v1 transaction anywhere in the block fails the whole request. If you see -32015 in your logs, the project is already failing on versioned transactions.
Upgrade your SDK before raising the value
SettingmaxSupportedTransactionVersion: 1 tells the node to return v1 transactions. Your client library still has to deserialize them. Upgrade first, then change the parameter:
Older
VersionedTransaction.deserialize implementations in JavaScript only handle legacy and v0 and throw on a leading 0x81 byte. Older Yellowstone protos predate the v1 message fields, so gRPC consumers on those versions never see transactionConfig. For Go gRPC clients, regenerate from the latest Yellowstone protos and solana-storage-proto.
Read priority fees from transactionConfig
Code that estimates a transaction’s priority fee by scanning for ComputeBudget program instructions (ComputeBudget111111111111111111111111111111, setComputeUnitPrice, setComputeUnitLimit) reads every v1 transaction as paying zero. On v1 the values live in message.transactionConfig, and the units differ:
Do not port the legacy
price × computeUnitLimit ÷ 1e6 math onto priorityFee. It is already the total.
priority-fee.ts
transactionConfig (or on version === 1) rather than on the presence of ComputeBudget instructions, since a legacy transaction with no priority fee also has none.
Decode raw transaction bytes with a v1-aware parser
This section only applies if you consume raw transaction bytes, for example from preconfSubscribe, preprocessedSubscribe, or abase64-encoded RPC response. If you work with json or jsonParsed responses, skip it.
Transaction v1 changes the wire layout in two ways:
- Version byte. A v1 transaction starts with
0x81(decimal 129). A v0 transaction starts with0x80. - Signatures move to the end. Legacy and v0 put signatures first, then the message. Transaction v1 puts the message first and the signatures last, so
bincode-style decoders that expect a leading signature array fail on v1 bytes.

Byte layout of a transaction v1 with three addresses and one instruction. The signature sits at the end, after the message.
- Rust:
agave-transaction-viewparses legacy, v0, and v1 in place.wincode, the bincode-compatible serializer used by current Solana SDKs, also decodes v1 intoVersionedTransaction. - JavaScript / TypeScript:
@solana/kit8.0+ or@solana/web3.jsv3.
0x81 means v1 and the signatures follow the message instead of preceding it.
Checklist
- Grep for
getBlock,getTransaction,getTransactionsForAddress,transactionSubscribe, andblockSubscribe, including raw JSON-RPC bodies and SDK wrappers such asconnection.getParsedTransaction. - Upgrade to a v1-capable SDK.
- Set
maxSupportedTransactionVersion: 1on every call found in step 1. - Replace ComputeBudget instruction scanning with a
transactionConfigcheck, and treatpriorityFeeas total lamports. - Replace
bincode-style raw decoders withagave-transaction-viewor an upgraded SDK. - Bump streaming dependencies to the versions in the table above.
- Grep logs for
-32015after the change to confirm nothing still fails.
Related
getTransaction guide
Parameters, response shape, and examples for fetching a single transaction.
getBlock guide
Fetch a full block, including every transaction it contains.
getTransactionsForAddress
Filtered, paginated transaction history for any address in one call.
Agave 4.2 migration checklist
Every Agave 4.2 breaking change, with remediation steps.