SIMD-0437: why Solana rent drops 90% in five steps

SIMD-0437 lowers lamports_per_byte from 6,960 to 696. The five steps, the safeguard, and what it means for accounts that already exist.

Updated

SIMD-0437 is the Solana Improvement Document that cuts the price of on-chain storage by 90%: lamports_per_byte goes from 6,960 to 696. It does so in five steps, each switched on separately by validators, so the network can watch how much new state cheaper accounts create before it takes the next one.

Why lower rent

Rent is priced in SOL, and the price per byte had not changed since Solana launched. Every new account, from a token account to an app’s data account, paid the same number of lamports for its bytes regardless of what a lamport was worth. Lower rent makes creating accounts cheaper for users and apps. The risk is state growth: if storage is too cheap, validators must keep more data in memory. A gradual cut lets the network stop if growth gets out of hand.

The five steps

StepLamports/byteToken accountStatus
Original6,9600.002039until 2026
Step 16,3330.001856live · Sep 3, 2026
Step 25,0800.001488live · Sep 11, 2026
Step 32,5750.000754next
Step 41,3220.000387planned
Step 56960.000204planned

Token account: 165 bytes, deposit in SOL. Live status comes from the rent reduction tracker.

Each step is its own feature gate. Validators activate it at an epoch boundary, and from that epoch on getMinimumBalanceForRentExemption returns the lower value. The first two steps went live in September 2026; the remaining three were scheduled with Agave 4.4, expected November 2026. Dates can move, which is why the tracker reads the live value from the chain.

What happens to accounts that already exist

Nothing, automatically. A token account opened at the old price still holds 0.00203928 SOL after every step. The runtime only checks that an account holds at least the minimum, so the old deposit is still valid; the part above the new minimum is simply surplus. No one sends it back, and it does not expire.

The owner can get it back in two ways:

Both work for token accounts and mints. Accounts owned by other programs, such as DeFi positions or stake accounts, need an instruction in their own program, and most do not have one yet.

Reclaim after every step?

Each step makes more of the old deposit reclaimable. You can withdraw after every step or wait for the last one; the total that comes back is the same, because each withdrawal only takes what lies above the minimum at that moment. Waiting costs nothing but time, reclaiming early costs a few network fees per transaction.

The safeguard: SIMD-0438 and SIMD-0392

If cheaper storage ever led to excessive state growth, SIMD-0438 provides a separate feature gate that restores 6,960 lamports per byte. It is not scheduled on any cluster. SIMD-0392 prepares the runtime for that case: existing accounts that hold less than a raised minimum keep working instead of being locked. Reclaimed SOL is yours either way; a raise would only make new accounts more expensive again.

In short

  • SIMD-0437 lowers the rent price from 6,960 to 696 lamports per byte in five separately activated steps.
  • Existing accounts keep their old deposit. The surplus belongs to the owner and does not come back on its own.
  • Token accounts and mints can return it with WithdrawExcessLamports, or with CloseAccount when empty.

Sources

Keep reading