Revision — Fees, Rent & Economics

The rest of this book was mechanics: a clock to order events, an account model to lay state out flat, a scheduler to run non-conflicting transactions in parallel. This part was the bill. If the machine runs at hardware speed for a fraction of a cent, then someone, somewhere, is paying for the CPU, the memory, and the people who keep validators online. Economics is the layer that decides who, and prices it so the network is cheap enough to use, expensive enough to spam, and profitable enough to secure.

The overview framed the whole part as four bills a global state machine must charge — compute, storage, supply, and security — each a different kind of scarcity, so each priced by a different mechanism. This page walks that chain back through one more time, in prose, and then closes on the single question the whole part exists to answer.

The unit: everything is an integer count of lamports

Before you can price anything you need a unit, and Solana’s is the lamport. SOL is a display unit — what wallets and exchanges show you — but the protocol never stores “1.5 SOL.” Underneath is one indivisible base unit, and the relationship is exact and fixed:

   1 SOL = 1,000,000,000 lamports   (10^9)

   1 lamport      = 0.000000001 SOL
   5,000 lamports = 0.000005 SOL     (the base transaction fee per signature)

Every balance, fee, deposit, and reward in this part is a whole number of lamports held in an Account.lamports field typed as a u64 — an unsigned 64-bit integer, never a float. That single type choice is not an accounting convenience; it is a correctness decision. Integer arithmetic is exact (no 0.1 + 0.2 = 0.30000000000000004 drift) and deterministic (bit-for-bit identical across every compiler, CPU, and machine). On a chain where thousands of validators must independently replay the same transactions and agree on the same balances to the last digit, exactness and determinism are the whole game — a disagreement of one lamport is a fork. See Lamports and the SOL Unit for why the base unit exists and why you convert to SOL only at the very last step, for display.

Hold onto one habit from that page: when a later figure says “0.000005 SOL,” read it as “5,000 lamports,” because that integer is what the runtime actually subtracts.

Pricing compute: a base fee plus a local priority market

With a unit in hand you can price the first bill — compute, the CPU and bandwidth a transaction burns when it runs. Compute is a flow: it happens once, and then it is gone. Solana prices it in two layers.

   total fee  =  base fee              +  priority fee
              =  5,000 × num_signatures +  (compute_unit_price × compute_units)
                 └── fixed, predictable ┘   └── optional, only when you want to jump the queue ┘

The base fee is a flat 5,000 lamports per signature — cheap and predictable, the floor everyone pays. The priority fee is what you optionally add when a block is contested: a price-per-compute-unit bid that lets an urgent transaction outrank others competing for the same scarce resource.

The subtle, distinctly-Solana idea is that the priority auction is local. Fees are not one global market where any hot account taxes the entire chain. Instead, congestion is isolated per account (per write-locked state). If one wildly popular program is getting hammered, the bidding war happens only among transactions that touch its accounts; a transaction touching completely unrelated state pays the calm price and sails through. This is the economic mirror of the parallel scheduler from earlier in the book: because transactions declare which accounts they read and write, the fee market can partition congestion along the exact same account boundaries the scheduler uses to run things in parallel. One hot spot no longer freezes the whole world. See Transaction Fees and Local Fee Markets.

Pricing storage: rent-exemption, because state is forever

Compute is a flow; storage is a stock. An account you create does not stop costing anything when the transaction that created it finishes — it sits in every validator’s memory, replicated across the world, indefinitely. You cannot price a perpetual cost with a one-time flat fee, and a running per-second meter on a global map is an accounting nightmare. Solana’s answer is rent-exemption.

To persist, an account must hold a minimum balance proportional to its byte size — enough that, at the protocol’s rent rate, it would cover roughly two years of rent. Cross that threshold and the account is rent-exempt: it pays no ongoing rent and lives as long as it holds the deposit. The key word is deposit: this is not a fee that disappears. It is a refundable balance locked against the storage the account occupies. Close the account and reclaim its bytes, and you get the lamports back.

   rent_exempt_minimum  ≈  (account_bytes + overhead) × lamports_per_byte_year × 2 years

   bigger account  →  bigger deposit
   close account   →  deposit refunded, bytes freed

This is the mechanism that keeps the flat Pubkey → Account map from growing without bound until validators run out of RAM. Storage is not free; rent-exemption makes someone pre-fund every byte that lives forever, and gives them the money back when they stop occupying it. See Rent and Rent-Exemption.

Pricing supply: a disinflationary issuance schedule

Fees and rent are money flowing into the system from users. The other two bills are money flowing out — to the people who run the machine — and that money has to come from somewhere. That somewhere is inflation: the protocol mints new SOL on a fixed, decaying schedule and pays it out as staking rewards.

