Solana's Planned 90% Cut to Account Deposits Could Weaken One Reason to Hold SOL
Key Takeaways
- •Solana's first rent reduction went live at epoch 1028 on Sept. 3, cutting the reserve parameter from 6,960 to 6,333 lamports per byte, roughly a 9% decrease.
- •The five-stage plan under SIMD-0437 targets a final parameter of 696 lamports per byte, meaning total persistent account state would need to grow tenfold to maintain the same minimum $SOL reserves as before.
- •Excess $SOL above the new minimum can be reclaimed via the WithdrawExcessLamports instruction, but only the account owner, mint authority, or owning program can authorize the withdrawal—not necessarily the party that funded the deposit.
- •The second reduction to 5,080 lamports per byte is on testnet with mainnet expected in mid-September, and the final three steps are expected with Agave 4.4 in November, subject to state-growth review and a fallback to the original parameter.
- •Solana Foundation researcher Umberto Natale found that 75.5% of account-creation events in the studied cohort closed within the same transaction, indicating that activity metrics alone do not measure persistent storage demand.

Solana's Planned 90% Cut to Account Deposits Could Weaken One Reason to Hold SOL
Eligible owners of Solana token accounts can now reclaim excess $SOL that was previously required to keep those accounts open, following the network's first rent reduction, which went live on Sept. 3. For businesses that fund new accounts, the same change reduces the upfront capital needed to create them.
The full plan would alter how account growth translates into $SOL held against storage. If Solana completes its proposed 90% reduction, total persistent account state — including each account's storage overhead — would need to grow tenfold to require the same minimum $SOL reserves as before the rollout. Adoption could therefore expand substantially while the minimum $SOL needed for this reserve channel falls.
The Solana Foundation's tracker confirms that only the first reduction, roughly 9%, is currently live on mainnet. The tenfold comparison applies to the conditional final target, while the initial cut has already lowered reserve requirements.
Solana Rent Reduction and the 10× Hurdle
Solana's "rent" is a balance held against account storage. It is generally recoverable when an account closes, rather than an ongoing bill paid to validators. Lowering the required balance lets new accounts open with less $SOL and can leave existing accounts holding more than their minimum.
At epoch 1028 on Sept. 3, Solana reduced the reserve parameter from 6,960 to 6,333 lamports per byte. The five-stage plan's final target is 696.
Under SIMD-0437, the rent-reduction specification, the minimum equals the account's data size plus 128 bytes of overhead, multiplied by the current lamports-per-byte parameter. A standard token account contains 165 data bytes, giving it an effective size of 293 bytes. SIMD stands for Solana Improvement and Design proposal, the mechanism through which protocol changes are specified and, where applicable, activated by validator vote.
Applying that formula to one million identical standard token accounts produces the following illustration:
These figures are calculated minimum requirements for a fixed account population, not measured withdrawals. The final row assumes all five reductions activate. Different account sizes would yield different totals.
The million-account example illustrates operating capital but cannot establish a network-wide supply effect. Its conditional final reduction of 1,835.352 $SOL represents about 0.000314% of the approximately 585.36 million circulating $SOL shown in CryptoSlate's Sept. 5 market data. The actual aggregate reserve channel would require a broader account inventory, accounting for account sizes, balances and reclaimability.
The tenfold threshold follows from the same relationship. At one-tenth the original reserve rate, ten times as many rent-bearing bytes would be needed to keep the aggregate minimum unchanged. That measure covers the total stock of persistent state, including per-account overhead. User counts, transaction counts and $SOL prices are separate measures; the tenfold comparison describes storage requirements alone.
The live first step sets a smaller hurdle: about 9.9% more rent-bearing state would preserve the original minimum requirement at 6,333 lamports per byte. Both comparisons concern required reserves — actual account balances can remain above those floors.
For payments, reserve demand arises mainly when accounts are opened. The Foundation's July account-state study explains that an associated token account normally serves a particular wallet and token mint. Once it exists, later payments in the same token do not require another account-creation deposit. More payments through existing accounts therefore need not produce a proportional increase in storage reserves.
Withdrawal Authority Decides Who Gets the Capital
The immediate benefit is access to capital already on-chain. The Foundation's Sept. 3 reclamation guide describes an instruction called WithdrawExcessLamports, which moves $SOL above the current minimum without closing a token account or changing its token balance. The Token-2022 program offers the same instruction.
For a token account, the owner must authorize the withdrawal. For a mint, authorization comes from the mint authority, or from the mint account itself signing if that authority has been revoked. Accounts owned by custom programs require the owning program to provide withdrawal logic and check the relevant authority.
This makes control of the account economically significant. A payments provider that funded a customer's token account cannot assume that paying the original deposit grants it the right to reclaim the excess. The party entitled to authorize the withdrawal may differ from the party that supplied the $SOL.
Moving a surplus balance requires an authorized transaction that leaves the minimum intact. It transfers existing $SOL between accounts while conserving the total; it does not issue new tokens. The guide provides no aggregate measure of completed withdrawals or subsequent sales.
For future onboarding, the benefit is more direct: whoever funds an account needs less $SOL upfront. Providers can potentially support more customer accounts with the same capital, even when customers themselves do not purchase $SOL. Whether existing surplus can be redeployed depends on the authority and program arrangements described above.
How long those accounts survive will determine the continuing reserve requirement. Gross account creation can give a very different impression from state that actually remains on-chain.
In his July 20 analysis, Solana Foundation researcher Umberto Natale found that 75.5% of account-creation events in the analyzed cohort closed within the same transaction. The observations were not deduplicated by address, so repeated creation and closure could count as separate events.
Such workflows can generate activity while leaving little persistent account storage behind. The finding does not predict how users will respond to September's reduction. The study also cautions that its weak, unstable correlations between $SOL prices and account activity are descriptive rather than a causal estimate of how cheaper rent changes demand.
A useful test of the policy will therefore track persistent account bytes and their associated minimum reserves alongside activity. Counting new accounts alone cannot establish whether the network has absorbed the lower reserve rate.
$SOL Demand Extends Beyond Account Reserves
Other uses of $SOL continue as well. Under Solana's fee rules, transactions require $SOL: half the base fee is burned and half goes to the validator, while the entire priority fee goes to the validator. Fee payments are a separate demand channel from refundable account reserves. More activity could increase fee use, but throughput alone does not establish how much users pay or the balances they retain.
$SOL holders can also delegate stake to validators to help secure the network and become eligible for rewards. Reclaimed capital could be staked or used to fund more accounts. The cited material does not establish either outcome as a result of the cut, so these possibilities provide no quantified offset to lower reserve requirements.
CryptoSlate's recent analysis of activity and fee economics examined a related distinction: network usage and token economics can move differently. Rent reduction adds a specific reason why growth can require less $SOL per unit of persistent state.
As of Sept. 5, the second reduction, to 5,080 lamports per byte, is on testnet, with mainnet expected in mid-September. The last three steps are expected with Agave 4.4 in November. Each activation remains subject to review of state growth, and a fallback can restore the original parameter. The staged, conditional design reflects a trade-off Solana operators have long weighed: lower reserve requirements make accounts cheaper, but faster state growth increases the storage burden that validators and RPC providers must carry.
The next gates will determine how far the capital saving goes. Persistent state growth and actual reclamation will then show how much of that saving becomes new account capacity, reusable working capital, or reduced $SOL held against storage.