No Fee Market, and How Spam Amplifies

The previous page showed why a speed-first chain has so little slack: it runs one synchronous state machine at hardware speed, so a load spike that a slower chain would absorb in its mempool instead lands on live validators all at once. That explained the fragility. This page explains the fuel — the economic mistake that turned ordinary demand spikes into network-melting floods.

The mistake is subtle because it looks like a feature. Early Solana made transactions flat and near-free: you paid a tiny fixed fee per signature whether your transaction succeeded or failed, and there was no way to bid for priority. That sounds friendly to users. But a fee that does not rise with demand, and barely punishes failure, removes the one thing that keeps a shared network honest under load: a cost that grows when everyone wants the same scarce thing at once. This page is the first-principles account of that missing price — and of spam amplification, the feedback loop it unlocked.

What early Solana charged: a flat per-signature fee

Solana’s base fee is deliberately simple. A transaction pays a fixed amount per signature — 5,000 lamports per signature (1 SOL = 1,000,000,000 lamports), so a typical one-signature transaction’s base fee is 0.000005 SOL, a small fraction of a US cent at most plausible SOL prices.

Three properties of that fee matter for everything below:

It is flat. The price does not rise when the network is busy. A signature costs 5,000 lamports at 3am on a dead network and 5,000 lamports in the middle of a frenzied token launch. There is no demand term.
It is charged on failure too. You pay the base fee for the attempt, not the outcome. A transaction that runs out of compute, hits a contended account, or loses a race still cost you 5,000 lamports — but only 5,000 lamports.
In early Solana, there was nothing else to pay. There was no priority fee, no per-compute-unit bid, no auction. Every transaction in a contested slot paid the same flat fee and took its chances. You could not signal “I want in more than the next person,” so the only lever left was to submit more transactions.

That last point is the whole story in miniature. When the only way to raise your odds is to send more attempts, and each attempt is nearly free even when it fails, a rational bot sends thousands.

   Early Solana fee, per transaction:

     cost = 5,000 lamports × (number of signatures)
          = flat, regardless of network load
          = charged whether the tx SUCCEEDS or FAILS
          = the ONLY fee (no priority bid to raise it)

   → demand has no price. The fee is a stamp, not an auction.

Why a flat, cheap fee removes backpressure

Every open network that strangers can write to faces the same problem: a shared resource that anyone can spam. The classic answer, on Bitcoin and Ethereum, is a fee market — a price on the scarce resource that rises with demand. That rising price is not just a toll; it is backpressure, a control signal that pushes back on load exactly when load is highest.

Look at how the two mature chains do it, and what each buys:

   Chain      Price mechanism                       What rises with demand?
   ─────      ───────────────                       ──────────────────────
   Bitcoin    open sat/vB fee auction               the clearing fee rate — you outbid
                                                     others for a slot in the next block
   Ethereum   EIP-1559 base fee + tip               a protocol-computed base fee ratchets
                                                     up block-by-block as blocks stay full
   Solana     flat 5,000 lamports/signature         NOTHING — the price is constant
   (early)    (no priority fee)                      no matter how contested the slot is

On Bitcoin, if you want your transaction in the next block during a surge, you bid a higher sat/vB rate; spam is self-limiting because flooding raises the price you yourself must pay. On Ethereum, sustained demand ratchets the base fee up until marginal users drop off. In both cases the price is a negative feedback loop: more demand → higher cost → less demand. The market clears.

Early Solana had no such loop. Because the fee never rose and failures were nearly free, the feedback loop that normally dampens a load spike was simply absent. There was nothing to price out the marginal transaction, so the marginal transaction was always worth sending. The network’s only remaining defense against a flood was raw capacity — and, as the previous page showed, a synchronous chain running flat-out has very little of that in reserve.

Put the flat fee against a bot’s economics. Suppose a bot wants to win one contested NFT mint or IDO allocation, and it does so by spraying attempts. Assume 0.000005 SOL per single-signature attempt and a SOL price of $100 (illustrative — SOL’s price is volatile; this is arithmetic, not a quote):

   cost per failed attempt   = 0.000005 SOL ≈ $0.0005   (five hundredths of a cent)

   100,000 attempts          = 0.5 SOL      ≈ $50
   1,000,000 attempts        = 5   SOL      ≈ $500

