Solana changelog: Transaction V1 on mainnet, cheaper rent, 250ms slots
The Solana Foundation's changelog dated 18 September 2026 lists three notable mainnet feature gates: Transaction V1, a rent reduction to 5,080 lamports per byte, and a slot time reduction to 250 ms. It was posted on 19 September.
The release list alongside them is long — Agave v4.4.0-alpha.4 and v4.3.0-rc.1, Firedancer testnet v26.09.3 and mainnet v26.08.5, Anchor v0.32.2, Token-2022 JS SDK v0.18.0 and a dozen others. Note the Agave entries are an alpha and a release candidate, not general releases.
The ecosystem section is where the argument is. A discussion has opened on removing compute limits entirely: blocks are currently fixed at 100M compute units, and the proposal weighs a two-step path to letting validators pack as much compute as they judge the network can carry. A separate proposal would disable the legacy and V0 transaction formats now that Transaction V1 is deployed, reducing validator complexity — explicitly compared to SIMD-0500, which disallowed deployments of sBPF versions older than v3. Two more proposals would simplify transaction fee burning (burning per transaction rather than summing and halving at the end of a slot) and introduce 128-bit integer multiplication in the runtime.

What it means
Read the three feature gates as one move rather than three. Shorter slots, cheaper rent and a new transaction format all reduce the cost of putting something on chain and increase how often the chain can accept it — and every one of them raises the load a validator must sustain.
That is why the compute-limit discussion sits in the same document. A fixed 100M CU block is the ceiling that makes validator hardware requirements predictable; removing it moves the decision to individual validators and makes the requirement emergent. Whether that is decentralising or the opposite depends on whether smaller operators can keep up with whatever the largest ones choose to accept.
⚠️ These are discussions and proposals, not decisions. On Solana a change becomes real in a SIMD that is accepted and a client release that ships it, and a changelog entry is neither. Nothing here is investment information.