Solana Foundation Vice President of Technology Jacob Creech outlined several upcoming Solana upgrades on Aug. 30. Transaction V1 is scheduled for Sept. 9, while the first stage of a network rent reduction is expected during the week beginning Aug. 31. Summary Solana plans to activate Transaction V1 on September 9, increasing transaction size to 4,096 bytes. The first rent reduction stage begins next week, starting a five-step path toward 90% savings. Solana already cut target slots to 350 milliseconds, with 300, 250 and 200 planned later. Alpenglow remains targeted for October, with Solana aiming for approximately 150-millisecond finality after mainnet activation. Legacy and version-zero transactions remain compatible because developers must opt into the larger V1 format. Creech also said developers plan to shorten slot times further and target October for Alpenglow. However, these changes follow separate activation processes. Transaction V1 will not automatically reduce slot times or activate Alpenglow. There are a lot of major changes happening soon– Next week: First step down in rent reduction– Sept 9: Transaction V1 goes live– Dropping slot time even further– October: AlpenglowThen we all meetup at Scale or Die in NovemberSolana development will never be the same— Jacob Creech (@jacobvcreech) August 29, 2026 Transaction V1 raises Solana’s limit to 4,096 bytes Transaction V1 will raise Solana’s maximum serialized transaction size from 1,232 bytes to 4,096 bytes. The increase is about 3.3 times the existing limit, according to Solana’s official upgrade roadmap. The larger format could support transactions containing zero-knowledge proofs, complex multisignature instructions and other data-heavy operations. The associated SIMD-0296 proposal also identifies BLS signatures and cross-chain operations as possible uses. Developers must opt into the V1 format. Existing legacy and version-zero transactions will remain valid. Transaction V1 will not support address lookup tables, meaning applications must decide which format suits each transaction. The change also requires wallets, application programming interfaces and other infrastructure to handle larger data payloads. The proposal acknowledges possible bandwidth and network fragmentation risks, which makes coordinated testing important before wider adoption. Solana rent reduction begins with one of five steps The first rent reduction does not deliver the full 90% target immediately. Solana plans five stages that would eventually lower the rent calculation from 6,960 lamports per byte to 696 lamports per byte. Solana uses rent-exempt balances to limit uncontrolled state growth. Applications lock SOL when creating accounts that store data. That SOL is generally recoverable when the account closes, meaning rent functions more like a refundable deposit than a recurring network fee. Lower requirements would reduce the amount of SOL that developers must lock when creating token accounts, program accounts and other onchain state. This could lower entry costs for applications that manage many user accounts. Agave 4.2 included the necessary code, but Solana placed the changes behind independent feature gates. As crypto.news previously reported, validators can activate the rent, transaction-size and slot-time upgrades separately after testing. Faster Solana slots follow a separate schedule Solana has already reduced its target slot time to 350 milliseconds, down from the previous 400-millisecond target. The network plans additional stages at 300, 250 and eventually 200 milliseconds. Creech did not provide dates for those remaining stages. Each reduction requires a separate feature activation. Network developers can therefore monitor validator performance before proceeding to the next target. Shorter slots can improve transaction confirmation speed and increase the frequency at which validators produce blocks. They also place greater timing and networking demands on validators. Solana plans to adjust resource limits proportionally during the rollout. Transaction V1 and reduced slot times are related to Solana’s broader performance roadmap, but they remain technically distinct. Reports describing Sept. 9 as the date for both changes would overstate Creech’s announcement. Alpenglow remains an October target Alpenglow is Solana’s proposed consensus redesign. Solana says it aims to reduce transaction finality to approximately 150 milliseconds, compared with the longer confirmation process used by the current consensus system. The official roadmap lists Alpenglow as “in development,” while Agave 4.3 is expected in October. Creech’s post supports October as the current target, but neither statement confirms a guaranteed mainnet activation date. Before then, Solana is expected to begin the first rent-reduction stage and activate Transaction V1 on Sept. 9. Further slot reductions will depend on separate validator activations. Alpenglow must also complete testing and secure the required network support. No verified market movement was directly attributed to Creech’s announcement at publication time.
