Solana just tripled its transaction capacity, What comes next?

Solana implemented the Transaction V1 feature on its mainnet on Tuesday, making it possible to add more data to each transaction. This will give developers more room for carrying out complex actions in one atomic process.

The development will be highly relevant to the developers in the DeFi sphere, wallet providers, indexers, and RPC operators. The new feature can affect other projects dealing with tokenised assets and payment solutions.

The txv1 feature gate has been rolled out at the beginning of epoch 1035 at about 01:00 UTC on September 15, as stated on the Solana upgrade page, and Transaction V1 is now live on the mainnet, testnet, and devnet.

From 1,232 bytes to 4,096

The first one is a transaction size limitation. Now, Solana has doubled the maximum size of serialized transactions to 4,096 bytes from 1,232 bytes, thus giving more space for transactions, which is about three point three times more space.

The format of the new transaction was defined in SIMD-0296, while the V1 Message Format is based on SIMD-0385.

Up until now, the limit in Solana was based on conservative network MTU limitations. Now, breaking away from the hard limit on stream size in QUIC enables larger transactions.

The extra space will be useful in handling the kinds of workloads where a lot of transaction data is involved, such as zero-knowledge proofs, huge multisig operations, and signatures including BLS. As reported by Cryptopolitan, V1 was launched on the testnet at epoch 1025, on September 1, giving the chance to infrastructure providers to prepare for the mainnet launch.

Why one atomic transaction matters

The developers who found that Solana had a cap on transaction size could, in some instances, split their operations into a series of transactions or use Jito bundles.

But as the explanation provided in SIMD-0296 explains, a bundle is not equal to a native transaction when discussing atomicity at a protocol level.

With Transaction V1, more instructions and data can be placed into a transaction. In this way, routing, proof checking, and batching will either all work or fail to work, instead of being performed in separate transactions.

In some cases, fewer signatures and confirmations would be required for the performance of an operation.

The address-lookup-table trade-off

V1 also alters the way that transactions manage resources and account references.

The compute limit and priority fee settings have been relocated from the ComputeBudget instructions to the transaction settings, enabling the infrastructure providers to have access to such settings easily.

V1 transactions are also stripped off the Address Lookup Tables as the accounts referenced are included in the transaction.

While this helps to simplify the transaction, it is at the cost of the transaction’s size, as a v0 Address Lookup Table will require only a one-byte index while an inline public key requires 32 bytes.

It was discovered through the analysis of the Address Lookup Tables of Solana that 62 percent of v0 transactions had at least one Address Lookup Table used; hence, dense transactions using more than one Address Lookup Table will increase the transaction size by more than 1,500 bytes. The limit of 64 accounts remains the same.

Where V1 fits into Solana’s tokenized-finance push

The upgrade occurs at a time when Solana is expanding its position in on-chain finance. According to DeFiLlama, the total value locked in Solana’s DeFi sector is nearly $5.95 billion, and its 24-hour decentralised exchange volume is around $1.79 billion.

The August summary for Solana also stated that the value of real-world assets on the network had exceeded $4 billion and was held across more than 350,000 addresses. Additionally, xStocks had gathered over $500 million in assets under management.

Just because more transaction capacity is available doesn’t mean that greater adoption will result.

Galaxy Research has observed that a large portion of the value tied up in Solana’s tokens is still not being used, whereas competing platforms are still leading in some rapidly growing areas.

V1 thus broadens the range of applications that developers can create on Solana. The more difficult question, however, is whether users, liquidity, and transaction activity will follow.

What do operators need to do now?

RPC readers should set maxSupportedTransactionVersion: 1 for getTransaction and getBlock, while indexers need to read V1 compute limits and priority fees from transactionConfig. Validators and RPC operators should run Agave v4.2.2 or later. V1 senders should also set compute and loaded-account limits explicitly and use base64 for transactions larger than 1,232 bytes. Wallet providers, meanwhile, should advertise V1 support only after confirming that their software can correctly parse and sign the new format, according to Solana’s upgrade guidance.

If you're reading this, you’re already ahead. Stay there with our newsletter.