Solana Developer Roadmap
From Zero to Validator Infrastructure — With Projects
Six phases covering Solana's core mechanics, account model, DeFi primitives, validator internals, MEV infrastructure, and Firedancer. One production-grade Rust project per phase. Rust required throughout.
Core Solana Mechanics
Before writing a single line of program code, you need an airtight mental model of how Solana works under the hood. This phase builds that foundation — covering the six core innovations that let Solana achieve 400ms slots and sub-cent fees: PoH, Tower BFT, Turbine, Gulf Stream, Sealevel, and Cloudbreak.
Week-by-Week Plan
Proof of History & Consensus
Proof of History (PoH): a Verifiable Delay Function that acts as a cryptographic clock — the leader runs SHA-256 in a loop, producing a hash sequence that proves time has passed. Tower BFT: Solana's consensus built ON TOP of PoH — validators vote on forks and each new vote doubles the lockout period on previous votes, making it exponentially costly to switch. ~600ms optimistic confirmation. Gulf Stream: transaction forwarding protocol — because the leader schedule is known 2 epochs in advance (~2 days), clients forward directly to the upcoming leader, enabling leaders to begin executing before block production starts.
Propagation, Execution & Storage
Turbine: block propagation inspired by BitTorrent — blocks broken into shreds (~1.4KB each), reducing bandwidth from O(n) to O(log n). Sealevel: Solana's parallel smart contract runtime — every transaction declares all accounts it will read/write, the runtime builds a dependency graph and executes non-overlapping transactions simultaneously. Cloudbreak: horizontally-scaled accounts database using memory-mapped files and SSD layout designed for concurrent reads/writes. Project: Solana Hello World CLI — native Solana program in Rust with counter stored on-chain, deployed to Devnet.
Resources6
Original paper — read sections 1–4 first. The PoH formulation is the key insight.
Best single article covering the full tx lifecycle and all 8 innovations. Read before the whitepaper.
Cluster overview, leader rotation, vote accounts — official reference.
Deep dive into slots, epochs, block time, and confirmation mechanics.
Original talk where Anatoly explains PoH — 18 minutes, essential viewing.
Interactive examples for accounts, programs, transactions.
Projects
- →Solana Hello World CLI — native Solana program in Rust storing a greeting count on-chain; counter program with initialize/increment/reset instructions; Rust client using solana-client crate to deploy and interact; deployed to Devnet via solana CLI. Reference: github.com/solana-labs/example-helloworld
Account Model, Programs & the SVM
Solana's account model is its most counterintuitive concept for developers coming from other chains. Everything is an account — wallets, programs, data, and system state. This phase covers the full model: account structure, PDAs, CPIs, rent economics, the SVM runtime, and the Anchor framework. Mastering this unlocks everything else.
Week-by-Week Plan
Accounts, PDAs & CPIs
Account structure: every account has address (pubkey), lamports (balance), owner (program that controls it), data (arbitrary bytes), executable flag, rent_epoch. Programs can only write to accounts they own — runtime-enforced security. Program Derived Addresses (PDAs): deterministic addresses with no private key, derived from seeds + program_id. Programs sign for PDAs via invoke_signed. This is how every DeFi protocol stores user state. Cross-Program Invocations (CPIs): programs calling other programs — invoke() for normal calls, invoke_signed() when the caller signs on behalf of a PDA. Understand CPI depth limit (4), stack frame limits, account ownership transfer.
SVM Runtime, Rent & Anchor
Rent economics: accounts pay rent proportional to data size; accounts with ≥2 years prepaid are rent-exempt. Learn to close accounts and recover lamports — essential for non-leaky programs. The Solana Virtual Machine (SVM): verifies signatures, routes instructions to programs, handles account locking, enforces compute unit limits. Since 2024 the SVM is being modularized as a standalone crate (solana-svm). Anchor framework: generates boilerplate (account validation, serialization, IDL) — most production programs use it. Learn native programs first so Anchor's magic isn't opaque. Project: SPL Token Vault with Escrow.
Resources7
Best visual explanation of owner, data, lamports relationships.
PDA seeds, bump, canonical bump, and real-world use cases.
invoke vs invoke_signed, CPI security, stack limits explained clearly.
Reference implementations: Token, Token-2022, ATA, Memo — read the source.
Best structured course covering native + Anchor in Rust.
Projects
- →SPL Token Vault with Escrow — Anchor program; vault PDA holds SPL tokens on behalf of users; deposit and withdraw instructions via CPI to Token program; per-user state in PDAs (seeds: [user_pubkey, b'vault']); time-lock blocks withdrawals for N slots after deposit; integration tests with Bankrun or localnet. Stretch: fee-on-withdrawal to treasury PDA.
Advanced Programs — DeFi Primitives
This phase covers the patterns behind every major Solana protocol — Serum, Raydium, Marinade, and Drift are all variations on these primitives. You go from 'can build' to 'builds production'. Versioned transactions, compute unit optimization, Address Lookup Tables, Token-2022, order book mechanics, and oracle integration.
Week-by-Week Plan
Transaction Anatomy & Compute
Transaction anatomy: signatures array, message (header + account keys + recent blockhash + instructions). Instructions are (program_id, accounts[], data). Versioned transactions (v0) add Address Lookup Tables (ALTs) allowing 64+ accounts per tx instead of the default 32–35. Compute units: each instruction consumes CUs, default limit 200k, max 1.4M. Use ComputeBudgetProgram to request more CUs and set priority fees (microlamports per CU) — critical for MEV resistance. Address Lookup Tables: store frequently-used account addresses on-chain, reference by index in v0 transactions. Essential for DeFi where a single swap may touch 20+ accounts.
Token-2022 & Oracle Integration
Token-2022 (Token Extensions): next-gen token program with built-in features — transfer fees, confidential transfers, interest-bearing tokens, permanent delegate, non-transferable tokens. Most new protocols launch on Token-2022. Oracle integration: Pyth Network and Switchboard provide price feeds as on-chain accounts updated every 400ms. Learn to read PriceUpdateV2 accounts in your programs — critical for lending, perpetuals, and options.
Order Book Mechanics & Project
Order book mechanics (Serum/OpenBook): how a central limit order book (CLOB) works on-chain — bids/asks in slab data structures, event queue for fills, cranking mechanism. OpenBook v2 is the reference impl. Project: On-chain Limit Order Book — users place limit buy/sell orders in PDAs, a crank instruction matches orders when prices cross, settlement moves tokens via CPIs. Uses ALTs for complex match transactions.
Resources6
Transaction format, versioned txs, ALTs, CU optimization — comprehensive.
microlamports, fee estimation, landing txs reliably — essential for production.
Best reference CLOB implementation on Solana — read the state structs.
Integrate price oracles into your on-chain programs.
Curated index of all major Solana technical resources — bookmark this.
Projects
- →On-chain Limit Order Book — Anchor; Market PDA (base/quote mint, fee rate, authority); Order PDA (seeds: [market, user, order_id], stores side/price/size/filled); place order CPIs Token program to lock collateral; match instruction finds crossing orders and emits FillEvent; cancel + withdraw closes PDA and reclaims rent. Uses Address Lookup Tables so a match transaction fits in one tx. Stretch: Pyth oracle for market orders at current price.
Validator & RPC Node Infrastructure
This phase shifts from writing programs to running the network. You'll learn what a validator does second-by-second — the full Agave client pipeline from QUIC receive through TPU, Banking Stage, PoH service, Turbine broadcast, and TVU replay. Then set one up and monitor it.
Week-by-Week Plan
TPU, TVU & Banking Stage
Transaction Processing Unit (TPU): processes incoming transactions when the validator is the leader. Pipeline: QUIC receive → SigVerify (GPU-accelerated) → Banking Stage (parallel execution) → PoH service → Broadcast (Turbine). Transaction Validation Unit (TVU): processes incoming blocks when NOT the leader — receives shreds via Turbine, reconstructs blocks, re-executes transactions to verify, and votes. Banking Stage: 6-thread pipeline (4 non-vote + 2 vote threads); since Agave 1.18 uses a central scheduler that builds non-conflicting transaction batches.
Hardware, Leader Schedule & RPC
Leader schedule: determined at epoch start (~2 days) by stake-weighted randomized selection — validators know 2 epochs ahead, enabling Gulf Stream pre-forwarding. Hardware requirements (2025): 512GB+ RAM (1TB recommended), AMD EPYC or Intel Xeon, NVMe SSD 2TB+, 1Gbps+ network. Validator vs RPC node: a validator votes, produces blocks, earns rewards, needs stake. An RPC node serves API requests (getAccount, sendTransaction, etc.) — no stake needed. Most teams run dedicated RPC nodes separate from their staked validators.
Setup, Tuning & Monitoring
Hands-on: install Agave client, configure system (CPU governor, NUMA, disk scheduler, swapfile), tune solana-validator flags (--limit-ledger-size, --no-port-check, --expected-shred-version). Monitor with solana-watchtower. Read core/src/tpu.rs and banking_stage.rs in the Agave source. Project: Validator Health Monitor — Rust CLI that polls RPC for vote account status, tracks skip rate, monitors vote account balance, and alerts on delinquency.
Resources6
Validators vs RPC nodes — best explainer, start here before touching hardware.
Step-by-step: install Agave, configure, tuning, monitoring.
Official validator setup — hardware, system tuning, configuration flags.
Source code — read core/src/tpu.rs and banking_stage.rs to understand the pipeline.
How the central scheduler works, thread model, and contention analysis.
Real-world lessons: what they don't tell you in the official docs.
Projects
- →Validator Health Monitor in Rust — CLI tool using solana-client; polls getVoteAccounts for voting status and delinquency; tracks slot height, skip rate vs cluster average; monitors vote account lamport balance; stdout/webhook alert when skip rate exceeds threshold or balance drops below minimum. Stretch: WebSocket slotSubscribe instead of polling; /metrics endpoint in Prometheus format for Grafana.
MEV, Jito, SWQoS & Advanced Infra
MEV on Solana is fundamentally different from Ethereum — there is no generalized mempool. Jito created an out-of-protocol blockspace auction. This phase covers the full MEV supply chain: Jito architecture, SWQoS, the searcher workflow, bundle mechanics, and Agave v2.0's SVM decoupling.
Week-by-Week Plan
Jito Architecture & SWQoS
Jito architecture: a fork of Agave adding Block Engine (MEV auction), ShredStream (low-latency shred relay), and Tip Distribution Program (distributes tips to stakers). ~65–70% of validators run Jito. Bundles are 1–5 transactions submitted atomically with a tip. Stake-Weighted QoS (SWQoS): implemented via QUIC in 2023 — TPU gives proportionally more connection slots to validators with more stake. Low-stake validators have harder time landing txs during congestion. QUIC protocol: switched from UDP to QUIC for transaction ingestion — provides stream multiplexing, congestion control, and the stake-weighting hook.
Searcher Workflow & Tip Game Theory
Searcher workflow: subscribe to Jito's mempool (limited access), identify arbitrage/liquidation opportunities, build bundles, submit with tips. Jito's Block Engine auctions the right to be included in the leader's block. Priority fees vs Jito tips: priority fees go to the leader as protocol revenue; Jito tips go to the tip distribution contract distributed to stakers. During congestion, both matter — a tx with high priority fee but no Jito tip may lose to a bundle with a tip. Read Jito Block Engine source and compare diffs to Agave.
Agave v2.0 & SVM Decoupling
Agave v2.0: introduced standalone solana-svm crate, new accounts index, breaking API changes for RPC providers. This is the foundation of the multi-client future. Eclipse, MagicBlock, and others are building SVM-based chains/rollups. Project: Jito Bundle Builder & Arb Scanner — monitor Raydium/Orca pools via Helius websocket, detect price discrepancies vs Pyth, construct arbitrage bundles with tips, submit to Block Engine via gRPC.
Resources6
Complete MEV landscape: Jito, sandwich attacks, REV, tips — definitive overview.
Block Engine API, ShredStream, bundle submission, searcher SDK.
SVM API changes, multi-client world, migration guide for RPC providers.
Source of the Jito fork — diff against Agave to understand what Jito adds.
TPU pipeline, leader packing, Jito block engine comparison — excellent visual walkthrough.
How SWQoS works and its implications for reliable transaction landing.
Projects
- →Jito Bundle Builder & Arb Scanner — Rust bot; Helius websocket subscribes to Raydium/Orca pool account changes; parse pool state to calculate price (x*y=k); detect deviation from Pyth reference price; construct Jito bundle [swap_tx_1, swap_tx_2, tip_tx]; submit to Block Engine via gRPC (jito-searcher-client crate); track bundle landing rate and tip efficiency. Stretch: sandwich protection by detecting large pending swaps.
Firedancer, Multi-client & The Future
The frontier of Solana infrastructure. Firedancer is Jump Crypto's complete reimplementation of the validator in C/C++, targeting 1M+ TPS. Frankendancer (hybrid Firedancer networking + Agave execution) is live on mainnet today. This phase covers Firedancer's tile architecture, Alpenglow consensus, the SVM as a modular component, and the multi-client roadmap.
Week-by-Week Plan
Firedancer Architecture
Why rewrite in C: Agave hits performance ceilings from Rust's allocator, Tokio async runtime, and original design constraints. Firedancer rewrites everything from scratch — zero-copy networking, custom memory allocator, cache-line aligned data structures. Tile architecture: the validator is decomposed into isolated 'tiles' — each tile is a single-threaded process pinned to a CPU core with dedicated memory. Tiles communicate via shared memory ring buffers (no syscalls). Tiles: net, quic, verify, dedup, pack, bank, poh, shred, store, replay, gossip. Read fd_tpu.c in the source.
Frankendancer & Alpenglow
Frankendancer: the hybrid validator — Firedancer's networking + transaction processing frontend (tiles: net, quic, verify, dedup, pack) connected to Agave's execution backend (bank, replay). Currently live on mainnet — most validators running it see 2–3x throughput improvement. Alpenglow consensus (2025): Solana's proposed replacement for Tower BFT targeting sub-150ms finality. Two-round voting protocol: Rotor for block dissemination + Votor for voting. Currently in research/testnet phase — the biggest consensus change since Solana's launch.
Multi-client Roadmap & Capstone
SVM as a modular component: the Solana VM extracted from the validator into a standalone library. Eclipse, MagicBlock, and others building SVM-based chains/rollups. Knowing SVM internals is increasingly valuable outside Solana mainnet. Multi-client roadmap: goal is no single client >33% of stake (liveness threshold) — Agave ~95%, Jito ~65% overlap, Firedancer/Frankendancer growing. Client diversity is critical for network resilience. Project: Validator Ops Dashboard — real-time TUI or web dashboard aggregating validator health, slot performance, MEV tips, and network-wide stats.
Resources6
Official Firedancer documentation and tile architecture overview.
Source code — read fd_tpu.c and the tile architecture in src/disco/.
Tile architecture, Frankendancer setup, performance benchmarks.
New consensus replacing Tower BFT — Rotor + Votor protocol for sub-150ms finality.
Ecosystem state, validator diversity metrics, upcoming protocol changes.
Technical writeups from the Firedancer engineering team at Jump.
Projects
- →Validator Ops Dashboard — Rust (ratatui TUI) or web; tracks vote success rate, skip rate, leader slot performance, epoch rewards; real-time slot data via slotSubscribe WebSocket; Jito tip revenue via tip distribution program account history; compare validator vs cluster avg using getClusterNodes + getVoteAccounts. Stretch: Firedancer tile status from metrics port; anomaly alerts using z-score detector on skip rate.