cryptoinbrief.

EN | AR Light |

By Moamen Basel, September 2026, 3 labs, about 35 minutes

Solana

Solana from zero

A clock first, consensus second, and what 400 millisecond blocks feel like.

I'm writing this like you've never touched crypto. I hide nothing here. Every mechanism gets built or simulated on the page, and every number carries its date. The three labs run real SHA-256 in your browser. Facts are current as of September 19, 2026.

01Where this sits

Fig. 1.1Three ticks of the clock this page keeps building, hashed live as you loaded it. Click to run a fresh chain. Each cell is the fingerprint of the cell to its left.

Solana is a proof of stake network. People lock up coins as collateral, called stake, and the right to append new transactions belongs to stake holders, weighted by how much they locked. Wreck the ledger and you've wrecked the value of your own collateral, so behaving is the profitable move. If staking is new to you, the proof of stake essay is the prerequisite read. This page builds on it rather than repeating it.

Solana keeps that security model and spends its ingenuity on a different question. Most networks do their hardest thinking about who writes next. Solana sweats the when. It bolts a cryptographic clock onto proof of stake, and the people who locked the coins as stake only get to vote after every event has been threaded through that clock. The clock is called Proof of History, and that's why this essay exists. You can build a working miniature of it in your browser before you finish your coffee.

The coin is SOL. Validators lock or receive delegated SOL and use that stake weight when they vote. The active validator count, stake share, and operator concentration change every epoch. This page avoids hard coding an aggregator snapshot as if it were a protocol constant. The stable fact is the trade off: running a voting validator needs a high performance server and reliable bandwidth, so operator cost is materially higher than a lightweight wallet or RPC client.

02Networks disagree about time

Before any attacker shows up, a distributed network has a mundane problem. Nobody's clock agrees. Machines drift, and messages cross the internet at variable speeds. If I pay you and pay a shop with the same coin in the same second, half the network honestly believes your payment arrived first, and both halves are telling the truth about what they saw. The double spend story at the heart of the Bitcoin essay grows from exactly this root.

Bitcoin orders by depth. Whichever chain carries the most accumulated work wins, and your payment counts as settled when enough blocks stack on top that undoing it would take absurd luck. Nothing there is ever mathematically final. A deep rewrite just becomes so improbable that nobody budgets for it. You pay in patience, since depth takes minutes to hours to accumulate. The finality math is worth a read on its own.

Ethereum's proof of stake orders by votes. Validators attest to a block every 12-second slot, and after two epochs, roughly 12.8 minutes, a checkpoint becomes final, meaning a supermajority has committed never to build on a rival. It's clean and auditable. Cadence is the cost. 12-second slots and two epoch finality put a floor under how fast the chain can absorb events. The mechanics are in the staking essay.

Solana's bet is different. If ordering is the bottleneck, stop voting on order after the fact and carry the order inside the data itself. Events get hashed into one serial stream where position is time. Then the claim that my payment came first stops being an argument. It becomes a checksum anyone can verify in one pass. The rest of this page is what that sentence costs in practice.

Two honest nodes receive the same two payments in opposite orders one coin, two payments, same second - arrival order is latency, not truth node 1 pay shop 1 SOL arrived 1st pay Alice 1 SOL swears: shop first node 2 pay Alice 1 SOL arrived 1st pay shop 1 SOL swears: Alice first PoH threads both payments into one stream, the order stops being an argument
Fig. 2.1The double spend root. Both nodes tell the truth about what they saw; Solana turns the argument into a checksum.

03A clock made of hashes

The Proof of History loop: hash the previous output, forever h (n-1) previous output SHA-256 one round h (n) becomes the next input, immediately tick 12,344 position in the stream = lower bound on elapsed time
Fig. 3.1The whole machine: hash the previous output, use the result as the next input, and never stop. The tick counter is just how far you have come.

Take SHA-256, the fingerprint function the Bitcoin essay hammers on. Feed it a starting value. Hash the output. Hash that output. Keep going. That loop, proposed in the 2017 Solana whitepaper, is Proof of History: each output is the fingerprint of the one before it, so the sequence can only be built front to back, one step at a time.

