The Reserve Was Never a Fee

Reserve votes ring like a bell

Reserves change through fee voting: every 256th ledger (roughly every 15 minutes) is a flag ledger, where each validator declares the schedule it wants; when a majority of the trusted validators agree on a change, a SetFee pseudo-transaction applies it one ledger later. Mid-upgrade — old defaults voting against new ones — whichever majority materialises at each boundary wins, so the enforced schedule oscillates. Hours after David Schwartz committed the new recommended schedule (9996e4a57e), the December 2013 cut applied, un-applied, and re-applied within a single day:

September 2021 was the same event at scale — thirteen changes, six full cut-and-revert cycles, before the seventh cut held:

Neither episode appears in any published reserve history we can find — each oscillation sits between voting windows a few thousand ledgers apart, invisible to a bisection, which only sees changes that last. By December 2024 the validator community coordinated before flipping: that cut applied once, cleanly. And the other number in the same object — the 10-drop reference fee — has never changed once in thirteen years. The reserve is the only knob validators have ever turned.

Does the reserve match what the SSD actually costs? Not remotely — on purpose

A trust line serializes to 211 bytes (measured with ledger_entry against our own node). Replicated across the 415 publicly visible rippled servers that is ~88 KB of NVMe, and consumer NVMe runs $60–90 per terabyte in 2026 (the tracker's Gen 4 average on 1 August 2026: $76/TB, held flat by AI demand for NAND). One-time hardware cost: about six millionths of a dollar.

A disk-priced reserve would be an invitation, not a fee: at $0.000006 per object, $100 buys ~16 million trust lines — an attacker could double the ledger's entire 13-year accumulated state for the price of lunch, and every future node would carry it forever. The sane comparison is carry cost, because the reserve is a lock, not a spend: 0.2 XRP idle at a 5% opportunity rate is about a cent a year, within an order of magnitude or two of the network's amortized hardware cost per object once RAM caching, history amplification (history-keeping nodes store a fresh copy of an object every time it changes) and node churn are counted. The margin above physical cost is the spam deterrent — storage was the resource being protected, never the bill being recovered. Even the proposed 0.01 XRP per object stays ~1,000× above disk; nobody proposes disk parity, because disk parity was never the design.

Same reserve, very different bytes

Do different objects at least weigh differently? Yes — by 25× — and the reserve ignores it entirely. We sampled 614,400 live state entries in binary off our node (a hash-ordered walk is a uniform random sample; its shares independently predict 6.90M trust lines and 30.0k AMMs against the 6.86M and 30.1k that actually exist):

An 83-byte Ticket and a 2 KB NFT page pay the identical 0.2 XRP — and the NFT page holds up to 32 NFTs on that one increment, making NFTs the cheapest bytes on the ledger per reserve XRP. Meanwhile one in six state entries is a DirectoryNode — the index pages the ledger creates as a side-effect of owned objects — and those pay no reserve at all. Both are further proof the reserve was never a storage price: it is a flat per-object deterrent. Scaling the sample up, the entire XRP Ledger state is ~19 million entries averaging ~180 bytes — about 3.5 GB of raw objects, or roughly a quarter's worth of NVMe per node after thirteen years.

Trust lines are the single largest thing on the XRP Ledger: 6.91 million of them, 1.46 GB, 41.7% of all state bytes — more than the accounts that own them. They are also the honest case, sitting almost exactly on their weight (36.0% of objects → 41.7% of bytes, a ratio of 1.16), and our own independent mirror holds 6.86M of them, agreeing with this ledger-derived estimate to within 0.6%. Accounts take a fifth of the bytes but pay the 1 XRP base; DirectoryNodes — the index pages the ledger builds for each owner — take almost a quarter and pay nothing. And then the outlier: NFT pages are 1.08% of objects and 11.0% of the bytes — 10.2× their object share, the largest disproportion of any reserved type on the ledger. That is not an anomaly; it is the pricing rule working exactly as written.

The flat design's weakest corner: NFT pages

The reserve is charged per page, not per NFT. rippled demands more reserve only when OwnerCount rises (NFTokenMint.cpp#L339), and a mint raises it only when it opens a new 32-slot page (Protocol.h#L68, kDirMaxTokensPerPage = 32):

So the deterrent is paid once per thirty-two mints. We filled a page to all 32 slots with maximum-length URIs on testnet: 9,458 bytes for a single 0.2 XRP unit, and no index page, against a trust line's 354 bytes all-in — a 26.7× per-byte discount. A gigabyte of permanent state that way locks about 21,200 XRP (~$22,800) against ~565,000 XRP (~$607k) for a gigabyte of trust lines. Nor does speed help the defender: that gigabyte is 3.4 million mints, which at a deliberately unremarkable ten mints per ledger takes about two weeks and burns roughly 41 XRP (~$44) in fees in total. Fee escalation answers bursts, not a patient drip — a slow miner pays the 12-drop floor forever, so the locked capital is the entire defence.

And the deposit does not come back the way it does elsewhere. We burned 20 of 32 NFTs from a full page: that page shrank from 9,424 to 3,564 bytes, but OwnerCount did not move and no reserve was refunded — a page is released only when its last NFT is burned. Every other object type in this article returns its increment the moment it is deleted, which is the self-cleaning behaviour the 2021 trust-line collapse shows at scale. NFT pages are the one place that behaviour does not apply.

This is the one place the article's own argument runs thinnest, so it is worth being exact about what the reserve still buys: $22,800 of capital frozen for as long as the spam exists is a real barrier, and the bytes per NFT are bounded whatever the attacker does. But the asymmetry is the point — and it cuts against the 0.1 / 0.01 proposal harder than anything else here. At 0.01 XRP per object that same gigabyte locks ~1,060 XRP: about $1,100 to permanently enlarge every node's state by a third, and none of it refundable until each page is emptied one NFT at a time. Whatever the right base reserve is, the per-object increment is the half that should not be cut twice as deep.

1. Every cut was a thermostat correction

April 2013 came as XRP first acquired a price; December 2013 as the ledger's own DEX — its on-chain order book, trading XRP against gateway USD before major exchanges listed it — priced XRP fifteen times above April; September 2021 at $1.08 after that year's run; December 2024 at $2.73, five weeks after XRP traded at $0.51. Validators cut when appreciation pushed the real value of the deterrent far above intent — restoring it, exactly what the April 2013 voting code was built for. A cut at today's ~$1 XRP would be the first in thirteen years with no price run to correct.

2. The deterrent is at its floor, not its ceiling

About a dollar per account, 21 cents per object — the bottom of the range ever enforced. And the cost falls on almost no one: honest users get the deposit back. The parties for whom a 10× cut is a real 10× saving create accounts in bulk and walk away — our blocklist flags 587 accounts, 575 of them wallet drainers, and disposable-wallet fleets are exactly the input those operations consume (payment-drain tracker). The base reserve is the only per-identity cost a sybil fleet pays.

3. The risk is asymmetric

A too-high reserve is fixed by one vote — the record shows five. A too-low one writes state that a later vote cannot un-write: raising the reserve does not shrink a ledger that already bloated. (This is the argument the measurements further down qualify most sharply — refundable state, it turns out, does get cleaned up.) And at 0.01 XRP per object the deletion refund stops being worth a transaction, quietly killing the self-cleaning behaviour. A deposit that rounds to zero is not a smaller version of the 2012 design; it is the absence of it.

The strongest case against holding — steelmanned

The pro-cut side has real arguments, and a position piece owes them their best form.

Both claims survive scrutiny, and both are about the base reserve specifically: the onboarding subsidy is a genuine ~$1-per-user spend for a non-custodial app, and the tipping barrier is the base reserve refusing the first payment. Neither is an argument about the per-object increment. Hold that thought — the measurements in the next section land on exactly that split.

“But hardware is ten times better now” — measured

The last serious pro-cut argument: drives improved so much since 2012 that the deterrent should fall with them. Measure it. Consumer SSDs sold at $0.82–0.98/GB in mid-2012 against $76/TB today — 12× cheaper per byte, and ~23× faster (SATA III's 0.6 GB/s cap vs Gen 5 NVMe's ~14). But DRAM — where a validator's hot state actually lives — went the other way: ~$3–5/GB in 2012 vs $11.75–18/GB in August 2026, after the AI build-out's 5× spike. Memory per byte costs more than it did when reserves were designed.

Set those curves beside the reserve's own: in XRP terms it already fell 200–250× — outpacing the fastest hardware curve by a factor of twenty. In dollar terms it held roughly flat while NAND got 12× cheaper, which is why the deterrent-to-disk multiple drifted from roughly 3,000–14,000× in 2013 to 10,000–35,000× today — a hardware dividend of about 10% a year, small enough to absorb by making the next price-run cut slightly deeper. What the technology argument cannot carry is a 10× cut now: the resource that binds a validator is hot-state DRAM plus replication across every future node, and neither followed the NAND curve. Better drives are a reason reserves could drift down over decades; they are not a reason to abandon the floor in one vote.

Then we tested it — and it changed our answer

Precedent is an argument; evidence is better. The network has already run this experiment twice, so we measured both. Sampling real state at ~30 historical ledgers on a full-history node gives the rate at which permanent objects were created before and after each cut:

Those are net figures over months. Zoom into a single week and a different fact dominates: the ledger is not accumulating state so much as renting it out and taking it back.

The XRP Ledger performs roughly 1.5 million object creations and deletions every day to net about 8,130 — a 185:1 churn-to-net ratio. Almost everything built is torn down again, and every teardown refunds its deposit. That is the clearest proof the 2012 design works as intended, and it is the mechanism a 20× cut to the increment would blunt: bots recycle tickets because holding one costs 0.2 XRP, and the largest ticket creator we found had made about 200,000 in three days while holding 89. At 0.01 XRP the reason to hand them back mostly disappears.

Both cuts moved the ledger from flat-or-shrinking to growing, so cuts do coincide with state creation — but the two things that grew have different shapes. Accounts rose steadily, +2.5 million over twenty-one months, with no spike: that is sustained adoption. Trust lines, by contrast, spiked hard in December 2024 and January 2025 and then fell away — and that spike has an owner, discussed below. The spam vectors never moved at all: NFT pages grew ~50/day on a base of 100,000. Total state went 2.44 → 3.20 GB in twenty-one months — across all 415 public nodes, about $24 of NVMe.

The 2021 cut is the more instructive one, because its burst was enormous and then undid itself. Trust lines were created at 92,800/day for a quarter — roughly 8 million of them — and then 2022 ran the film backwards at −13,000 to −18,000/day as the same lines were closed and their reserves refunded. That is the 2012 design's self-cleaning half, visible at scale: speculative state that stops being worth 2 XRP gets deleted, and the ledger shrinks again.

Now the honest part, because it is the weakest link in every causal claim above: December 2024 has at least three causes running at once. The reserve was cut on the 2nd; XRP ran from $0.51 to $2.73 in five weeks; and the FirstLedger launchpad had opened on 15 October, seven weeks before the cut. That launchpad issued 13,521 tokens carrying 685,000 trust lines in its first four months — 82% of every token it has ever launched — peaking in the exact window the cut lands in. So the trust-line spike is launchpad mania, not the reserve; it began before the cut and it decayed to ~60 tokens a month by 2026 while the reserve stayed cheap. Cheaper trust lines plausibly amplified it, but they cannot have started it.

What survives that unpicking is narrower and more useful. The spike is explained away. The sustained account growth — 2.5 million over twenty-one months, still running at ~2,300/day with no launchpad boom and no bull run to carry it — is not, and account creation is precisely what the base reserve prices. And under three simultaneously spam-favourable conditions, the junk still never arrived.

The floor nobody priced: reserves below the cost of reclaiming them

Everything above assumes a deleted object hands its deposit back. For accounts that is only true while the deposit is worth the trouble of asking. rippled charges one owner reserve to run AccountDelete — “The fee required for AccountDelete is one owner reserve” (AccountDelete.cpp#L60) — so closing an account returns the base and burns the increment:

This is not a projection. Measured on-chain over matched seven-day windows, account deletions as a share of creations halved after the December 2024 cut — 22.7% to 11.8%. The reserve got ten times cheaper and reclaiming it stopped being worth doing, exactly as the arithmetic predicts. At the proposed 0.1 XRP the net recovery is nine hundredths of an XRP, about ten cents, and note that cutting the increment alongside it does not help: the ratio stays 10:1 either way. What matters is the absolute number, because the threshold is not set by the protocol — it is set by what a human's attention or a bot's transaction slot is worth. Below that floor, accounts are simply never closed, and every account ever created becomes permanent at roughly 751,000 a year. Raising the reserve later does not make them deletable; it only makes them look cheaper in hindsight.

Solana already ran this experiment — and is about to run it again

One chain has spent years at the price XRPL is contemplating. Solana charges rent per byte — (128 + data_size) × lamports_per_byte (rent explainer) — where XRPL charges a flat amount per object. A minimal Solana account costs about $0.07 against an XRPL account's $1.08: 16.5× cheaper.

Solana also removed automatic cleanup: SIMD-0084 disabled rent collection, so accounts are no longer reclaimed by decay and are permanent unless explicitly closed — the same end state XRPL reaches if AccountDelete stops being worth running. Their dust problem is named and unfixed: a large share of stake accounts hold under one SOL and carry “significant account overhead without adding meaningful economic weight,” and any remedy would grandfather the existing ones. The engineering answer now under discussion is archival — moving live state from ~500 GB down to 50–100 GB — which is a large project to undo a pricing decision.

And here is the part that should give the XRPL debate pause. SIMD-0436 proposes halving Solana's minimum right now, and its argument is the same one being made here almost word for word: an “arbitrary constant set years ago” that rose in real terms with the token price and makes the chain “less competitive.” It names state growth as the only risk, calls it “unlikely,” and contains no account counts, no state-size figures and no growth projection. Its mitigation is that rent can be raised back later — the same move that does not work, because a higher price never un-writes the state written at the lower one.

The one idea worth taking from Solana is the pricing basis. Per-byte rent would dissolve the NFT-page asymmetry entirely: the 9,458-byte page that costs $0.22 here would cost $4.88 under Solana's formula. XRPL's flat-per-object rule is what makes a 2 KB page and an 83-byte ticket cost the same, and it is the root of every asymmetry measured in this article.

But the comparison ends with a difference that runs the other way, and it is the most important line in the table. Solana validators are paid and XRPL validators are not. A Solana validator earns roughly 6–7% a year from inflation, priority fees and MEV (Figment's breakdown), which is what makes a ~$60k-a-year machine a business decision. On the XRP Ledger the transaction fee is destroyed — ctx_.destroyXRP(fee) in Transactor.cpp, with the comment noting the ledger header merely accounts for it — there are no block rewards, and XRP was never inflated. Validators receive nothing, deliberately, so that payment cannot warp their behaviour (xrpl.org FAQ). They run at pure cost, for reputation, governance and their own infrastructure.

That inverts the lesson. Solana's 384–512 GB hardware bar produces centralisation pressure, but its economics at least fund the machine; rising state is a cost the protocol pays for. XRPL has no such budget. Every byte added to state is an unfunded obligation on volunteers, and the network is currently secured by a 36-validator UNL and about 415 publicly visible servers — a small set with no revenue to absorb a rising floor. That obligation is cheap today: a top-ranked dUNL node runs on roughly $80 a month, as the operator evidence further down shows. This is a claim about who bears future cost, not a claim that the floor is biting now. State growth on XRPL is not paid for by anyone; it is simply endured until someone stops. Cheap reserves are therefore more dangerous here than on a chain that pays for its own replication, not less — which is the precise opposite of how the “Solana is cheaper, so we can be too” comparison is usually deployed.

What an actual validator operator measured — and where it corrects us

The strongest counter-evidence in this debate did not come from a model. Daniel Keller — who operates dUNL validator nHU2k8Po…KBvcpVji, a key we confirmed is on our own node's trusted list — published instrumented results from his machine and opened by naming the problem with the debate: “A lower reserve is a threat to validator performance — is it though? The current debate… is unfortunately still driven more by emotional doomsday vibes than by verifiable evidence from the opposing side.”

His node is a six-year-old Xeon E-2236 with 32 GiB of RAM and two NVMe drives in RAID 1, costing about $80 a month. It runs RocksDB rather than NuDB — the slower option — on a near-stock config, with debug and analytics scripts looping and log levels at debug. Under those deliberately unfavourable conditions it ranked 4th of ~101 observed validators by median arrival percentile, at a 390 ms median lag. His summary is the part that should be conceded rather than argued with: “Not in a lab. Not under perfect conditions. In the real world, under deliberately bad conditions… There is a meaningful difference between knowing something because you actually do it, and repeating second-hand claims.”

That corrects something in this article. We wrote that state growth is an unfunded obligation on volunteers and implied a rising hardware floor threatens a 36-validator UNL. At $80 a month on 2020 hardware, that framing was too dramatic for the ledger we actually have. Consensus performance today is not remotely constrained by state size, and anyone arguing that a reserve cut endangers validator performance right now is contradicted by the one participant who instrumented his own machine.

Our own measurements point the same way from the other direction. If account creation tracks price rather than reserve cost — and the table below says it does — then a cut cannot produce a flood of accounts either. The spam-doomsday case is weak, and our data says so as plainly as his does.

What that test cannot settle is what it was not built to settle. Arrival percentile measures consensus latency, not state capacity — a node can post excellent timing while its state grows, right up until it cannot. It measures the ledger we have, 3.49 GB, not the one a cut would produce, and no measurement of the present can answer that. And the proposal is 0.1 base and 0.01 per object, while the hardware argument is about accounts.

The sharpest technical point in that whole thread came from a reply, not either headline. @ShortTheFOMO: “Most people relate performance down to the disk, that's not the part that has the issue… The objects and the active memory tree is the ‘performance’ part,” and then, decisively, “Fees should protect the size of the ledger in memory on the nodes.”

That is right, and it is the same structure we found in Solana's AccountsDB — account data on disk, the index driving memory. It also reframes the whole argument correctly: the reserve is not buying SSD, which is why 3.8 GB of Solana's empty accounts costs 29 cents. It is buying memory-resident tree and per-object index cost. Which makes it an argument for holding the increment specifically — the number the hardware debate never reaches.

The question we left open — now answered on-chain

Everything above left one thing unresolved, and it was the load-bearing one: does a cheaper reserve actually cause adoption, or did December 2024 just coincide with a price run? The confounds looked fatal. They are not, because the ledger contains all four cells of a natural experiment — and the decisive cell is November 2024, when XRP tripled while the reserve was still 10 XRP.

Read the fifth row. With the reserve untouched at 10 XRP — $27 an account, the most expensive it had ever been in dollars — account creation jumped from a ~1,264/day baseline to 5,540/day. A 4.4× increase, before the cut, from price alone.

Now read the last row. Today the reserve is 1 XRP — about $1.10, twenty-five times cheaper in real terms — and account creation is 2,395/day, less than half the rate achieved when an account cost twenty-seven dollars. If the price of an account were the binding constraint on adoption, that ordering is impossible.

The honest conclusion is that account creation on the XRP Ledger tracks price momentum, not reserve cost. The reserve's independent effect is somewhere between small and undetectable in this data. It is not nothing — the December spike to 10,755/day exceeded what price alone had been producing — but it decayed within months while the reserve stayed cheap, which is the signature of a sentiment cycle, not a lowered barrier. Caveats, stated plainly: these are different eras with different secular trends, November 2024 was an exceptional macro event, and account creation is only one measure of adoption. But the direction is unambiguous and it runs against the cut.

So we changed our mind — asymmetrically

We changed our answer twice writing this. First the two natural experiments pushed us off “hold both” and toward cutting the base — the last base cut produced users, not junk. Then measuring reclamation pushed us back, because a base reserve below the cost of recovering it quietly converts every account into permanent state, and Solana shows where that road ends. The goal is safe adoption, not a defended position, so here is where the evidence actually leaves it:

So: hold both. That is where this article started, on precedent — but it is not why it ends there. The increment has a measured exploit, a one-way ratchet and the recycling pressure that keeps churn at 185:1. The base has an adoption case that did not survive the on-chain test and a reclamation floor beneath it. Cutting either buys something we could not detect and costs something we could measure. If the network wants cheaper onboarding, the lever that would actually work isreclamation — make closing an account worth doing — not a lower price of entry that the evidence says nobody was waiting on.

Three things would change this answer again, and all are measurable rather than rhetorical. If NFT-page creation ever inflects the way trust lines did in 2021, the increment needs to go up, not down — or pages need pricing by byte rather than by page, which is the one idea Solana got right. If account deletions keep falling as a share of creations, the cleanup problem is already here and the base should not move until it is fixed. And if a base cut does not move account creation, it bought nothing and the deterrent should be left alone. Reserves were built to be voted, in both directions, on evidence like this — which is also the strongest argument against copying a proposal that ships without any.