Major Protocols & Wallets

The last four pages built the primitives: a shared SPL Token program and its per-holder token accounts, two ways to price a swap, Metaplex NFTs as a mint-with-metadata standard, and compressed NFTs that keep only a root on chain. Each one is the same trick — a small convention over a large amount of shared code. This page is where those primitives get used: the applications people actually open, and the wallet that stands between a human and a signature.

The point of this page is not to catalogue products. Products come and go; a protocol that dominates one year is a footnote the next. The point is to survey the categories by function — what job each kind of protocol does, and how it composes over the shared token program — and to be precise about the one piece of software every user touches directly: the wallet. When we name a specific protocol or wallet, treat it as an example of a category, dated and volatile, never an endorsement.

The composition layer, in one idea

Everything below rests on a single fact established earlier in this part: on Solana, state lives in accounts outside programs, and programs are shared. That means a protocol is rarely a self-contained world. It is a thin program that calls other programs over the same accounts, via cross-program invocation (CPI).

   ONE user transaction, many programs invoked over shared token accounts:

   [ your wallet signs ]
          │
          ▼
   ┌──────────────────────┐
   │  aggregator program  │  "swap 100 USDC -> max SOL"
   └──────────┬───────────┘
     CPI      │  routes the trade across several venues
     ┌────────┼─────────┬───────────────┐
     ▼        ▼         ▼               ▼
  [AMM pool] [AMM pool] [orderbook]  ... each is its own program
     │        │         │
     └────────┴─────────┴──► all read/write SPL Token accounts (your ATA + pool ATAs)

Because the token program is shared, none of these venues had to agree on a format in advance. A brand-new AMM works with the aggregator on day zero, for the same reason a brand-new mint works with every wallet on day zero: they all speak the one SPL Token program. This is composability, and it is the reason the “application layer” on Solana is a graph of programs calling programs, not a set of walled gardens.

Protocol categories, by function

Four categories cover most of what people mean by “Solana DeFi.” Learn what each does and what accounts it composes over; the specific names are interchangeable and dated.

DEX aggregators

A decentralized exchange (DEX) lets you swap one token for another with no custodian. As the previous page showed, there are two engines underneath: an orderbook (buyers and sellers post prices to a shared book) and an AMM (a constant-product pool prices the trade from its reserves). A single chain hosts many of each — dozens of AMM pools for the same pair, plus one or more orderbook venues.

An aggregator sits on top and answers one question: given “spend 100 USDC, get the most SOL possible,” which venues, in which proportions, produce the best fill? It splits the order across pools and books, invokes each via CPI within one transaction, and returns the combined output. The user signs once; under the hood a dozen programs may have run.

   Naive swap:      you -> one AMM pool                (whatever price that pool gives)
   Aggregated swap: you -> aggregator -> {pool A 40%, pool B 35%, book C 25%}
                                          └─ best blended price, one signature

The aggregator holds no liquidity of its own. It is pure routing logic — the clearest possible example of composition: it is valuable precisely because every venue shares the token program, so routing across them is just a matter of which CPIs to emit.

Lending and borrowing

A lending protocol is a program that holds a pool of deposited tokens and lends them out against collateral. You deposit USDC and earn interest; someone else posts SOL as collateral and borrows USDC against it, paying interest. The protocol is the counterparty to both sides.

Two mechanisms make this safe enough to run without a human underwriter:

• Over-collateralization. A borrower must lock collateral worth more than they borrow — say, deposit $150 of SOL to borrow $100 of USDC. The gap absorbs price moves.
• Liquidation. If the collateral’s value falls until the loan is no longer safely covered, anyone may repay part of the loan and seize the collateral at a discount — a liquidator. This is a permissionless job the protocol depends on being profitable enough that someone always does it.

Both mechanisms need one thing the chain cannot produce by itself: a price. The protocol must know “how much is this SOL collateral worth in USDC right now.” That number comes from an oracle — an off-chain price fed on-chain by a dedicated program. Oracles are the soft underbelly of lending, and we return to them under failure modes.

