Revision · The Ecosystem: SPL, DeFi & NFTs

The previous parts built Solana’s engine: an account model that pulls state out of programs into named accounts, a parallel runtime that uses declared footprints to run non-conflicting transactions across cores, a verifiable clock that orders events without a conversation, and consensus that agrees on one fork. This part did something different. It stopped building the engine and started reading what people build on it — tokens, exchanges, collectibles, and the wallets and protocols that stitch them together.

The whole part turned on a single idea, and if you retain one sentence, retain this one: on Solana, an application is rarely a program you deploy — it is a convention you adopt over programs that already exist. Where Ethereum answers “how do I build a token?” with “deploy your own contract,” Solana answers with “create a new account that the one shared program already knows how to operate on.” Every page below is that answer, pushed into a different corner of the ecosystem. This recap walks the thread end to end so you can hold it in one breath.

The throughline: shared programs over named accounts

Start from the contrast the Overview drew, because everything else is a special case of it. On Ethereum a token is a contract: your own bytecode, at your own address, with balances living inside its own storage. A thousand tokens is a thousand deployed programs, each audited on its own. On Solana there is one SPL Token program, deployed once, shared by every token that will ever exist. A new token is not new code — it is a new account that the shared program reads and writes. The code is fixed and global; only the data multiplies.

   ETHEREUM: one contract per app            SOLANA: one program, many accounts
   ─────────────────────────────             ──────────────────────────────────
   token   = a deployed contract             token   = a mint account
   NFT     = a deployed contract             NFT     = a mint account (supply 1)
   DEX     = a deployed contract             DEX     = a program over pool/order accounts
   ──────────────────────────────            ──────────────────────────────────
   N things = N programs to audit            N things = few programs + N data accounts

This is the account model’s promise cashed a second time. Because state lives outside programs — in externally addressable accounts — many applications can share one program and compose over the same accounts. If state lived inside each program, every app would be an island with private storage, and none of this would be possible. The ecosystem is not new machinery. It is the engine from the earlier parts, dressed for a specific job.

And it is always a trade, never a free win. The habit this part drilled is one sentence: for every convenience the ecosystem hands you, find the bill. Shared machinery is convenient precisely because it centralizes, and centralizing always concentrates a cost somewhere. Naming that somewhere on each page was the whole skill.

SPL Token and Associated Token Accounts

The SPL Token program is the primitive everything else rests on, so it is worth getting exactly right. A fungible token is three kinds of thing, and only one of them is code:

• The program — deployed once, shared, stateless. It knows how to mint, transfer, burn, and freeze. It holds no balances of its own.
• The mint account — one per token. It carries the token’s identity: its supply, its decimals, and who is allowed to mint more. USDC is a mint. A meme coin is a mint. They are peers, differing only in data.
• The token account — one per (holder, mint) pair. It records how much of one mint a particular owner holds. Your USDC balance is not a row inside the program; it is its own account tied to your wallet and the USDC mint.

The clean picture, then: identity lives in the mint, balance lives in a token account, and the program is stateless code that operates on both.

        SPL Token program  (deployed once, holds no balances)
                 │  operates on
      ┌──────────┼───────────────────────────────┐
      ▼          ▼                                ▼
  [USDC mint]  [Alice's USDC token account]  [Bob's USDC token account]
   supply,       owner = Alice                 owner = Bob
   decimals      amount = 100                   amount = 5

The remaining wrinkle is finding a holder’s token account. If token accounts sat at random addresses, sending someone tokens would require first asking “which account holds your USDC?” — a lookup before every transfer. The Associated Token Account convention removes that lookup by deriving a deterministic address from the owner’s wallet and the mint, using a Program Derived Address. Given a wallet and a mint, everyone computes the same ATA address with no on-chain query. That is why you can paste a wallet address and send it a token you have never discussed: the destination account’s address is a pure function of two things you already know.

The bill for all this shared machinery: you inherit the program’s fixed feature set. You cannot fork ERC-20 to bolt on a custom transfer hook the way you would on Ethereum. New behavior arrives only when the shared program is carefully extended — the role Token-2022 plays — and never as a per-token fork.

Orderbook DEXs vs AMMs

With tokens defined, the first thing people do is trade them, and the DEX page showed there are two fundamentally different ways to price a swap over accounts. The difference is not cosmetic; it decides how well the exchange fits Solana’s parallel runtime.

An orderbook DEX works the way a traditional exchange does. Makers post limit orders — “sell 10 SOL at 150” — into a shared book, and a matching engine pairs buyers with sellers at agreed prices. It gives tight spreads and true price discovery, and Solana is one of the few chains fast enough to run the book on-chain rather than off. The cost is written into the design: nearly every trade touches the same shared order-book account. That is precisely the hot-account ceiling from the runtime part — a single account that many transactions must write serializes them, throttling the very parallelism the chain was built for.

An AMM takes the opposite approach: there is no book and no counterparty. A liquidity pool holds a reserve of two tokens, and a formula sets the price. The classic is the constant-product rule, x * y = k: the product of the two reserves is held constant, so buying one token out of the pool pushes its price up along a curve.

   AMM constant product:  x * y = k

   pool reserves:  x SOL   ×   y USDC   =   k   (constant)
   a swap moves along the curve; taking SOL out raises SOL's price

        USDC
         │•
         │ •
         │  •••
         │     ••••••
         └───────────── SOL
   large trades slip far up the curve  →  "slippage"

