TL;DR:
- Solana raised its maximum transaction size from 1,232 bytes to 4,096 bytes through Transaction V1, giving developers more room for complex operations.
- The upgrade supports zero-knowledge proofs, multisignature wallets and atomic multi-step transactions while preserving backward compatibility with older formats.
- Infrastructure providers must update systems to read V1 transactions, while the change narrows Solana’s structural gap with Ethereum without altering the network’s transactions-per-second capacity or overall throughput capacity.
Solana has activated a major mainnet upgrade that raises the maximum transaction size from 1,232 bytes to 4,096 bytes, more than tripling the amount of data a single transaction can carry. The change went live Tuesday at the start of epoch 1,035, around 1:00 a.m. UTC, through the new Transaction V1 format. The expansion gives developers more space for complex instructions, signatures and application data. The core change is capacity per transaction, not transaction throughput, allowing Solana applications to execute heavier operations without automatically splitting them across multiple transactions.
The upgrade specifically targets workloads that previously struggled against Solana’s strict size ceiling. Zero-knowledge proofs, multisignature company wallets and newer onchain signature schemes can require more data than the old format comfortably allowed. Developers can also place more steps inside a single atomic transaction, meaning the entire operation can succeed or fail together. Larger transactions therefore improve composability for applications where several approvals or instructions must remain synchronized. Older transaction formats remain fully supported, preserving backward compatibility, although protocols seeking the larger capacity must adopt V1 to benefit from the expanded limit.

Solana Narrows a Structural Gap With Ethereum
Solana’s larger transaction format narrows one structural disadvantage against Ethereum, where developers have not faced an equivalent rigid per-transaction byte cap. Ethereum instead relies on a flexible block gas limit, allowing data-heavy operations when users are willing to pay the required gas. Solana’s previous 1,232-byte restriction often forced builders to compress operations or divide them into bundles that lacked the same network-level atomic guarantee. The jump to 4,096 bytes removes much of that constraint, giving developers greater freedom to design complex trading, privacy and enterprise workflows without changing Solana’s underlying transaction-speed model.
The transition still creates work for infrastructure providers. Wallets, trading applications, analytics platforms and other services that read Solana data must update their systems to recognize V1 transactions. If they do not, requests for individual V1 transactions can fail, and requests for entire blocks may also fail when even one V1 transaction is present. These are compatibility concerns rather than signs of a network outage. Solana also recently reduced slot time from 400 milliseconds to 350 milliseconds, placing the transaction-size expansion alongside broader efforts to improve network performance and developer flexibility. Together, the changes give builders more room without abandoning compatibility.