---
title: "Solana Rent Takes the First of Five Steps to a 90% Cut"
description: "The first step of SIMD-0437 activated at mainnet epoch 1028, dropping lamports_per_byte from 6,960 to 6,333. Four more feature gates follow, each one waiting on state growth data, until Solana's storage cost lands 90% below where it started."
author: "Mike Hale"
published: 2026-09-07T22:17:00.000Z
updated: 2026-09-08T20:28:05.943Z
category: "Infrastructure"
tags: ["Solana"]
canonical: https://stacksmith.xyz/articles/simd-0437-rent-reduction-mainnet
source: "Stacksmith"
---

# Solana Rent Takes the First of Five Steps to a 90% Cut

The first step of [Reduced Rent](https://solana.com/upgrades/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 | `lamports_per_byte` | 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](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0437-incremental-rent-reduction.md) 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](https://solanafloor.com/news/here-s-everything-you-need-to-know-about-the-upcoming-319-m-sol-airdrop), 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](https://x.com/a_milz) has shared a [walkthrough of both cases](https://x.com/a_milz/status/2095532192579661927) for teams that want to offer it, and the Solana Foundation's [program examples](https://github.com/solana-foundation/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.