Liquid staking

Recall Proof of Stake: to help secure the chain, you stake SOL by delegating it to a validator, and in return you earn a share of inflation rewards. But staked SOL is locked — it is doing a job (backing consensus via the stake-weighted vote and the leader schedule), and while it is staked you cannot spend it, trade it, or use it as DeFi collateral.

Liquid staking resolves that tension with the same shared-program trick. You deposit SOL into a liquid-staking program; it stakes that SOL across validators on your behalf and mints you a liquid staking token (LST) — an SPL token representing your staked position and its accruing rewards.

   Plain staking:   [ SOL ] --stake--> validator      (locked; earns rewards; illiquid)

   Liquid staking:  [ SOL ] --deposit--> LST program --stakes--> validators
                                              │
                                              └─ mints [ LST ] back to you
                        LST is a normal SPL token: trade it, lend it, use it as collateral,
                        while the SOL underneath keeps earning staking rewards.

The LST is an ordinary SPL token, so every protocol above already understands it: you can lend it, put it in an AMM pool, or use it as collateral — all while the underlying SOL keeps securing the network. The LST’s value tracks the staked SOL plus accrued rewards, so over time one LST is redeemable for slightly more SOL than you put in. This is liquid staking’s whole appeal, and its whole risk: you are now trusting the LST program’s staking logic and the market’s willingness to treat the LST as worth its backing (see depegs, below).

Perpetual futures (“perps”)

A perpetual future (“perp”) is a derivative that lets you take a leveraged long or short position on a token’s price without holding the token. Deposit $100 of collateral, take a 5x position, and you gain or lose as if you held $500 of the asset. There is no expiry — the position “perpetuates” — and a funding rate periodically transfers value between longs and shorts to keep the perp’s price tethered to the spot price.

Perps are the category that leans hardest on the two dependencies we keep flagging: they need a fast, accurate oracle (leverage magnifies any price error) and a liquidation engine that closes underwater positions before they go negative. On a slow chain those requirements are hard to meet; Solana’s speed is part of why on-chain perps are viable here at all. It is also why, when they fail, they fail loudly.

The wallet: keypair custody and signing

Everything above assumed one thing: your wallet signs the transaction. A wallet is the piece of software that holds your keys and produces signatures. Strip away the UI and it does exactly four jobs.

1. Custody a keypair

An address on Solana is a public key; the matching ed25519 private key is the sole thing that can authorize spending from it. The wallet’s first job is to store that private key and never leak it — typically derived from a human-readable seed phrase, kept encrypted, and used only to sign. Whoever holds the key holds the funds; the wallet is a careful vault around it.

2. Connect to a dApp

When you open a Solana app in a browser, the app asks your wallet to connect. Connecting shares only your public key (address) — never the private key. From that address alone the app can look up all your on-chain state, because everything you own is an account addressable from your key.

3. Find your balances (via ATAs)

Here is where the earlier pages pay off. A wallet does not store your balances — the chain does. To show “you hold 42 USDC,” the wallet must find your USDC balance. It does this exactly the way the Associated Token Account page described: for each mint of interest, it derives the deterministic ATA address — a Program-Derived Address from (your wallet, the token program, the mint) — and reads that account.

   To display your USDC balance, the wallet computes (no lookup, pure derivation):

     ATA = PDA( seeds = [ your_wallet_pubkey, TOKEN_PROGRAM_ID, USDC_mint ] )

   then reads that single account's `amount` field. Repeat per mint to build
   the whole balances list. The wallet stores nothing; it *derives and reads*.

This is why any wallet can display any token instantly, with zero integration per token: the ATA address is a pure function of your key and the mint, so the wallet computes it rather than looking it up in some registry.

4. Sign transactions

