Solana has activated its new Transaction V1 format on mainnet, lifting the maximum serialized transaction size from 1,232 bytes to 4,096 bytes. The extra room is meant for complex cryptographic payloads and multisignature workflows—not to multiply the network’s transactions per second.
Direct answer
Solana Transaction V1 went live at the start of mainnet epoch 1035 on September 15, 2026, at about 01:00 UTC. V1 raises the per-transaction ceiling to 4,096 bytes, while legacy and v0 transactions remain capped at 1,232 bytes and continue to work. The change expands what can fit in one transaction; it does not by itself deliver a 3.3-fold increase in network throughput.
The distinction matters because “bigger transactions” can sound like “more transactions.” This upgrade is about the size of an individual envelope, not the number of envelopes Solana can process in a second.
The Solana Foundation’s upgrade page says the txv1 feature gate activated on mainnet at epoch 1035. Testnet and devnet had already enabled the format. Applications must deliberately create v1 transactions to use the larger limit, but software that reads blocks or transactions may encounter v1 data whether or not it sends the new format.
What changed on September 15
Solana’s old 1,232-byte ceiling came from a conservative 1,280-byte network maximum transmission unit, with room deducted for overhead. The accepted design in SIMD-0296 uses Solana’s QUIC transaction-ingestion path to support a 4,096-byte maximum for v1.
That is roughly 3.3 times the serialized space. It can accommodate data that was difficult or impossible to fit into one transaction, including certain zero-knowledge proofs, untruncated Winternitz one-time signatures, nested corporate multisig structures and some onchain signature schemes such as BLS. These are examples from the proposal, not a claim that every implementation is immediately production-ready.
Developers have previously worked around the old ceiling with address lookup tables, chains of transactions or Jito bundles. A single larger transaction can offer stronger atomicity: either the entire operation succeeds or it fails as one unit. The proposal notes that bundles do not provide the same protocol-level atomicity guarantee as a single transaction.
A new envelope, not a throughput multiplier
Nothing in the size proposal raises Solana’s block compute limits or promises 3.3 times as many transactions per second. A 4,096-byte transaction is simply allowed to carry more serialized data than a 1,232-byte transaction.
In fact, larger payloads consume more network bandwidth. SIMD-0296 says the scheduler should treat larger transactions differently and may require a higher priority fee for them to land. The proposal does not introduce a separate per-byte fee schedule.
That makes the practical effect workload-specific. A team that previously split one operation across several transactions may reduce signatures and confirmations by consolidating it. A simple token transfer has little reason to become larger, and it does not become faster merely because v1 exists.
V1 changes more than the byte limit
The format specification, SIMD-0385, reorganizes the transaction envelope. A version byte identifying v1 sits at the beginning, signatures move to the end, and resource settings are placed in a configuration mask rather than hidden among Compute Budget program instructions.
That layout lets validators identify and prioritize a transaction without first scanning its instruction list. It also creates compatibility work for indexers, wallets, RPC providers, fee sponsors and risk systems.
V1 does not support address lookup tables. Instead, it can carry as many as 64 account addresses inline within the larger envelope. Legacy and v0 formats remain available, so a project that depends on lookup tables can continue using v0 rather than migrate immediately.
The Solana Foundation flags a less obvious risk for transaction readers. RPC clients that fetch versioned transactions or blocks must set maxSupportedTransactionVersion to 1. Indexers and fee sponsors must read compute limits, loaded-account data limits and priority-fee settings from the new transaction configuration instead of assuming those values appear as Compute Budget instructions.
That means sending v1 is optional, but reading it is not optional for infrastructure that aims to represent the full mainnet ledger correctly.
Who benefits first
The clearest early users are applications whose payloads ran into the old byte ceiling: privacy systems carrying proofs, institutional multisig tools, cryptographic protocols with large signatures and complex programs touching many accounts.
For consumers, the upgrade may initially be invisible. Wallets can continue to send legacy or v0 transactions. The benefit arrives indirectly if applications can execute a complex action as one atomic operation instead of asking users to approve or monitor several dependent steps.
There is also a longer-term security angle. Larger signature and proof payloads give protocol designers more room to experiment with cryptography that does not fit comfortably into older transaction formats. That does not solve the migration challenges covered in our report on Bitcoin’s post-quantum planning, but it illustrates why byte limits can become architectural constraints when signature schemes change.
What developers should check now
Projects that only submit ordinary v0 or legacy transactions do not need to rush a sending migration. Teams that operate RPC consumers, indexers, explorers, analytics systems, transaction simulators or fee-sponsorship services have a more immediate job: confirm that their parsers accept version 1 and that policy checks read resource settings from the v1 configuration fields.
Senders choosing v1 should also set the compute-unit and loaded-account-data limits explicitly. According to the Foundation’s implementation guidance, those fields default to zero for v1, so omitting them can result in failed transactions rather than a generous default.
Library versions matter. The Foundation’s Transaction V1 developer reference lists compatible releases and explains how to verify the feature gate. Teams should test their exact wallet, signing and RPC path rather than infer readiness from the mainnet activation alone.
Frequently asked questions
Did Solana increase transaction size to 4,096 bytes?
Yes, for the new v1 format. Legacy and v0 transactions remain limited to 1,232 bytes.
Does Transaction V1 make Solana 3.3 times faster?
No. The 3.3x figure describes the maximum number of serialized bytes in one v1 transaction. It is not a claim about TPS, slot time or block capacity.
Are old Solana transactions still supported?
Yes. Legacy and v0 continue to work. Sending v1 is opt-in, though systems that read mainnet transactions must be able to recognize the new version.
Can V1 transactions use address lookup tables?
No. V1 can include up to 64 account addresses inline. Applications that still need address lookup tables can remain on v0.
Reporting note: This article is based on the Solana Foundation’s September 2026 upgrade page, SIMD-0296, SIMD-0385 and the Foundation’s Transaction V1 developer reference. Featured photo: Kevin Ache/Unsplash. Inline photo: Greg Martínez/Unsplash. No affiliate links are used.
Investment disclaimer: This article is provided for general information only and does not constitute investment, financial, legal or tax advice. Digital assets are volatile, and all investment decisions and their consequences are your own responsibility.