Draft demo: this is meant to showcase what complete AssumeUTXO removal could look like and the simplifications that AssumeUTXO currently prevents. The decision about complete removal is of course still open. This draft is meant to serve as a concrete reference for the smaller proposals below - it's not meant to be merged.
Smaller PRs: I will carve out individual changes to gauge interest in each part, and link them here as they are opened. Some of the findings are useful even if snapshot loading or background validation stays. Feedback on which parts seem worth pursuing, and in which order, is welcome.
Motivation: this follows our in-person discussion at the October 2026 Core Dev meeting. My impression was that there was rough agreement about the ambiguity background validation introduces: we trust a snapshot enough to use it immediately, but describe that trust as temporary until the same node finishes checking history.
Multiple chainstates affect much more than snapshot loading: ordinary validation changes have to account for different chainstate roles, candidate sets, notifications, downloads, pruning, cache allocation, database lifetimes and locks.
I am not sure this amount of complexity in the most critical part of our codebase is still worth it, given that adoption isn't where we hoped it would be.
Ordinary IBD is also getting faster: #35295 is already merged, and the upcoming pruneassumevalid will make pruned IBD even faster.
Snapshot bootstrapping without background validation can still offer an advantage: a new node becomes usable before ordinary IBD would finish because snapshot loading time scales with the UTXO set size, while ordinary IBD time scales with the blockchain size. Whether that is worth its maintenance cost is a fair question, and we can discuss it here or in the dedicated PR where I will propose the removal. Even after removal, we could decide to add it back in a cleaner way, for example isolated through IPC. This demo makes that cost, and the code we could remove, visible for that discussion.
Background validation can be considered separately: if we keep snapshot loading, I would prefer making its trust assumption explicit and distributing verification across ordinary IBD nodes, as proposed in #32377 and #36543. That could give us wider independent checking of the commitment without making every snapshot user maintain a second chainstate.
Users who want to validate history themselves and transition to an archival node could rebuild with -reindex and pruning disabled.
Alternatively, they could run IBD in a separate datadir while their snapshot node remains usable, then switch once it is ready.
@Sjors's #36557 discusses dropping mandatory background sync and these alternatives.
What the series demonstrates:
- After the fixture cleanup in #36601, the next eight commits remove background validation while snapshot loading keeps working, a stopping point that can be reviewed on its own.
- The middle commits remove snapshot imports and startup resumption, then the validation, block storage, notification and release-process special cases they needed.
- The final seven commits add the simplifications this removal enables: startup in one pass, stable database ownership, one download path, a single prune height, and removal of the locks and diagnostics used to select and identify chainstates.
Ordinary validation, -assumevalid, pruning, ChainstateManager and UTXO export (dumptxoutset) remain.
Related work:
- AJ's recent faster-loader branch and Sjors's chunked-import experiments explore reducing import overhead while retaining snapshot support.
- #35054 contains the broader discussion about P2P snapshot distribution, its users and its costs.