What a sync from genesis involves, and the one setting that a from-genesis follower needs and a validator does not.
Full sync, not snap sync
Full sync from block 0 is the mode that verifies the published history, and it is what the anchor requires: a node with the anchor rules armed refuses a lighter mode at startup.
Snap sync against a QBFT chain trusts a peer for the state and verifies far less. It is not a faster route to the same guarantee; it is a different guarantee.
Storage format is a local choice and not part of consensus.
Peering
Discovery needs a bootnode enode, and both discovery UDP and peer-to-peer TCP must be open in both directions. The node package publishes one bootnode, a public read host outside the validator set, and its run-node.sh uses it by default; the limit is that it is the only one and that the Foundation operates it. (Corrected 2026-10-27: until this date this paragraph said a dedicated public bootnode does not exist yet; the package has published one since 2026-08-25.)
The only proof that your peering works is your own net_peerCount. A non-zero count after a few minutes means discovery succeeded.
The genesis validator set, and the setting it forces
This is the part that surprises everyone who syncs from block 0, so it is worth reading before you start.
A node syncing from genesis starts into the genesis validator set, which is three validators with a quorum of two, not the ten of today. The anchor threshold guard refuses an effective minimum above three seals against that set (N - f) and, from AIP-22 stage R, one above its quorum of two, so it refuses the minimums of six and seven seals of the published schedule, and a from-genesis follower will not start at all without one more setting.
The published answer is a ceiling that lowers the effective seal-count floor to 1, without editing the schedule. The exact property name is in the package. (Corrected 2026-10-26: until this date this page said the guard refuses a minimum of three seals against that set and gave the floor as quorum(3) - 1 = 1; since 2026-08-20 the guard refuses only above N - f, and from stage R also above the quorum.)
State the consequence honestly, because it is a real weakening of one check. With that ceiling, the follower's seal-count requirement is 1 at every height rather than the minimum of the schedule (seven since block 20,715,632). Against an adversary that holds every classical validator key and no post-quantum key this changed nothing below AIP-22 stage R, because one seal the adversary cannot make is enough, and from block 24,148,752 (stage R) it costs one block: the follower's rewrite bound is 33 where a validator's is 32, because below the quorum of one round the anchors it accepts do not prove that their parent was decided; but one leaked or misused validator post-quantum key makes this follower's rewrite depth unbounded, where a validator needs seven such keys (section 6.4 of the package SPEC.md). Restart the node without the ceiling once it is synced to the head.
What is not weakened, and this is most of the check:
- every anchor must still carry a digest binding its certificate under the block hash
- seal indices must still be strictly increasing
- every carried seal is still Falcon-verified against the registry correct for that height
- eligibility in the parent's validator set is still enforced
Real anchor blocks carry at least one valid Falcon seal: anchors with one or two seals occur from block 13,014,000 until the emergency ceiling was lifted on 2026-08-14 (83 of the 625 anchors of the warm-up, blocks 13,014,000 to 13,033,999, and later ones too, such as block 13,283,120 with one; the last one found in a sample is block 13,890,544), three or more after that, and at least seven per scheme since block 20,715,632 (8 to 10 distinct Falcon-512 signers on the 32 anchors measured on 2026-10-26), so all of history imports at the follower's floor of one. (Corrected 2026-10-27: until this date this sentence said that real anchors carry between three and ten seals; anchors before 2026-08-14 carry one or two, measured on 2026-10-26.) The seal-count floor also bounds how much of history one leaked validator post-quantum key can rewrite for this follower (above). (Corrected 2026-10-26: this sentence called the floor a proposer-liveness property and not a history-verification property.)
A validator, which starts into the full set, does not set the ceiling.
When the sync is done
Compare your head to a public endpoint, and compare your block 0 hash to 0xd86d57a899cbfa580669f0e1c7cd4ae5f525247c3c823f8f75df176a0c5d7f1a before you trust either.
Sizing
Memory is the constraint, not CPU, and the requirement grows with the height. Read Requirements before starting a from-genesis sync; the heap table there is the difference between an import that finishes and one that stops.