Skip to content
Solana · First Principles

Network Upgrades and the Roadmap

The last five pages each introduced a thing — Firedancer, state compression, ZK compression, Token-2022. This page introduces no new thing. It answers a different question: once the protocol is live and holding real value, how do you change it without breaking it, and how do you reason about what comes next?

That is a process question, and it is the natural close to the whole book. The throughline — how do you build a single global state machine that runs at hardware speed without falling apart? — does not stop being asked once the machine is running. Every upgrade re-asks it. The roadmap is just the list of places the answer is still being worked out. So this page has two jobs: explain the mechanism by which Solana ships changes, and then teach you to read the roadmap itself the way an engineer reads a changelog — by durable theme, and with a heavy discount on any specific date or number.

The upgrade problem: changing a machine that can’t stop

Section titled “The upgrade problem: changing a machine that can’t stop”

A blockchain is a distributed state machine that thousands of independent operators run in lockstep. To change a rule — how a fee is computed, which syscall a program may call, how a block is validated — every operator has to start applying the same new rule at the same logical moment. If half the validators apply the new rule and half apply the old one, they compute different states from the same transactions, disagree on what a valid block is, and the chain forks into two incompatible histories.

Two blunt ways to handle this, and Solana rejects the blunt one:

   the naive spectrum of protocol change
   ──────────────────────────────────────────────────────────────
   hard fork          flag day: everyone MUST upgrade by block N,
                      or they split off onto an incompatible chain
                      → coordination crisis, contentious, all-or-nothing


   silent change      just ship new code and hope validators run it
                      → different versions compute different states
                      → consensus divergence, undefined behavior
   ──────────────────────────────────────────────────────────────

A hard fork in the contentious sense — “block N is a flag day; upgrade or you’re on a different chain” — is exactly the drama Solana works to avoid. It couples code deployment (operators installing a new binary) to rule activation (the network starting to enforce a new rule) into a single tense moment. The fix is to decouple them.

Feature gates: activate rules on a schedule, not on a deadline

Section titled “Feature gates: activate rules on a schedule, not on a deadline”

Solana ships nearly all protocol changes behind feature gates. The idea is small and powerful:

New behavior is written into the validator code but kept dormant, guarded by a runtime check. It switches on only when a specific on-chain feature account is activated — and every validator, reading the same on-chain state, sees that activation at the same slot.

This inverts the hard-fork model. Operators can upgrade their binaries whenever they like, over a window of days or weeks, because the new code stays inert until its gate flips. Rule activation is a separate, on-chain event scheduled for a future epoch. Deployment is spread out and boring; activation is a single coordinated instant that every validator agrees on because it is read from the ledger itself, not from a wall clock or a social agreement.

   feature-gated upgrade, decoupled in time
   ──────────────────────────────────────────────────────────────
   phase 1  new rule lands in validator code, gated OFF
            operators upgrade binaries over a WINDOW (days/weeks)
            old behavior still in force — nothing changes yet
                          │
                          ▼
   phase 2  feature account is activated at epoch E (on-chain)
            every validator reads the same activation from the ledger
            at slot(E) all upgraded validators flip to the new rule
            → same rule, same moment, no fork
   ──────────────────────────────────────────────────────────────

Two properties make this safe:

  • The activation point is deterministic and shared. The feature account lives in on-chain state (a regular account, owned by a special feature program). Its activation is recorded in the ledger, so every validator computing the same ledger reaches the same conclusion about whether and when the gate is on. There is no “did you get the memo?” — the memo is the chain.
  • Adoption is measurable before it bites. Because gated code ships ahead of activation, the network can see what fraction of stake is running a version that even contains the new rule. Activation of a consequential feature is typically held until a supermajority of stake has upgraded — so the flip lands on a network that is already ready for it, rather than forcing a deadline on stragglers.

Under the hood — a feature gate is just a branch guarded by on-chain state

Section titled “Under the hood — a feature gate is just a branch guarded by on-chain state”

Strip away the ceremony and a feature gate is an if in the runtime. Conceptually:

// Not literal Solana source — the shape of the mechanism.
// Each gated rule has a well-known feature pubkey.
if feature_set.is_active(&reduce_stake_warmup_cooldown::id()) {
    apply_new_stake_warmup_rule(&mut state);   // dormant until the gate flips
} else {
    apply_old_stake_warmup_rule(&mut state);   // today's behavior
}

