Overview — The Ecosystem: SPL, DeFi & NFTs

Every part before this one built Solana’s engine. The account model pulled state out of programs and into named, external accounts. Sealevel used the declared footprints those accounts expose to run non-conflicting transactions in parallel across cores. Proof of History gave every validator a verifiable clock so they could agree on order without a round of messages, and Tower BFT over Proof of Stake turned a stake-weighted vote into agreement on one canonical fork. Put together, that is a single global state machine that runs at hardware speed. The engine is finished.

This part is about what people build on top of it. Nobody buys a chain to admire its scheduler; they buy it to move money, trade assets, and own things. So the question this part turns on is a level up from the engine: how do you build financial primitives — tokens, exchanges, collectibles — as shared programs over accounts, rather than as one bespoke contract per application? The answer Solana gives is the same answer the account model gave, applied one storey higher: externalize the state, and let one program serve all the instances. That single design choice is the thread of this entire part, and it is worth stating precisely before we spend six pages proving it.

The central contrast: one shared program vs one contract per app

On Ethereum, a token is a contract. If you want to launch a token, you deploy your own copy of the ERC-20 code — your own bytecode, at your own address, with balances living inside its own storage. A thousand tokens is a thousand deployed contracts, each a separate program the world must trust and audit individually.

On Solana, a token is not a program. There is one SPL Token program, deployed once, shared by every token that has ever existed on the chain. A new token is not new code — it is a new account (a “mint”) that the shared program knows how to operate on. Your balance in that token is another account (a “token account”) that the same shared program reads and writes. The code is fixed and global; only the data multiplies.

   ETHEREUM: one contract per token          SOLANA: one program, many accounts
   ─────────────────────────────────          ──────────────────────────────────

   ┌───────────────┐ ┌───────────────┐         ┌─────────────────────────────┐
   │ USDC contract │ │ DAI contract  │         │      SPL Token program      │
   │  code + all   │ │  code + all   │         │   (deployed ONCE, shared)   │
   │  balances     │ │  balances     │         └──────────────┬──────────────┘
   └───────────────┘ └───────────────┘              operates on │
   ┌───────────────┐ ┌───────────────┐         ┌───────┬───────┼───────┬───────┐
   │ SHIB contract │ │ ...1000 more  │         ▼       ▼       ▼       ▼       ▼
   │  code + data  │ │  each its own │      [USDC   [DAI   [SHIB  [your  [...N
   └───────────────┘ │  bytecode     │       mint]  mint]  mint]  token  mints]
                     └───────────────┘                            acct]

   N tokens = N programs to audit          N tokens = 1 program + N data accounts

This is not a cosmetic difference. It is the account model’s contract-owned-storage-vs-external-accounts contrast, promoted from “where does a counter’s state live” to “how does an entire asset class get built.” And like every choice in this book, it is a trade, not a free win — we will name what it costs on every page.

What the shared-program model buys, and what it costs

Read this part with one habit: for every convenience the ecosystem hands you, find the bill.

Shared programs mean a token is instantly composable — every wallet, exchange, and protocol already understands the one SPL Token program, so a brand-new mint works everywhere on day zero with no integration. The cost: you inherit whatever the shared program does and does not do. You cannot fork ERC-20 to add a custom transfer hook the way you would on Ethereum; you get the mint’s fixed feature set (extended, carefully, by Token-2022) and nothing more.
Cheap NFTs mean minting a million collectibles costs cents, not a fortune in rent — but only because state compression moves the data off the ledger and keeps just a hash on chain, so the asset is only as available as the off-chain indexer that stores its leaves.
Deep liquidity on a fast chain means an orderbook DEX can run on-chain where other chains can only afford an AMM — but an on-chain orderbook writes a hot, shared account on nearly every trade, which is exactly the hot-account ceiling Sealevel warned about, throttling the parallelism the chain was built for.

None of these are gotchas. They are the shape of the trade: Solana’s ecosystem is convenient because it centralizes shared machinery, and centralizing shared machinery always concentrates a cost somewhere. Naming that “somewhere” on each page is the whole skill.

A note on names, numbers, and dates

This part must mention real things — protocol names, program IDs, total-value-locked figures, transaction costs. Treat every one of them as a snapshot, not a constant. Protocols get exploited, forked, rebranded, or abandoned; a DEX that dominated one year is a footnote the next. TVL and token prices move by the hour. Program upgrades change fee schedules and add features.

So throughout this part, established mechanisms are stated confidently — the SPL Token program’s account layout, how an AMM’s constant-product formula works, how a Merkle proof reconstructs a compressed NFT — because those are engineering facts. But any figure or ranking or roadmap claim is hedged with an absolute date (“as of 2024”), and you should mentally re-verify it before relying on it. If a page says “one of the largest AMMs on Solana,” read it as “was, at the time of writing” and go check the current landscape yourself.