For the price of a nice dinner, a bot can fire a million transactions at the network. If winning the mint is worth thousands of dollars, spending $50–$500 to flood is not just rational — it is cheap, and every other bot does the same arithmetic. The flat fee priced an attempt like a postage stamp, so bots bought stamps by the million. (Figures are illustrative; the durable point is the order of magnitude — flooding cost cents-to-dollars, not the thousands it would need to be a deterrent.)

Spam amplification: one intent, thousands of transactions

Here is the mechanism the page is named for. Spam amplification is the gap between what a user intends and what actually hits the network — and a near-free failure cost blows that gap wide open.

Consider one user’s real goal: “mint one NFT” or “buy this token at launch.” On a network with a working fee market, that intent maps to roughly one transaction: you attach a fee that reflects how badly you want in, and either you clear or you re-bid a small number of times. The mapping from intent to load is close to 1:1.

Now put the same intent on early Solana, run by a bot:

   USER INTENT                 WHAT THE BOT ACTUALLY SENDS
   ───────────                 ───────────────────────────
   "mint one NFT"        →     duplicate the same tx N times (in case some drop)
                              + retry immediately on every failure (failures are ~free)
                              + fan out across many payer accounts in parallel
                              + keep firing until the mint is sold out

   1 intent             →      thousands of transactions per bot
   × many bots          →      millions of transactions targeting one moment

Every arrow in that diagram is a rational response to the flat fee:

Duplicate to beat drops. Solana forwards transactions to the upcoming leader without a global mempool (via Gulf Stream), and under load some get dropped. A bot that sends one copy might lose it; a bot that sends fifty copies is more likely to land one. Since copies are nearly free, send fifty.
Retry instantly on failure. A failed transaction cost 5,000 lamports and told you nothing except “try again.” With no priority fee to raise instead, retrying is the strategy. The retry loop has no natural brake.
Fan out to parallelize. One payer account is a bottleneck, so bots spread attempts across many funded accounts and fire them concurrently, multiplying the transaction count again.

The result is amplification: the load on the network is not proportional to the number of users or their intent — it is proportional to how aggressively every bot is willing to retry, which the flat fee capped at approximately infinity. A few thousand people wanting one NFT each could generate millions of transactions in a slot. The network was not being asked to do a lot of work; it was being asked to sort through a mountain of near-duplicate junk to find the real work, and that sorting is itself the load.

This is the exact input the previous page warned about: a synchronous machine with little slack, handed a load spike with no upstream buffer. Spam amplification is what makes the spike arbitrarily large.

Under the hood — why “charge on failure” was not enough of a deterrent

It is tempting to think “but they did charge for failed transactions — 5,000 lamports each — so spam was priced.” It was priced; it just was not priced enough, and the shape of the pricing was wrong in two ways.

First, the fee did not scale with contention. The scarce resource during a mint is not “a slot on the network” in general — it is write access to one specific account (the candy-machine or market account). A flat per-signature fee charges the same whether you touch a cold, idle account or the single hottest account on the chain. So the fee failed to make the expensive thing expensive. (This is the seam the hot-account ceiling exposes: contention is per-writable-account, so a flat global fee cannot possibly price it.)

Second, there was no bid, so extra willingness-to-pay had nowhere to go. On a chain with priority fees, a user who badly wants in expresses that by paying more per transaction. On early Solana the only way to express “I want in more” was to send more transactions — the fee mechanism converted willingness-to-pay into transaction volume instead of transaction price. That is the amplifier, stated precisely: the missing bid rail forced demand to spill into the one channel that hurts the network most, raw count.

Where the flood lands: one hot account

Amplification would be less catastrophic if it spread out. It does the opposite: the events that trigger it — an IDO, an NFT mint, a token launch — are precisely the events where thousands of bots hammer the same piece of state at the same instant.

