Solana transactions reach 4,096 bytes: what v1 changes

Updated September 8, 2026. V1 transactions are active on testnet and devnet, not yet on Solana mainnet.

Solana transactions can grow from 1,232 to 4,096 bytes under the new v1 format. The additional room lets zero-knowledge proofs, larger multisigs and batches that previously needed several steps fit into one operation. It does not mean network throughput or speed automatically triples.

The upgrade requires practical changes across wallets, indexers, RPC clients and fee sponsors. Legacy and v0 applications continue to work, but block readers that do not declare v1 support can fail once the format reaches mainnet.

Solana transactions: from 1,232 to 4,096 bytes

The official Solana upgrade page describes a 3.3-fold higher limit. The old ceiling was tied to a conservative network packet size. QUIC transport now makes it possible to carry a transaction across multiple frames.

The cap remains at 4 KiB to contain memory pressure and retransmission costs. Larger transactions use more bandwidth and may be more expensive to propagate. A higher maximum creates room for complex workloads rather than free resources for every user.

V1 moves resource configuration into the message and places signatures at the end. Its first byte lets infrastructure identify the version before decoding the whole payload. Legacy and v0 retain the 1,232-byte ceiling.

What can fit into one transaction

A ZK proof or institutional multisig may require more data and signatures than the old format permits. Developers have had to split a workflow into several transactions, use address tables or rely on bundles. Each step adds confirmations, signatures and an opportunity for partial failure.

V1 allows some workflows to become atomic: either the complete group executes or none of it changes state. Confidential Transfers, advanced signature schemes and coordinated actions across programs are among the relevant uses.

More space does not remove logical limits. V1 retains a maximum of 64 account addresses and 64 instructions and requires explicit resource budgets. Application complexity still needs design rather than merely being packed into a larger envelope.

Why indexers and explorers must update

Clients calling getTransaction or getBlock need to set maxSupportedTransactionVersion to 1. Without it, a v1 operation can produce an unsupported-version error. With getBlock, one unknown transaction may prevent the entire block response from being read.

The August 27 Solana changelog tells teams to prepare. The developer-facing risk is concrete: an indexer can appear healthy until the first v1 block, then stop advancing or expose incomplete information.

Geyser and gRPC pipelines need compatible generated stubs, while decoders and archives must recognise the v1 prefix. Our coverage of Solana validators and Agave changes explains why infrastructure needs to move with the protocol.

Compute budgets and priority fees move

Under v1, compute-unit limits, loaded-account data size, heap and priority fee live in transactionConfig. A system that only scans old ComputeBudget instructions can quietly report zero values, producing incorrect analytics without an obvious decoding error.

The priority-fee unit changes too. V1 stores a total number of lamports, whereas previous formats use micro-lamports per compute unit. Reapplying the old multiplication can calculate or enforce the wrong fee.

Applications sending v1 must explicitly set compute and loaded-data limits. Defaults are zero, so an unconfigured transaction may fail before execution. Simulation is needed to estimate both resources with enough headroom for state changes between simulation and inclusion.

Address Lookup Tables and accounts

V1 does not use Address Lookup Tables. Its larger envelope can include up to 64 addresses directly, removing a dependency that v0 uses to fit accounts into a smaller packet. Duplicate addresses are rejected.

This makes some payloads more self-contained, but does not make every existing v0 system automatically compatible. SDKs, wallets and programs need to choose the appropriate format and support both during the transition.

Support is arriving in library releases including Anza Kit. A version that can read v1 may not necessarily build and send it. Developers need to verify the exact capability matrix for their language and client.

Mainnet activation status

The official page reports that the feature gate is active on testnet and devnet while mainnet remains inactive. Planning targets Agave 4.2, but the schedule is explicitly tentative and may change.

Ordinary users do not need to take action because legacy and v0 continue operating. The immediate responsibility falls on developers, RPC providers, explorers, indexers, relayers, fee sponsors and co-signing services.

It would be inaccurate to say Solana has already tripled every transaction. The new format raises the ceiling when v1 is selected and supported. Older formats keep their dimensions and behaviour.

Costs and risks of larger transactions

One atomic operation can reduce signatures and confirmation steps compared with several linked transactions. Larger packets also consume more bandwidth and, according to the documentation, may require higher priority fees to compete with smaller transactions at equivalent priority.

The error surface grows as well. Incorrect limits, old parsers and fee analytics built around the previous format can interrupt a service. Testing needs to cover reading, simulation, submission, storage and later reproduction of the data.

The OpenSea integration of Solana NFTs illustrates why infrastructure compatibility matters alongside protocol capability. A useful feature only becomes real for users once wallets, APIs and explorers support it consistently.

Solana transactions with the 4,096-byte ceiling solve a genuine constraint for complex applications, particularly ZK, multisig and atomic batches. The upgrade’s value will not be measured in bytes alone. Ecosystem readiness, propagation cost and accurate data during the v1 transition will determine whether the larger envelope works safely in practice.