Every account on Solana carries a security deposit. To keep data alive on-chain, you lock up SOL proportional to the bytes you occupy — the “rent-exempt” balance — and you get it back only when the account closes. That deposit is one of the oldest levers in Solana’s economic design, and a data-heavy analysis published by the Solana Foundation this week argues it is now calibrated roughly ten times higher than the network’s own security math requires. The conclusion, spelled out across attack-cost models, survival curves and Dune dashboards: Solana could cut rent by an order of magnitude without opening the door to the state-bloat attack rent exists to prevent.
That matters because rent is not an abstract parameter. At the SOL price used in the analysis (about $77.94), creating a standard SPL token account costs roughly $0.159 in locked deposit. A 10x reduction takes that to about $0.016 — and for payments products that must create an Associated Token Account for every new wallet-and-token pair they onboard, that one-time cost is the difference between negligible and material at scale.
The $17 million question
The reason rent exists is state growth. Unlike transactions, which are processed and left behind, account state is forever: every validator must store, index, snapshot and maintain it continuously. A network that makes state too cheap invites an attacker to bloat AccountsDB until validator hardware buckles. So the honest way to evaluate a rent cut is to ask what an attack would cost after the cut.
The Foundation’s model starts from commodity storage at $0.50 per gigabyte, multiplies it by roughly 1,000 validators replicating every byte, then applies a further 100x safety multiplier for operational overhead. That lands on a deterrence benchmark of about $50,000 per gigabyte — a conservative bar for what occupying a gigabyte of everyone’s disk should cost. Current rent prices state at roughly $500,000 per gigabyte, ten times above that benchmark.
Run the attack scenario at one-tenth of today’s rent: AccountsDB storage files currently occupy about 495 GB against a recommended 1 TB of capacity, leaving 505 GB of headroom. Adjusting for the observed 1.47x storage amplification, filling that headroom means allocating roughly 343 GB of live account state — which at the reduced rate still requires approximately $17 million of capital. If validators moved to 2 TB drives, the figure grows to $51 million. And because rent deposits are recoverable when accounts close, that is capital immobilized rather than money burned — but it must stay locked for as long as the malicious state stays live, with no protocol-native payout on the other side. The analysis is careful to note this doesn’t prove an attack unprofitable (an attacker might profit externally via shorts or extortion); it shows the economic barrier survives the cut.
State growth is slower than the raw numbers suggest
The more surprising half of the analysis is what Solana’s state is actually doing under normal load. Gross demand looks alarming: newly created accounts request roughly 10 GiB of state per day. On July 11, for instance, new accounts asked for 10.23 GiB — 84% of it from classic SPL token accounts.
Almost none of it sticks. In the cohort the Foundation tracked, 75.5% of account-creation events closed within the same transaction, and only 5.65% of allocated bytes were still alive after a million slots (about 4.7 days). Much of the churn traces to trading workflows — including one arbitrage bot that creates and closes accounts in tight loops yet leaves a live footprint of under half a gigabyte. Net of closures, the live account state grows by roughly 0.3 GB per day, and a direct fit to AccountsDB storage-file metrics gives about 0.23 GB per day.
Extrapolated two years out, baseline growth puts AccountsDB near 665 GB. Even a deliberately aggressive 10x-growth scenario reaches only about 2.3 TB — inside the range of ordinary validator hardware, before accounting for the fact that compressed full snapshots run at roughly 22% of the raw storage-file size.
The analysis also checked whether cheap state mechanically accelerates account creation — the fear being that a rent cut would itself trigger the growth it must withstand. Using SOL price swings as a natural experiment in the USD cost of state, it found the correlation between rent’s dollar cost and account creation to be weak, unstable and regime-dependent. Demand appears driven by what applications are doing, not by what bytes cost — though the authors flag, correctly, that this is descriptive evidence, not a causal estimate of what a policy-level cut would do.
What is actually occupying the disk
A snapshot at epoch 997 shows live state concentrated in a few heavyweight categories. SPL token accounts are the single largest component — with roughly 30% of that token footprint attributable, via an admittedly imperfect suffix heuristic, to Pump.fun-style memecoin issuance. OpenBook/Serum markets are the opposite pattern: a tiny share of accounts occupying roughly 30% of live bytes, because an on-chain orderbook stores its market, request queue, event queue, bids and asks as separate persistent accounts. NFT infrastructure, mostly Metaplex token metadata, remains a substantial third block.
That composition matters for the policy debate: today’s state is dominated by a few structurally heavy programs and token-account sprawl, not by a long tail of applications waiting for cheaper bytes.
Where the proposals stand
None of this is protocol policy yet. The live vehicles are SIMD-0437, which proposes incrementally reducing the rent rate (lamports per byte) to 696, and the broader SIMD-0389 discussion on reducing account creation costs, which pairs a reduction with a supervisory controller that could adjust parameters if state growth misbehaves. The Foundation analysis is best read as the evidentiary brief for those proposals: rent sits about 10x above its own security benchmark, persistent growth is a fraction of gross demand, and the deterrent survives a big cut.
The historical context strengthens that brief. Solana’s rent parameters were calibrated years ago under a very different operating environment — validator hardware has improved, operators have accumulated hard-won experience running AccountsDB at scale, and the economic value of SOL has changed substantially since the schedule was set. A deposit rate fixed in lamports inherits every move in SOL’s dollar price, which is precisely how a parameter meant to price disk space drifted an order of magnitude away from the infrastructure cost it was designed to track.
The payments implication is the part builders will feel. Because an Associated Token Account is a one-time onboarding cost per wallet and mint, a 90% cheaper deposit compounds across every user a payments app touches. The analysis benchmarks a post-cut Solana against Tempo — a payments-first L1 with stablecoin-denominated gas — and finds Solana’s account-creation costs landing in the lower tail of Tempo’s observed range, with less volatility, even though Solana’s deposit remains recoverable while gas is simply spent.
There are honest caveats. The attack model is a benchmark, not a guarantee; correlation analysis can miss delayed or nonlinear responses to cheaper state; and validators’ real constraint set includes I/O, snapshot generation and restart times, not just disk capacity. But the direction of the evidence is unambiguous, and the interesting question has shifted from whether Solana can afford to cut rent to how fast governance moves on SIMD-0437. For anyone building account-heavy applications on Solana — payments above all — that is a parameter change worth watching closely.
