Skip to main content
A node joining the network has to answer two questions: how do I get to where the chain is now, and how do I stay there. State sync answers both, and the trade-off between them is explicit rather than hidden.

​
Two modes of catching up

Bootstrapping — reaching the current version from nothing — can be done in one of two fundamentally different ways. Replay the history. Start at genesis and work forward, either by executing every transaction again or by applying the outputs that execution already produced. The result is a node holding the entire history: every version, every proof, every transaction. It is also slow, and gets slower every day the chain runs. Download the current state. Skip the history and fetch the state keys and values as they stand at the latest version, verified against the committed root. The node is current in a fraction of the time, and knows nothing about how the chain got there.
A new node
Bootstrapping mode
Replay the historyre-execute, or apply stored outputs, from genesisslow, and slower every day the chain runs
Download current statekeys and values at the latest version, verified against the committed rootcurrent in a fraction of the time
Current versionthen continuous sync
The two paths are not equivalentA node that downloaded current state cannot serve historical queries or say how a position got where it is. A node feeding an indexer or an audit needs the history it skipped.
Within the replay path there is a further choice — re-execute transactions, apply the stored outputs, or let the node pick whichever is faster at each point. Re-executing is the stronger check, since it reproduces the result rather than trusting a recorded one; applying outputs is faster. The mixed mode exists because the right answer changes with how far behind the node is.
This is an operational decision, not a default to accept without thinking. A node that downloaded current state cannot serve historical queries or answer questions about how a position got where it is — it has no history to read. A node serving an indexer or an audit process needs the history it skipped.

​
Staying current

Once at the current version, a node keeps up by consuming committed blocks as they arrive — again either by executing the transactions or by applying the outputs, with the same trade between verification strength and speed. The difference from bootstrapping is that the gap is small and constant rather than large and shrinking. A node that falls behind enough re-enters the bootstrapping path rather than trying to close an arbitrary gap incrementally.

​
How data moves

Sync is not one node asking another for a range of blocks. It separates into layers so that no single peer is a dependency and no single failure stalls progress. The consequence worth understanding: a syncing node is not trusting a peer. Every chunk arrives with a proof against a root the network committed, and a peer that serves something inconsistent is rejected rather than believed. Peer selection is a performance decision, not a trust decision.

​
Verification

Nothing in state sync is accepted on the strength of who sent it. State values are verified against the committed state root. Transactions and outputs are verified against the accumulators. A node that finishes bootstrapping has a state whose root matches what a quorum of validators signed — which is what makes the fast path safe: downloading current state skips the history, but it does not skip verification.

​
Where to go next

Storage and proofs

The structures that make sync verifiable.

Run a node

Node roles, and how to ask about operating one.

Network topology

Which tier of node a syncing peer is talking to.

Indexer

What history answers that current state cannot.