Now the trick. Each hash takes a small, irreducible amount of computation, and each one needs the previous result as its input, so the loop cannot be parallelized or skipped ahead in. If the stream you hand me is 5 million hashes long, at least 5 million sequential hashes ran before you could show it to me. The count is a lower bound on elapsed time. That is the entire idea: a clock whose ticks anyone can verify, with no trusted time server and no synchronized wristwatches anywhere.

Be precise about what this buys, because the naming misleads people. Proof of History is not a consensus mechanism and secures nothing on its own. It is a clock with a notary attached: real events, meaning batches of transactions, get hashed into the stream as it runs, so the stream answers two questions at once, roughly how much time passed and exactly which events happened in what order. Consensus, where stake votes on which stream to follow, is a separate floor built on top, and it arrives in section 6.

One honesty note. The protocol groups hashes into ticks, a fixed number of SHA-256 rounds per tick. Old documentation says 64 hashes per tick, other current sources say 128, and I could not confirm which figure is live in 2026. So the lab below runs one hash per tick and the argument never depends on the multiplier.

04The PoH ticker

LAB 01 The PoH ticker HASH 0.0s

Generates 300 ticks, one SHA-256 each, then verifies all ten 30-tick segments concurrently. Elapsed numbers measure hashing only, never the animation.

Toy scale, real hash loop. 300 ticks stand in for millions; the serial versus parallel asymmetry is the actual lesson and matches how mainnet works.

Stare at the two elapsed numbers the machine prints. Generation had to hash one output at a time, because each input doesn't exist until the previous hash finishes. Verification already knew the ending hash of every 30-tick segment in advance, so your browser checked all ten segments at once and crossed off the whole stream several times faster. Still 300 hashes either way. One direction carries a dependency chain. The other direction doesn't. That's why thousands of validators can keep up with a leader emitting blocks every fraction of a second.

Generating the stream is serial; verifying it shards across cores 300 ticks: one way to build them, another way to check them leader h0 h1 h2 h3 h4 h5 generation: hash n+1 cannot start until hash n lands, 1 lane, 300 serial rounds core 1 h 0 30 ticks h 30 core 2 h 30 30 ticks h 60 core 3 h 60 30 ticks h 90 verification: ten segments, all in flight at once, same 300 hashes
Fig. 4.1The leader hashes one tick at a time. Verifiers know every segment's endpoint in advance and check all of them at once.
Contents
  1. Where this sits
  2. Networks disagree about time
  3. A clock made of hashes
  4. The PoH ticker
  5. Slots, leaders, the schedule
  6. Tower BFT and lockouts
  7. A fork race
  8. The rest of the machine
  9. Parallel lanes
  10. What changed by 2026
  11. Solana next to Ethereum

05Slots, leaders, and the schedule

A leader schedule: rotating validators each own a slot v3 v9 v14 v3 v22 v9 v3 v14 epoch boundary v9 v22 v3 v14 v9 v3 your transaction rides the green slot: leader v22, known roughly an epoch in advance 300 or 250 ms: official status pages conflict; target 200 ms
Fig. 5.1Slots rotate through a schedule derived from stake. Everyone computes the same rotation, so a router can send your transaction straight to whoever leads next.

A slot is one leader's shot at producing a block. A leader is the validator whose turn it is, and they're picked by a schedule computed deterministically from the stake distribution roughly one epoch ahead and weighted by activated stake. You never bid here. Nobody negotiates the rotation. The schedule is arithmetic on the stake table, so every node derives the same rotation and knows far in advance who proposes when.

For most of its life a Solana slot targeted 400 milliseconds, which is what this page's subtitle is pointing at. SIMD-0525 stages reductions toward 200 milliseconds. At this page's September 20, 2026 fact check, Solana's dedicated rollout tracker and its newest changelog disagree about whether mainnet is at 300 or 250 milliseconds. The page therefore reports the conflict instead of presenting 250 milliseconds as settled fact.