The AMM’s virtue is exactly what the orderbook lacks: because each pool is its own account, swaps against different pools do not conflict and run in parallel; and anyone can supply liquidity by depositing into the pool, with no obligation to actively make markets. Its costs are equally intrinsic — large trades slip up the curve (slippage), and liquidity providers face impermanent loss when the pool’s price diverges from the outside market. Neither design is “better.” The orderbook buys price quality with a hot shared account; the AMM buys parallelism and passive liquidity with slippage and a formula that only approximates a fair price. Which trade you want depends on the asset and the volume — which is why real ecosystems run both.

Metaplex NFTs

Trading is one thing you do with tokens; minting unique ones is the other. The Metaplex NFT page showed that a non-fungible token needs no new token machinery at all. It is a tighter version of the same convention:

• Take an ordinary SPL mint, but set its supply to 1 and its decimals to 0. One indivisible unit that can only ever exist once — that is uniqueness, expressed entirely in the mint’s own fields.
• Attach a metadata account — a Metaplex convention — at a PDA derived from the mint. It holds the name, symbol, royalty settings, and a URI pointing at the off-chain JSON and image.

So an NFT is a supply-1 mint plus a metadata account, and a “collection” is a standard over accounts, not a bespoke contract per project. This is the shared-program idea again: the same SPL Token program that moves fungible balances also moves NFTs, because from its point of view a supply-1 mint is just a mint. The convenience — every wallet and marketplace understands your NFT the instant you mint it, because it understands the shared standard — carries the same bill as always: your NFT does exactly what the standard supports, and the image usually lives off chain at that URI, so the on-chain token guarantees provenance but not that the picture will still resolve.

Compressed NFTs and state compression

Metaplex NFTs are cheap by Ethereum standards but not free: each one is a handful of real accounts, and every account pays rent for the space it occupies. Mint a million of them and the rent alone is a fortune. The compressed-NFT page showed the escape, and it is the cleanest single example of “find the bill” in the whole part.

The trick is state compression: instead of storing a million NFTs as a million accounts, store only a Merkle root — one 32-byte hash — in a single on-chain account, and keep the actual leaves off chain. The root commits to the entire tree, so any individual NFT can be proven to belong by supplying its leaf plus the sibling hashes along the path to the root. Change one leaf and the root changes; the on-chain hash is the compact fingerprint of the whole collection.

                    root  (32 bytes, ON CHAIN)
                   /    \
                 h01    h23
                /  \    /  \
             NFT0 NFT1 NFT2 NFT3   ← leaves live OFF chain, in an indexer
             prove NFT2 ∈ tree by giving [NFT2, NFT3→h23, h01]

This collapses the cost of minting at scale from per-account rent to essentially the cost of one account plus the transaction fees to update the root — cents for a whole collection. The bill is stated plainly: the leaves are not on the ledger, so the asset is only as available as the off-chain indexer that stores them. The chain proves a compressed NFT is authentic; it does not, by itself, hand you its data. You are trading on-chain rent for a dependence on infrastructure that holds the leaves — the same shape of trade as the off-chain image URI, one storey deeper.

Protocols and wallets: the composition layer

The final page pulled back to the plumbing that ties it all together — the layer where the shared-program idea pays its biggest dividend. Two mechanisms carry it.

A wallet is, at bottom, a keypair plus a signing interface. It does not hold your tokens — those live in token accounts on the ledger. What it holds is the private key that authorizes changes to accounts your wallet owns. When an app asks you to swap or mint, it hands the wallet an unsigned transaction; the wallet shows you what it does, and you produce the signature that makes it valid. Custody is custody of the key, not of the assets.

Composability is the other half, and it is the account model’s promise at full volume. Because programs are stateless and state lives in shared external accounts, one program can call another mid-transaction via cross-program invocation (CPI). A lending protocol can call the SPL Token program to move collateral; a DEX aggregator can call three different AMMs in one atomic transaction and revert all of them if any leg fails. Nothing is an island: the same accounts and the same shared programs are the common ground every protocol builds on.

Because this is the layer of named protocols, TVL figures, and rankings, it is also where the part’s warning bites hardest. Established mechanisms — the SPL account layout, the constant-product formula, how a Merkle proof reconstructs a compressed NFT — are engineering facts, stated confidently because they do not change with the market. But any figure, ranking, or roadmap claim is a point-in-time snapshot: protocols get exploited, forked, rebranded, or abandoned, and TVL and prices move by the hour. Everywhere this part named “one of the largest” anything, read it as “was, at the time of writing, as of 2024” and re-verify before you rely on it. That hedge is not hand-waving; it is honesty about the difference between the durable and the volatile.

The takeaway

You can now open any Solana application — a swap page, a mint page, a lending market — and decompose it into the same few pieces: a handful of shared programs operating on a graph of named external accounts, with a wallet supplying signatures and CPI stitching the programs together. A token is a convention (mint plus token accounts). An NFT is a tighter convention (supply-1 mint plus metadata). A compressed collection is that convention with the leaves swapped for a Merkle root. A DEX is a little new code over pool or order-book accounts. None of it is new machinery.

And each convenience carried a matching cost, which is where this part rejoins the book’s throughline: how do you build a single global state machine that runs at hardware speed without falling apart? The ecosystem is the payoff for keeping state outside programs — that is what lets everyone share one program and compose over common accounts. But the same externalization that buys hardware speed is what forces the trades you kept naming: the shared orderbook is a hot account that fights the scheduler; cheap NFTs push their data off the ledger onto an indexer; a token inherits its program’s fixed features rather than forking freely. The engine runs at hardware speed because it centralizes shared machinery — and centralizing shared machinery always concentrates a cost somewhere. The ecosystem is that bargain, cashed in public. If you can point at any Solana app and name both the convenience and its bill, you have understood this part.

Next, revisit the Overview with this frame, or step back to the account model that made the whole bargain possible in the first place.