feature_set is derived from on-chain feature accounts as of the current slot, so it is identical on every honest validator processing that slot. The new code path exists in the binary the whole time; the branch just doesn’t take until the feature account is activated. That is the entire trick. A protocol change is not a new binary that must arrive everywhere at once — it is a branch that already shipped, waiting for a flag it reads out of the ledger.

This is why Solana upgrades tend to be undramatic. The tense, all-or-nothing “hard fork” is replaced by a smooth process: land the gated code, wait for stake to adopt it, activate at an epoch boundary, done. The same design that lets the runtime be deterministic — everyone computing the same state from the same inputs — is what lets upgrades be deterministic too.

Reading the roadmap: durable themes, not dated promises

Section titled “Reading the roadmap: durable themes, not dated promises”

Now the second job. Solana’s roadmap, like any live system’s, is a stream of specific proposals, code names, target dates, and TPS numbers. Most of those specifics will be stale by the time you read them. Named upgrades get renamed, merged, split, delayed, or quietly dropped. So the durable skill is not memorizing this quarter’s release — it’s recognizing the themes that recur across releases, because the themes are stable even as the specifics churn. Group by theme, and the roadmap stops being a wishlist and becomes a map of where the throughline is still unresolved.

Four themes recur, and every one is a continuation of something you already studied in this book.

Theme 1 — Reliability and liveness hardening

Section titled “Theme 1 — Reliability and liveness hardening”

The reliability part showed that a speed-first, single-synchronous-machine chain has less slack than a slow one, and documented real halts. A permanent strand of the roadmap is closing those failure modes: better admission control at the TPU, graceful shedding of excess load instead of resource exhaustion under forwarding storms, and work to make coordinated restarts rarer and faster. This theme almost never trades toward raw speed — it trades speed away for the property the throughline cares about most: not falling apart.

Theme 2 — Fee-market refinement

Section titled “Theme 2 — Fee-market refinement”

The local fee market already prices congestion per writable account rather than per block. Roadmap work in this theme sharpens that: better priority-fee estimation for wallets, tighter coupling between a transaction’s declared footprint and what it pays, and refinements that make the per-account auction behave well under memecoin-scale bursts. It is a direct extension of the fee-market design — the same “price contention where it happens” idea, tuned.

Theme 3 — Scheduler and networking improvements

Section titled “Theme 3 — Scheduler and networking improvements”

This is Sealevel and the validator pipeline continuing to evolve. On the scheduler side: smarter batching that squeezes more real parallelism out of a mixed workload without violating the conflict rule. On the networking side: hardening the QUIC-based transaction ingress and Turbine block propagation so a leader is not overwhelmed by connection floods. Every item here is the same lesson from Day 29: parallelism is revealed, not added — so the work is revealing more of it, more efficiently, without breaking determinism.

Theme 4 — Raising real (not theoretical) throughput

Section titled “Theme 4 — Raising real (not theoretical) throughput”

The foundations part drew the sharp line between the theoretical ceiling and the real throughput a live, adversarial network sustains. This theme is about closing that gap: independent client implementations like Firedancer that push the pipeline’s real limits, plus protocol tweaks (larger lookup tables, higher compute ceilings) that raise sustained capacity. Watch for whether a claim is about a benchmark on a test cluster or throughput a real validator holds against real load — the roadmap’s honest wins are the second kind.

   roadmap theme  →  book part it continues
   ────────────────────────────────────────────────────────────
   reliability/liveness   →  Reliability (why a fast chain can halt)
   fee-market refinement  →  Economics (local fee markets)
   scheduler + networking →  Sealevel + Validator Pipeline
   real throughput        →  Foundations (serialization ceiling)
                             + Firedancer / client diversity
   ────────────────────────────────────────────────────────────
   every arrow is the SAME throughline, still unresolved:
   run at hardware speed WITHOUT falling apart.

Notice what nearly every item has in common: it trades raw speed against reliability and decentralization pressure. A faster scheduler that a hobbyist validator can’t keep up with centralizes the network; a higher compute ceiling that lets a bad block wedge a leader hurts liveness. The interesting roadmap items are precisely the ones fighting on both sides of that trade at once — more speed and more slack — because that is the hard part the throughline names.

How to read a forward-looking claim skeptically

