Skip to main content
TLDR:
  • 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 WithdrawExcessLamports instruction. 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 getMinimumBalanceForRentExemption rather 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:
The rate was 6,960 lamports per byte from Solana’s launch until September 2026. SIMD-0437 lowers it to 696 in five steps, each behind its own feature gate. A step activates only after a risk review of the previous one, and the SIMD-0438 feature can reset the rate to 6,960 if state grows too fast.
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:
On Mainnet, after step 2:
The minimum for a given size comes from getMinimumBalanceForRentExemption, which the CLI wraps as 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

The WithdrawExcessLamports 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.
This script finds the wallet’s token accounts under both token programs, adds any mints passed as arguments, and withdraws the excess from each one in batches of 20:
reclaim.mjs
Run it with the addresses of mints for which your wallet is the mint authority, or with no arguments for token accounts only:
The five accounts in this run are two Token program accounts, a Token-2022 account, a Token program mint, and a Token-2022 mint, all funded at the rate before SIMD-0437. One transaction reclaimed 2,451,520 lamports for a 5,000-lamport fee. A second run reports 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:
This undelegated account holds the reserve from before SIMD-0437, so 616,640 lamports are excess at step 2. Withdraw them with the withdraw authority:
For a delegated account, the withdrawable amount is the balance minus the delegated stake and the current reserve. A withdrawal above that fails with 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
The PDA keeps exactly the current minimum for its size. Programs that you do not control need their own instruction for this, and many programs have none.

When to reclaim

Each step makes more of the same balance withdrawable, and every reclaim costs a transaction fee of 5,000 lamports for up to 20 accounts in this script. A token account created before SIMD-0437 frees 550,840 lamports at step 2 and 1,835,352 lamports in total after step 5. Running the reclaim after each activation collects the excess as it appears. Waiting until step 5 collects all of it in one pass.

Additional resources

Last modified on October 7, 2026