An epoch is 432,000 slots, and that's the span the leader schedule covers. That is about 36 hours at 300 milliseconds or 30 hours at 250. Solana's official sources conflict at this page's September 20 fact check. The rollout tracker says mainnet is at 300 milliseconds with 250 pending, while the September 19 changelog lists the 250 millisecond gate under mainnet. I will not pick one silently. The long term target is 200 milliseconds. Stake you delegate activates at the next epoch boundary rather than instantly.

06Tower BFT and stacking lockouts

A validator's vote tower: each vote doubles the lockout of the votes below it vote 6 locked 32 slots vote 5 locked 16 vote 4 locked 8 locked 4 locked 2 each new vote on the same fork doubles the lockout below it, up to 2 to the 32 after 32 votes oldest votes expire first, first-in first-out, which is what lets a validator eventually switch forks
Fig. 6.1One validator's tower. Votes on the same fork stack expiry dates; the deeper the stack, the longer you are committed.

Proof of History orders things. It doesn't decide anything. When two validators legitimately hold different blocks for the same slot, you're looking at a vote, and Solana's voting floor is Tower BFT, described by its builders as a pipelined variant of PBFT, the classic vote in rounds family of agreement protocols, rebuilt to run on top of the clock.

Every time a validator votes, the lockout on its previous votes doubles. This is the bite. A lockout is a span of slots during which that validator cannot vote against what it already voted for, an expiry date stamped on its own opinion. Vote once and you're lightly committed. Keep voting the same fork and the stack thickens, with lockouts of 2, then 4, 8, 16 slots and beyond, doubling to a ceiling of 2 to the 32 after 32 consecutive votes, while the oldest votes drain out of the stack first in first out as they expire.

I care about two thresholds in practice. When two thirds of staked weight, a supermajority, has voted one fork, the network reports optimistic confirmation. Wallets and apps treat it as settled. Measurements reported through December 2024 put it around 6.4 seconds typical. Full finality, what the API calls rooted, waits for lockouts to harden and sat near 12.8 seconds in 2025 and 2026 reporting. You'll want both numbers. Section 10 is about to attack them.

The stack also answers a question I don't hear enough. What happens when a validator restarts? Its recent votes and their remaining lockouts are reconstructable from the ledger, since Tower votes are themselves transactions carried in the PoH stream. Replaying means rebuilding a short stack that prunes itself as lockouts expire, not re deciding history from scratch. Catch up is cheap work. It's also why the vote traffic that bloats raw transaction counts is doing real structural work.

07A fork race, weighted by lockouts

LAB 02 Two blocks, one slot FORK 0.0s

A toy network of 24 validators with weighted stake votes on two rival blocks for slot 1000. The doubling lockout rule is the real one; the population is a toy. Fixed seed, so you see the race described in the text.

Toy parameters, real arithmetic. Losing validators abstain until their lockout expires, then join the heavy fork, which is how the actual protocol resolves a split.

That's the replay, slot by slot. At slot 1000 both blocks were honestly signed, and the toy validators split about 60 to 40 based on which block reached them first. Through slots 1001 and 1002 the minority still sat on its hands, unable to switch at all, because their own votes had them locked to the fork they'd already backed. Lockouts expired at 1003. Every one of them joined the heavy fork and the race ended. Confirmation needed more than the 66.67 percent supermajority. It got 100 percent of the toy stake.

I'll tell you what didn't happen. Nobody rewrote the losing fork. Its block from slot 1000 is still there in the console, struck through and abandoned, and nothing will ever build on it, because the stake that would have built there is locked to the winner. A Solana reorganization looks like that. The losing branch stops growing and falls out of the tree. It isn't a rollback. The lockout arithmetic is what keeps the winner stable while it happens, and the tower line printed for one validator, lockouts of 2, 4, 8, 16, 32 slots, is the same stack from Figure 6.1 doing its job in the wild.

A fork race: lockouts hold the minority until expiry, then one fork stops growing one slot, two honest blocks, here is what the stake does next slot 1000 block A block B 40% 60% locked, cannot switch abandoned grows on: 1001 1002 1003 a Solana reorg: the dead branch is abandoned, never rewritten
Fig. 7.1The race from Lab 02 as a picture. Lockouts hold the minority until expiry; then the losing fork just stops growing.

