Solana activates Transaction V1 on Sept 9, raising serialized transaction size from 1,232 to 4,096 bytes, with rent cuts and faster slots following.
Solana activates Transaction V1 on Sept 9, raising serialized transaction size from 1,232 to 4,096 bytes, with rent cuts and faster slots following.

Solana will activate Transaction V1 on Sept 9, raising maximum serialized transaction size from 1,232 to 4,096 bytes, a 3.3x increase.
Jacob Creech, vice president of technology at the Solana Foundation, outlined the upgrade timeline on Aug 30, also confirming the first of five rent-reduction steps for the week beginning Aug 31.
The larger format supports zero-knowledge proofs, complex multisignature instructions, BLS signatures and cross-chain operations, per the SIMD-0296 proposal. Developers must opt into V1; legacy and version-zero transactions remain valid. The change also requires wallets and APIs to handle larger payloads, with the proposal flagging bandwidth and network fragmentation risks.
The rent reduction lowers the calculation from 6,960 lamports per byte to 696 lamports per byte across five stages, cutting the SOL developers must lock for token accounts and program state. Slot times have already dropped to 350 milliseconds, with further stages targeting 300, 250 and 200 milliseconds. Alpenglow, Solana's consensus redesign targeting 150-millisecond finality, remains an October target but requires separate validator activation.
Transaction V1 raises the ceiling for data-heavy operations
The SIMD-0296 proposal identifies zero-knowledge proofs, BLS signatures and cross-chain operations as primary use cases for the expanded format. Applications that previously split complex instructions across multiple transactions can now consolidate them into a single payload.
Address lookup tables are not supported in V1, meaning applications must decide which format suits each transaction. The proposal acknowledges that coordinated testing is needed before wider adoption to mitigate bandwidth and network fragmentation risks.
Rent cuts and faster slots follow separate activation paths
The first rent-reduction step does not deliver the full 90 percent target immediately. Solana plans five stages that would eventually lower the rent calculation from 6,960 lamports per byte to 696 lamports per byte. Rent functions as a refundable deposit rather than a recurring fee — SOL is recoverable when accounts close.
Agave 4.2 included the necessary code, but Solana placed the changes behind independent feature gates. Validators can activate the rent, transaction-size and slot-time upgrades separately after testing. Solana has already reduced its target slot time to 350 milliseconds from 400 milliseconds, with additional stages at 300, 250 and eventually 200 milliseconds. Creech did not provide dates for those remaining stages.
Alpenglow, Solana's proposed consensus redesign, aims to reduce transaction finality to approximately 150 milliseconds. The official roadmap lists it as "in development," with Agave 4.3 expected in October. Neither Creech's post nor the roadmap confirms a guaranteed mainnet activation date.
No verified market movement was directly attributed to the announcement at publication time. The upgrades are incremental rather than a broader change, and each requires separate validator activation. The Solana ecosystem will gather at the Scale or Die conference in November, where further development milestones are expected to be discussed.
This article is for informational purposes only and does not constitute investment advice.