Solana can confirm a transaction in under a second and process thousands per second on its live network. The architectural feature most responsible for that speed is Proof of History. Almost every explanation of it gets one thing wrong from the start: Proof of History is not a consensus mechanism. It does not replace Proof of Stake and it does not decide which blocks are valid. What it does is solve a problem that has limited every distributed network since the first distributed systems were designed – the problem of time. This article explains what that problem is, how Proof of History addresses it, and why Solana is now replacing it with something faster.
First, the clarification: Proof of History is not a consensus mechanism
The confusion is understandable. The name follows the same pattern as Proof of Work and Proof of Stake, so the assumption that it is a third alternative to those two mechanisms is a natural one. Crypto.com, one of the most widely read crypto education platforms, labels Solana Proof of History as “SOL’s unique consensus mechanism” in its article title. That description is inaccurate, and the inaccuracy matters because it leads to a misunderstanding of how Solana actually works.
Proof of History is a pre-consensus algorithm. It runs before the voting phase begins and provides the ordering framework that makes Solana’s Proof of Stake faster. The Helius developer blog states it plainly: “Proof of History is not a consensus algorithm. More accurately, it is a component that aids in achieving consensus.” Solana still uses Proof of Stake for security, for validator selection and for finality. PoH is the cryptographic clock that tells those validators what order events occurred in, so they can skip the communication rounds that slow down every other PoS network.
Without PoH, Solana’s validators would need to exchange messages to agree on transaction ordering before processing anything – the same bottleneck that limits Ethereum’s throughput at L1. With PoH, validators can independently verify the order of events from the cryptographic record and begin processing immediately. The result is a blockchain that achieves 400-millisecond slots without validators waiting for each other.
The problem Proof of History was built to solve
To understand why Proof of History matters, you have to understand the specific problem it was designed to address. In any distributed network, nodes need to agree on what happened and in what order. The “what happened” part is handled by cryptographic signatures – a transaction either has a valid signature or it does not. The “in what order” part has no equally clean solution.
Why blockchains cannot simply trust a timestamp
The obvious answer to the ordering problem is to attach a timestamp to every block. Bitcoin does this. The Bitcoin protocol accepts a block timestamp as valid if it is greater than the median of the previous eleven blocks and less than two hours ahead of the network-adjusted time. That is a deliberately wide window because the network cannot do better: clocks on different machines drift, network latency means packets arrive at different times, and a Byzantine node – one that is actively trying to deceive – can lie about its local clock entirely.
This is what cryptographers call clock drift. Two machines that synchronised their clocks one hour ago may now disagree by several seconds, and there is no way to determine which one is correct without a trusted external time source. Blockchains specifically cannot rely on a trusted external time source because that would reintroduce the centralised authority they are designed to remove. So blockchain timestamps are approximate, loosely enforced and wide enough to accommodate the reality of distributed systems.
The wallclock timestamp approach also creates an attack surface. A validator that controls its own clock can attempt to manipulate the ordering of transactions by lying about when it received them. The wider the acceptable timestamp window, the more room exists for this manipulation.
The cost of waiting for agreement
The consequence of unreliable timestamps is that blockchains must rely on communication rounds to establish ordering. Validators broadcast transactions and blocks to each other, wait for acknowledgements, vote, wait for vote confirmations and then proceed. Bitcoin’s ten-minute block time exists partly to give this process enough time to complete across a globally distributed network. Ethereum’s pre-Merge block time of around 12 to 15 seconds served the same purpose.
Every communication round adds latency. Latency limits throughput. And as a network grows – more validators, more geographic spread, more transactions – the communication overhead grows with it. Transaction ordering by committee is inherently slow, and making it faster by reducing validator count raises centralisation concerns. Anatoly Yakovenko’s insight was that if you could prove the passage of time cryptographically rather than through communication, you could bypass this bottleneck entirely.
What Proof of History actually is: a cryptographic clock
Proof of History is a method for creating a verifiable record of time that every participant in a network can trust without checking with anyone else. It is a decentralized clock – not a clock in the mechanical sense, but a cryptographic structure that proves a specific amount of computational work was done sequentially, and therefore that a measurable amount of real time passed. Solana Proof of History is the specific implementation Anatoly Yakovenko designed to solve the ordering problem that limited every blockchain before it. As a decentralized clock, it gives every validator on the network the same verifiable time reference without requiring any of them to trust or communicate with a central time server.
Anatoly Yakovenko published the Proof of History whitepaper in November 2017 while working on what would become Solana. The core idea came from his background in distributed systems at Qualcomm, where clock synchronisation across hardware components was a fundamental engineering problem. His solution to the blockchain version of that problem was to make time provable rather than trusted.
How the SHA-256 hash chain creates a timeline
The mechanism behind Proof of History is a continuous SHA-256 hash function that feeds its own output back as the next input. The output of hash 1 becomes the input of hash 2. The output of hash 2 becomes the input of hash 3. This continues without interruption. Each step in the chain depends on the result of all previous steps, which means the chain cannot be forged in parallel and cannot be fast-forwarded.
The result is a hash chain that encodes the passage of time. If you know that computing one SHA-256 hash takes a fixed amount of time on a given processor, then a chain of one million hashes proves that approximately one million hash-computation intervals have elapsed. Any validator can inspect the chain, replay a portion of it and confirm both that the chain is valid and that the time implied by the chain length is accurate.
Events – including transactions – are inserted into the hash chain as they arrive. A transaction inserted at position 500,000 in the chain provably occurred before a transaction inserted at position 501,000. The chain itself is the timestamp, and the timestamp is cryptographically verifiable by anyone with a copy of the chain.
Why SHA-256 specifically and why it cannot be shortcut
SHA-256 was chosen because it is sequential and pre-image resistant. Sequential means each hash must be computed one at a time – you cannot distribute the computation across cores to speed it up, because each step requires the output of the previous step as its input. Pre-image resistant means given any output, you cannot work backwards to find an input that produces it without brute force search.
Together these properties create what cryptographers call a verifiable delay function (VDF). A VDF is a function that takes a minimum amount of real time to compute but whose output can be verified almost instantly. The computation cannot be parallelised to bypass the time requirement. Verification, on the other hand, can be parallelised across cores – validators can check many portions of the chain simultaneously even though the chain itself had to be built sequentially.
This asymmetry between computation and verification is what makes PoH practical. The slot leader spends significant computational resources generating the chain. Every other validator spends very little time confirming it is correct. The cost is concentrated at the point of production and distributed at the point of verification.
What a PoH tick is and how it maps to a Solana slot
The PoH chain runs continuously and produces what Solana calls ticks. Each tick corresponds to a fixed number of hash iterations. A batch of ticks comprises a slot – the basic unit of time on the Solana network. Each slot lasts approximately 400 milliseconds.
Every slot is assigned to one validator called the slot leader. The slot leader is responsible for running the PoH generator during its slot, collecting incoming transactions, inserting them into the hash chain and broadcasting the resulting block to the network. The slot leader changes every four slots – approximately every 1.6 seconds – in a rotation determined by the leader schedule.
The leader schedule is calculated once per epoch. An epoch contains 432,000 slots, which works out to roughly two days. At the start of each epoch, the network computes which validator will lead which slots for the entire coming epoch based on stake weight. Validators with more delegated stake are assigned more slots. Because every validator knows the schedule in advance, they can prepare to receive blocks from the upcoming leader before that leader’s slot begins – which is the foundation of Solana’s Gulf Stream transaction forwarding mechanism.
How Proof of History works step by step
Knowing the components individually is one thing. Understanding how they connect during a live transaction is another. Here is what happens when a user submits a transaction and a slot leader processes it using Proof of History.
The generator node and the continuous hash sequence
The current slot leader runs a PoH generator – a process that continuously computes SHA-256 hashes and chains them together. This runs from the moment the slot begins until the slot ends. The generator does not wait for transactions to arrive. It produces hashes at a fixed rate determined by the hardware’s SHA-256 computation speed. The chain of hashes is the clock. It ticks regardless of whether any transactions are present.
This continuous computation is why slot leaders require high-performance hardware. The PoH generator runs on a single thread – parallelising it would defeat the purpose of a sequential hash chain – and it must maintain a consistent tick rate to keep the network’s time reference accurate. A slow or interrupted generator would cause the slot to be skipped.
How transactions are inserted into the hash chain
As transactions arrive at the slot leader through Gulf Stream’s forwarding mechanism, the leader inserts their data into the ongoing hash sequence. Specifically, the transaction data is mixed into the SHA-256 input at the current position in the chain. The resulting hash incorporates both the previous hash and the transaction data.
This insertion gives the transaction a cryptographic timestamp. Any validator looking at the chain can see that transaction A was inserted at hash position 487,302 and transaction B at hash position 487,891. Transaction A provably came first. No one needs to send a message asking “when did you receive transaction A?” The answer is in the chain. This is how PoH eliminates the communication rounds that order events on other networks.
How validators verify the sequence independently
Once the slot leader broadcasts the block, every other validator receives a copy of the hash chain segment corresponding to that slot. Verification is straightforward: replay the hash computations, check that each output matches the next input and confirm that the inserted transaction data appears at the claimed positions.
Because SHA-256 is deterministic – the same input always produces the same output – this verification requires no communication with the slot leader or with any other validator. Each validator can independently confirm the chain is valid. If the chain is valid, the ordering of transactions within it is accepted. Validators can then move directly to the Proof of Stake voting phase without a prior ordering negotiation. That elimination of the ordering negotiation is the primary speed advantage that Proof of History provides.
Verifiable Delay Functions: the cryptography behind the clock
The term verifiable delay function appears in most explanations of Proof of History, usually without much elaboration. It is worth understanding precisely because the limitations of Solana’s PoH implementation – and the motivation for Alpenglow – flow directly from the properties of VDFs.
A VDF has three required properties. First, it must take a guaranteed minimum amount of real time to compute regardless of available hardware. Second, its output must be uniquely deterministic – only one valid output exists for any given input. Third, the output must be verifiable much faster than it was produced.
SHA-256 used as a sequential hash chain satisfies properties two and three. The problem is property one. Computation speed for SHA-256 is directly proportional to hardware capability. A validator running a processor that computes SHA-256 twice as fast as another validator will produce twice as many hashes per second, and therefore its PoH chain will run at twice the rate. This means the PoH tick rate on Solana is not fixed by mathematics – it is determined by the hardware of the slot leader running the generator at that moment.
Solana accounts for this by requiring validators to stay within a defined tick rate range. Validators that deviate too far from the expected rate have their slots skipped. But the underlying point stands: Solana’s PoH is a practical approximation of a VDF, not a theoretically perfect one. It achieves the goal of creating a verifiable timeline, and it does so with the SHA-256 algorithm that every modern processor handles efficiently. The formal limitations of this approach are part of what the Alpenglow upgrade addresses.
Proof of History and Proof of Stake: how they work together
Proof of History handles ordering. Proof of Stake handles security. Neither is sufficient without the other on Solana, and the interaction between them is what produces the network’s performance characteristics. For a deeper look at how Solana’s full architecture works across all eight technical components, the complete breakdown covers each layer in detail.
What PoH contributes: ordering without communication
The slot leader produces a block during its 400-millisecond slot using the PoH generator. The block contains an ordered sequence of transactions with their cryptographic positions in the hash chain. When this block reaches other validators, those validators already know the ordering because it is encoded in the chain. They skip the communication phase that would otherwise be needed to agree on what came first.
This means validators can start the voting phase faster. On a standard Proof of Stake network, voting begins after ordering negotiation. On Solana, voting begins the moment a valid block is received because the block itself carries its own verifiable ordering proof through the embedded PoH sequence.
What Proof of Stake contributes: security and finality
PoH provides no security on its own. A validator could in principle generate a valid-looking PoH chain containing fraudulent transactions. What prevents this is the Proof of Stake layer. Validators stake SOL as collateral and can have that stake slashed if they vote for blocks that violate the protocol. The economic cost of dishonesty is real and enforced on-chain.
PoS also provides finality. A block is not final simply because it has a valid PoH chain. It becomes final when enough staked validators have voted for it through the Tower BFT mechanism. Until that threshold is reached, the block could theoretically be replaced by a competing fork. The PoH chain establishes ordering; the PoS votes establish finality.
Tower BFT: the consensus layer that uses PoH as its clock
Tower BFT is Solana’s Byzantine Fault Tolerant consensus implementation. It is an adaptation of Practical Byzantine Fault Tolerance (PBFT), redesigned to use the PoH clock as a pre-established timeline rather than relying on message-round timekeeping.
Under Tower BFT, validators cast votes on blocks. Each vote locks the validator into that branch of the chain for a period called a lockout. The lockout doubles with each subsequent vote on the same branch. A validator that has voted ten consecutive times on the same branch would need to wait 1,024 slots before switching to a conflicting fork – a period long enough to make switching economically irrational unless the network has genuinely split.
Because the PoH timeline is established before voting begins, Tower BFT does not need multiple rounds of messaging to agree on which events preceded which. Validators can vote quickly with confidence that the ordering question is already settled. The result is optimistic confirmation in approximately 400 milliseconds to 1.5 seconds for most transactions, with full Tower BFT finality taking approximately 12.8 seconds. This 12.8-second finality time is one of the targets that Alpenglow was designed to reduce.
Why Proof of History made Solana fast: the direct connection to TPS
The speed advantage of Solana Proof of History is not a marketing claim about theoretical maximums. It flows directly from the architectural change PoH makes to how validators spend their time. On most blockchain networks, validators spend a significant portion of each block period on ordering negotiation – exchanging messages, waiting for responses and aggregating results before processing can begin. PoH removes that pre-processing phase entirely.
The time savings compound. Because validators do not wait for ordering agreement, the slot leader can produce a new block every 400 milliseconds. Because Sealevel can identify non-conflicting transactions in the incoming stream using the account access declarations each transaction includes, it can execute those transactions in parallel across multiple CPU cores. The PoH-established ordering feeds directly into Sealevel’s parallel processing scheduler.
The combined result is a network that handles 2,000 to 4,000 transactions per second on its live network, with a theoretical maximum approaching 65,000 transactions per second under optimal hardware conditions. For context, Ethereum’s base layer processes 15 to 30 transactions per second. Bitcoin processes roughly 7. The difference is not raw compute power – it is the architecture that PoH enables. For more context on the Solana network and how it compares to competing blockchains, the full overview covers scalability trade-offs in more depth.
Limitations of Proof of History: the trade-offs Solana made
Every architectural decision involves trade-offs. Proof of History delivered speed advantages that no other blockchain had achieved at launch. The costs of those advantages became clearer over time.
Centralization: one generator per slot
In each 400-millisecond slot, one validator is the slot leader. Only that validator runs the PoH generator. No other validator can insert transactions into the chain during that slot. Every other validator is passive during that window – verifying, not generating. This design concentrates block production into a single point per slot, which is a form of centralization that does not exist in networks where any validator can propose a block at any time.
The concern is not that one slot leader can steal funds – the PoS layer prevents that through slashing. The concern is that the leader has discretion over which transactions to include and in what order within its slot. This creates an MEV surface where the slot leader can reorder transactions to extract value. It also means that a slot leader that goes offline causes its slot to be skipped, temporarily reducing throughput.
Hardware requirements and the cost of running a validator
Running the PoH generator at a consistent tick rate requires high-performance hardware. A competitive Solana validator in 2025 needs a high-core-count CPU (typically 32+ cores), 512 GB or more of RAM, fast NVMe SSD storage and a high-bandwidth internet connection. The cost of this setup runs to roughly $10,000 or more for initial hardware, plus ongoing bandwidth and electricity costs.
These hardware requirements limit who can run a validator. As of early 2026, the network has approximately 1,900 active validators – significantly fewer than Ethereum’s roughly one million. Solana’s staking delegation system allows token holders to participate in network security without running their own hardware, but the validator count itself reflects the barrier that PoH’s computational demands create.
The outages: when the architecture met live network stress
Solana experienced several significant network outages between 2021 and 2023. The most notable was in September 2021, when a token launch generated 400,000 transactions per second – far beyond what the network could handle – and the resulting memory overflow caused validators to crash and restart at different points in the PoH chain, unable to agree on state.
PoH itself did not cause the outage. The cause was a transaction flood that overwhelmed validator memory. But the architecture’s reliance on a single PoH generator per slot meant there was no straightforward way to degrade gracefully under that kind of load. When validators diverged on chain state, the only resolution was a coordinated restart. The introduction of QUIC for transaction ingestion and local fee markets addressed the spam vector, and the network has operated without a major outage since mid-2023.
Proof of History vs Proof of Work vs Proof of Stake
The comparison between consensus approaches requires one clarification upfront: PoH is not directly comparable to PoW or PoS because it operates at a different layer.
The table below compares the complete consensus systems of three networks – Bitcoin (PoW), Ethereum (PoS) and Solana (PoH + PoS via Tower BFT).
| Feature | Bitcoin (PoW) | Ethereum (PoS) | Solana (PoH + PoS) |
|---|---|---|---|
| Block time | ~10 minutes | ~12 seconds | 400 milliseconds |
| Practical TPS | ~7 | ~15-30 | 2,000-4,000 |
| Finality | ~60 minutes (6 blocks) | ~12 minutes | ~12.8 seconds |
| Transaction ordering | Miner discretion | Validator voting | Cryptographic (PoH chain) |
| Energy consumption | Very high | Low | Low |
| Validator hardware | Specialised (ASICs) | Consumer grade possible | High-end server hardware |
| Active validators | ~20 major pools | ~1 million | ~1,900 |
The trade-offs are visible in the numbers. Solana achieves its speed and finality advantages through an architecture that requires more expensive hardware and produces fewer validators. Bitcoin achieves its security and decentralisation through an architecture that is energy-intensive and slow. Ethereum sits between them on most dimensions after its transition to Proof of Stake. None of these is objectively superior – each reflects different priority weightings on the decentralisation-security-scalability triangle. For a look at the SOL token and how staking economics work alongside PoH, the tokenomics breakdown covers the validator incentive structure in detail.
Alpenglow: why Solana is replacing Proof of History in 2026
In August 2025, developers at Anza submitted SIMD-0326, a governance proposal for the most significant architectural change in Solana’s history. The proposal, nicknamed Alpenglow, passed with 98.27% validator support on September 1, 2025. SIMD-0326 replaces both Proof of History and Tower BFT with a new two-component system called Votor and Rotor. Mainnet deployment is scheduled for 2026, pending testnet validation.
What limitations led to Alpenglow
The primary target of Alpenglow is Tower BFT finality. At 12.8 seconds, Tower BFT finality is slower than credit card processing, slower than most payment systems and slow enough that some applications must treat optimistic confirmation as a proxy for finality rather than waiting for the real thing. Tower BFT’s lockout mechanism, which doubles with each vote, was designed around the assumption that validators need substantial time to agree – an assumption that PoH was meant to reduce but could not eliminate entirely.
The second target is on-chain voting overhead. Under Tower BFT, every validator vote is submitted as an on-chain transaction. These vote transactions consume block space, compete with user transactions for inclusion and add latency to the voting round. In a network processing millions of daily transactions, the overhead of thousands of vote transactions per slot is a meaningful cost.
Votor: what replaces Tower BFT
Votor replaces Tower BFT as the consensus mechanism. Where Tower BFT casts votes on-chain, Votor uses off-chain direct validator communication with cryptographic signature aggregation. Validators exchange votes directly using aggregated signatures, then submit a compact proof on-chain once consensus is reached. The on-chain footprint is a fraction of what Tower BFT requires.
Votor operates in two modes. If 80% of staked weight votes in the first round, the block finalises immediately. If only 60% vote in the first round, a second round runs. Under normal network conditions, the single-round path is the default, and finality arrives in approximately 150 milliseconds. That is a reduction from 12.8 seconds to 150 milliseconds – a change of roughly 85 times faster.
With finality arriving in 150 milliseconds, the question of why PoH is also being replaced becomes clear. If consensus completes in 150 milliseconds, the elaborate cryptographic clock machinery of PoH – which was designed to eliminate ordering communication for a 12.8-second finality process – is no longer necessary. At 150-millisecond timescales, each validator simply observes local timeouts. The cryptographic clock can be replaced by a fixed block interval and local timeout logic.
What Alpenglow means for Proof of History’s legacy
Alpenglow does not mean Proof of History was a failure. It means it was a successful solution to a problem that is now being solved differently. PoH enabled Solana to achieve 400-millisecond blocks at a time when no other blockchain was close to that performance. It proved that cryptographic time-keeping could replace the communication-heavy ordering negotiation that limited throughput across the entire industry.
The Alpenglow upgrade preserves the 400-millisecond slot structure – that part of Solana’s architecture stays. What changes is the mechanism inside that slot. The PoH generator is removed. Ordering within a slot becomes the slot leader’s responsibility through standard block production rather than continuous hash chain generation. The cryptographic proof of time is replaced by a social proof of time: validators agree on block timing through the Votor voting protocol rather than through a shared mathematical clock.
For users and developers, the transition is largely invisible. The same wallets, the same programs, the same account model and the same transaction structure remain. The Solana programs and smart contracts that run on the network today will continue running under Alpenglow without modification. What changes is the speed: finality that currently takes 12.8 seconds will arrive in 150 milliseconds, making Solana’s settlement speed competitive with payment card networks for the first time.
Alpenglow also changes the economics of block production. The fixed 400-millisecond slot remains, but the PoH generator’s hardware overhead disappears. Validators no longer need to dedicate a dedicated thread and significant CPU capacity to continuous SHA-256 chain generation. This reduction in validator compute requirements may, over time, lower the hardware barrier to running a node and expand the validator set. The transaction fee structure will also evolve as Alpenglow changes the relationship between block production and fee markets, particularly how local fee markets price congestion at the slot level.
Frequently asked questions
Is Proof of History a consensus mechanism?
No. Proof of History is a pre-consensus algorithm that provides a verifiable ordering of events before consensus voting begins. Solana’s actual consensus mechanism is Proof of Stake, implemented through Tower BFT. PoH gives validators a shared cryptographic timeline so they can skip the communication rounds that order transactions on other networks. Without PoH, Solana would still achieve consensus through PoS, but more slowly.
Who invented Proof of History?
Anatoly Yakovenko, the co-founder of Solana, published the Proof of History whitepaper in November 2017. His background in distributed systems at Qualcomm, where clock synchronisation across hardware components was a standard engineering challenge, directly informed his approach to the blockchain time problem. He recognised that creating a verifiable cryptographic record of time would eliminate the ordering negotiation that limited throughput on every existing blockchain.
How does the SHA-256 hash chain create a timeline?
The output of each SHA-256 computation becomes the input of the next. This chain cannot be built faster than one hash at a time because each step depends on the previous result. The number of completed steps proves that a measurable amount of time has elapsed. Transactions inserted at specific positions in the chain have a cryptographic timestamp that proves their ordering relative to all other events in the chain, without anyone needing to communicate about when they were received.
What is a verifiable delay function (VDF) and how does it relate to PoH?
A verifiable delay function is a computation that takes a guaranteed minimum amount of real time to produce but can be verified much faster. Proof of History uses SHA-256 as a practical approximation of a VDF. It satisfies the verification speed requirement and the sequential nature requirement but does not have a hardware-independent minimum time guarantee – a faster machine produces the hash chain faster. This distinction is technically important and is one reason Alpenglow does not rely on the same approach.
What is a slot leader on Solana?
A slot leader is the validator assigned to produce a block during a specific 400-millisecond slot. The slot leader runs the PoH generator, collects incoming transactions, inserts them into the hash chain and broadcasts the resulting block. Slot leaders rotate on a schedule calculated once per epoch based on each validator’s stake weight. Validators with more delegated stake are assigned more slots over the course of an epoch.
How fast does Proof of History make Solana?
The combination of PoH with Sealevel parallel processing allows Solana’s live network to process 2,000 to 4,000 transactions per second, with a theoretical maximum of around 65,000 TPS under optimal conditions. Block time is 400 milliseconds. Optimistic confirmation – the point at which a transaction is unlikely to be reversed – arrives in 400 milliseconds to 1.5 seconds. Full Tower BFT finality takes approximately 12.8 seconds.
What are the limitations of Proof of History?
Three trade-offs stand out. First, each slot has a single leader producing the PoH chain, which concentrates block production and creates an MEV surface. Second, running the PoH generator at the required rate demands high-end server hardware, which limits who can participate as a validator and results in a validator count of around 1,900 compared to Ethereum’s roughly one million. Third, the architecture contributed to fragility during early network outages, where validators crashing at different points in the chain required coordinated restarts.
How does Tower BFT use Proof of History?
Tower BFT is Solana’s consensus voting mechanism. It uses the PoH clock to eliminate the need for multiple communication rounds during voting. Because the ordering of events is already established by the PoH chain before voting begins, validators can start casting votes immediately when they receive a valid block. Lockout periods in Tower BFT are measured in slots, using PoH as the common time reference. Full Tower BFT finality takes approximately 12.8 seconds.
What is Alpenglow and does it replace Proof of History?
Alpenglow is a consensus upgrade that passed with 98.27% validator support on September 1, 2025. It replaces both Proof of History and Tower BFT with two new components: Votor, a direct off-chain voting protocol, and Rotor, a new block propagation mechanism. Under Alpenglow, the PoH generator is removed. Finality drops from 12.8 seconds to approximately 150 milliseconds, making the elaborate cryptographic clock machinery of PoH unnecessary at that timescale. Mainnet deployment is expected in 2026.
Will Alpenglow change Solana’s 400-millisecond block time?
No. The 400-millisecond slot structure is preserved under Alpenglow. What changes is the mechanism inside each slot: the PoH hash chain generator is removed and replaced by standard block production with fixed timing. Validators agree on block timing through Votor’s voting protocol rather than through a shared mathematical clock. The slot itself remains 400 milliseconds, but finality now arrives within that window rather than after 12.8 seconds of additional voting.
How does Proof of History differ from Proof of Work?
Proof of Work requires miners to compete by performing energy-intensive computation to win the right to produce the next block. By contrast, Proof of History is not competitive – one validator per slot is pre-assigned as leader based on stake weight. PoW is a consensus mechanism that secures the network through computational cost. PoH is a timekeeping mechanism that removes ordering negotiation from the consensus process. They solve different problems at different layers of blockchain architecture.
Why is Proof of History being replaced if it worked?
Proof of History worked well enough to make Solana one of the fastest blockchains for several years. The reason it is being replaced is that Alpenglow’s Votor protocol can achieve 150-millisecond finality, at which point the cryptographic clock machinery of PoH is no longer necessary. When finality arrives faster than the interval PoH was designed to bridge, a simpler approach – fixed block intervals with local validator timeouts – achieves the same ordering goal without the hardware overhead and architectural complexity of a continuous hash chain generator.
