Whitepaper
In progress
This page describes what the SnapStream whitepaper will cover: the problem it addresses, how SnapStream works, and the evidence behind every result we publish. The paper itself is not written yet.
What it covers
The restart-coordination problem
Solana's earlier attempt at automatic restart coordination, wen_restart, took close to three years of work across two client teams and was removed in February 2026 without ever handling a real restart. We use that history to explain the specific problems SnapStream is built to solve.
SnapStream's design
SnapStream tracks who is ready to restart together across different validator clients, without sitting inside consensus. It never blocks or delays a validator's actual restart: if SnapStream goes dark, validators keep voting without it.
The client-identification standard
Our standard for naming which client a validator runs is open-ended, not a fixed list. It detects the client automatically where possible, asks the operator to declare it otherwise, and records which of the two happened for every entry.
Testing methodology and evidence
Our test plan runs rehearsal drills first, then a real two-node restart-participation exercise on the public testnet, then an induced restart on a private cluster we own outright. We capture every run's data and hash it into a manifest before analyzing it, and every report states what the results do not prove alongside what they do.
Status
We are still writing the paper. It publishes together with our test campaign's results, not before them.
← Back home