Recall from the Sealevel part what that means for a parallel runtime. Solana runs non-conflicting transactions across cores, but two transactions conflict when they share an account and at least one writes it. A mint funnels every attempt at the same writable mint account, so none of those transactions can run in parallel — the scheduler must serialize them into one lane. The hot-account ceiling is the wall: one contended account has fixed serial throughput, and no number of cores buys past it.

Now stack the two facts:

   Spam amplification  →  millions of near-duplicate txs, all targeting ONE account
   Hot-account ceiling →  that ONE account can only clear txs ONE AT A TIME, in order

   ┌─────────────────────────────────────────────────────────────┐
   │  demand for the hot account   :  millions of tx / slot        │
   │  supply of the hot account    :  one serial lane / slot       │
   │  ─────────────────────────────────────────────────────────    │
   │  the backlog has NOWHERE to go, and the flat fee never        │
   │  rises to shrink the demand side of that inequality           │
   └─────────────────────────────────────────────────────────────┘

The flood is aimed at the one resource that cannot be parallelized away, and the fee that should have rationed access to that resource was flat and blind to it. Demand for the hot account outran its single serial lane by orders of magnitude, and — with no rising price to push back — the excess did not stay politely queued around that account. It spilled outward: validators drowned in the work of receiving, deduplicating, and rejecting the junk, degrading performance for transactions that never touched the hot account at all. That spillover — how a storm around one account becomes a network-wide problem — is the subject of the next page.

On 14 September 2021, Solana’s mainnet stopped producing blocks for roughly 17 hours — its first major outage, and the archetype of this exact failure mode. Per the post-mortem, the trigger was a flood of bot transactions around a token sale on Grape Protocol (an IDO on Raydium). Bots submitted transactions at a reported rate on the order of hundreds of thousands per second (widely-cited figures put it around 300,000–400,000 tx/s at peak), overwhelming validators; the resulting memory exhaustion and forking forced operators to coordinate a restart from a known slot.

Read it through this page’s lens. The IDO concentrated demand on a few hot accounts at one instant (contention). The flat, near-free fee meant every bot’s rational move was to retry without limit (amplification). And there was no priority fee to convert that willingness-to-pay into price instead of volume (the missing bid). All three ingredients were present, and the network halted.

This was a liveness failure, not a safety one — the chain stopped and was restarted; it did not confirm-then-reverse transactions or mint funds from nothing. And the fix that followed is the tell: much of Solana’s later reliability work (QUIC ingress, stake-weighted QoS, and the local fee markets this part builds toward) was aimed squarely at pricing and shaping exactly this kind of load. (Dates and rates are the widely-reported figures; treat the hour count and per-second rate as approximate.)

The fix, previewed: give demand a price

If the disease is “demand for a hot account has no cost that rises with contention,” the cure writes itself: make contention cost something, per account. That is exactly the direction Solana took, rolled out gradually across roughly 2022–2024, and it comes in two connected pieces this part will build up to:

Priority fees. A transaction can attach an extra per-compute-unit bid to compete for earlier inclusion. This is the missing rail: it lets a user express “I want in more” by paying more per transaction instead of sending more transactions, converting willingness-to-pay back into price rather than volume.
Local fee markets. Crucially, that bidding is scoped to the specific writable accounts a transaction touches. Congestion on one hot mint account raises the price for writes to that account — not for the whole chain. This prices the scarce resource (one account’s serial lane) at exactly the seam where the scarcity lives.

   Early Solana:   demand ──► send MORE transactions ──► spam amplification ──► halt
                   (flat fee; no bid rail; contention unpriced)

   After the fix:  demand ──► pay MORE per transaction ──► priced out, not flooded
                   (priority fee + local fee market; contention priced per account)

We will build the ingress-side defenses first — QUIC and stake-weighted QoS, which decide whose transactions even get in — and then the economic fix, local fee markets and priority fees, which decide what it costs once you are in. Together they turn “retry-spam until you win” back into “state how badly you want in, and pay for it.” For the full first-principles treatment of why the price must be per-account, see the hot-account ceiling.

The architect’s lens

A fee market is a major piece of a public chain’s design, so the flat-fee-and-no-market choice earns the five questions — read as why the absence of a fee market was the load-bearing failure.

