Solana's first rent cut is live on mainnet. Step 1 of SIMD-0437 activated at slot 444,096,000, roughly 23:24 UTC on 3 September, cutting the constant behind every account's minimum balance by 9%. It is the first of five planned cuts aiming at a 90% reduction overall, and it landed exactly where Anza said it would: the day before Transaction V1 arrives on 9 September.
What changed, confirmed directly
Solana's rent model works off one constant, lamports_per_byte, multiplied by an account's size plus a fixed overhead. We queried it on mainnet before writing this, rather than trusting a summary of the proposal:
| Empty account (128 bytes overhead) | SPL token account (165 bytes) | |
|---|---|---|
| Before, lamports_per_byte 6,960 | 890,880 lamports | 2,039,280 lamports |
| Now, lamports_per_byte 6,333 | 810,624 lamports | 1,855,569 lamports |
810,624 divided by 890,880 is a 9.01% cut, matching the "Eff Reduc" column in SIMD-0437's own schedule table exactly. At today's SOL price of $104.26, opening one SPL token account now locks up $0.194 instead of $0.213.
Why this needed a feature gate at all
lamports_per_byte is a consensus-critical constant. Every validator has to agree on an account's minimum balance to agree on whether a transaction that touches it is valid. Anza cannot simply change the number in a config file; the value ships in the client, sits dormant, and only takes effect once enough stake activates the gate at an epoch boundary. That is what happened at slot 444,096,000.
Why the constant was too high to begin with
SIMD-0437 is blunt about the reason. Its own motivation section reads:
Minimum account balance depends on an arbitrary constant set years ago that has since increased significantly in real terms due to increases in the SOL price. This has made state allocation cost more expensive on mainnet beta than on competitors, with no compelling justification provided by real resource costs.
The number 6,960 was never recalibrated for what SOL is worth today. It is the same lamport figure whether SOL trades at $10 or $400, so every time the price rises, the real-dollar cost of opening an account rises with it, for no reason connected to the actual disk space being reserved.
The schedule, and why it is five steps instead of one
SIMD-0437, written by Igor Durovic at Anza, supersedes an earlier proposal, SIMD-0436, that would have simply halved the constant in one move. The five-step version exists because a single 90% cut is a real risk to validators: rent is what keeps Solana's state from growing without bound, and cutting it sharply makes account creation cheap enough that state could grow faster than validators can absorb.
| Step | lamports_per_byte | Cumulative cut | Status, 4 Sep 2026 |
|---|---|---|---|
| 0 | 6,960 | 0%, baseline | Superseded |
| 1 | 6,333 | 9% | Live on mainnet |
| 2 | 5,080 | 27% | Not scheduled |
| 3 | 2,575 | 63% | Not scheduled |
| 4 | 1,322 | 81% | Not scheduled |
| 5 | 696 | 90% | Not scheduled |
The proposal's own text is explicit that this is not a countdown: "Proceed to the next step only if a risk analysis, grounded in existing safeguards and empirical data, indicates that it is safe to do so," and warns that "risk increases superlinearly as the reduction increases with each step." Step 3 alone, 2,575, carries more than a third of the entire planned reduction by itself.
Steps 2 through 5 are not pre-staged
Each step is its own feature gate with its own address. We checked all five directly: step 1's gate is funded and active. Steps 2 through 5 have no account on chain at all, meaning nobody has even created and funded the gate yet, let alone scheduled its activation. The five-step number in every headline about this SIMD is a design target, not a queue.
The safety valve
Cutting rent is easy to reverse in one direction and hard in the other. SIMD-0437 depends on two earlier proposals for exactly that reason: SIMD-0194, which removed a separate rent exemption threshold multiplier from the calculation, and SIMD-0392, which relaxes a post-execution balance check specifically so that rent can be raised back if state grows too fast, without breaking accounts that were created at the lower minimum. A related proposal, SIMD-0389, would do that increase automatically rather than requiring a fresh vote.
That is the actual design: an aggressive cut with a manual brake, not a one-way commitment to 696.
What this sets up for 9 September
This is the second of three items Jacob Creech listed on 29 August: rent reduction, then Transaction V1, then Alpenglow in October. Rent reduction landed a week later than "next week" suggested, and five days ahead of the Transaction V1 date. Whether the two are related, cheaper accounts arriving just before a format that carries more of them inline, is not stated in either SIMD, but the sequencing is hard to miss.
What other coverage left out
Reporting on this step has been accurate on the headline cut and the testnet-to-mainnet timeline. What we did not see anywhere else: the exact activation slot, a same-session RPC verification of the before and after balances rather than a restatement of the SIMD's own numbers, the dollar figures recomputed at today's SOL price rather than the roughly $78 implied by the commonly quoted $0.159 figure, and direct confirmation that steps 2 through 5 do not yet have funded feature gates.
Market context
SOL traded at $104.26 as of 00:41 UTC on 4 September 2026, up 4.57% over 24 hours, for a market capitalisation of $61.03B. The network was in epoch 1028. None of that move is attributable to this SIMD; a rent parameter change on new and existing small accounts is not the kind of thing that moves price, which is itself a useful signal for readers trying to separate protocol news from market news.