Introduction: what Solana is and how it works

If you’ve never touched blockchain — or Solana in particular — I recommend reading through this intro: a lot of the technical decisions later in the series will make much more sense afterwards.

Let’s start simple, in plain language. What is Solana? To make it really click, it’s worth explaining — at least in passing — what a blockchain is in general, and only then how Solana fits into that family and what sets it apart from other networks.

Blockchain in plain terms

Blockchain literally means “a chain of blocks”. Each block stores confirmed transactions. For every block a hash is computed — a short cryptographic fingerprint of the block’s contents; change even one byte of the input and the fingerprint comes out completely different, and there’s no practical way to fake it. That hash gets included in the next block — that’s how blocks link into a chain. You can’t quietly edit something in an old block: its hash would change, every block after it would “break”, and the network would reject the tampering immediately. In effect, every new block vouches for the authenticity of the entire history before it.

Everyone knows the words “blockchain” and “decentralized” always travel together. But where’s the decentralization here? Someone has to produce all these blocks and store them somewhere, so they turn from an ephemeral idea into something tangible. That’s the job of a network of validators — essentially ordinary servers scattered around the world, owned by different independent operators. That’s the decentralization: there’s no single owner with a kill switch to flip.

Validators come in two flavors:

• Voting validators participate in consensus — the process by which thousands of machines that don’t trust each other agree on a single version of history. They vote on blocks and take turns producing new blocks themselves.
• Non-voting nodes (RPC nodes) are the network’s operational support. They’re how people submit transactions and read the network’s state — the “front doors” (entrypoints) into the blockchain. They also often work as indexers, keeping the transaction history around.

How Solana produces blocks

In Solana, time is sliced into slots of ~400 milliseconds. In each slot exactly one validator — the leader — collects transactions and produces a block. Leaders rotate constantly (each one gets 4 slots in a row, i.e. ~1.6 seconds).

To keep this whole carousel spinning fast, Solana uses several signature technologies:

• Proof of History (PoH) — a cryptographic “clock” that lets you provably order events in time without waiting for all the nodes to agree with each other first.
• Tower BFT — the mechanism by which validators vote on blocks, built on top of PoH.
• Turbine — the block propagation protocol: the leader slices a block into small pieces (shreds) and fans them out across the network.
• Gulf Stream — Solana has no public mempool. In most blockchains (Bitcoin, Ethereum) pending transactions sit in a public waiting room — the mempool — where every node can see them before they land in a block. In Solana, transactions are instead forwarded directly to the current and upcoming leaders. Remember this fact — it’ll matter again below.

Who signs what: processed, confirmed, finalized

Here’s a point people constantly get confused about. It’s not the validator that signs a transaction — it’s the sender, with their private key. (Every wallet is really a keypair: a private key you keep secret and use to produce a signature, and a public key anyone can use to verify that signature — proof the transaction really came from you, without you ever revealing the secret.) Validators, meanwhile, don’t vote on individual transactions — they vote on whole blocks. And the “weight” of a vote isn’t measured in node count but in the share of stake (staked SOL — coins locked up as skin in the game) behind those nodes.

From this follow the three commitment levels you’ll run into constantly when working with the network:

• processed — the transaction made it into a block that was processed by the node you happened to ask. The block can still fall off in a fork — a brief moment when two competing versions of the chain exist and one of them gets discarded.
• confirmed — a supermajority (⩾2/3) of the network’s stake has voted for the block. This is “optimistic confirmation”: in practice, rollbacks from this level don’t happen.
• finalized — 31+ confirmed blocks have been built on top of the block (the block is “rooted”). Takes ~12.8 seconds. This one really is forever.

Right now this may look like a pile of useless trivia, but the moment you start interacting with the network it all falls into place: you’ll be choosing one of these levels in nearly every RPC request.

What’s in it for validators?

The obvious part — rewards:

• staking commission: delegators — regular SOL holders who don’t run any servers themselves — stake their SOL on a validator and earn inflation rewards (newly minted SOL the network issues on a schedule to pay for its own security), while the validator takes a cut (the commission);
• block rewards: the base transaction fee is split in half — 50% is burned, 50% goes to the leader — while the priority fee (an optional extra you pay to jump the queue) has gone entirely to the leader since 2024 (see SIMD-96);
• MEV tips via Jito — extra payments from traders and bots for guaranteed inclusion and ordering of their transactions.

