#36543 validation: check the most recent AssumeUTXO commitment during IBD

Verifies the hardcoded AssumeUTXO commitment during normal Initial Block Download when block connection reaches the snapshot height and block hash. Pending UTXO modifications are synchronously flushed to disk, the serialized UTXO set is hashed, and a mismatch or failure causes the node to shut down with a fatal error. To prevent repeated multi-minute hashing passes during IBD, chainparams is simplified to store only the single most recent AssumeUTXO commitment per network, deprecating older snapshot activations.

Problem: AssumeUTXO relies on hardcoded snapshot hashes compiled into the node binary. Even though nodes running standard IBD independently reconstruct the exact UTXO set from genesis, they never compare it against the hardcoded commitment, passing up crowd-sourced verification of baked-in snapshot commitments against history (#32377).

Evidence of importance:

• Linked issue #32377 ('AssumeUTXO: crowdsource trust through independent snapshot verification') notes that every syncing full node could automatically audit hardcoded snapshot hashes during standard IBD.
• Commit 36a2a70452 explains: 'This checks the developer-provided commitment against the UTXO set that every node reconstructs during IBD (see #32377).'

Scope: Retaining only the single latest snapshot commitment is a breaking change for loading older AssumeUTXO snapshots or restarting snapshot chainstates built against retired commitments.

Risk of a mistake: medium (validation). It inserts a synchronous disk flush, multi-minute UTXO hashing pass, and potential fatal error exit into ConnectTip during normal block validation.

Changed since the previous assessment: Propagates snapshot verification errors out of ConnectTip as runtime errors instead of reporting success, and refines interruption handling so interrupted hashing during shutdown is not recorded as a validation failure.

Paused · Waiting on author

Open objections from Sjors, ajtowns, fametrano with no author reply for 7 days; review would repeat what has been asked.

Waiting on (from the thread read):

• author: addressing objections and suggestions from Sjors, optout21, ajtowns, and fametrano's assert bug report 2026-10-25

Blocked

objection that needs a change, nobody has replied (Sjors, fametrano)

Thread notes: fametrano gave a Concept ACK but reported a concrete correctness objection: an assertion failure occurs when the check fails because coins update before the chain tip, which also allows a restart to skip the check.

Objections, suggestions, and questions:

Support:

• Sjors (member) (Concept ACK, 2026-10-17): see #32377, with two caveats
• optout21 (contributor) (Concept ACK, 2026-10-17): As there is a hash provided that requires trust, the more checks the better. It makes sense to use all nodes performing IBD to also perform this check, as it's relatively cheap to do.
• fametrano (contributor) (Concept ACK, 2026-10-25) [both: ConnectTip, ConnectBlock, CheckBlockIndex, feature_assumeutxo.py]: (no reason given) [not substantive]

Participants:

• Sjors (member, objection, 1 statements 2026-10-17 to 2026-10-17): Concept ACK with caveats; objects to stopping on mismatch as an effective checkpoint, suggests keeping older commitments, and asks about flushing
• optout21 (contributor, support, 1 statements 2026-10-17 to 2026-10-17): Concept ACK; suggests an option to skip the check and keeping older commitments for visibility
• ajtowns (member, objection, 1 statements 2026-10-24 to 2026-10-24): objects that crashing IBD on mismatch makes bad snapshot releases worse for everyone, asks about performance impact, and suggests alternative approaches
• fametrano (contributor, objection, 1 statements 2026-10-25 to 2026-10-25): Concept ACK, but objects to assertion failure on mismatch leaving coins cache and chain tip out of sync, allowing restarts to bypass the check

145 lines under test/bench/ci.

• src/kernel/chainparams.cpp +21/-116
• src/validation.cpp +48/-31
• src/test/validation_chainstatemanager_tests.cpp +55/-9
• src/test/validation_tests.cpp +5/-17
• src/test/fuzz/utxo_snapshot.cpp +14/-6
• src/test/util/setup_common.cpp +18/-2
• doc/assumeutxo.md +15/-1
• src/kernel/chainparams.h +3/-11
• src/util/vector.h +0/-12
• test/functional/feature_assumeutxo.py +7/-5
• doc/release-notes-assumeutxo-latest-snapshot.md +11/-0
• src/rpc/blockchain.cpp +2/-5
• src/test/util/setup_common.h +7/-0
• src/validation.h +6/-0
• src/node/blockstorage.cpp +2/-3
• doc/release-process.md +1/-1
• src/external_signer.cpp +1/-1

The short text the ranking pass compares across PRs.

This PR verifies the hardcoded AssumeUTXO snapshot hash during standard Initial Block Download when block connection reaches the commitment height, triggering a fatal error and node shutdown on a mismatch. Full nodes independently rebuild the UTXO set from genesis during IBD, but previously never checked whether their reconstructed UTXO set matched the baked-in commitments (#32377). To avoid multiple expensive UTXO hashing passes during IBD, chainparams is changed to retain only the single latest AssumeUTXO commitment per network, retiring support for loading older snapshots.

P2 · new feature (ranking pass: Moved up: closes a real trust gap in hardcoded snapshot commitments, comparable to other assumeutxo correctness work)

Crowdsources verification of baked-in snapshot commitments against history during standard IBD. As noted in #32377, full nodes currently reconstruct the full UTXO set without auditing hardcoded AssumeUTXO commitments, leaving a trust gap in snapshot validation.

Membership: Has the Validation label and modifies block connection and chainstate flushing logic in src/validation.cpp to audit AssumeUTXO commitments during IBD.

Factors: security/stability 1, bug 0, performance 0, user value 1, leverage 1