Roadmap for this part

Read these in order. Each page takes the shared-program idea and drives it into a specific corner of the ecosystem — first the token primitive itself, then the two things people do with tokens (trade them, and mint unique ones), then the plumbing that connects it all.

#	Page	The idea it forces	Builds on
2	The SPL Token Program & Associated Token Accounts	one shared program + a mint account + per-holder token accounts is all a fungible token is	everything is an account, PDAs
3	Orderbook DEXs vs AMMs	two ways to price a swap over accounts — a shared orderbook (hot, contended) vs a constant-product pool (parallel-friendly)	the hot-account ceiling, the conflict rule
4	Metaplex NFTs	a non-fungible token is a mint with supply 1 plus a metadata account — a standard over accounts, not new code per collection	SPL Token, PDAs
5	Compressed NFTs & State Compression	keep only a Merkle root on chain and prove leaves against it — trading account rent for indexer dependence	everything is an account, cryptographic hashing
6	Major Protocols & Wallets	the composition layer — how wallets sign, and how protocols call each other via CPI over the same shared accounts	transactions, signing & verification
900	Revision — The Ecosystem	the part compressed to what you must retain	the whole thread in one page

By the end you will be able to open any Solana application — a swap, a mint page, a lending market — and decompose it into the same few pieces: a handful of shared programs operating on a graph of external accounts, with a wallet supplying signatures and CPI stitching the programs together. Nothing in the ecosystem is genuinely new machinery. It is the engine from the previous parts, dressed for a specific job.

The thread

What does building the ecosystem force you to understand? That “an application” on Solana is rarely a program you deploy — it is a convention you adopt over programs that already exist. A token is a convention (mint + token accounts) over the shared SPL Token program. An NFT is a tighter version of the same convention (supply 1 + metadata). A DEX, a lending market, a compressed collection — each is a small amount of new code sitting atop a large amount of shared code, gluing external accounts together with CPI. The account model’s promise — that state lives outside programs, in accounts anyone can address — is what makes this possible: if state lived inside each app’s program, every app would be an island, and none of this composition could happen. The ecosystem is the account model’s payoff, cashed a second time.

The first job is the primitive everything else rests on: what, exactly, is a token when there is no token contract? Start with The SPL Token Program & Associated Token Accounts.

Check your understanding

State the central contrast of this part in one sentence: how does “launching a token” differ between Ethereum’s contract model and Solana’s shared-program model?
On Solana, if the SPL Token program is deployed only once, where does a specific token’s identity live, and where does your balance in it live?
The part’s recurring habit is “name the cost of every convenience.” Pick any one convenience from this page (shared programs, cheap NFTs, or deep on-chain liquidity) and state the specific cost it carries.
Why does the page insist you treat protocol names, TVL figures, and rankings as snapshots rather than facts — and what does it say to do differently for a mechanism like the constant-product formula?
Using the book’s throughline and the account model’s promise, explain why the shared-program ecosystem is only possible because Solana keeps state outside programs.

Show answers

On Ethereum, launching a token means deploying your own contract — new bytecode at a new address, with balances stored inside it — so N tokens are N programs. On Solana, launching a token means creating a new account (a mint) that the single, already-deployed SPL Token program operates on — so N tokens are one shared program plus N data accounts.
The token’s identity lives in its mint account (its own external account, distinct from the program). Your balance lives in a separate token account that ties your wallet to that mint. The SPL Token program holds neither — it is stateless shared code that reads and writes both.
Any one of: shared programs buy instant composability but cost you the ability to customize behavior — you get the mint’s fixed feature set, not a forkable ERC-20. Cheap NFTs work only because state compression moves data off-ledger, so the asset depends on an off-chain indexer’s availability. Deep on-chain liquidity via an orderbook writes a hot, shared account per trade, hitting the hot-account ceiling and throttling parallelism.
Because names, TVL, and rankings are volatile — protocols get exploited, forked, rebranded, or abandoned, and figures move by the hour — so any such claim is a snapshot to re-verify, hedged with an absolute date. A mechanism (like how a constant-product AMM prices a swap) is an engineering fact, stated confidently because it does not change with the market.
The book’s throughline is building a single global state machine that runs at hardware speed. The account model achieves the “hardware speed” half by keeping state outside programs, in externally addressable accounts. That same externalization is what lets many applications share one program and compose over the same accounts via CPI. If state lived inside each app’s program (Ethereum’s model), every app would be an island with private storage, and the shared-program ecosystem — one SPL Token program for all tokens, protocols calling each other over common accounts — could not exist.