One of the quiet questions behind every decentralized network is also one of the most important: how does a brand new machine join? Not a machine that has been running for months and just needs to catch up on a few blocks, but a fresh one, empty disk, that wants to become a full participant in a chain that already has real history behind it.
Today that path on QBC is fast and clean. A fresh node joins the live chain in about three minutes with a single command. It downloads a recent, cryptographically verified snapshot of the chain state, checks the finality proof that backs it, and then starts following new blocks in lockstep with every other validator. No copying an eleven gigabyte database between machines, no waiting hours to replay years of history. This is warp sync, and getting it working end to end against the live network is a real step toward the thing we keep pointing at: thousands of nodes, anyone able to join.
The two ways to join a chain
There are fundamentally two ways for a new node to come up to speed.
The first is the literal one: start at the genesis block and replay every block since, re executing every transaction, rebuilding the entire state from scratch. This is the most trustless approach because the node verifies the whole history itself. It is also the slowest, and on a chain with real history it gets slower every day. For a chain that has been producing blocks every few seconds for a long time, full replay is measured in hours.
The second way is warp sync. Instead of replaying history, the joining node asks the network for a recent finalized state directly, along with the finality proof that shows that state was agreed by the validator set. It verifies the proof, installs the state, and starts following the chain from there. The history is still there, still immutable, still served by archive nodes for anyone who wants to audit it. The new node simply does not have to re execute all of it before it can be useful.
Warp sync is the modern default for exactly this reason. It is how you onboard onto a chain that has accumulated real, valuable history without making every newcomer pay the full replay cost. The longer a healthy chain runs, the more this matters.
A long history is a feature, and it has consequences
QBC has deep history. The chain inherited its starting state from the original network at a specific block and has been finalizing blocks on Substrate ever since, well past nine hundred thousand of them. That early state, the genesis of the current chain, is frozen. It is a fixed, immutable anchor that every node agrees on, and it has been agreed on continuously through a long sequence of runtime upgrades that took the chain to its current version without ever stopping or re launching it.
That immutability is the point. A chain whose deep history could be quietly regenerated or swapped would not be much of a chain. The history is fixed precisely because it is where the chain's identity and its accumulated state live. The flip side is the one every long lived network meets eventually: you do not want new joiners to have to reconstruct that entire deep history locally just to say hello. The right answer is not to make the history smaller or softer. The right answer is to give new nodes a way to trust a recent finalized state and start participating from there. That is warp sync, and it is the same answer the broader ecosystem converged on.
So the design goal was straightforward to state. A fresh node should be able to present itself to the live network, agree on the chain's identity, fetch and verify a recent state, and then follow finality, all without replaying deep history and without anyone shipping it a database by hand.
How a fresh node warps onto QBC
The join sequence has a few distinct stages, and each one is a place where a naive implementation can quietly stall. Walking through them is the clearest way to show what is actually happening.
First, identity. When two nodes meet they check that they are talking about the same chain before they exchange anything else. The joining node presents the network's chain identity on the wire so that the live validators recognize it as one of their own and accept the connection. This handshake is what turns a stranger into a peer.
Second, the warp proof. The joining node asks a peer for the finality proof that carries it from the chain's starting point up to a recent checkpoint. This proof is what makes warp sync trustless rather than a blind download. The node verifies it against the validator set before trusting anything that follows. In our runs the proof verified cleanly and the node logged warp sync complete within a second or two of connecting.
Third, state. With a verified checkpoint in hand, the node downloads the actual state at that point, the full set of accounts, balances, validator records, and everything else the runtime needs. This is the heavy part by volume, on the order of a couple hundred megabytes, streamed from peers and imported into the local database. When it finishes, the node holds a complete, verified, recent snapshot of the chain.
Fourth, the gap. This is the subtle one. After warping, the node has the recent state but not the individual historic blocks between the deep start and the checkpoint it warped to. A node that tries to backfill that entire gap from a standing start can get stuck chasing blocks that are not the point of warp sync in the first place. So the node recognizes that this historic gap is not something it needs to fill to participate, marks it accordingly, and moves on. Archive nodes keep the full history available for anyone who wants it; a freshly warped node does not need a local copy of every old block to validate new ones.
Fifth, follow the tip. With recent state installed and the gap handled, the node starts importing new blocks as they are produced and tracking GRANDPA finality, exactly like every established validator. At this point it is a full peer. From empty disk to following the live tip, the whole sequence takes about three minutes.
Proving it, not asserting it
A feature like this is only as good as the evidence that it works on the real network, under the real runtime, today. So warp join is a first class check in our verification harness rather than a thing we ran once and trusted forever.
The check launches a genuinely fresh node, empty base path, isolated from everything else, and points it at the live chain. It then watches the full sequence: peers connect, warp proof verifies, state downloads and imports, the historic gap is skipped, and then, the part that actually matters, the node imports new blocks after reaching the checkpoint. That last step is the real proof of life. Reaching a recent snapshot only shows the download worked. Importing fresh blocks on top of it shows the node is truly following the living chain and not sitting frozen at a snapshot. The check only passes if the node both reaches the tip and then advances past it, and in the latest run it caught up and then imported dozens of new blocks within seconds while finality kept advancing.
We also keep a deliberately adversarial variant of the same test. It runs the join the naive way, without the network identity handshake, and confirms that the network correctly refuses it as a different chain. Keeping that failure path in the harness is intentional. It documents exactly why the proper join sequence is necessary and it would immediately catch any regression that silently broke the real path. A test that can only ever go green is a test that has stopped telling you anything.
The whole run happens against the live network without touching it. The probe node uses its own ports and its own throwaway database, the live validators never skip a beat, and finality keeps advancing throughout. Re running it against the current runtime version, after the long sequence of upgrades the chain has been through, it came up green: warp proof verified, state synced, gap skipped, following the tip, about three minutes start to finish.
Why this is the onboarding primitive
It is worth being clear about why a sync feature earns a blog post. Permissionless participation is not really one feature. It is a stack of them, and the bottom of that stack is the ability for an arbitrary new machine to join cheaply. If joining requires an operator to manually copy a multi gigabyte database from an existing node, then joining is gated on that operator and that copy, and you do not have a permissionless network, you have a club with a manual admissions process. Fast, self serve warp join is the primitive that turns running a node from a hand held operation into something a script, or a stranger, can do in minutes.
That is the keystone we have been building toward on the consensus side. Multi author block production, a rotating finality set, validator scaling, all of it assumes new nodes can actually show up. Warp join is how they show up. Having it working and continuously verified against the live chain moves the thousand node goal from a diagram to a sequence of steps we have actually walked.
The honest edges
A scorecard without its rough edges is marketing, so here are the real ones.
The join path is proven against the live chain from this machine, with a fresh node reaching and following the tip. The next mile is breadth: exercising it from more network positions and as part of a larger multi machine soak, which is its own milestone with its own infrastructure.
There is also a small piece of housekeeping the work surfaced. The shipped network configuration still lists some older introductory peer addresses from an earlier server layout. The join works regardless because nodes discover current peers once connected, but refreshing that list is a clean follow up so that the very first contact is as smooth as everything after it.
And the deep history, the part that is immutable by design, deserves one forward looking note. Because that history is fixed and archive copies of the earliest state are precious, keeping a healthy archive node running is something we treat as part of the chain's long term hygiene, so that recent verified snapshots can always be produced for the next generation of joiners.
None of that changes the headline. A new node joins the live QBC chain, verifies a recent state against the validator set, and starts following finality, in about three minutes, with one command and no database to copy. That is what permissionless onboarding is supposed to feel like, and it is running today.