title: Syncing a node
description: Details syncing a node to the current state and the bootstrap and catchup process
tags: mina, candidate
# Syncing a node
To successfully produce a block that extends the Mina blockchain, a node requires the [current state](../overview/protocol-state.md).
To retrieve this state, a node will [initialize](syncing-a-node.md#initialization) by determining the current [best tip](../overview/protocol-state.md) of the network from a random sample of (8) peers. The distance from the root of the node's [transition frontier](transition-frontier.md) to the current best tip determines if the node requires bootstrapping. If the best tip is too far into the future, for example, a node that is new to the network or has been offline for an extended period, then a bootstrap is triggered. Alternatively, a node may enter catchup to sync to the current best tip using the existing root of the transition frontier.
The syncing process builds the node's transition frontier by creating [breadcrumbs](transition-frontier.md) from all transitions between the transition frontier's root to the current best tip. Once this has been completed, the node is synced.
After pausing to ensure that the node is well connected, a node requests the best tip from a random sample of (8) peers. The best tip is used to determine whether a bootstrap or catchup is triggered.
A [bootstrap](syncing-a-node.md#bootstrap) will be initiated if there is no existing transition frontier, for example, if the node is new to the network, or if the current best tip is too far into the future (`> 2 * k + delta`).
A [catchup](syncing-a-node.md#catchup) is triggered when the root of the existing transition frontier does not contain a transition to the best tip but the best tip is not too far into the future.
The code to determine bootstrap vs. catchup may be found in `src/lib/transition_router.ml`
Bootstrapping involves creating the root of the transition frontier. A node that is new to the network will always require bootstrapping as it will not have an existing transition frontier.
The node requests the initial root transition and current root state from peers and syncs this root state. This state is first validated, and the node constructs a breadcumb in a new transition frontier with this synced state forming the root.
From this root state, additional transitions obtained during the catchup process are applied. This process generates a transition frontier that contains all transitions from the root to the current best tip. To do this, the missing transitions are required, which is the role of the catchup process.
The time to bootstrap is provided with the `Bootstrap.bootstrap_time_ms` metric
If a catchup is triggered, the node will attempt to catchup to the current best tip by determining, then downloading all transitions between the transition frontier root and the current best tip from a random sample of peers (8).
First, a node requests the missing transition hashes and a transition chain proof. This proof proves the path provided is valid, i.e., that the provided transition hashes lead from the root to the best tip. The node validates this locally, updating its [trust system](../networking/trust-scores.md), punishing the peer if an invalid proof is provided.
If the node is unable to download the transition from the chosen peers, alternative peers are chosen and the process retried. Once the node has all transition hashes, it requests the full external transition for each transition hash from peers.
During the catchup process, additional transitions may be seen and incorporated, ensuring a complete path from the transition frontier root to the current best tip.
With each external transition, the node builds up its transition frontier by applying each to the prior state to construct a breadcrumb. When catchup is complete, the node's local best tip is the same as the network's best tip, and breadcrumbs have been constructed for all transitions from the transition frontier root (`best tip` - `k`) to the current tip, and each has been validated. At this point, the node is [synced](#).
At any time, a catchup may be triggered if the node sees a disjoint transition in the same path, indicating there are missing transitions.
During the bootstrap and catchup phases, the node will receive gossipped snark work for transactions that are unknown to the node. This will result in `Rejecting gossiped snark work $stmt, statement not referenced` messages.
* Expand on the bootstrap phase - explain the syncing and exactly what is synced