Overview — Fees, Rent & Economics

The book asks one question over and over: how do you build a single global state machine that runs at hardware speed without falling apart? So far the answer has been mechanical — a clock to order events, an account model to lay state out flat, a scheduler to run non-conflicting transactions in parallel. All of it aims at one target: settle tens of thousands of transactions a second for a fraction of a cent. But that target hides a bill. Hardware costs money. Storage costs money. Someone runs the validators, and they will not do it for free.

This part is about the bill. If the network runs at hardware speed for near-zero fees, then the obvious question — the one every skeptic asks first — is: who pays, and how is the whole machine funded? A state machine that charges nothing gets spammed into the ground; a state machine that charges too much gets abandoned. The economics is the layer that threads that needle. It is not decoration bolted onto the runtime. It is the incentive system that keeps the runtime alive — running, secured, and not drowning in junk.

The four bills a global state machine must charge

Strip Solana’s economics down to first principles and it is not one fee. It is four distinct costs, each priced by a different mechanism, because each one is a different kind of scarcity.

   The four bills — and who each one falls on
   ───────────────────────────────────────────

   1. COMPUTE   running your transaction burns validator CPU & bandwidth
                → priced by  TRANSACTION FEES  (per-signature + priority)

   2. STORAGE   your account sits in every validator's memory, forever
                → priced by  RENT (rent-exemption deposit)

   3. SUPPLY    new SOL must be minted to pay for security
                → priced by  INFLATION (a scheduled, decaying issuance)

   4. SECURITY  validators & stakers must be paid to secure the chain
                → priced by  VALIDATOR ECONOMICS (rewards − vote costs)

Notice these are genuinely different problems. Compute is a flow — it happens once, when your transaction runs, and it is gone. Storage is a stock — your account keeps occupying memory on every validator long after the transaction that created it finished. You cannot price a stock the way you price a flow: a one-time fee undercharges for state that lives forever, and a per-second charge on a global map is an accounting nightmare. So Solana prices them separately. Inflation and validator economics are the other side of the same coin: the fees and rent are what users pay in; inflation and rewards are what the network pays out to the people who make it run.

The dependency chain, in one line

The pages of this part are not a grab-bag of topics. They are a chain, each link built from the one before it:

   lamports ──► transaction fees ──► rent ──► inflation ──► validator economics
     │              │                  │          │                │
   the unit    price a TX         price an     mint the     tie it all
   of value    (compute)          ACCOUNT      rewards      together:
                                  (storage)    (supply)     who gets paid,
                                                            and what it costs them

You cannot talk about a fee without a unit, so lamports come first: the integer denomination everything is measured in. With a unit in hand you can price a single transaction’s compute — the base per-signature fee plus, when a block gets hot, a priority fee set in a local fee market. Then you price storage, which is a different beast entirely: an account pays a one-time rent-exemption deposit to earn the right to persist. Where does the SOL to reward validators come from? Inflation mints it on a fixed, decaying schedule. And finally validator economics closes the loop: a validator earns those rewards but pays real costs to earn them — most surprisingly, it pays fees to vote. Follow the chain and the whole funding model of the machine falls out in order.

Roadmap for this part

Read these in order. Each one prices exactly one of the four bills — or gives you the unit and the loop that make the prices make sense.

#	Page	What it prices	The one idea it forces
2	Lamports and the SOL Unit	the unit itself	all value on-chain is an integer count of lamports; 1 SOL = 1,000,000,000 lamports
3	Transaction Fees and Local Fee Markets	compute (a flow)	a base per-signature fee plus a local priority market, so one hot account doesn’t tax the whole chain
4	Rent and Rent-Exemption	storage (a stock)	an account must pre-fund ~2 years of rent to live forever; storage is not free and someone must deposit for it
5	Inflation and Staking Rewards	supply	new SOL is minted on a decaying schedule and flows to stakers, funding security without a per-user charge
6	Validator Economics and Vote Costs	security (the loop)	a validator’s rewards minus its real costs — including paying a fee for every vote — decides whether securing the chain pays
900	Revision — Fees, Rent & Economics	the whole part	the four bills, compressed to what you must retain