The schedule is disinflationary by design. Issuance starts at an initial annual rate, decreases by a fixed percentage each year (each epoch, in practice), and tapers toward a long-run floor. New SOL is minted every epoch and distributed to stakers — validators and the delegators who stake with them — in proportion to their stake.

   inflation rate over time (illustrative shape, not exact figures)

   rate │*
        │ *
        │  *
        │   *_
        │     `--.__
        │           `--.____________  ← long-run terminal rate
        └──────────────────────────── epochs / years

The reason issuance exists at all is that Proof-of-Stake security is not free: validators and stakers must be paid to lock up capital and honestly secure the chain, and that reward comes from freshly minted supply rather than from charging every user directly. Inflation is how the network funds its own security without turning “cheap, fast blockspace” into “expensive blockspace.” It is the source of the rewards the final bill spends. Because these are recent and volatile figures, treat any specific initial rate or terminal rate as approximate and subject to governance — the load-bearing idea is the shape: mint on a decaying curve, pay stakers, fund security. See Inflation and Staking Rewards.

Pricing security: validator economics, and the cost of voting

The last bill closes the loop. A validator does not earn rewards for free; it pays real costs to earn them, and whether securing the chain pays is the difference between the two.

On the income side, a validator earns from three sources: its share of inflation rewards (proportional to the stake delegated to it), the commission it takes from delegators’ rewards, and transaction fees (the base and priority fees from blocks it produces). On the cost side sit the obvious expenses — serious server hardware, bandwidth, and operations, the price of keeping up with a chain built for hardware speed — and one that surprises newcomers: voting costs lamports. A validator votes on blocks by submitting vote transactions, and those transactions pay fees like any other. Vote constantly, as consensus requires, and you spend lamports every slot just to be heard.

   validator net  =  ( inflation rewards + commissions + fees )
                     − ( hardware + bandwidth + ops + per-vote fee costs )

That per-vote outlay has a sharp consequence: a validator with too little delegated stake earns rewards smaller than the fixed cost of voting, and runs at a loss. Security, in other words, has a minimum viable scale — a floor of stake below which participating does not pay. This is where the whole part’s accounting meets the trilemma trade-off Solana chose: optimizing hard for throughput pushes hardware requirements up, which pushes the break-even stake up, which is real pressure on how many independent operators can afford to secure the chain. See Validator Economics and Vote Costs.

The throughline: who really pays for cheap, fast blockspace?

Line the four bills up and the shape of the whole funding model is visible at once:

   ┌──────────┬───────────┬──────────────────────────────┬─────────────────┐
   │  BILL    │  SCARCITY │  MECHANISM                   │  WHO PAYS / GETS │
   ├──────────┼───────────┼──────────────────────────────┼─────────────────┤
   │ compute  │  flow     │  5,000/sig + local priority  │  the sender pays │
   │ storage  │  stock    │  refundable rent-exempt dep. │  the creator pays│
   │ supply   │  minted   │  disinflationary issuance    │  all holders (↓) │
   │ security │  the loop │  rewards − vote/hardware cost │  stakers get paid│
   └──────────┴───────────┴──────────────────────────────┴─────────────────┘

Now the question this part was built to answer. A user sends a transaction and pays 5,000 lamports — a fraction of a cent. That fee does not cover the true cost of running a validator fleet at hardware speed. So who makes up the difference? The answer is the quiet punchline of the whole economics layer: near-zero user fees are subsidized by inflation and by validator hardware. The bulk of what pays for security is not the user’s fee — it is freshly minted SOL, whose cost is spread across every SOL holder as dilution, and the operating capital validators sink into machines in the hope that stake-weighted rewards exceed their costs.

That is the real trade the economics encodes. “Cheap, fast blockspace” is not free; it is subsidized, and the economics decide exactly who absorbs the subsidy. Users pay a tiny direct fee and a bit of refundable rent; holders pay through inflation’s dilution; validators pay in hardware and per-vote lamports, betting that scale makes it profitable. Get those five moving parts straight — lamports, fees and local markets, rent-exemption, the inflation schedule, and validator net income — and you can look at any lamport that moves on Solana and say which bill it settles and who ultimately foots it.

Which returns us to the book’s one question: how do you build a single global state machine that runs at hardware speed without falling apart? The runtime is the engine; economics is the fuel system and the governor. Price the four bills right and the machine stays cheap enough to use, expensive enough to resist spam, and funded enough to keep every validator on Earth replaying the same state — the incentive layer that lets a global computer run fast and stay standing.