08The rest of the machine, briefly

Four more parts move traffic between the slots. Every one of them leans on the clock or the schedule you already hold.

Gulf Stream and the missing mempool

There's no public waiting room. Solana has no persistent mempool, the queue where other networks park pending transactions, so routers forward your transaction directly to the upcoming leaders, whose identities the published schedule already names. The next leader can even cache the accounts your transaction will touch and start preparing before its slot begins. The mechanism is Gulf Stream. It exists only because the schedule is known ahead of time.

Sealevel, parallel by declaration

Execution is parallel by default. A Solana transaction must declare, upfront, every account it will read or write, and the runtime, Sealevel, treats those declarations as a dependency graph so transactions touching disjoint accounts execute simultaneously across CPU cores, and only genuine collisions queue. The design dates to a 2019 engineering post and still describes the runtime in 2026. Section 9 races it live.

Local fee markets and MEV

Fee pressure can stay local to writable accounts. When a crowd dogpiles one hot account, transactions that need that account compete with one another, while disjoint work can still execute in parallel. Senders can add a priority fee priced in compute units. The ordering auction itself, MEV, often runs through block building infrastructure such as Jito, where searchers bid tips for placement. If MEV is a new word, the Bitcoin essay covers it. Ordering power is the shared root of both designs.

QUIC at the door

The front door got a bouncer. Through the 2021 and 2022 bot spam outages, validators drowned in junk traffic. The fix shipped as a set of three. QUIC is a modern transport protocol with per connection flow control, which is one of those three. Stake weighted quality of service is in the same set. So are the fee markets above. Under the stake weighted rule, a sender holding 1 percent of stake can send at most about 1 percent of a leader's packets, and unstated senders share a small residual slice. Your place in line at the door is proportional to your collateral.

A transaction's path between slots: QUIC, Gulf Stream, Sealevel, local fees a transaction's path between slots, every stop leans on the clock or the schedule QUIC stake-weighted door Gulf Stream no mempool Sealevel declared accounts fee market local, not global no waiting room, no global auction: pressure lands where the accounts are
Fig. 8.1Four parts, one path. Each exists because the clock and the leader schedule are already public.

09Parallel lanes

LAB 03 Sealevel in miniature HASH 0.0s

Eight transactions with declared accounts. Pass one runs them on a single lane, one at a time. Pass two groups disjoint transactions into lanes and runs each group concurrently. Real SHA-256 work stands in for execution, 1,200 hashes per transaction.

Real conflict detection, real hashing, toy transaction set. Both passes do identical work, so the time gap is pure scheduling.

Two things jump out. The lanes never collapse to one. Eight transactions settled into three groups, and the machine names the account that forced each wait, B, C, G and friends. Both passes hashed exactly the same bytes to the same final fingerprints, so the time gap is pure scheduling. That's the honest Sealevel ceiling. The same declaration plus grouping logic runs across many cores on every validator, which is how it scales.

Throughput claims need a denominator. Solana's raw transaction counts include validator votes, while user transaction dashboards often exclude them. A stress test peak, a theoretical scheduler limit, and sustained public demand answer different questions. This page does not collapse them into one TPS number. The lab above demonstrates the architectural claim that can be checked locally: transactions with disjoint writable accounts can run in parallel, while transactions sharing a writable account serialize.

The same eight transactions on one queue, then on three parallel lanes eight transactions, same 9,600 hashes, the schedule is the only difference 1 lane T1 T2 T3 T4 T5 T6 T7 T8 serial queue: every transaction waits for the one in front, 8 hashes-chains end to end lane 1 T1 T2 T4 A B C D F G lane 2 T3 T5 T7 B C E G H lane 3 T6 T8 A D E H collide disjoint sets run together, shared accounts force the wait
Fig. 9.1The same eight transactions from Lab 03. One queue, or three lanes split by declared accounts.

10What changed by 2026

Two projects dominate the current story. One's shipping and one's arriving.