When an app wants you to act — swap, deposit, mint — it builds a transaction (a message listing instructions and the accounts each touches) and hands it to your wallet. The wallet shows you what you are about to authorize, and if you approve, it signs the message with your private key and returns the signature. The app broadcasts it; validators verify the signature against your public key before the runtime runs a single instruction.

The critical security property is that the wallet signs a specific message, not a blank cheque. A signature authorizes exactly the instructions and accounts in that transaction — which is also why the wallet’s job is to help you read what you are signing, because a malicious dApp’s whole game is to get you to sign something you did not understand.

By the numbers — a swap fee, decomposed

A user swaps on an aggregator. What do they actually pay? As of 2024, on Solana the base transaction fee is 5,000 lamports per signature, i.e. 0.000005 SOL — a fraction of a US cent. The real costs are elsewhere:

   Per-swap costs (illustrative, magnitudes only — verify current values):

     base network fee     ~5,000 lamports  = 0.000005 SOL   (paid to validators)
   + priority fee         variable         (bid for block space when congested)
   + AMM pool fee         ~0.01%-1% of trade size (paid to liquidity providers)
   + price impact / slippage on the trade itself (the biggest cost on large orders)

   For a small swap, the network fee rounds to zero; the *pool fee* and
   *slippage* dominate. The chain being cheap does not make trading free.

The lesson: Solana’s near-zero network fee is real, but it is the smallest line on the bill. The economically meaningful costs are the protocol-level pool fees and the market-level slippage — neither of which the chain’s speed reduces.

Ecosystem risks: the recurring failure modes

Composability cuts both ways. Because protocols stack on shared programs and shared price feeds, a failure in one layer propagates into everything built on it. Three failure modes recur across the whole ecosystem.

• Smart-contract exploits. A bug in a protocol’s own program — a missing check, an arithmetic error, a signer confusion — lets an attacker drain accounts the program controls. Because DeFi programs custody pooled funds, a single exploited program can lose everything deposited into it. Composition amplifies this: if protocol B builds on protocol A, a bug in A can drain B’s users too.
• Oracle failures. Lending and perps cannot function without a trusted price. If the oracle reports a wrong price — stale, manipulated, or briefly spiking — the protocol acts on a lie: it may let a borrower over-borrow against phantom collateral, or wrongly liquidate a healthy position. The oracle is a dependency the chain’s own security does not cover.
• Depegs. A token that is supposed to hold a fixed value — a stablecoin pegged to $1, or an LST redeemable for its backing SOL — can trade away from that value if the market loses confidence or the backing is questioned. A depeg cascades: every lending market and pool that treated the token as worth its peg is suddenly mispriced, triggering liquidations and bad debt across protocols that never touched the depegged token directly.

None of these are Solana-specific; they are the failure modes of composable finance on any chain. But Solana’s speed and low fees make the ecosystem denser and more interconnected, which means propagation is faster. The defensive habit is the same one from the overview: for every protocol you use, ask what does it depend on that it does not control — a shared program’s correctness, an oracle’s honesty, a peg’s credibility.

It actually happened — the Mango Markets exploit, October 2022

In October 2022, an attacker drained roughly $100 million from Mango Markets, a Solana lending-and-perps protocol, without breaking a single line of Mango’s cryptography. The method was pure oracle manipulation composed with lending:

1. The attacker opened a large perp position in the thinly-traded MNGO token.
2. They then bought MNGO aggressively on the spot market, spiking its price.
3. The oracle Mango used dutifully reported the (real, but manipulated) high price.
4. At that inflated price, the attacker’s position was “worth” enormous collateral — so Mango let them borrow against it, and they borrowed out nearly the whole treasury.

Every individual step behaved exactly as designed. The failure was the composition: a lending protocol that trusts an oracle, feeding a market thin enough to move. The lesson is the theme of this page — a protocol is only as safe as its dependencies, and an oracle is a dependency the chain’s own guarantees do not cover.

The architect’s lens

The “protocol + wallet” layer is a major component: it is where the engine finally does the job people bought it for. Answer these before treating any specific protocol as trustworthy.

