What is Proof of History?
Solana's ordering mechanism, a continuously hashed sequence that produces a verifiable record of time passing between events.
Not yet verifiedHow we verify
3 min read
In this entry
Solana's ordering mechanism, a continuously hashed sequence that produces a verifiable record of time passing between events.
It is not a consensus algorithm on its own; it gives validators an agreed clock so they can pre-commit to a block schedule instead of negotiating timestamps, which is where much of the chain's throughput comes from (source: the Solana white paper). Consensus over that ordering is provided separately by the network's voting rules.
The name misleads people into thinking it is an alternative to proof of work or proof of stake. It is not in that category at all. Solana secures itself with proof of stake; Proof of History solves a different and narrower problem, which is agreeing on the order and spacing of events without every node exchanging messages about it.
How it works
- A leader runs a hash function on its own previous output, over and over, in an unbroken chain. Each output becomes the next input.
- Because the function cannot be parallelized, producing the ten-thousandth hash necessarily took longer than producing the hundredth. The sequence therefore encodes elapsed time.
- Events are mixed into the sequence by hashing the event data together with the current state. That fixes the event's position: it must have happened after everything before it and before everything after it.
- Anyone can verify the sequence, and verification splits across cores while generation cannot. Checking is far cheaper than producing (source: the Solana white paper).
- Validators use this shared clock to know in advance which leader is producing blocks in which slot, so they do not have to agree on timestamps by exchanging messages.
Consensus over the resulting chain is a separate mechanism, the network's voting rules, historically described as tower bft. Proof of History orders; consensus decides which ordering the network accepts.
Example
A useful way to see the idea is a sealed timestamp. Suppose you want to prove a document existed before a certain moment. You hash the document into a sequence that has been running continuously, and the position it occupies proves everything after it came later, without any trusted clock or authority signing a date.
Solana does this for transactions. One leader at a time appends events into the running sequence, and every other validator replays and verifies it in parallel. The saving is not in computing the hashes, which is cheap, but in the messages nobody has to send: without a shared clock, agreeing on ordering means rounds of communication between nodes, and that is what limits throughput on many designs.
Why it matters when you buy
Throughput claims built on this mechanism are marketing until measured. What matters to a buyer is what a transaction actually costs and how reliably it settles, both of which are observable on real blocks rather than in a design document. The chain pages publish measured throughput with the window and method stated, alongside fees, and layer 1 versus layer 2 covers how these approaches differ.
Related terms
proof of stake — what actually secures the chain; tower bft — consensus over the ordering; slot — the time unit leaders are assigned; consensus — how nodes agree on state; validator — who produces and votes; parallel execution — the other throughput mechanism.
Questions
Is Proof of History a consensus mechanism?
No. It orders events and encodes elapsed time. Agreement on which chain is canonical comes from the network's stake-weighted voting, which is a separate system.
Does it replace proof of stake?
No, the two work together. Solana is a proof of stake network; Proof of History removes the need for validators to negotiate timestamps, which is a throughput optimization rather than a security model.
Why can it not be sped up with more hardware?
Each hash takes the previous output as its input, so the steps must run in sequence. Adding cores does not shorten the chain. Verification is the reverse: segments can be checked independently, so it parallelizes freely.