For AI agents: an LLM-friendly Markdown version of every page is available by appending .md to its URL or by sending an Accept: text/markdown request header. The full documentation index is at https://www.ankr.com/docs/llms.txt
Skip to main content

Solana activated Transaction V1: send maxSupportedTransactionVersion 1

Ankr Team
Docs Team

Solana turned on Transaction V1 at the start of epoch 1035, on 15 September 2026 at about 01:00 UTC. Our nodes run Agave v4.2.2 and serve v1 blocks, so nothing changes on our side. Your side has one change to make: getBlock and getTransaction calls that still pass "maxSupportedTransactionVersion": 0 now fail with -32015 on almost every block, because almost every block already carries a v1 transaction.

Network upgrades​

Solana Transaction V1, live since 15 September​

The upgrade raises the maximum transaction size from 1232 to 4096 bytes and introduces transaction version 1. A client that asks for a lower maximum version gets an error instead of the block:

{
  "code": -32015,
  "message": "Transaction version (1) is not supported by the requesting client. Please try the request again with the following configuration parameter: \"maxSupportedTransactionVersion\": 1"
}

We sampled 60 consecutive finalized blocks on our own mainnet endpoint after activation. 56 of them returned -32015 at maxSupportedTransactionVersion: 0, and all 60 returned normally at 1. Treat this as affecting every getBlock and getTransaction call, not a fraction of them.

Our mainnet and devnet nodes run Agave v4.2.2, which is the version Solana names as the minimum for RPC nodes through this activation. getVersion on rpc.ankr.com/solana returns solana-core: 4.2.2.

Worth checking on your side​

Pass the parameter as the integer 1, not the string "1".

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBlock",
  "params": [SLOT, { "maxSupportedTransactionVersion": 1 }]
}

Check your decoder before you flip the parameter. Once you accept v1, blocks return transactions your parser has not seen. A client that asks for version 1 and then throws on the response is worse off than one that fails cleanly at the RPC layer.

Three behavior changes apply if you also send v1 transactions, and they are easy to miss because each one silently defaults to something different from v0:

  • The compute unit limit defaults to 0 CU when unset, where v0 fell back to 200k per instruction. Set it explicitly.
  • The loaded accounts data size limit defaults to 0 bytes when unset, where v0 defaulted to 64 MiB. Set it explicitly.
  • The priority fee is an absolute total in lamports, not micro-lamports per compute unit. The same number means a very different fee.

Our Solana method pages now show 1 in every example. The getBlock and getTransaction pages previously showed 0, which was correct before this activation and is not correct now.

Nothing else on Solana changed. Same endpoints on mainnet and devnet over HTTPS and WSS, same rate limits, same method list, same plans. No method limits, error codes, batch caps or block-range caps changed on any other network.

Solana documents the upgrade at solana.com/upgrades/larger-transaction-sizes.