Firedancer is Jump Crypto's independent validator client, written from scratch in C. Frankendancer is the hybrid: Firedancer networking and block production paired with Agave execution and consensus. The project's mainnet report shows both client families producing blocks on mainnet, and Solana's September 19 changelog lists Firedancer mainnet release v26.08.5. Stake share changes by epoch, so this page does not freeze a percentage into prose. The lasting point is client diversity: one implementation bug is less likely to stop the whole network when independent clients carry meaningful stake.

Alpenglow is pointed at the protocol's spine. It's a proposed replacement for the entire consensus stack, Proof of History and Tower BFT both, from Anza's research division under ETH Zurich professor Roger Wattenhofer. The whitepaper first landed May 19, 2025 and was revised twice, most recently July 29, 2026. Two components do the work. Votor handles voting and finality. The fast path finalizes in a single round when at least 80 percent of stake participates. The fallback needs two rounds and 60 percent responsiveness. Both run concurrently. Rotor replaces the block distribution tree with a single layer of stake proportional relay nodes that erasure code data outward, so the leader's uplink stops being the bottleneck. The stated goal is 100 to 150 millisecond median finality, against the 12.8 second Tower baseline, while tolerating 20 percent adversarial plus 20 percent unresponsive stake.

Alpenglow is not running on mainnet as of September 20, 2026. The Solana Foundation upgrade page lists it as in development and targets roughly 150 millisecond finality. Anza's v4.3 schedule is explicitly tentative, with general mainnet adoption targeted after this page's fact check date. Until the feature gates activate, mainnet still uses Proof of History and Tower BFT.

Client diversity grows while Alpenglow remains in development who runs the chain, and what replaces its spine 2024: hybrid live Frankendancer 2025: hybrid 2025: full client Dec 25: full client 2026: live report Tower rooted 12.8 s Alpenglow target 100-150 ms, in development
Fig. 10.1Client diversity is the shipped story; Alpenglow is the arriving one. Every dot carries its date.

11Solana next to Ethereum

Drop the marketing layer. Both chains are proof of stake networks securing a replicated ledger. I care about the engineering trade offs, so the table just dumps them without flattery. Figures as of September 2026.

SolanaEthereum
To stakeDelegation can use any amount; activation occurs at an epoch boundary32 ETH minimum for solo validation; compounding validators can hold up to 2048 ETH
HardwareHigh performance server class CPU, memory, storage, and networkExecution and consensus clients can run on consumer hardware with sufficient SSD capacity
CadenceOfficial pages conflict between 300 ms and a newly listed 250 ms gate; target 200 ms12 s slots
Finality todayOptimistic around 6.4 s, rooted around 12.8 s2 epochs, about 12.8 min
Finality targetAlpenglow aims at 100 to 150 ms, not live yetNo comparable proposal
Slashing realityNo in protocol slashing currently appliedSlashable signatures trigger forced exit and stake loss
Punishment modelJailing and stake withdrawal frictionInactivity leaks plus correlated slashing penalties
ClientsHistorically Agave dominant; Frankendancer and full Firedancer now appear in mainnet reportsMultiple consensus clients, with shares that change over time
Rewards sourceIssuance, fees, and optional block builder tipsConsensus issuance plus execution layer priority fees and MEV payments

Solana buys speed with expensive hardware and tight engineering tolerances, and the bill lands on validator operators. Ethereum keeps more modest hardware requirements and slower finality, so the bill lands on latency. Solana does not currently apply in protocol slashing, while Ethereum does. Different systems choose different deterrents and failure costs.

Solana next to Ethereum: cadence on one view, finality on the other same replicated ledger, opposite bills Solana 300 or 250 ms, official pages conflict Ethereum 12 s slots optimistic 6.4 s rooted 12.8 s ETH final ~12.8 min Alpenglow 0.10-0.15 s target bars schematic, numbers real, September 2026
Fig. 11.1Cadence and finality, side by side. Solana bills the validators; Ethereum bills the latency.

If the clock idea is still rattling around, I'd go to the Sui essay, which hits the same ordering problem from the opposite end and gets its fast finality a different way. The summary page has all seven essays in one stack.