By the end you will be able to look at any lamport that moves on Solana and say which of the four bills it settles: is this fee paying for compute, is this deposit paying for storage, is this reward newly minted supply, or is this a validator paying to be heard? That is the entire economic model, and it is only five moving parts.

The architect’s lens

The economics layer is a major component of the system, so put it under the lens before we dive in.

• Why does it exist? A global state machine is a shared, finite resource — CPU, bandwidth, and memory that every validator on Earth replicates. Left free, it would be consumed until it collapsed. Economics is the pricing system that turns “free-for-all” into “pay for what you consume.”
• What problem does it solve? Two at once: spam (a fee makes flooding the chain expensive) and funding (rewards make securing the chain profitable). It keeps the machine from being either abused or abandoned.
• What are the trade-offs? Prices have to be low enough to keep Solana’s throughput-at-low-cost promise, yet high enough to deter spam and fund security. Set fees too low and the network is trivially spammable; set them too high and you have thrown away the whole point of building for hardware speed. Local fee markets and rent-exemption are the mechanisms that try to hold both ends.
• When should I avoid it? You never turn economics off on a live shared chain — an unpriced global resource is a denial-of-service vector by construction. You only relax it in a closed setting (a local test validator, a private cluster) where every participant is trusted and there is nothing to spam.
• What breaks if I remove it? Everything downstream. With no fee, the parallel scheduler you built earlier just schedules an infinite flood of spam. With no rent, the flat Pubkey → Account map grows without bound until validators run out of RAM. With no rewards, validators stop validating and the chain stops producing blocks. The runtime is the engine; economics is the fuel system and the governor.

The thread

What does pricing the machine force you to understand? That “hardware speed for near-zero fees” is not free — it is a budget, and every part of the runtime you already built shows up as a line item in it. Compute is the CPU the Sealevel scheduler burns; storage is the memory the account model occupies; ordering is the work Proof of History does; security is what stake pays for. Economics is where the whole book’s engineering meets its accounting: the incentive layer that keeps a single global state machine from being spammed into uselessness or abandoned for lack of anyone paid to run it. Get the four bills straight and every SOL that moves becomes legible.

Start with the unit that all four bills are counted in: Lamports and the SOL Unit.

Check your understanding

1. This part reframes “who pays the bill?” as four distinct costs. Name all four, and say why compute and storage cannot be priced by the same mechanism.
2. The pages form a dependency chain, not a grab-bag. Why must lamports come before transaction fees, and why must inflation come before validator economics?
3. Fees and rent are money flowing into the system; inflation and rewards are money flowing out. Who pays each of the two “in” bills, and who receives each of the two “out” flows?
4. The architect’s lens says removing economics breaks three things downstream. What are they, and which piece of the runtime does each one correspond to?
5. Using the book’s throughline, state in one sentence what role the economics layer plays in keeping a single global state machine running at hardware speed without falling apart.

Show answers

1. Compute (priced by transaction fees), storage (priced by rent), supply/issuance (inflation), and security (validator economics). Compute is a flow — it happens once when a transaction runs and is gone — while storage is a stock that keeps occupying memory on every validator forever; a one-time fee undercharges for perpetual state and a per-second charge on a global map is unworkable, so they need different mechanisms.
2. Lamports are the unit every fee is denominated in, so you cannot price a transaction before you have the unit to price it in. Inflation is what mints the SOL that validators are paid, so you have to know where the reward supply comes from before you can reason about whether earning it is worth a validator’s costs.
3. In: users pay transaction fees (for compute) and account creators pay the rent-exemption deposit (for storage). Out: newly minted inflation flows to stakers as staking rewards, and validators receive rewards (net of their vote and operating costs) for producing and voting on blocks.
4. Removing economics breaks: (a) the scheduler, which now happily schedules an infinite flood of spam because nothing costs anything; (b) the account model / flat map, which grows without bound until validators run out of RAM because there is no rent; and (c) consensus/block production, which stops because validators have no reward to keep validating.
5. Economics is the incentive layer that prices the machine’s four scarce resources — compute, storage, supply, and security — so the network stays cheap enough to use, expensive enough to spam, and profitable enough to secure, keeping the single global state machine from being either flooded or abandoned.