From March 2020 to October 2026, every Solana block was stamped by a counter that never stopped. One processor core on the leader’s machine took a SHA-256 hash, hashed the result, hashed that result again and kept going: about two million times per 200-millisecond slot under the parameters of October 2026. That chain of hashes was Solana proof of history, and it let thousands of machines that did not trust each other’s watches agree on what came first and whose turn it was to build the next block.
On 21 October 2026 at 13:36:05 UTC, at slot 459,648,000, the Alpenglow feature gate activated on mainnet, and about 18 minutes later the network handed consensus from Tower BFT to a new voting protocol called Votor. Anza, the developer of the Agave validator client, now writes on its Alpenglow page that “Proof of History is gone.” Almost. A single-hash tick still closes every block, a leftover the migration proposal keeps because removing it would be “a load of risky work.”
This lesson explains what the clock did, what Solana built around it, why both were retired and who runs the network as of 8 November 2026. It follows our lesson on BFT consensus, Tendermint and HotStuff, which showed how classical voting protocols reach a two-thirds quorum. A reminder from the lesson on finality and reorganisations: Solana exposes three commitment levels (processed, confirmed, finalized); under Tower BFT, finalized meant 31 confirmed blocks on top, about 12.8 seconds at 400-millisecond slots, and Alpenglow merged confirmed and finalized into one step. This lesson goes one layer down, to the clock under those levels and the machinery that replaced it. If quorums and Byzantine faults are new to you, start with the Byzantine generals problem.
Solana proof of history: a hash chain that counts time
Distributed systems have no shared clock. Every server keeps its own time, drifts and can lie about it. Bitcoin avoids the question by ordering transactions only when a miner finds a block; classical BFT protocols order them through rounds of messages. Anatoly Yakovenko’s white paper, which describes version 0.8.14 of the design, proposed a third route: write a verifiable record of elapsed time into the ledger itself. In the words of its abstract, “PoH is used to encode trustless passage of time into a ledger”.
Sequential to produce, parallel to verify
The mechanism fits in one line. Take a value, hash it with SHA-256, feed the output back in as the next input and keep a counter beside it. Each step needs the previous output, so nobody can compute hash number one million without first computing the 999,999 before it, and adding processors does not help: the work cannot be split. A long chain is therefore evidence that a known amount of computation, and so roughly a known amount of time on known hardware, has gone by.
Checking it is another matter. A verifier who receives the chain with intermediate checkpoints, say the outputs at counts 200, 300 and 400, can hand each segment to a different core and confirm them all at once, since each segment starts from a published hash. The white paper’s example splits the sequence across a graphics card with 4,000 cores. Production runs on one core, verification on thousands, and that asymmetry is the whole idea: what cryptographers call a verifiable delay.
It is easy to confuse with proof of work, which also burns hashes. A Bitcoin miner searches in parallel for a lucky hash below a target, and more machines mean more chances; the earlier lesson of this path on hashrate and mining difficulty shows how that race is measured. The PoH generator searches for nothing. There is no lottery and no reward for running a second generator, only a counter that has to keep counting.
Stamping transactions into the sequence
To record an event, the generator mixes the hash of the data into the chain: the next output becomes the hash of the previous output combined with the data’s hash. From then on anyone can show two things. The data existed before the following entries, because they were computed from it. And it was added after the previous entry, because inserting it earlier would change every hash downstream. Order is fixed without any message between nodes.
What the chain gives is order and spacing, not dates. A gap of two million hashes says that much sequential work separates two events; it does not say whether that took 200 or 300 milliseconds, because hashing speed depends on the chip. The block times that explorers display never came from the hash chain. Under Tower BFT, validators attached their own wall-clock timestamps to their votes, and Anza’s design notes for its timestamp oracle describe a stake-weighted mean of those reports.
What the white paper promised
The paper paired the clock with a consensus algorithm; it never claimed to replace one. Its abstract says PoH can reduce messaging overhead when used alongside proof of work or proof of stake, leading to sub-second finality. It also ran a throughput analysis on a 1 gigabit-per-second network: divide that bandwidth by 176-byte transactions and you get the famous 710,000 transactions per second, a theoretical ceiling set by bandwidth, not a figure ever measured on mainnet.
Two names that every Solana explainer uses, Tower BFT and Turbine, do not appear in version 0.8.14 of the paper. The voting protocol it sketched was a different proof-of-stake design built to recover from network partitions. What shipped on Solana in 2020 grew out of that paper but differed from it, which is one reason so many descriptions of “how Solana works” mix up the parts.
Proof of history is not consensus, and not a timestamp service
The most common mistake about Solana sits in the question “is it proof of stake or proof of history?”, as if the network had picked one over the other. Solana has always been a proof-of-stake chain. SOL staked to a validator decides how often it leads, how much its vote weighs and what it earns; our lesson on proof of stake in depth explains those mechanics on Ethereum, and the lesson on validators, slashing and rewards covers how operators are paid and penalised. PoH answered a different question: in what order did things happen, and is it really your turn? Deciding which blocks count was always the job of a separate vote.
The second mistake is to treat the hash chain as proof of real-world time. Nobody checks PoH against UTC. A leader with a faster chip simply hashes faster, and the protocol handled that by fixing the number of hashes per tick and changing it when needed. That is why SIMD-0525, the proposal behind the faster slots of 2026, lowered the hashes per tick from 62,500 at 400-millisecond slots to 31,250 at 200 milliseconds: the count was calibrated to an expected duration, never checked against one.
Slots, leaders and epochs: a schedule everyone can compute
The leader schedule
Solana divides time into slots and slots into epochs of 432,000. For each epoch every validator computes the same leader schedule from the stake distribution, so leadership is shared in proportion to stake. Anza’s documentation describes the schedule as computed one epoch ahead and, in the design used before Alpenglow, seeded from the PoH tick height. Each leader gets four consecutive slots. A sample of 24 slots read from the public mainnet RPC on 8 November 2026 showed exactly that pattern, with one leader holding eight slots because the draw gave it two windows in a row.
This is where PoH did its daily work. Each slot was 64 ticks, each tick a fixed number of hashes. A leader could not start early, because its first block had to continue the hash chain from the end of the previous slot. If the previous leader stayed silent, the next one had to hash through the empty slot to prove that the time had passed before taking over. The clock enforced turns without any round of messages asking for permission.
Slot time cut from 400 ms to 200 ms in four steps
For most of its life Solana targeted 400-millisecond slots, and many explainers still say so. That figure is out of date. SIMD-0525, written by Brennan Watt of Anza, cut the target in four feature-gated steps between August and October 2026 while keeping 64 ticks per slot, four-slot leader windows and 432,000-slot epochs. Each gate takes effect one epoch after it activates, and the chain’s own block times show every step: the average slot fell from about 416 to about 366 milliseconds in the epoch that began on 21 August, and the same drop shows at each later step. Per-slot limits such as compute units per block were cut in proportion so that capacity per second stays roughly the same.
| Target slot | In effect from (2026, first slot of the epoch) | Nominal epoch | Leader window | Hashes per tick before Alpenglow | Measured average slot |
|---|---|---|---|---|---|
| 400 ms | until 21 August | 48 hours | 1.6 s | 62,500 | about 416 ms (epochs 1016-1019) |
| 350 ms | 21 August, 07:45 UTC (epoch 1020) | 42 hours | 1.4 s | 54,687 | about 365-367 ms (epochs 1020-1023) |
| 300 ms | 28 August, 15:25 UTC (epoch 1024) | 36 hours | 1.2 s | 46,875 | about 315-317 ms (epochs 1024-1036) |
| 250 ms | 18 September, 05:06 UTC (epoch 1037) | 30 hours | 1.0 s | 39,062 | about 266-269 ms (epochs 1037-1052) |
| 200 ms | 9 October, 14:40 UTC (epoch 1053) | 24 hours | 0.8 s | 31,250 | about 212-218 ms (epochs 1053-1079) |
Slots run a little slower than the target, as they always did. The public RPC’s performance samples on 8 November 2026 showed 277 to 284 slots per minute, about 211 to 217 milliseconds each. SIMD-0525 gives the motivation plainly: shorter slots cut confirmation times, and a leader window of 0.8 second instead of 1.6 halves the time a leader can delay or reorder transactions before the next one takes over. One side effect for users: a recent blockhash, which a transaction must reference, expires after 150 blocks, so a signed transaction now goes stale in about 30 seconds instead of about a minute.
How a block became final under Tower BFT
Votes with doubling lockouts
Tower BFT was Solana’s adaptation of practical Byzantine fault tolerance to the PoH clock. Validators voted on the blocks they saw, as ordinary on-chain transactions, and every vote carried a lockout: a promise not to vote for a conflicting fork for a certain number of slots. According to Anza’s Tower BFT documentation, each new vote doubled the lockouts of the earlier votes in a validator’s tower, so a vote’s commitment grew 2, 4, 8, 16 slots and on as more votes stacked on top. After 32 votes the oldest reached a lockout of 2 to the power of 32 slots, left the tower and its block became that validator’s root.
Two safety rails stopped validators from locking themselves onto a losing fork. Before committing deeper, a validator checked that its vote eight positions down the tower was backed by two thirds of the stake. To switch to another fork, it needed proof that more than 38 percent of the stake was already elsewhere. PoH is what made lockouts enforceable: they were counted in slots, slots were counted in ticks, and nobody could shorten a lockout by claiming that time had passed without showing the hashes.
Optimistic confirmation and the 12.8-second gap
Wallets did not wait for roots. A block voted by two thirds of the stake counted as confirmed within about a second, while full finality took 32 slots. Alpenglow’s own proposal, SIMD-0326, is blunt about its predecessor: Tower BFT “does not have a security proof, which is concerning.” It was also expensive. Validators paid about 1 SOL a day each in vote transaction fees, according to the same document, and those votes competed with user transactions for space in every block.
Turbine and Gulf Stream: moving blocks and transactions
A leader producing a block every few hundred milliseconds cannot send it to each of several hundred validators in turn. Turbine, Solana’s block propagation layer, cuts each block into small packets called shreds, adds erasure-coded recovery shreds so a block can be rebuilt even when some packets are lost, and pushes each shred through a tree of validators in which nodes with more stake sit closer to the leader. Anza’s documentation says the tree is reshuffled for every shred. Turbine still carries blocks today: its planned replacement, Rotor, is not live.
Gulf Stream was the original name for a second idea: no public waiting room. Because the leader schedule is known in advance, RPC nodes forward transactions straight to the current and next leaders instead of gossiping them across the network, as Bitcoin and Ethereum do with their mempools and fee markets. Later upgrades moved those connections to the QUIC protocol and added stake-weighted quality of service, which reserves more of a leader’s inbound capacity for traffic relayed by staked validators. The name barely survives in the code; the forwarding model does.
Alpenglow: the vote that replaced Tower BFT and the clock
Alpenglow was designed by Quentin Kniep, Kobi Sliwinski and Roger Wattenhofer and specified for Solana in SIMD-0326. Solana’s stake-weighted governance vote approved it in early September 2025 with about 98 percent of the votes cast in favour, according to Blockworks. Anza’s page, dated 5 November 2026, lists testnet activation on 24 September and devnet on 25 September, ahead of mainnet. SIMD-0326 covers the voting half, Votor. The block-spreading half, Rotor, is due to get its own proposal later.
Votor: one round at 80 percent, or two at 60
Under Votor, each validator runs a local timer for the current slot. If a valid block arrives in time, it votes to notarize that block; if not, it votes to skip the slot. Votes are no longer transactions. They travel directly between validators and are aggregated into compact BLS signatures called certificates. If 80 percent of the stake notarizes a block in that first round, the block is final at once, which the specification calls fast finalization. If only 60 percent does, validators run a second round, and 60 percent of finalize votes completes the job.
SIMD-0326 defines five certificates: notarization, skip, finalization, fast finalization and notar-fallback. The fallback votes let the network recover when the first round splits. There are no lockouts and no 32-vote tower: when a block is finalized, all its ancestors are finalized with it and slots missing from its chain are treated as skipped.
The price is a different fault model. Classic BFT protocols, including the Tendermint family of the previous lesson, stay safe with up to one third of Byzantine stake. Alpenglow’s authors chose what they call a 20+20 model: correct operation with up to 20 percent of stake acting maliciously plus another 20 percent simply offline. The proposal says it gives up the 33 percent Byzantine bound in return for single-round finality and 40 percent crash resilience, and argues the trade is worth it.
What changed for validators
With votes off chain, vote fees disappeared. To keep the economics roughly where they were, Alpenglow added a Validator Admission Ticket, deducted before each epoch and burned rather than paid to anyone. It equals 80 percent of the old vote cost, about 0.8 SOL per day. SIMD-0525 scales it with slot time so the daily cost does not change: 1.6 SOL per 48-hour epoch at 400 milliseconds, 0.8 SOL per 24-hour epoch at 200. The active set is capped at the 2,000 validators with the most stake, far above today’s count. Rewards go to votes that a leader includes in aggregates eight slots later, and a validator that earns nothing in an epoch leaves the active set.
One trace of this is visible from outside. In each of the three one-minute performance samples the public RPC returned on 8 November 2026, about 50,000 transactions, the count of non-vote transactions equalled the total. Under Tower BFT the total included the vote transactions. It is a quick check, not an audit, but it matches votes that no longer travel inside blocks.
The hand-off of 21 October 2026
Switching consensus on a live network without undoing confirmed payments was the hard part. SIMD-0384, the migration proposal, set the boundary 5,000 slots after the feature activation, at slot 459,653,000. From there blocks carried only votes until one block won strong optimistic confirmation from 82 percent of stake. Validators then signed a genesis vote for the last Tower BFT block before the boundary, and 82 percent of those votes formed the genesis certificate. Blocks after the genesis block were discarded, which was safe because they held no user transactions, and Alpenglow took over.
On mainnet, the gate became active at slot 459,648,000, which the chain dates 13:36:05 UTC on 21 October 2026. Slots 459,653,000 to 459,653,007 produced no block; the first block after the boundary, slot 459,653,008, carries 13:54:03 UTC, about 18 minutes after the gate. The 82 percent threshold comes with a short proof in the proposal: with at most 19 percent of stake malicious, two conflicting certificates cannot both reach 82 percent, and the 63 percent of honest stake that remains is enough to run Alpenglow.
What is left of proof of history
Anza’s page puts the replacement in one line: “Every node runs its own timers and independently identifies a silent leader.” A slot whose leader stays quiet ends with a skip certificate. SIMD-0326 says of these timeouts: “Their purpose is akin to Proof-of-History, but without any notion of synchronized time.” Clock drift no longer matters: the proposal notes that tolerating 5 percent drift only means making the timeouts 5 percent longer.
The exact residue is written in SIMD-0384 (its repository page still showed it as under review on 8 November 2026, so read it as the specification, not as a code audit). Once Alpenglow blocks began, the tick producer was put into a low-power mode of one hash per tick, the bank’s tick height is set just short of its maximum before each block ends, and one final tick closes every block so the software that packs transactions and broadcasts shreds knows the block is over. Tick verification was switched off. SIMD-0525 adds that hashes per tick must not be lowered while Alpenglow runs, its low-power path being “currently expected to be one hash per tick.”
So a 200-millisecond slot that carried 2 million sequential hashes in mid-October now ends with one hash that proves nothing about time. The function names survive in the code; the clock does not. Leaders are still assigned in advance by stake, in windows of four slots, as the RPC sample shows; which seed the schedule has used since the switch is not stated in Anza’s public documentation.
Targets that are still targets
Two headline numbers need care. Anza’s May 2025 announcement put Alpenglow’s median finality at about 150 milliseconds, sometimes 100, from simulations on the stake distribution of the time. No independent measurement of mainnet finality since 21 October had been published as of 8 November 2026, so 150 milliseconds is the design target, not an observed result. Rotor, which Anza says will replace Turbine’s multi-layer tree with a single relay hop, is listed under what comes next.
| Tower BFT (until 21 October 2026) | Alpenglow Votor (since then) | |
|---|---|---|
| Votes | on-chain transactions with lockouts | sent directly between validators, aggregated as BLS certificates |
| Final when | 32 votes deep (rooted); confirmed at two thirds of stake | 80% notarize in one round, or 60% in two rounds |
| Typical time | about 12.8 s at 400 ms slots | about 150 ms median, design target |
| Fault model | under one third Byzantine | 20% Byzantine plus 20% offline |
| Timing | PoH hash chain, 64 ticks per slot | local timeouts; one closing tick of one hash |
| Cost of voting | about 1 SOL per day in fees | admission ticket of about 0.8 SOL per day, burned |
| Validator cap | none | 2,000 highest-staked |
| Block spreading | Turbine | Turbine (Rotor planned) |
Why the outages mattered more than the clock
Solana’s reputation problem was never the speed of its clock. It was the network stopping. Six full halts between September 2021 and February 2024 lasted from about four and a half to about 20 hours each, and they help explain why validators accepted both a second client and a complete replacement of consensus.
| Date (UTC) | Approximate duration | What happened |
|---|---|---|
| 14-15 September 2021 | about 17 hours | bot transactions flooding the Grape Protocol token sale on Raydium exhausted validators’ memory; restart coordinated by operators |
| 30 April-1 May 2022 | about 7 hours | bots competing to mint NFTs through Metaplex’s Candy Machine flooded leaders; validators ran out of memory; restart completed about 03:00 UTC |
| 1 June 2022 | about 4.5 hours | a bug in the handling of durable nonce transactions split validators; halted about 16:30 UTC, restarted 21:00 UTC |
| 30 September-1 October 2022 | about 8 hours | a misconfigured hot-spare node produced duplicate blocks and a bug in fork selection stopped block production; halted 22:41 UTC, restarted about 07:00 UTC |
| 25-26 February 2023 | close to 20 hours (press estimates) | finalization degraded during the upgrade from version 1.13 to 1.14; restart on 1.13.6, first attempt abandoned |
| 6 February 2024 | about 5 hours | infinite recompile loop in the program cache of v1.17; finalization halted 09:53 UTC, resumed 14:55 UTC |
6 February 2024, the last full halt
The Anza report on the February 2024 outage traces it to the cache that stores just-in-time compiled programs. A program using a legacy loader, deployed in a particular sequence, sent validators into an endless recompile loop. More than 95 percent of the stake ran the same v1.17 release, so almost every validator stalled on the same block, nobody voted, and finalization stopped at 09:53 UTC. Engineers shipped v1.17.20 with a targeted fix around 12:34 UTC, and consensus resumed at 14:55 UTC after a coordinated restart. A similar bug had hit devnet a week earlier.
The 2021 halt was different in kind. The Solana Foundation’s initial overview described bots flooding a token sale until validators ran out of memory, and engineers needed about 14 hours to write a fix and coordinate a restart. Load, not a single code path, was the trigger. The same pattern returned on 30 April 2022, when NFT minting bots swamped the network for about seven hours, and later upgrades to how leaders accept transactions, the QUIC and stake-weighted changes described above, targeted that weakness.
1,000 days without a halt, and one client too many
No full halt has been reported since. Crypto Briefing counted 1,000 consecutive days without a network halt around 2 November 2026, and wrote that Solana’s status page had shown 100 percent uptime in the months before. The status page itself listed no incident for mainnet in the two weeks to 8 November. The February 2024 episode shows the risk that remains: when nearly all stake runs one codebase, one bug stops everyone at once. Alpenglow keeps finalizing with up to 40 percent of stake crashed, per its specification, and no further; identical software tends to crash together.
That is the case for Firedancer, an independent validator client written from scratch by a team at Jump Crypto. Its GitHub releases page lists v26.10.6 as a mainnet-ready release on 5 November 2026; Alpenglow support first reached a mainnet-ready release with v26.10.2 on 14 October. No neutral, published tracker of client shares was available as of 8 November 2026. Coindaro’s reading of the public node list that day found 92 voting nodes holding about 15.6 percent of active stake on version strings starting with “26.”, which match Firedancer’s year-and-month numbering, while nodes on “4.” versions, the Agave line and forks of it such as Jito’s client, held about 83.5 percent. Six more ran “0.” versions, the numbering of Frankendancer, a hybrid that pairs Firedancer’s networking with Agave’s runtime, for about 0.6 percent. That split is Coindaro’s inference from version labels, not a figure published by the developers.
Who runs Solana as of 8 November 2026
Alpenglow’s thresholds make stake concentration easy to read: 20 percent is the malicious budget of its fault model, 40 percent the crash budget, 80 percent the fast path. The table counts vote accounts, from the largest down, needed to reach each line.
| Measure (public RPC, 8 November 2026, about 10:00 UTC) | Value |
|---|---|
| Vote accounts with active stake | 697 (662 voting, 35 delinquent) |
| Active stake | about 434.8 million SOL |
| Largest vote accounts holding 20% of stake | 8 |
| Holding one third | 18 |
| Holding one half | 40 |
| Holding two thirds | 78 |
| Needed for 80% (fast finalization) | 141 |
| Share of the 10 largest | 24.6% |
| Nodes visible in gossip (includes RPC and non-voting nodes) | 3,843 |
A vote account is not a company. One operator can run several, and stake delegated through exchanges and staking services may answer to fewer hands than the table suggests, so real concentration can only be higher than these counts. Read with that caveat, eight vote accounts already hold the 20 percent that Alpenglow’s model treats as its malicious maximum, and the fast path needs 141 accounts to respond within the same round. Chainspect, which publishes Nakamoto coefficients for many chains, showed 17 for Solana across 664 validators on the same day, close to the 18 vote accounts in the table. For how delegation shapes these numbers on other networks, see our lesson on delegated proof of stake.
What proof of history leaves behind
Solana proof of history did one job well: it turned a hash function into a metronome that every validator could check, and it let leaders take turns without asking. It never decided which blocks were final, and since 21 October 2026 it no longer keeps time either. Local timers do that job, and votes travel off chain as certificates.
Two things are still to come. Rotor is expected to replace Turbine through its own proposal, and the 150-millisecond finality target has yet to be confirmed by an independent mainnet measurement. The next lesson of this path, consensus mechanisms compared, sets proof of history, Alpenglow and the other families side by side in one table.
