Skip to main content
Rent is a refundable deposit, not a fee. SIMD-0437 lowers the deposit every account must hold, in five independently gated steps. Accounts created before a step keep the balance they were funded with, so each step leaves them over-funded. The SPL Token and Token-2022 programs can return that difference through WithdrawExcessLamports without closing the account or touching its token balance. Nothing expires — the excess sits in your own accounts until you choose to move it.
Read Account model first if you are new to how Solana accounts are funded.

What rent actually is

Every account on Solana holds a SOL deposit sized by the space it occupies. It is not spent — it is returned in full when the account is closed. The formula is:
ACCOUNT_STORAGE_OVERHEAD is a fixed 128 bytes that every account pays for regardless of its payload. lamports_per_byte is the network-wide constant that SIMD-0437 changes. A standard 165-byte SPL token account has therefore always cost (128 + 165) × 6,960 = 2,039,280 lamports — the ~0.00203928 SOL you see deducted whenever a wallet opens an associated token account.

What SIMD-0437 changes

SIMD-0437 cuts lamports_per_byte from 6,960 to 696 — a 90% reduction — rolled out through five separate feature gates so validators can absorb the state-growth effect one step at a time. Step 1 activated on mainnet on 3 September 2026. The remaining steps land as their feature gates are enabled; treat the schedule as subject to change and read the live value from the cluster rather than hardcoding it.
SIMD-0437 depends on SIMD-0194, which deprecates the rent exemption threshold “to avoid unnecessary floating point math when setting the rent params on feature activation”. In practice the Rent sysvar now carries lamports_per_byte_year = 6,333 with exemption_threshold = 1.0, rather than the old 3,480 × 2 split that produced 6,960. Do not multiply those two fields yourself — call getMinimumBalanceForRentExemption and let the cluster answer.

Why existing accounts hold too much

Lowering the constant changes what an account needs. It does not change what an account has. An account funded at 6,960 lamports per byte keeps that balance after step 1 activates, so it is over-funded by:
For a 165-byte SPL token account after step 1 that is 293 × (6,960 − 6,333) = 183,711 lamports, or ~0.000184 SOL per account. A Token-2022 account carrying extensions is larger, so it holds proportionally more — a 182-byte account is over-funded by 310 × 627 = 194,370 lamports. Individually that is dust. A wallet that has interacted with a few hundred tokens over the years is holding a meaningful multiple of it, and by step 5 each 165-byte account has 1,835,352 lamports (~0.00184 SOL) sitting above its minimum.

Which accounts can hand it back

Excess lamports in a program-owned account can only be moved by that program. Whether you can reclaim rent without closing the account therefore depends entirely on which program owns it.

SPL Token and Token-2022

Both expose WithdrawExcessLamports. The account stays open, keeps its token balance, and simply drops to the current minimum.

Everything else

No equivalent instruction. The rent is released only when the account is closed — a destructive operation with its own preconditions, not a rent sweep.
Concretely, for the account types Raydium users hold: Wrapped SOL accounts are the one token-program exception: their lamport balance is their token balance, so both programs reject them with TokenError::NativeNotSupported. Token-2022 added UnwrapLamports (discriminant 45) for that case; @solana/spl-token ships createUnwrapLamportsInstruction for it as of 0.4.15. Skip native accounts in a rent sweep and handle them deliberately.

The WithdrawExcessLamports instruction

Discriminant 38 in both token programs’ instruction enums. From spl-token-interface:
Three properties make it safe to fire at every account in a wallet:
  • It takes no amount. The program computes source.lamports − rent.minimum_balance(source.data_len()) itself, so it can never take an account below the current minimum, and it stays correct as later steps activate.
  • It does not close anything. The account keeps its data, its owner, and its token balance.
  • It is idempotent. Running it against an account already at the minimum moves zero lamports and succeeds.
A frozen token account is still eligible: freezing restricts token movement, not lamports.

Building the instruction

@solana/spl-token does not export a builder for it. As of 0.4.15 the enum entry is still commented out:
Encode it directly. The payload is a single discriminant byte:
Pass each account’s own programId. SPL Token and Token-2022 instructions can share a transaction, but each one must be addressed to the program that owns its source account. Measured on mainnet, the instruction costs 270 compute units on the SPL Token program and 1,414 on Token-2022 — negligible either way. The real constraint is transaction size, not compute.

Finding reclaimable accounts

Do not derive the excess from a hardcoded rate. Ask the cluster what each account needs right now, so the same code keeps working through all five steps:
getMinimumBalanceForRentExemption(0) is a useful side-channel: it returns exactly 128 × lamports_per_byte, so dividing by 128 tells you which rollout step the cluster is on without parsing the Rent sysvar.

Batching: how many fit in one transaction

Each WithdrawExcessLamports instruction contributes one unique writable account key — 32 bytes in the compiled message — plus about 7 bytes of instruction encoding. Destination, authority and fee payer are all the same wallet, so they cost one key between them. Against the 1,232-byte transaction limit, roughly 26 instructions fit once compute-budget instructions and the blockhash are counted. Twenty per transaction is the safe working number, and it is what Raydium’s own implementation uses. A wallet with 116 reclaimable accounts therefore sweeps in six transactions, at one 5,000-lamport base fee each. Note the economics: the fee is charged per transaction, not per account. Reclaiming fewer accounts does not cost less, which is why a partial sweep is rarely worth the extra round trips.

Reclaiming through Raydium

The raydium.io/reclaim-rent page scans the connected wallet’s SPL Token and Token-2022 accounts, shows the total split by program, and sweeps everything in batched transactions. The scan is read-only — no signature until you press Reclaim all rent. The page deliberately covers token accounts only. Account types that can release rent only by closing are excluded rather than listed as unavailable, because closing an account is a different, destructive action.

Reclaiming from the SDK demo

Version banner. Demos target @raydium-io/raydium-sdk-v2@0.2.42-alpha against Solana mainnet-beta, verified 2026-09. WithdrawExcessLamports is encoded by hand and is independent of the SDK version; the SDK is used only for transaction building and batching.
Two scripts in raydium-sdk-V2-demo/src/rent:
reclaimRent.ts batches at 20 accounts per transaction and signs all batches in one pass:
Simulate before you send. simulateTransaction with accounts.addresses returns post-execution lamport balances, which is the cheapest way to confirm the arithmetic matches what the cluster will actually do.

Should you reclaim now or wait?

Both are fine, and the difference is small either way:
  • The excess is not going anywhere. It sits in your own accounts. Nothing expires, nothing is swept, no deadline applies.
  • Waiting compounds. Each step releases more from the same accounts, and one sweep after step 5 costs the same in fees as one sweep today.
  • Reclaiming now does not forfeit later steps. An account you sweep today is simply at the current minimum; the next step makes it over-funded again and you can sweep it again.
The only real cost of reclaiming early is the base fee, and the only real cost of waiting is that the lamports stay immobile a while longer.

Further reading

SIMD-0437

The proposal itself — the five feature gates and the rationale for stepping the reduction.

Reduced rent

Solana’s rollout page: current step, schedule, and what changes for new accounts.

Rent reduction: a data-backed analysis

The economics, and the state-growth risk the stepped rollout is designed to manage.

Account model

How Solana accounts are funded, owned, and closed — the background for everything above.