AssumeUTXO
AssumeUTXO is a Bitcoin Core feature that lets a node load a serialized UTXO set snapshot at a predetermined height, then sync headers and blocks from that height to the tip while a background process reconstructs the UTXO set from genesis and checks that it matches the snapshot. The node can serve wallets sooner than a full initial block download, without permanently trusting the snapshot: divergence from the recomputed set is treated as a failure.
IBD context
Initial block download validates every block from genesis and builds the UTXO set incrementally. On a typical connection this takes hours to days, dominated by script verification (unless assumevalid skips old scripts) and by disk writes to the chainstate. Pruning reduces disk for old blocks but does not shorten the time to a complete chainstate. AssumeUTXO, designed by James O'Beirne and others, treats a UTXO snapshot the way assumevalid treats historical scripts: a compiled-in hash of a particular height's chainstate is trusted temporarily. The snapshot is distributed out of band (file download). Mainnet parameters for height 840,000 were added in Bitcoin Core 28.0, enabling loadtxoutset on mainnet for a snapshot that matches that hash.
Snapshot and validation
A snapshot is a serialization of the UTXO set at a snapshot height, content-hashed. Bitcoin Core ships the expected hash for one or more heights. The operator obtains a snapshot file from a source they consider available (another node, a published dump) and calls loadtxoutset. The node loads the snapshot into a secondary chainstate and checks its hash against the compiled-in value; syncs headers to the tip, then downloads and validates blocks after the snapshot height, updating the snapshot chainstate (script verification applies to those new blocks as usual); and in the background starts a full validation from genesis (or from an existing local chain) that rebuilds a chainstate independently. When background validation reaches the snapshot height, it compares the reconstructed UTXO set hash to the snapshot. A mismatch fails the node.
Until background validation completes, the node is relying on AssumeUTXO for the state at the snapshot height. Peers and wallets can use the node for recent payments. Mining and other operations that require a fully validated history may be restricted until the background check finishes. Snapshots must correspond to a block on the most-work chain that the node later sees. The feature does not replace checkpoints for header validity; it only compresses the wait for a usable UTXO set.
Bitcoin Core is the implementation. Experimental support appeared in earlier major versions; 28.0 added mainnet snapshot parameters at height 840,000. Other node software may have analogous snapshot-import tools that are not called AssumeUTXO and may not revalidate in the background. Related approaches to reducing full node resource costs include Utreexo.
Snapshot files are large because they contain the full UTXO set at the snapshot height. Operators usually download them from a published mirror or copy them from another node that already produced the dump. The compiled-in hash is the security boundary for that height. A corrupt or substituted file that fails the hash check is refused before the secondary chainstate is used.
Status
Background revalidation still downloads and verifies historical blocks, so disk and CPU costs are deferred rather than eliminated. Pruned nodes can use AssumeUTXO if they retain enough data for the background chainstate to complete, subject to Core's pruning rules. Future releases may ship hashes for newer snapshot heights as the chain grows past 840,000. Operators should obtain snapshots from known mirrors and check the hash against Bitcoin Core's compiled-in value before calling loadtxoutset. A mismatched file is rejected, but a correct hash only proves agreement with that release's expected chainstate tip height.