Solana plans to activate Transaction V1 on Sept. 9, according to an Aug. 30 update from Solana Foundation Vice President of Technology Jacob Creech. The change would increase the network’s maximum serialized transaction size from 1,232 bytes to 4,096 bytes, opening more room for data-heavy transaction types while leaving existing formats in place.
Creech also said the first stage of Solana’s planned rent reduction is expected during the week beginning Aug. 31. That effort is separate from other performance-related changes now on the roadmap, including additional slot-time cuts and the proposed Alpenglow consensus redesign, which still carries an October target rather than a confirmed activation date.
Larger transaction format scheduled for Sept. 9
Transaction V1 would raise Solana’s transaction size ceiling by roughly 3.3 times. The larger format is intended to support more complex payloads, including potential uses such as zero-knowledge proofs, complex multisignature instructions, BLS signatures and some cross-chain operations, as described in the associated SIMD-0296 proposal.
The rollout is not backward-breaking. Developers must explicitly opt into the V1 format, while legacy and version-zero transactions will remain valid. At the same time, V1 will not support address lookup tables, meaning applications may need to choose between formats depending on the type of transaction they are sending.
Infrastructure changes and testing remain important
The higher size limit does more than alter application design. Wallets, APIs and other parts of Solana’s infrastructure will need to handle larger transaction payloads if they want to support the new format.
The proposal also notes possible bandwidth and network-fragmentation risks, which is why coordinated testing matters before broader uptake. Sept. 9 refers to the planned activation of Transaction V1 itself, not to an immediate network-wide shift in how all transactions are built or relayed.
Rent reduction starts with the first of five stages
Solana’s upcoming rent cut is expected to begin in stages rather than as a one-time reset. The network ultimately aims for a 90% reduction, lowering the rent calculation from 6,960 lamports per byte to 696 lamports per byte over five steps.
On Solana, rent-exempt balances are used to limit unchecked growth in onchain state. Applications lock SOL when they create accounts that store data, and that SOL is generally recoverable once the account is closed. In practice, that makes rent closer to a refundable deposit than a recurring usage fee.
A lower rent requirement would reduce the amount of SOL developers need to lock when creating token accounts, program accounts and other state-heavy structures. The code needed for the change was included in Agave 4.2, but the feature remains gated so validators can activate it independently after testing.
Slot times and Alpenglow follow separate paths
Creech also pointed to Solana’s broader effort to speed up the network, but the timelines are distinct. Solana has already reduced its target slot time to 350 milliseconds from 400 milliseconds, and later stages at 300, 250 and 200 milliseconds are planned. No dates were given for those remaining reductions, and each one requires its own validator activation.
Alpenglow, Solana’s proposed consensus redesign, remains targeted for October. Solana has said the goal after mainnet activation is roughly 150-millisecond finality, but the roadmap still lists Alpenglow as in development. Agave 4.3 is expected in October, yet that does not amount to a guaranteed mainnet launch date.
For now, the confirmed near-term milestones are narrower: the first rent-reduction stage is expected in the week beginning Aug. 31, and Transaction V1 is scheduled for Sept. 9. Further slot-time cuts and any Alpenglow activation still depend on additional testing and the required level of network support.
Source: crypto.news