- SIMD-0437 lowers the rent rate from 6,960 to 696 lamports per byte in five feature-gated steps. Steps 1 and 2 are active on Mainnet, so the rate is 5,080 lamports per byte and a token account needs 1,488,440 lamports instead of 2,039,280.
- Existing accounts keep their balances. Anything above the new minimum is excess that the account’s authority can withdraw, and each later step frees more.
- Token accounts and mints, under both the Token and Token-2022 programs, release it through the
WithdrawExcessLamportsinstruction. Stake accounts release it through a normal stake withdrawal. A PDA releases it only through an instruction in the program that owns it. - If the rate is ever reset to 6,960 under SIMD-0438, accounts you have reclaimed stay valid as long as they do not grow or change owner.
- Read minimums from
getMinimumBalanceForRentExemptionrather than hardcoding them.
Main article
Every Solana account holds a minimum balance, its rent-exempt minimum, which is refunded in full when the account closes. The minimum is the account’s size plus 128 bytes of metadata, multiplied by the rate in lamports per byte:To follow along, you need a Solana node endpoint. See Solana tooling to get set up.
Reduction schedule
All amounts are in lamports. On Mainnet, step 1 activated at slot 444,096,000 on September 3, 2026, and step 2 at slot 446,256,000 on September 11, 2026. Solana expects steps 3–5 with Agave 4.4 in November 2026. The SIMD-0438 reset is gated by
rnt8ZQpz2HYhX3DkYBDGjJS1a36mYq69oXka7JrhEdi.
Check the current rate
Query the six features through your endpoint:solana rent:
solana-test-validator 4.3.0 starts at 6,960 lamports per byte, even with --clone-feature-set, which marks the rent features active without applying their rates. A reclaim script finds no excess on a local validator, so test it on Devnet, where steps 1 and 2 are active as on Mainnet.What happens to existing accounts
The reduction does not move any lamports. An account created before a step keeps its balance, and everything above the new minimum for its size becomes excess. How you withdraw the excess depends on the program that owns the account:
If SIMD-0438 ever resets the rate, the protocol keeps reclaimed accounts valid. Under SIMD-0392, active on Mainnet since slot 443,664,000, a transaction can leave an account below the current minimum as long as the account does not grow, does not change owner, and does not lose lamports below its starting balance. Only new allocations pay the higher rate.
Reclaim from token accounts and mints
TheWithdrawExcessLamports instruction moves an account’s lamports above its current minimum to a destination you choose. Who signs depends on the account:
- Token account — the owner.
- Mint — the mint authority. A mint without a mint authority accepts the mint account’s own keypair instead.
- Multisig — the multisig’s signers.
reclaim.mjs
Reclaimable: 0 lamports from 0 accounts until the next step activates.
WithdrawExcessLamports fails on a wrapped SOL account with Instruction does not support native tokens, and on a mint without a mint authority with Account does not support specified authority type unless the mint account itself signs.
Reclaim from stake accounts
The stake program computes a stake account’s reserve from the current rate, so the excess on an older stake account can be withdrawn like any other unstaked balance.solana stake-account shows the reserve that the stake program applies:
insufficient funds for instruction.
The
meta.rentExemptReserve field in parsed stake account data always reads 2282880, the value before SIMD-0437. The stake program writes that fixed value for compatibility and ignores it, so compute the reserve with getMinimumBalanceForRentExemption(200).Reclaim from your program’s PDAs
Only the program that owns an account can debit it, so excess rent on your program’s PDAs stays there until your program moves it. An instruction that has already checked the authority’s signature and the PDA’s seeds can transfer the excess directly:src/lib.rs