But there’s also a big expense line few people know about: a voting validator pays a fee for every vote transaction, and that adds up to roughly ~1 SOL per day (300+ SOL a year). That’s exactly why it’s hard for a small validator to break even on rewards alone, so validators pick up side income, for example:

• selling the Shred Stream — the raw feed of shreds, i.e. the contents of the block being produced right now;
• running custom clients that let them reorder transactions during their own leader slot before writing the block — for arbitrage (profiting from price gaps between markets) and sandwich attacks (wedging your own trades right before and after someone else’s to profit off the price move they cause). This is what’s called MEV — “maximal extractable value”, the profit you can squeeze out purely by choosing and ordering transactions.

Who needs the Shred Stream, and why

Obviously, someone who needs a speed advantage. It’s less convenient and more expensive than a regular RPC connection — but in many cases it pays for itself very fast.

Remember that Solana has no mempool? That means there’s nowhere to “peek at” other people’s transactions before the block. The earliest place you can see them is the shreds of the block the leader is producing right now. By receiving that stream directly (say, by placing your server next to a validator), you see the block’s contents tens to hundreds of milliseconds before it reaches ordinary RPC nodes and gets confirmed.

Say you run a trading bot and want to react to events before everyone else. Or you’re copy-trading someone’s wallet — which only works if you enter the position right behind them. A high priority fee raises the odds the leader includes your transaction earlier (and Jito bundles let you outright lock in the exact ordering of transactions within a block). In short, speed is everything: with instant reactions, almost any strategy starts to work. That’s why people pay serious money for Shred Stream access.

But even here it’s not that simple: shreds are broadcast by the current leader, and leaders change every 4 slots.

How do you know who the leader will be?

Solana has an RPC method, getLeaderSchedule, that returns the leader schedule. The schedule is computed in advance for an entire epoch (432,000 slots, ~2–3 days), so who produces blocks and when is known ahead of time.

Who gets how many slots? The selection is pseudo-random but stake-weighted: the more stake behind a validator, the higher its odds of being leader. And it’s not just the validator’s own SOL that counts, but all the delegated SOL too — so validators also compete for delegators’ trust. But broadly, yes: the more money you have (and the more people trust you), the more money you make.

Just like real life.

Blocks are history, accounts are state

Almost forgot something important. Besides the transaction history, Solana has state: accounts holding balances and data, and programs — Solana’s word for smart contracts, i.e. code deployed on the chain that runs whenever transactions invoke it and manages that state. And here newcomers often get tangled up: do accounts live in blocks too?

No. Only transactions get written into blocks. A blockchain is a changelog: “who did what, in what order”. The state — a big “address → account” database — lives locally on every validator (in the so-called AccountsDB), and each node builds it itself by applying transactions from the blocks, one after another. A good analogy is git: blocks are commits, and the accounts database is the working directory, which you can reconstruct by replaying all the commits in order. Convergence is guaranteed by consensus: when validators vote on a block, they’re effectively voting on a hash that has a digest of the state changes mixed into it — if someone’s node computed the state differently, its hash won’t match the majority’s.

Two non-obvious things follow from this:

• Snapshots. Replaying the entire history from genesis — the network’s very first block, block zero — every time you start a node would be madness, so a new validator downloads a snapshot from its peers — a ready-made image of the state at a recent slot — and only replays the fresh blocks on top.
• Not everyone stores history. Ordinary validators prune their ledger, keeping only a recent tail of blocks. The full history from genesis is kept by dedicated archive nodes — and that’s exactly the “indexer” role of RPC nodes I mentioned above. Which is why looking up a year-old transaction doesn’t work on just any node, and archive RPCs are expensive.

One more thing: “Solana” isn’t a single network but several clusters:

• mainnet-beta — the live network with real money;
• devnet — a sandbox for developers: the same thing, but SOL there is free (handed out via airdrop — you just ask the network and it credits you test SOL) and worth nothing;
• testnet — a proving ground where the core dev teams shake out new releases; you usually don’t need it for applications;
• localhost — a local test validator on your own machine, ideal for program development.

What’s next

I think you now have a more-or-less sufficient picture of what this system is and how it’s put together. In the next part we’ll get practical: set up the tooling and create your first wallet, so you have something to actually touch the network with. After that come the core concepts you can’t get anywhere in Solana without — accounts, programs, instructions, transactions. And then the most interesting part: talking to the network directly, first over HTTP RPC, then over WebSocket subscriptions where the network tells you what happened.