AssumeUTXO

What Is AssumeUTXO?

AssumeUTXO is a Bitcoin Core feature that dramatically reduces the time it takes to bootstrap a fully validating Bitcoin node. Instead of downloading and processing every block since genesis (a process called initial block download, or IBD), the node loads a serialized snapshot of the UTXO set at a specific block height. Once loaded, the node immediately begins validating new blocks from the network tip, making it usable for sending and receiving transactions within minutes.

The feature was proposed by James O'Beirne in 2019 and developed over several years across dozens of pull requests. The core logic shipped in Bitcoin Core v26.0 (December 2023), and mainnet support arrived in v28.0 (October 2024) with the first hardcoded snapshot parameters at block height 840,000.

AssumeUTXO does not weaken Bitcoin's security model in the long run. After loading the snapshot, the node runs a full IBD from genesis in the background. When that background sync reaches the snapshot height, it compares its independently computed UTXO set hash against the hardcoded value. If the hashes match, the node has fully verified the entire blockchain. If they don't, the node shuts down with a warning.

How It Works

The process involves six distinct phases. At each stage, the node maintains one or two chainstate databases simultaneously.

Phase 1: Snapshot Loading

The user obtains a UTXO snapshot file (approximately 3.2 GB for mainnet) and loads it via the loadtxoutset RPC. Bitcoin Core validates the snapshot against the hardcoded hash using MuHash3072, then creates a second chainstate directory called chainstate_snapshot.

# Load a UTXO snapshot file
bitcoin-cli loadtxoutset /path/to/utxo-840000.dat

# Monitor sync progress of both chainstates
bitcoin-cli getchainstates

Phase 2: Catching Up to the Tip

The snapshot chainstate becomes the active chainstate. The node downloads and fully validates all blocks from the snapshot height to the current network tip. This catch-up phase takes roughly 80 to 90 minutes depending on hardware, compared to 10+ hours for a traditional IBD from genesis.

Phase 3: Background Validation

While the snapshot chainstate serves the network tip, the original chainstate performs a complete IBD from the genesis block. Cache allocation is split approximately 70/30 in favor of the snapshot chainstate to prioritize staying current with new blocks. This background process runs at lower priority and can take many hours.

Phase 4: Verification and Cleanup

When the background chainstate reaches the snapshot's base block, it hashes its independently built UTXO set and compares the result to the hardcoded value. On success, the snapshot chainstate replaces the background one, and the node is indistinguishable from a traditionally synced full node. On failure, the node halts with an error.

Generating and Verifying Snapshots

Any node operator can independently generate a UTXO snapshot using the dumptxoutset RPC and verify it against the hardcoded hash:

# Generate a snapshot at a specific height
bitcoin-cli dumptxoutset /path/to/output.dat rollback

# Verify the current UTXO set hash
bitcoin-cli gettxoutsetinfo muhash

The snapshot for height 840,000 contains 176,948,713 coins and has a MuHash value of a2a5521b1b5ab65f67818e5e8eccabb7171a517f9e2382208f77687310768f96. Anyone can reproduce this value by running gettxoutsetinfo at that height.

AssumeUTXO vs AssumeValid

Bitcoin Core has included assumevalid since v0.14.0 (2017). Both features share a philosophy of trusting developer-reviewed hardcoded values to speed up sync, but they optimize different parts of the process:

AssumeUTXO cannot be overridden from the command line because a malicious UTXO snapshot requires no proof-of-work computation, making it cheaper to produce than a fake blockchain. The hash is only settable in source code, where it undergoes peer review.

Comparison to Ethereum Snap Sync

Ethereum's snap sync (used by Geth) addresses a similar problem: letting nodes become operational faster. However, the two approaches differ in a fundamental way. AssumeUTXO eventually achieves full independent verification of all historical data through background validation. Snap sync does not re-execute historical transactions; it trusts Merkle-proven state from peers and only verifies new blocks going forward.

For a deeper look at how different Bitcoin node implementations handle synchronization, see the Bitcoin node implementation comparison.

Why It Matters

Running a full node is the most trustless way to interact with Bitcoin, but the time and hardware cost of IBD has historically been a barrier. Traditional IBD can take anywhere from 6 hours on high-end hardware to over a week on modest machines. AssumeUTXO reduces that barrier to under two hours, making self-custody and independent transaction validation more accessible.

This is especially relevant for infrastructure that depends on fully validating nodes. Layer 2 protocols like the Lightning Network and Spark benefit when more participants can spin up validating nodes quickly. Faster bootstrapping means operators can recover from hardware failures, scale infrastructure, or deploy in new regions without waiting hours for a node to become usable.

Use Cases

• Faster node recovery: if a node's chainstate database becomes corrupted, the operator can reload from a UTXO snapshot rather than replaying the entire blockchain from genesis.
• Infrastructure scaling: services that need to spin up additional validating nodes (exchanges, payment processors, Lightning routing nodes) can deploy new capacity in under two hours instead of waiting overnight.
• New user onboarding: users setting up their first Bitcoin node no longer need to wait a day or more before the node is functional, reducing one of the biggest friction points for self-custody.
• Development and testing: developers can quickly bootstrap mainnet nodes for testing and debugging without dedicating hardware to multi-hour sync processes.

Risks and Considerations

Temporary Trust Window

Between loading the snapshot and completing background validation, the node trusts the hardcoded UTXO set hash without having independently verified it. During this window, the security model relies on the same peer review process that governs all Bitcoin Core releases. A compromised hash could theoretically allow fake coins to appear valid, but this would require subverting the open-source release process itself.

External Snapshot Distribution

Users must obtain the snapshot file from outside Bitcoin Core (another node, a torrent, or a trusted host). The file is verified against the hardcoded hash, so a tampered snapshot will be rejected. However, the distribution mechanism introduces a practical dependency on external infrastructure. A draft BIP proposed in 2026 aims to enable P2P snapshot distribution, which would eliminate this requirement.

Resource Usage During Background Sync

Running two chainstates simultaneously increases disk I/O and memory usage. Nodes on resource-constrained hardware may experience slower performance while the background validation runs. The cache split (roughly 70/30 favoring the active chainstate) mitigates this, but operators should expect higher resource consumption until background sync completes.

Snapshot Compatibility

The snapshot format was redesigned in Bitcoin Core v28.0, making snapshots generated by earlier versions incompatible. Operators must ensure they use a snapshot file matching their node's expected format and height. Each Bitcoin Core release includes updated snapshot parameters: v28.0 supports height 840,000, v29.0 added 880,000, and v30.0 added 910,000.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.