Proof of History

Proof of History is a core component of the Solana blockchain's architecture that functions like a universal clock for the network. Before we delve deeper into how it works, we need to clarify some details.

Ticks

First, in our introduction to Solana, we wrote that Solana's block time is 400 ms - in reality, it's the ideal block time the chain is aiming for, but there's a drift window that allows both faster and slower blocks to be produced and added to the blockchain. This drift window for each block slot ranges from -25% to +150% of the ideal block time, so in practice a block slot can be as short as ~300 ms or as long as ~1 s without being rejected by the network's validators - in human time.

And even though there technically is a hard "human time" cap on each block slot, Proof of History isn't an actual atomic clock - it's more like the beating heart of the Solana network, where each individual heartbeat is recorded and considered to be the basic unit of time within the network. One beat of the Proof of History "heart" is called a tick.

Each tick is a SHA256 hash of the previous tick* - creating a deterministic, cryptografically self-verifiable sequence of "timestamps" the whole network then coordinates around. Solana block data proposed to the network is voted on by validators after 64 ticks, 64 ticks equal one block slot (one block slot is actually considered to be Solana's basic unit of time in their documentation, not one tick, but we chose to explain this from the smallest unit up).

*each tick is actually the previous tick hashed not once, but 12.500 times by default with some wiggle room. Hashing each tick like this before considering the final hash to be the next tick serves as a VDF - verifiable delay function. The PoH idea was introduced in the Solana whitepaper in 2017, while a function similar to it which was later called a VDF came from Stanford in June 2018 - the researchers who introduced this term argue that PoH technically isn't a VDF because Solana's approach is algorithmically slow according to their metrics (and other reasons), so it remains disputed whether PoH is a VDF or not, but they have similar roles within a blockchain system.

Let's now have a look at how blocks are proposed and what role the PoH mechanism plays.

Epochs and Leader Schedule

In order to add a block of data to a blockchain's ledger, the block has to be first proposed and then confirmed by validators. The block is proposed by a single node, designated to operate as what is called a leader on the Solana blockchain. The leader is the only node with authority to propose new data to the current block slot, and all other nodes can then check the leader's proposal and either confirm or reject it with their vote. In theory, a node that's currently not the leader can also propose block data, but this data will certainly be rejected by validators because it will not be signed by the current leader - this ensures that there is only one valid leader per block slot at all times. All other nodes that aren't currently the leader are called replica nodes (a term from distributed systems theory).

When compared to Ethereum, where the leader node is decided by on-chain randomness seconds before a new block slot starts, the leader for each slot on Solana is decided by a pre-calculated leader schedule rotation which is calculated every 432.000 block slots, or every 2 days or so in practice. This 2-day period is called an epoch. The leader schedule is calculated locally on each validator using the same algorithm - they all end up with the same leader schedule "calendar".

When an epoch ends, a snapshot of the state of the blockchain ledger from its last confirmed block is taken and from this snapshot, a list of nodes that meet all conditions to function as a leader is created and ordered by stake* in the network (from largest to smallest). This list is then algorithmically shuffled and new leaders are selected to fill in the 432.000 slots of a new epoch (the bigger the stake, the higher the chance for each eligible node to be assigned as leader to a slot, but randomness still plays a role).

*only stake considered in Solana terms to be effective is counted; newly delegated stake warms up at ≤ 25 % per epoch, so a whale can’t dominate the very next schedule as soon as they stake their SOL.

There's a one-epoch offset for the schedule, which means that at the end of each epoch, the leader schedule is calculated not for the new epoch that just started, but for the next one after it.

Each leader proposes blocks for 4 block slots in the current implementation, or about 1.6 s, before another validator becomes the leader. As of April 2025, there are around 1300 active validator nodes on the Solana blockchain, so during one epoch, a single node has a very high chance to be the leader multiple times.

PoH Stream, Transaction Execution and Block Assembly

When a validator becomes the leader for its 4-slot turn, it takes the last tick hash from the last block added to the blockchain and runs a repeated sequence of hashing it and recording the subsequent PoH ticks (the leader generates the ticks, but all replicas are also hashing the PoH chain independently at the same time) while also receiving user transactions and interweaving them with the ticks as they come.

This essentially assigns each executed transaction a PoH tick which serves as a timestamp. The leader broadcasts the time-stamped data to the network in real time (and not at once as a whole block when the block slot closes) before the slot is fully completed - this is important, because this allows validators to process the received block data long before their vote is required to validate the transactions, which saves a lot of time. After the 64th tick closes the block slot, validators finish replaying the received data and vote to confirm the block.

The next leader will then start this process anew from the last PoH tick hash. This makes the PoH tick sequence completely unbreakable - if a validator in replica mode receives block data, replays it and finds out it started from a different tick than the last tick of the previous block or that it's shorter or longer than 64 ticks, it will simply cast a "no" vote.

Note that the Proof of History chain itself can’t be faked or reordered, but PoH alone doesn’t stop a leader from proposing a conflicting fork; Tower BFT, Solana's PoS consensus mechanism, prevents a malicious block from being added to the blockchain in this case.

So, in summary, Proof of History is Solana's built-in clock mechanism in the form of a chain of "ticks" that prove how much time has passed. By weaving each incoming transaction into this chain, PoH gives every validator the same tamper-proof record of transaction ordering, letting the network reach consensus and execute transactions without constant back-and-forth messaging between validators, because each node on the network is generating the PoH ticks locally.

In a way, PoH can be thought of as a pre-consensus mechanism - because of it, all nodes agree on the ordering of events without having to speak to one another, which is probably the most important design choice in the Solana network that makes it so quick. But this alone isn't enough to decide if a block should be confirmed, although it makes the process easier. We'll explore Tower BFT, Solana's Proof-of-Stake consensus mechanism, in the next article.