Section titled “How to read a forward-looking claim skeptically”

Every claim about the future — a named upgrade, a target date, a TPS record — should be treated as a snapshot taken at some moment, not a fact about now. A simple discipline:

  • Named upgrade or code name? Assume it may be renamed, merged, split, delayed, or dropped. Track the theme it belongs to (one of the four above), which is stable, not the name.
  • A date? Attach an absolute “as of” to it in your own head and go verify it against current sources — release notes, the feature-gate status on the live cluster, client changelogs. Roadmap dates slip; that is normal, not scandal.
  • A TPS or throughput number? Ask three questions before believing it: test cluster or mainnet? theoretical ceiling or sustained real load? peak burst or steady state? The honest number is almost always smaller and more qualified than the headline.

The reason this discipline matters is not cynicism — it is that the roadmap moves, and a book cannot freeze it. What does not move is the shape of the problem. So the transferable knowledge is the four themes and the upgrade mechanism, not this quarter’s release name. When you meet a specific claim in the wild, slot it into a theme, date it, and verify the number. That is how you read a roadmap without being its marketing.

The thread

Section titled “The thread”

The roadmap is not a separate topic bolted onto the end of the book — it is the throughline still being answered in public. How do you change a global state machine that runs at hardware speed without falling apart? Feature gates answer the how do you change it half: decouple deployment from activation, read the activation out of the ledger, wait for stake to adopt, flip at an epoch. The four themes answer the what’s left half: reliability, fee markets, scheduler and networking, real throughput — each one a place where speed and not-falling-apart are still being traded against each other. Learn the mechanism and the themes; discount every date and number. The specifics will be stale; the shape of the question will not.

Check your understanding

Section titled “Check your understanding”
  1. What problem does a contentious hard fork create, and how does a feature gate avoid it? Be specific about what gets decoupled.
  2. A feature gate’s activation is “deterministic and shared.” Where does the activation actually live, and why does that guarantee every honest validator flips to the new rule at the same slot?
  3. Why is feature activation gated on stake-weighted adoption rather than validator headcount, and what goes wrong if a consensus-affecting feature is activated while significant stake is still on old code?
  4. The page groups the roadmap into four durable themes. Name them, and for each, name the earlier part of the book it continues.
  5. You read a blog post claiming “Solana will hit 1,000,000 TPS after the Frankendancer upgrade next quarter.” Apply the page’s skeptical reading discipline: what do you distrust, what do you keep, and how do you verify?
Show answers
  1. A contentious hard fork sets a flag day: every operator must upgrade by block N or split onto an incompatible chain — it couples code deployment to rule activation into one tense, all-or-nothing moment. A feature gate decouples them: the new rule ships in the binary but stays dormant behind a runtime check, so operators upgrade over a window whenever they like, and the rule activates separately at a scheduled on-chain event. Deployment is spread out; activation is a single coordinated instant.
  2. The activation lives in an on-chain feature account (a regular account owned by a special feature program), so it is recorded in the ledger. Every validator computing the same ledger reads the same activation status at the same slot — there is no out-of-band memo to miss, because the memo is the chain. Same on-chain state in, same activation decision out.
  3. Because consensus is stake-weighted, what matters is the fraction of stake enforcing a rule, not the number of machines. If a consensus-affecting feature activates while, say, 12% of stake runs old code lacking the rule, that stake computes a different (old) state for the same block, disagrees on validity, and forks off — potentially stalling or splitting the network. So activation waits until stake-weighted adoption is safely past what consensus needs.
  4. Reliability/liveness hardening — continues the Reliability part; fee-market refinement — continues Economics / local fee markets; scheduler and networking improvements — continue Sealevel and the validator pipeline; raising real throughput — continues Foundations / the serialization ceiling plus Firedancer and client diversity.
  5. Distrust the specifics: the code name (may be renamed/merged/dropped), the date (“next quarter” — attach an absolute as-of and expect slippage), and the number (1,000,000 TPS — ask: test cluster or mainnet? theoretical ceiling or sustained real load? peak burst or steady state?). Keep the theme: it belongs to real throughput + client diversity, which is a durable roadmap strand. Verify by checking current release notes, the live cluster’s feature-gate status, and client changelogs — and by distinguishing any benchmark figure from throughput a real validator holds under real, adversarial load.