Solana Makes Room for Transactions More Than Three Times Bigger
Solana has raised the maximum amount of data a single transaction can carry, giving complex applications more room for proofs, signatures and connected instructions within one operation.
Key Takeaways
- V1 raises transaction capacity to 4,096 bytes.
- Legacy and V0 transactions remain fully supported.
- Proofs and multisigs gain more transaction space.
- Applications must explicitly opt into V1.
- Larger messages may require higher priority fees.
Solana activated its txv1 feature on mainnet at approximately 01:00 UTC on September 15, at the start of epoch 1035. The upgrade increased the maximum transaction size from 1,232 bytes to 4,096 bytes.
The additional space is available through the V1 transaction format. Applications must add support before using it, while legacy and V0 transactions continue to operate under their existing limits.
A larger transaction is not a larger SOL transfer
The new limit concerns the information carried by a transaction, not the amount of SOL a user can send. A standard transfer needs relatively little data because it contains only a small number of accounts, instructions and signatures.
More advanced operations can require several instructions, numerous account addresses, multiple approvals or cryptographic proofs. Once that information exceeded the former limit, developers had to reduce the payload, separate the operation or use alternatives such as address lookup tables and transaction bundles.
Solana can process unrelated transactions in parallel, as explained in this guide to how Solana works. V1 does not alter that execution model. It provides more room when a single operation must contain several connected parts.
When those instructions are submitted as one atomic transaction, they are processed as a unit. The complete operation succeeds or its changes are reversed, avoiding a situation in which only some of its instructions reach the ledger.
Which operations benefit from additional space?
- Batched trades: A trading application can place connected instructions inside one transaction instead of coordinating several confirmations.
- Large multisig approvals: Treasury and company wallets can accommodate more signatures and account information when several people must authorise an operation.
- Zero-knowledge proofs: Applications can prove that a condition is satisfied without revealing all the underlying information, but the proof itself may require substantial transaction space.
- Onchain signature schemes: Some cryptographic signature formats previously produced more data than one Solana transaction could contain.
The Solana Foundation identifies confidential transfers, nested multisigs, batched operations and certain onchain signature schemes as potential uses for the new format.
Most wallet users do not need to take action
The activation does not require users to move their SOL, create another address or convert an existing account. Applications that continue using legacy or V0 transactions should behave as they did before the upgrade.
Users will need a compatible wallet when an application chooses to send a V1 transaction. Keeping wallet software updated will make that support available as providers introduce it, but an application should still check compatibility before asking a wallet to sign.
The change may eventually appear to users as fewer approval requests for complex operations. A service that previously needed several connected transactions could instead present one request and wait for one confirmation.
Developers and indexers need to update their software
Sending V1 transactions is optional, but reading them can create compatibility problems for infrastructure that has not been updated.
RPC services retrieving transactions or blocks must set maxSupportedTransactionVersion: 1. Without that setting, a request for a V1 transaction can return an error, while a single unsupported transaction can cause a request for an entire block to fail.
Indexers face a different risk. V1 stores its compute limit, loaded-account data limit and priority fee inside transactionConfig rather than in Compute Budget instructions. Software that continues scanning the old location may classify the transaction incorrectly or report its resource limits and priority fee as zero.
Applications creating V1 transactions must set their compute-unit and loaded-account data limits explicitly. Both values default to zero in the new format, so omitting them can cause the transaction to fail before execution.
Transactions larger than 1,232 bytes must also be submitted with base64 encoding. The base58 submission path retains the former size ceiling.
V1 provides more space but changes other limits
V1 is not simply V0 with a larger payload. It can include up to 64 account addresses directly in the transaction, but it does not support address lookup tables. Duplicate account addresses are also rejected.
Those rules create a different design choice for application teams. V0 remains useful when lookup tables provide an efficient way to reference accounts, while V1 is intended for operations that benefit more from additional room for instructions, signatures or proofs.
A basic payment is unlikely to gain anything from the new format. Using V1 makes more sense when the application can replace a complicated sequence or accommodate data that previously could not fit at all.
More transaction space may carry a higher fee
Increasing the byte limit does not automatically make every V1 transaction more expensive. The cost depends on the resources requested, the number of signatures and the priority fee selected by the application.
Larger messages do consume more validator bandwidth. Solana’s documentation says the scheduler is expected to require a higher priority fee for a larger transaction than for a smaller one seeking equivalent priority, particularly when blockspace is in demand.
V1 also expresses the priority fee as a total amount in lamports. V0 uses a price per compute unit, meaning analytics platforms must normalise the two formats before comparing them.
Priority-fee demand can change substantially with network activity, as shown by Solana’s recent fee data. Developers will therefore need to weigh the convenience of one larger operation against the cost of getting it included during congested periods.
READ MORE:
XRP Ledger Nears a New Payments Update
Activation begins the adoption test
The upgrade removes a constraint that previously shaped how Solana applications were built, but mainnet activation does not guarantee widespread use. Wallets, RPC providers, indexers and application libraries must handle the new format correctly before developers can rely on it in customer-facing products.
The earliest benefits are likely to appear in workloads that already struggle with the former ceiling, including confidential transfers, institutional multisig arrangements and instruction-heavy applications. For ordinary transfers, the established formats remain the simpler option.
V1’s importance will ultimately depend on whether fitting these workloads into one atomic transaction produces enough savings in coordination, signatures and failed attempts to justify the required infrastructure updates.
This article is provided for informational purposes only and does not constitute financial or investment advice. Wallet compatibility, application support and transaction fees can change.
Alex is Editor-in-Chief of Coindoo and co-founder of Millennial Media Group, with nearly a decade of experience covering financial markets - crypto first, then everything else. It started in 2016 with Bitcoin. Like most people at the time, he didn't fully understand it - so he kept digging. Blockchain, tokenomics, the projects, the cycles. That curiosity never stopped, and eventually pulled him into traditional markets too: equities, commodities, macro. Not because he left crypto behind, but because you can't properly understand one without the other. What drives him is straightforward: he wants to know why something is happening, not just that it's happening. Most market coverage stops at the headline - price up, price down, here's a chart. Alex finds that kind of reporting actively unhelpful. If you walk away from an article without understanding the mechanism behind the move, what did you actually learn? He holds a degree in Tourism from New Bulgarian University - not the most obvious path into financial markets, but markets have a way of pulling in people who are simply too curious to stay out. He has authored over 200 in-depth analyses and more than 10,000 articles across crypto and traditional finance. He still thinks every day in markets teaches him something new. That's probably why he hasn't stopped.