Why does it exist? Early Solana chose a flat, near-zero per-signature fee to make transactions feel free — part of the project’s founding bet that a chain should feel like the internet, a rounding error per action. The near-free fee was a deliberate UX goal, not an oversight.
What problem does it solve? For the user, it solves cost and predictability: you always know the fee, and it is tiny. What it conspicuously does not solve is spam and contention — the very problems a rising fee market exists to handle.
What are the trade-offs? A flat fee removes the demand-side backpressure that Bitcoin’s auction and Ethereum’s EIP-1559 base fee provide. Cheap-and-flat buys user friendliness at the cost of a network with no economic brake on flooding — the trade that showed up as the 2021–2022 outages.
When should I avoid it? Whenever demand can concentrate on a scarce, non-parallelizable resource (a hot account), a flat fee is exactly wrong: it fails to make the expensive thing expensive. The fix — priority fees plus local fee markets — prices contention where it actually occurs.
What breaks if I remove it? Remove the fee market entirely (which is roughly where early Solana sat) and you remove the only mechanism that converts “I want in” into price rather than volume. Willingness-to-pay then spills into raw transaction count, bots amplify one intent into millions of attempts, and the network’s slack — already thin on a synchronous chain — is exhausted. That is the outage.

Check your understanding

Describe early Solana’s fee precisely: what did it charge, was it charged on failure, and what could you not do that Bitcoin and Ethereum users can?
What is “backpressure” in the context of a fee market, and why is a flat fee unable to provide it? Contrast with Bitcoin’s auction or Ethereum’s EIP-1559 base fee.
Define spam amplification. Walk through why a near-free failure cost makes a bot’s rational strategy “retry and duplicate without limit,” and how that decouples network load from user intent.
Why is an IDO or NFT mint the worst-case trigger for this failure mode? Connect spam amplification to the hot-account ceiling — what happens when millions of amplified transactions all target one writable account?
State the fix in one sentence, name its two pieces, and explain why the pricing has to be per account rather than a single global fee.

Show answers

It charged a flat 5,000 lamports per signature (≈0.000005 SOL for a one-signature tx), a price that did not rise with demand. The fee was charged whether the transaction succeeded or failed — you paid for the attempt, not the outcome. And there was no priority fee / no bid: unlike Bitcoin (bid a higher sat/vB rate) or Ethereum (attach a tip and watch the base fee ratchet up), you could not pay more to signal urgency, so the only way to raise your odds was to send more transactions.
Backpressure is a rising cost that pushes back on load exactly when load is highest — a negative feedback loop (more demand → higher price → less demand). A flat fee has no demand term at all, so it never rises and never dampens a spike. Bitcoin’s open fee auction and Ethereum’s EIP-1559 base fee both climb with sustained demand until marginal users drop off; early Solana’s constant fee provided no such brake.
Spam amplification is the gap between a user’s intent (e.g. “mint one NFT”) and the transactions actually sent. Because a failed transaction cost almost nothing and there was no priority bid to raise instead, a bot’s rational move is to duplicate (in case copies drop), retry instantly on every failure, and fan out across many payer accounts — turning one intent into thousands of transactions. Load then tracks retry aggressiveness, not user count or intent, so a few thousand real users can generate millions of transactions.
Those events concentrate every attempt on the same writable account (the mint / market account) at the same instant. By the conflict rule, such transactions cannot run in parallel — the scheduler serializes them into one lane with fixed throughput (the hot-account ceiling). So amplified demand (millions/slot) slams into a supply of one-serial-lane/slot, the backlog has nowhere to go, and with no rising price to shrink demand, the excess exhausts validators and spills into network-wide congestion.
Price contention per account — give demand a cost that rises where the scarcity actually is. The two pieces are priority fees (a per-compute-unit bid, so willingness-to-pay becomes price instead of volume) and local fee markets (that bidding is scoped to the specific writable accounts a transaction touches). It must be per-account because contention is per-writable-account — a single global fee charges the same for a cold account and the hottest account on the chain, so it can never make the genuinely scarce resource expensive.