Priced by the Byte
Two chains charge for the same thing — permanent space in a replicated database — using opposite rules. Solana bills by the byte; the XRP Ledger bills by the object. We pulled Solana's numbers straight from mainnet RPC and set them against our own measurements of XRPL state, and the result is not the one the usual comparison implies. XRPL is more expensive than Solana for ordinary objects. It is 22× cheaper for the one object that matters most.
Two rules for the same job
Solana charges for state by the byte: every account, whatever it holds, pays the same rate per byte forever. The XRP Ledger charges a flat 0.2 XRP per object regardless of what that object weighs — a ticket and an NFT page holding thirty-two NFTs cost exactly the same. One rule produces a single price. The other produces a range.
Solana's bar is a point because the price cannot vary. XRPL's stretches across two orders of magnitude — and the cheapest end is exactly where the largest objects sit.
That is the whole argument in one figure, and it is not the one the usual comparison implies. XRPL is not simply cheaper or more expensive than Solana — it is both, depending on which object you create.
How we derived Solana's rate from the chain
Solana's rent-exempt minimum is (128 + data_size) × 6960 lamports. We did not take that constant from a document. Asking mainnet RPC for the minimum balance at two sizes returns 890,880 lamports at 0 bytes and 2,039,280 at 165; the difference over 165 bytes is 6960 exactly, and feeding it back through the formula reproduces the RPC's own answer to the lamport.
Read the amber line as the whole of Solana's policy and the blue dots as the whole of XRPL's. Against a uniform $0.000511 per byte, an XRPL ticket costs 1.9× more, a trust line 1.2× more, and a full NFT page 22× less. The internal spread on XRPL is 43×. On Solana it is exactly 1.
So the popular framing — Solana is cheap, XRPL is expensive — is wrong in both directions at once. For the objects most users actually create, XRPL already charges more than the chain it is being compared unfavourably against. What XRPL has is not a low price. It is an inconsistent one.
What Solana got for the uniform price
Uniform is not the same as adequate. At $0.065 for a bare account — one sixteenth of XRPL's — Solana has accumulated roughly 957 million accounts across its eight largest programs and at least 283 GB of live state(our measurement of the five largest; published figures put the full total near 500 GB), against the XRP Ledger's 8.15 million accounts and 3.49 GB. That is 80 to 140 times the state for a network of comparable age, and it is why a 2026 Solana validator is specified with 384–512 GB of ECC RAM while an XRPL validator runs on a consumer machine. Solana keeps accounts in memory; state size is a hardware bill, paid monthly, forever.
We counted one slice of it — and half of it is empty
Those totals are usually quoted rather than measured, because the RPC method that would count them is disabled on public endpoints. Using a provider that permits paginated getProgramAccountsV2, we sized the SPL Token program directly. Pagination runs in pubkey order, so the last key read gives the fraction of the address space covered and the total follows — a method we calibrated against the Stake program, walked to exhaustion at 1,470,159 accounts, which the estimator reproduced to 0.1% from one second of reading. On that basis there are roughly 612 million SPL token accounts. Then we re-read a sample of them for the balance field, and found the number that matters:
53.3% of SPL token accounts hold zero tokens. Not low balances — none. Across roughly 612 million of them that is about 326 million empty accounts occupying some 54 GB — fifteen times the entire XRP Ledger, storing nothing at all, with on the order of $49M of SOL frozen behind them as rent nobody will reclaim because reclaiming it is worth fifteen cents an account.
Is 54 GB actually a problem? Only if you price the right thing
Taken as storage, barely. At 2026 NVMe rates 54 GB costs about $4 per node, and account data on Solana lives primarily on disk in memory-mapped account files, not in RAM. Anyone claiming those empty accounts are eating a validator's 512 GB of memory has the architecture wrong, and this article said so too loosely before we checked.
What each account costs is not its bytes — it is a permanent row in the accounts index, plus a hash input every time the accounts hash is recomputed, plus weight in every snapshot a new validator must download and replay before it can join. Anza's own description is blunt about which of those bites: “because there are so many accounts on Solana, the index can become very large which can lead to large RAM requirements” — which is why the index itself has since been pushed onto disk with only hot entries cached in memory. The cost of an empty account is per account, and it is paid on every node, at every snapshot, forever.
And before that count is used as an indictment, two measurements cut the other way — both of which we went looking for expecting the opposite.
The empty accounts are not spam. Slicing mint and owner out of 352,217 sampled accounts, the 187,804 empties are spread across 101,900 distinct mints: the single largest mint accounts for 5.9% of them, the top ten for 13.7%, the top hundred for under 20%. And the biggest sources are the most legitimate tokens on the chain — USDC, USDT, wrapped SOL and JUP. This is overwhelmingly the residue of people who held something, spent all of it, and left the account open. A spam campaign would show a handful of mints and a handful of owners; this shows neither. (The one caveat: 56.5% of empties sit in mints with no live holders at all — dead tokens — and this sample cannot say whether those were bought-then-abandoned or airdropped.)
And that raw state comparison is unfair as stated. Solana's headline throughput is half consensus overhead — measured over 30 samples, 3,257 raw TPS is 1,629 non-vote TPS, the rest being votes every validator emits each slot, which XRPL has no equivalent of. Against XRPL's 17.4 real TPS measured over 120 ledgers, Solana carries roughly 94× the real transaction load. Normalised that way the state comparison collapses. Against XRPL's 0.20 GB per TPS, Solana runs 0.17 GB per TPS on the 283 GB we measured and 0.31 if the full ~500 GB is used — so somewhere between slightly more efficient than XRPL and 1.5× less. Either way, nothing remotely like the raw eighty-fold gap. Per unit of work actually done, the two chains carry comparable state.
So the honest verdict on Solana's trade is that it was probably worth it — for Solana. Cheap state bought a chain doing ninety times our transaction volume, its junk is the by-product of real use rather than attack, and its validators are paid well enough to carry the hardware. What does not follow is that the same trade transfers here, because the two conditions that make it work are precisely the two XRPL lacks: the throughput to amortise the state, and the revenue to pay for it.
Which produces the irony at the centre of this comparison. Solana charges by the byte but is hurt by the count. XRPL charges by the count but is hurt by the bytes — a 9,458-byte NFT page pays the same 0.2 XRP as an 83-byte ticket. Each chain prices the dimension it is not mainly constrained by. That, and not the level, is the design lesson worth taking from either of them.
One honest caveat in Solana's favour: this is not the whole picture in the other direction either. Those 43.67 million token accounts cost $6.5M in rent at Solana's per-byte rate; the same number of objects on the XRP Ledger would lock $9.5M. Per object, XRPL is more expensive — which is exactly the point made at the top of this article, and exactly why the interesting question is not the level but what the level is charged on.
The response has been engineering rather than repricing. Keeping that many accounts addressable is now its own discipline — Anza's deep dive into AccountsDB and Syndica's independent reimplementation of it are both, in effect, engineering around the size of the account set. Meanwhile SIMD-0084 disabled rent collection outright, so accounts are no longer reclaimed by decay — they persist unless someone explicitly closes them. Any fix grandfathers the existing ones in.
The dust the proposals describe, counted
Solana's own improvement discussions say a large share of stake accounts hold under one SOL and carry “significant account overhead without adding meaningful economic weight.” That is usually left as an assertion. We walked the entire Stake program — 1,470,159 accounts, the complete set, not a sample — and it is worse than the sentence suggests:
Complete walk of the Stake program, not a sample: pagination ran to exhaustion at 1,470,159 accounts. 37.0% hold under 0.1 SOL. Rent collection was disabled by SIMD-0084, so none of them expire.
53.8% of every stake account on Solana holds less than one SOL. They occupy 54% of all stake-account state and represent 0.02% of the SOL staked in them. More than a third hold under a tenth of a SOL. Half the rows, half the bytes, one five-thousandth of the value — and because rent collection was disabled, nothing removes them. This is the clearest illustration in either article of what happens when the cost of keeping a row falls below the cost of caring about it.
So does charging more actually keep a ledger clean?
The obvious test is to put the two side by side. A trust line on the XRP Ledger and a token account on Solana do the same job — they are the record that says “this wallet can hold this token” — so they compare directly. We sampled 120,000 trust lines and 200,000 accounts from our own copy of the XRP Ledger:
The answer is yes, but not for the reason people usually give. People abandon token positions at roughly the same rate on both chains — 39% of trust lines hold nothing, against 53% of Solana token accounts. That gap is real but modest, and it is mostly human behaviour rather than protocol design. Charging more does not make people tidier.
What changes enormously is how many of these records each person creates in the first place. The average Solana wallet carries 7.2 token accounts; the average XRPL wallet carries 0.85 trust lines — 8.5 times fewer. At 0.2 XRP you open one when you actually mean to hold something. At 15 cents you open them without thinking, and on Solana a stranger can even open one for you, which the XRP Ledger does not allow at all.
That is where the deposit earns its keep. The end result is 0.95 GB of abandoned token records on the XRP Ledger against 53.8 GB on Solana — a 57-fold difference produced almost entirely by restraint at the moment of creation, not by anyone tidying up afterwards. On the accounts themselves the same pattern holds: 16.6% of XRPL accounts are empty and 5.1% have never sent a single transaction, so the ledger is not spotless either. It is simply much smaller.
One thing this comparison cannot settle: Solana token accounts have no equivalent of a trust line's limit field, so there is no way to tell an account someone deliberately left open from one they forgot. On the XRP Ledger only 1.8% of trust lines are provably abandoned — nothing held and nothing authorised — but there is no Solana number to set beside it, which is why the honest comparison above uses the plain zero-balance share for both.
Paying validators does not buy decentralisation
Solana funds its hardware bill honestly: 3.72% inflation, all of it to validators (getInflationRate, epoch 1010), plus priority fees and MEV. That is a real budget for a real cost, and it is the strongest argument for Solana's design — rising state is a bill the protocol pays.
It has not produced a widely distributed validator set. Of 693 active vote accounts (11 delinquent, 3,784 gossip nodes), the top ten hold 24.4% of the 432 million SOL staked, and eighteen validators hold a third of it — the threshold at which a colluding or failing group can stop the chain. Paying validators bought Solana throughput (~2,600 TPS sustained, 99.8% of slots filled) and a funded hardware floor. It did not buy a flat distribution of power, because the hardware floor itself concentrates who can participate.
And the XRP Ledger has no budget at all
This is where the comparison stops being reassuring. XRPL transaction fees are destroyed — ctx_.destroyXRP(fee) in rippled's Transactor, with the ledger header merely accounting for the burn. There are no block rewards and XRP was never inflated. Validators are paid nothing, deliberately, so that payment cannot warp their behaviour (xrpl.org FAQ). They run at pure cost for reputation, governance, and their own infrastructure.
So every byte added to XRPL state is an unfunded obligation on volunteers, secured today by a 36-validator UNL and about 415 publicly visible servers. Solana's state growth raises a bill someone is paid to pay. XRPL's raises a bill that is simply endured until an operator decides it is not worth it. Cheap state is therefore a larger risk on the XRP Ledger than on Solana, not a smaller one — the exact reverse of how “Solana charges less, so we can too” is normally argued.
They are about to do it again
SIMD-0436 proposes halving Solana's rent constant from 6960 to 3480 lamports per byte. Its case is that the existing figure is an “arbitrary constant set years ago” which has risen in real terms with the token price and makes the chain “less competitive.” It names state growth as the sole risk, calls it “unlikely,” and — on a chain already carrying 500 GB and researching archival mechanisms to survive it — offers no account counts, no state-size figures and no growth projection. Its mitigation is that rent can be raised again later, which does not un-write anything written meanwhile.
That argument should sound familiar, because it is the same one being made for cutting XRPL's reserve from 1 XRP to 0.1. Two chains, opposite pricing rules, and the same reasoning arriving at the same conclusion with the same absence of measurement. We tested the XRPL version of it and changed our own answer twice doing so.
What XRPL should actually take from Solana
Not the price. The basis.
Every asymmetry we have measured on the XRP Ledger follows from charging per object rather than per byte. A full NFT page buys 9,458 bytes for one 0.2 XRP increment — 44.8× what a trust line gets for the same money, and 22× cheaper per byte than Solana charges anyone. Pricing that page by the byte, at Solana's own rate, would cost $4.90 instead of $0.22. The exploit would not need a policy fix; it would not exist.
Meanwhile the objects ordinary users create — tickets, trust lines, offers, checks — are already priced above Solana's per-byte rate. A per-byte reserve on XRPL would make small objects cheaper and large ones honest, which is the opposite trade-off to the one currently proposed, and the only one the measurements support.
Solana's mistake was not the level; it was removing reclamation and then discovering that 500 GB of state is easier to create than to store. XRPL's risk is different in kind: it has no revenue to absorb the same mistake, and it prices state in a way that makes the cheapest bytes available precisely to whoever wants the most of them.
Method
Solana figures are primary, read from mainnet-beta JSON-RPC on 2 August 2026 (epoch 1010, slot 436,730,055): getMinimumBalanceForRentExemption at seven account sizes, getVoteAccounts, getClusterNodes, getSupply, getInflationRate, getBlockProduction. The 6960 constant is derived from two RPC answers, not quoted. The account counts here are measured, not quoted, but only for one program. getProgramAccounts is blocked on public RPC, so the SPL Token walk was run against a paid endpoint that permits paginated getProgramAccountsV2: 43,669,985 token accounts walked at 10,000 per page before we hit our own limit — which turned out to be about 7% of the program, and is why the counts quoted above come from the keyspace estimator rather than that walk. The 53.3% empty share comes from re-walking 880,333 of those accounts reading the u64 balance at byte offset 64, and the mint/owner concentration from a further 352,217 read with the first 72 bytes sliced in. The whole-chain figures are now estimates rather than citations too. Sizing the eight largest programs the same way gives roughly 957 million accounts (SPL Token ~688M across all sizes, Token-2022 ~100M, System ~85M, Metaplex metadata ~82.8M, Stake 1.47M exact, Vote 6,843 exact, BPF Loader 88,865 exact), and multiplying each by its measured mean account size plus ~128 B of per-account overhead gives ~283 GB across those five largest — consistent with the ~500 GB figure once the long tail of other programs is included. What is still genuinely unmeasured is that tail: no RPC method enumerates program IDs, so there is no way for anyone without a full validator snapshot to close the gap, ours or anyone else's. Every other Solana number on this page is re-derivable from the RPC calls listed above, and a runnable harness re-checks all of them. XRPL figures are our own: a 614,400-object state census, a 220-account testnet fleet for true object-plus-index byte costs, and full-history sizing; method in the companion article. Prices at time of writing: SOL $73.44, XRP $1.082. Both chains' costs move with their token, which is the whole reason each keeps revisiting the question.