Mike Hale The first step of Reduced Rent on Solana activated at the start of mainnet epoch 1028 on September 3, dropping lamports_per_byte from 6,960 to 6,333. That's a 9% cut to Solana's storage cost, and it's the first of five feature gates that will take the constant down to 696 for a 90% reduction overall. The official upgrade page lists it as a non-breaking change that requires no action from anyone running a program today.
What changes is the price of state. Every account created from epoch 1028 onward needs 9% less SOL to reach rent exemption, and by the end of the rollout an SPL token account's deposit falls from roughly $0.159 to about $0.0159.
Activation: epoch 1028, September 3, 2026. lamports_per_byte is 6,333 on mainnet-beta. Rent-exempt minimums are computed from that constant, so every new account is cheaper to open as of this epoch.
Five gates, paced by state growth rather than a calendar
The reduction ships as five independent feature gates rather than one change, and each one activates only after state growth has been checked at the current level.
Step |
| Cut from 6,960 | Expected |
|---|---|---|---|
1 | 6,333 | 9% | Live, epoch 1028 |
2 | 5,080 | 27% | Mid-September 2026 |
3 | 2,575 | 63% | Agave 4.4, November 2026 |
4 | 1,322 | 81% | Agave 4.4 |
5 | 696 | 90% | Agave 4.4 |
Those dates are expectations. The whole point of splitting one constant change into five gates is that cheaper storage invites more of it, and nobody knows exactly how much more until it happens. Devnet took step 1 in August, mainnet followed in September, and the remaining gates move when the data supports moving.
There's a rollback too. SIMD-0438 is a separate safeguard gate that restores lamports_per_byte to the legacy 6,960 if reduced rent produces excessive state growth, and the SIMD-0437 proposal describes it alongside the reduction schedule. It exists ahead of time so core developers don't have to design, review, and ship a consensus change while an incident is unfolding.
Rent is the mechanism that has kept Solana's state from growing without limit, and cutting it by 90% loosens that constraint on purpose. Five gated steps with a rollback already deployed is how the network tests that decision in increments it can undo.
Existing accounts end up over-funded
Rent-exempt minimums are a floor, not a fee, and lowering the floor doesn't claw anything back from accounts that are already funded. An account opened before epoch 1028 keeps the balance it was funded with, which now sits above what the runtime requires for its size.
That gap widens at every step. By the time the fifth gate lands, accounts across the network will hold roughly 3.06 million SOL more than they need, on SolanaFloor's estimate, with step 1 accounting for about a tenth of it.
None of that moves on its own. Reclaiming it takes an instruction, and the paths already exist. The Token Program's Pinocchio reimplementation ships a WithdrawExcessLamports instruction that pulls surplus lamports out of a token account, mint, or multisig without touching token balances or closing the account, and Token-2022 exposes the same thing.
For accounts your own program owns, you write the equivalent yourself, because the System Program can't move lamports out of accounts it doesn't own. @a_milz has shared a walkthrough of both cases for teams that want to offer it, and the Solana Foundation's program examples repo carries the realloc pattern in Anchor, native Rust, and Pinocchio.
Rent has been a fixed number long enough that treating it as a constant became normal, and plenty of production code encodes that assumption without anyone remembering it's there. The cheapest time to find those spots is now, while the reduction is still only 9% and a stale constant over-funds an account instead of failing to create one.