• Why does it exist? So that financial applications can be built as thin programs that compose over shared token accounts, rather than each re-implementing balances, matching, and custody from scratch — and so a human can authorize on-chain actions with a key they control instead of trusting a custodian.
• What problem does it solve? It turns the raw primitives (mints, token accounts, AMMs) into usable products — best-price swaps, lending markets, liquid staking, leveraged trading — and gives the user a single trusted vault (the wallet) that signs specific transactions and reads their balances directly off the chain.
• What are the trade-offs? Composability is the whole value and the whole danger: sharing programs and oracles means a new venue works everywhere for free, but a failure in one layer (a buggy program, a bad oracle, a depeg) propagates into everything stacked on it.
• When should I avoid it? Avoid treating any named protocol as an endorsement or any TVL/ranking as durable — all of it is point-in-time and volatile. Avoid using a protocol whose dependencies you cannot name (its oracle, its underlying programs), and avoid signing a transaction whose instructions your wallet cannot show you in terms you understand.
• What breaks if I remove it? Remove the wallet and there is no way for a human to hold a key and sign — the chain is unusable by people. Remove composability (shared programs) and every protocol becomes an island with private storage, which is exactly the Ethereum contract-per-app model this whole part exists to contrast against.

Check your understanding

1. A DEX aggregator holds no liquidity of its own. What does it do, and why is it the clearest example of composability on Solana?
2. A lending protocol relies on two mechanisms to lend safely without a human underwriter, plus one external input. Name all three and say what each is for.
3. Liquid staking hands you an LST in exchange for staked SOL. What is an LST mechanically, why can every other DeFi protocol use it immediately, and what new risk does holding it introduce?
4. Walk through how a wallet displays your USDC balance when it stores no balances itself. Which earlier concept makes this possible with zero per-token integration?
5. The Mango Markets exploit drained $100M without breaking any cryptography. Which two protocol categories combined to make it possible, and what general lesson about composable finance does it teach?

Show answers

1. An aggregator is pure routing logic: given “spend X, get the most Y,” it splits the order across many AMM pools and orderbooks, invokes each via CPI within one transaction, and returns the best blended fill. It is the clearest example of composability because it holds nothing itself — it is valuable only because every venue shares the one SPL Token program, so combining them is just a question of which CPIs to emit.
2. Over-collateralization (a borrower locks collateral worth more than the loan, so the gap absorbs price moves); liquidation (a permissionless job where anyone can repay an under-covered loan and seize the collateral at a discount, which the protocol depends on being profitable); and an oracle (an off-chain price fed on-chain, needed because the protocol must know what the collateral is currently worth). The chain cannot produce a price by itself, which makes the oracle the soft underbelly.
3. An LST is an ordinary SPL token minted by a liquid-staking program to represent your staked SOL and its accruing rewards; the program stakes the underlying SOL for you. Every DeFi protocol can use it immediately because it is a normal SPL token — the shared token program means lending markets, AMMs, and collateral systems already understand it with zero integration. The new risk: you now depend on the LST program’s staking logic and the market treating the LST as worth its backing — if confidence drops, the LST can depeg from the SOL it represents.
4. The wallet stores nothing; it derives and reads. For each mint, it computes the Associated Token Account address as a PDA from (your wallet, the token program, the mint), then reads that single account’s amount field. Because the ATA address is a pure function of your key and the mint — no registry, no lookup — any wallet can display any token instantly. The enabling concept is the deterministic ATA / Program-Derived Address.
5. Lending/borrowing composed with perpetual futures, both trusting the same oracle. The attacker used a leveraged perp position and manipulated the spot price of a thin token so the oracle reported an inflated value, letting them borrow out the treasury against phantom collateral. Every step worked as designed; the failure was the composition. Lesson: a protocol is only as safe as its dependencies, and an oracle is a dependency the chain’s own guarantees do not cover — composable finance propagates a single bad input across everything stacked on it.