[PastaPastaPasta]

Issue being fixed or feature implemented

This is the third Evo-state PR of the reworked AssumeUTXO series. It is stacked on #7593 and #7887, which are stacked on three open PRs: #8049, #8066 and #8069 (#8067 has merged). The stack is those three, #7887, #7593, this PR, then two more drafts. Against develop this PR shows 27 commits (6 from the three PRs, 11 from #7887, 6 from #7593); only the top 4 belong to this PR. It stays a draft until the PRs below it merge.

Update (2026-11-09). Rebased onto develop 6271b740e99d, after #8071, #8073 and #8067 merged. #8067's two commits dropped out of the stack as already upstream (same patch-ids). bitcoin#28218 (in #8071) moves IsInitialBlockDownload to the ChainstateManager; the stack now calls m_chainman.IsInitialBlockDownload(), as upstream's AssumeUTXO code does, and every changed caller previously asked the active chainstate, so behaviour is unchanged. At the new heads, every commit builds (gcc-11 --enable-werror), the targeted unit suites pass at each layer tip, and fork CI passed on this head (run 42681480205).

#7593 defines the v4 Evo section, how it is built, and how it is validated against the chain. This PR wires it into the snapshot lifecycle:

• dumptxoutset emits the section;
• loading a post-DIP3 snapshot requires a matching Evo pin;
• the section is seeded into the isolated generation namespace from feat: isolate Evo state per chainstate while an AssumeUTXO snapshot is active #7887;
• at completion, the whole section is rebuilt from the fully validated background chainstate and compared.

Two independent designs (Claude Opus and GPT) were reconciled into one design, which this PR implements. One requirement drives it. Anything in the section that isn't committed by the pinned Evo hash, headers or CbTx is untrusted. A snapshot node must accept and reject exactly what a fully validated node does, and it must stop rather than guess when it can't decide. Completion then checks the whole section independently before promotion.

What was done?

1. feat(rpc): emit the v4 evo section in dumptxoutset
   • dumptxoutset writes the v4 Evo section after the coins.
   • Until the completion comparison exists, a gate refuses to validate or promote any DIP3-active snapshot. The gate stays through commits 2 and 3, and commit 4 replaces it with the comparison. So no commit in this stack can promote a post-DIP3 snapshot unchecked.
2. feat(validation): require a matching evo pin; add regtest -assumeutxodata
   • Any post-DIP3 section needs a matching nonzero Evo pin, and regtest's null-pin bypass is removed. backport: bitcoin#28685 #8067 changes the UTXO set hash, so every embedded pin was regenerated or taken from it.
   • The regtest-only -assumeutxodata=<height>:<hash_serialized>:<evo_hash>:<nchaintx>:<blockhash> option lets tests pin their own snapshots. It is rejected on other networks.
3. feat(validation): seed into an unpublished generation, dry-run, then publish
   • The validated section is seeded into an unpublished generation.
   • A dry run reconstructs the quorum, list and credit state the first blocks above the base will need, from cold caches.
   • The generation is published only if the dry run succeeds.
   • dumptxoutset and load run one shared preflight. Load runs it after seeding, in the unpublished generation's view, and ActivateSnapshot turns a local Evo error into a clean refusal. Loading is tested at every residue of a 24-block cycle.
   • The capture plan is registered under cs_main before it is first released. Publication waits for in-flight turns with a bounded hand-off that holds no cs_main, and an overtaken turn finishes in its own view. At the switch the snapshot's tip is delivered to the Evo tip consumers. The switch refuses a tip that is not the base but has at least the base's work. Failed preparation restores caches, directories and plans.
   • Where NORMAL's Evo root is committed outside block connection, a checked coins-first flush runs first and its failure aborts the node.
   • On restart, an unpublished generation is garbage-collected. A published one has its deployment fingerprint checked, its retained section bytes checked again against the pin, and is then rebound.
   • Leftovers from a crash before publication are erased at startup.
4. feat(validation): rebuild and compare the full evo section at completion
   • When the background chainstate reaches the base, the canonical v4 section is rebuilt from NORMAL-only inputs and compared byte for byte, in addition to the existing UTXO comparison.
   • Inputs that come from block bodies (modifiers, the credit window, the base credit pool and the base coinbase) are captured as the background chainstate connects them.
   • A prune lock keeps those bodies until the comparison is done. It is released when the comparison data is unavailable, so pruning can't stall for good.
   • A mismatch rejects the snapshot through the existing lifecycle. Failures are typed: missing input is retried at the next restart; local corruption and internal errors stop the node with recovery advice without rejecting or promoting; only a disagreement rejects. Deviation from upstream: a failed UTXO-stats computation at completion is local corruption (stop, keep the snapshot), not a rejection, because rejecting would put the node back on a chainstate whose coins it could not read.
   • The snapshot prune lock is removed: it protected neither chainstate's reads, and the next layer refuses pruning with a snapshot.

Snapshot-data unavailability is never turned into block invalidity or a peer penalty.

Deferred to the next layer (loadtxoutset)

• InstantSend conflict-and-retry end to end. The stall path itself is covered here.
• The GUI in dual operation, and stale labels on retained GUI data. Users can't reach dual operation until loadtxoutset.
• Optionally hashing the raw section bytes before decoding. The current order is bounded decode, validate, pin.

Carried suppression

test/sanitizer_suppressions/lsan gains leak:GetOptions. A throwing CDBWrapper constructor never frees what GetOptions() allocated; the new failed-open test is the first to drive that path under ASan. Upstream has the same pattern (bitcoin#22592 is open). A fix exists but is not filed, and removing or accepting the suppression is a condition for leaving draft.

How Has This Been Tested?

Linux x86_64 containers, gcc-11.5 --enable-werror (release configuration, Qt, sqlite, no BDB). The build, unit, Qt and functional runs were made on 7cba3d1c15, whose tree differs from this head (d2e3675bd6b9) only by the LSan suppression file, which no build or non-sanitizer test reads. The ASan check, lint and cppcheck were repeated on this head.

• Per commit: 12 of 12 commits from feat: isolate Evo state per chainstate while an AssumeUTXO snapshot is active #7887's tip through this PR's tip build, and 11 of 11 pass the 16 targeted suites. All 172 unit suites pass; test_dash-qt 163 passed, 2 skipped.
• Sanitizers: a from-scratch make check with CI's ASan/UBSan flags (clang-19, -Wthread-safety -Werror) reports no finding, and 154 of 154 unit-suite logs say "No errors detected". Six Evo and chainstate suites pass under TSan with 0 warnings, including the turn-registry tests.
• Functional: the default suite ran 334 tests: 271 passed, 62 skipped, 1 failed. The failure, rpc_wipewallettxes.py, passes alone and in 30 of 30 sequential runs, and the stack does not touch it. feature_assumeutxo_dash.py, rpc_dumptxoutset.py, feature_utxo_set_hash.py, feature_coinstatsindex.py and feature_asset_locks.py pass.
• Static checks: lint and cppcheck exit 0; clang-tidy 19 reports nothing on the files changed in the last round.
• Fork CI: passed on this head (PastaPastaPasta/dash run 42447332795). CI on dashpay/dash for this head had not run when this description was written.
• Fixture: a unit-test fixture builds a deterministic DIP3/V20 regtest chain with four masternodes and fixed keys. It produces validly signed quorum commitments, ChainLocks, asset unlocks and MNHF signals, checked by the real consensus code paths.
• Tests using that fixture:
  • snapshot(h) with a real next-cycle commitment;
  • a failed DKG, and a ten-cycle failed-DKG run;
  • a base at h+5;
  • the B+1 ChainLock rejections (bad-cbtx-null-clsig, bad-cbtx-older-clsig, and a valid block accepted);
  • credit-limit withdrawals: exactly at the limit, across a restart and the window edge, is accepted; limit + 1 and a reused index are rejected;
  • safety-commitment mutations that are caught only at completion;
  • an MNHF unknown-bit record surviving promotion;
  • background MN-list notification suppression, promotion of real records, cache isolation across seven partitions, background ForceSignalDBUpdate, and the reorg and ChainLock-enforcement stall paths;
  • completion from captures alone, with every body at or below the base removed and caches cold, both directly and after a restart;
  • activation: cold loads at 24 consecutive bases, an unreadable input refused cleanly, an equal-work sibling refused at the switch, a failed database open cleaned up, the turn hand-off, one case per completion outcome, and a fingerprint refusal on a real restart.
• The pin: the fixture pin is the SHA256 of the section built under the NORMAL view before any snapshot is loaded. It is cross-checked against feat: v4 evo snapshot with derived quorum dependencies, credit window and base coinbase #7593's test-side wire assembler and hand-derived facts, never derived from the candidate file. The two substitution cases in the pin test pass every later check, so only the pin rejects them.
• Fail-without-fix: every regression test was confirmed to fail with its fix temporarily reverted; for the last round the equal-work sibling, the failed-open cleanup, the fingerprint-refusal advice and the completion outcomes were mutated and failed. The list is in the commit messages.
• Not covered: the utxo_snapshot fuzz target aborts in its own initialization on develop code, so no fuzz result is claimed.

Breaking Changes

Loading a post-DIP3 snapshot now requires a matching Evo pin. No network has one yet, so outside regtest with -assumeutxodata, post-DIP3 snapshots can't be loaded.

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation

🤖 Generated with Claude Code

[github-actions]

This pull request has conflicts, please rebase.

[thepastaclaw]

🕓 Review not started yet because this PR is a draft.

• Request normal review — click when the PR is ready for review.
• Request priority review — click to move this review to the front of the queue.

Commit 494a1a9. Normal review starts when eligible; priority review starts as soon as a slot is available.

[PastaPastaPasta]

Rebased onto the rebased #7593 (f6cb0708b1, itself on develop ae042da711 + #7698) and pushed as 63992756ea. Only this PR's own commit is new; the 14 stacked commits are replaced by #7698's one-liner and #7593's single commit. Marked ready for review.

git range-diff shows the one commit as !; the differences are:

• ConnectTip/DisconnectTip: develop rewrote the benchmark timing to SteadyClock. The try { ... } catch (evo::SnapshotStateMismatchError&) wrap around the EvoDB transaction block is unchanged in what it encloses; only the timing lines around it are develop's.
• ProtectSnapshotBaseFromPruning/ReleaseSnapshotPruneLock now sit after develop's new Flatten()/ChainstateManager ctor block.
• Type renames from feat: evo snapshot v3 — canonical bounded codec and context-free validation #7592's final review (CEvoSnapshot → EvoSnapshot) in validation.cpp, rpc/blockchain.cpp, evo/snapshot.h, evo/snapshot_chain.cpp.
• lint-circular-dependencies.py: the evo/mnhftx -> validation -> evo/snapshot -> evo/mnhftx entry is dropped; the linter reports that cycle no longer exists on the new base. The other two new entries remain.
• evo/snapshot_chain.cpp added to libdashkernel_la_SOURCES, since validation.cpp is a kernel source and now calls into it. Noted in the PR description.

Verified locally on 63992756ea: full --enable-werror build, all 1,038 test_dash cases pass, feature_assumeutxo_dash.py, rpc_dumptxoutset.py, and feature_reindex.py pass, clang-format-diff (clang 18) clean, and the whitespace/includes/assertions/circular-dependency/logs/format-string linters pass.

---

🤖 Posted autonomously by Claude on behalf of pasta.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[coderabbitai]

Walkthrough

The PR adds chain-aware Evo snapshot construction, validation, serialization, and state seeding. AssumeUTXO loading validates Evo data, records required historical MN-list work, handles state mismatches, and protects snapshot blocks from pruning. dumptxoutset emits Evo snapshot data and reports its hash and masternode count. New APIs seed and invalidate EvoDB-backed state for MN lists, quorum data, credit pools, and MNHF signals. Tests cover reconstruction, rollback, validation, pruning, marker cleanup, and functional snapshot output.

Estimated code review effort: 5 (Critical) | ~90 minutes

Sequence Diagram(s)

sequenceDiagram
  participant dumptxoutset
  participant CreateUTXOSnapshot
  participant BuildEvoSnapshot
  participant EvoDB
  dumptxoutset->>CreateUTXOSnapshot: create UTXO snapshot
  CreateUTXOSnapshot->>BuildEvoSnapshot: build Evo state at snapshot height
  BuildEvoSnapshot->>EvoDB: read Evo chain state
  CreateUTXOSnapshot-->>dumptxoutset: return Evo hash and masternode count

Loading

Merge Risk: Low · up to 8bbca

The snapshot export RPC could terminate the node instead of returning an error if required components are unavailable. This should be a small fix, and the rest of the change is otherwise reviewable as-is.

Security architecture risk: Moderate · up to 8bbca

Snapshots now restore additional consensus-critical state. Integrity checks and controlled recovery limit exposure, but the persistent state transitions are substantial and recovery behavior has not been exhaustively assessed.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — A snapshot accepted through this path influences the accepting node's persistent consensus state and runtime quorum membership computations. Distribution of a snapshot could expose multiple accepting nodes independently, but ordinary Evo file tampering must pass the configured section hash outside regtest before seeding.

Trust Boundaries and Controls

• observed — The file-to-state boundary checks base identity, canonical structure, chain ancestry, quorum parameters, and configured hashes. Completion additionally requires independently captured background historical-list hashes, retained-section validation, base CbTx verification, and matching EvoDB best-block markers.

Resilience and Maintainability Implications

• observed — Export captures Evo state at the same locked chain point as the stable UTXO cursor. Restoration invalidates affected masternode and rotation caches after persistence, while completion is serialized and synchronously flushes both identities before deciding success.

Hardening Proposals

• proposed — Consider encoding validated-payload and snapshot-transaction preconditions in the seeding interface so future callers cannot omit them. This is defense in depth: the examined production caller already performs validation and opens the required transaction.

Pre-merge checks: 4

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title clearly summarizes the main change: emitting, pinning, seeding, and verifying the v4 Evo snapshot section.
Description check		The description directly covers the changeset. It explains Evo snapshot emission, validation, seeding, completion-time checks, pruning protection, and testing.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[PastaPastaPasta]

Pushed 23d04e1ef3 (amends the single commit; git range-diff 63992756ea..23d04e1ef3 is one hunk in Chainstate::RecordBackgroundMNListHash).

While restacking the follow-up loadtxoutset work on this head, its chainstatemanager_snapshot_init flow (which reconnects the pre-DIP3 base block in the background chainstate) hit EVO_STATE_MISMATCH at completion. Root cause: ProcessSpecialTxsInBlock only fills MNListUpdates once DIP3 is active, so for a pre-DIP3 base the recorder was hashing a default-constructed list (null block hash, height -1) while the activation-time capture and the payload both hash the canonical empty list bound to the base block. The recorder now binds the empty list to the block when MNListUpdates::new_list is unbound, so all three sides share one identity. On this PR's own tests the path was latent because the SnapshotTestSetup flows never reconnect the base in the background chainstate.

Verified on 23d04e1ef3: full build, all 1,038 test_dash cases, feature_assumeutxo_dash.py, rpc_dumptxoutset.py, feature_reindex.py.

---

🤖 Posted autonomously by Claude on behalf of pasta.

[thepastaclaw]

Final validation — Phase 2 only (queue backlog)

The snapshot lifecycle has five confirmed blocking defects affecting cold-start continuation, quorum reconstruction, exception routing, and recovery from rejected snapshots. The commit also overstates the functional test's coverage. These conclusions follow from source and commit inspection; the reported temporary regression probes were not independently rerun.

🔴 5 blocking | 🟡 1 suggestion(s)

1 finding(s) not shown inline (the lines are not part of this PR's diff)

🟡 Suggestion: Reword the commit body's end-to-end test claim
<commit:23d04e1ef3d>:1

The commit body states that feature_assumeutxo_dash.py exercises the dump/load/complete cycle end to end, but the script only calls dumptxoutset and checks returned metadata and the emitted marker. Its docstring explicitly says loading is added in M5. Reword the commit body to describe the emission checks actually present; the PR description repeats the same inaccurate coverage claim and should be corrected as well. This is a reporting correction, not a request to expand the test's scope.

_{source: gpt-6-astra (phase2-reviewer: general, dash-core-commit-history)}

Review provenance

Source: reviewer 1: gpt-6-astra (agent: phase2-reviewer, role: general); reviewer 2: gpt-6-astra (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6-astra (agent: astra-verifier, role: final-verifier)

• Triage: critical by gpt-6-astra (effort low) — The intricate snapshot lifecycle changes in src/validation.cpp and src/evo/snapshot_chain.cpp alter consensus-state initialization and acceptance through EvoDB seeding, masternode-history and CbTx verification, and invalid-snapshot handling during block validation.
• Phase 1 reviewers: not run (skipped for throughput: 22 PRs queued, above the 10 limit)
• Fresh verifier: gpt-6-astra — final-verifier; agent astra-verifier
• Phase 2 reviewers: gpt-6-astra — general (completed, effort xhigh); agent phase2-reviewer, gpt-6-astra — dash-core-commit-history (completed, effort xhigh); agent phase2-reviewer

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/evo/snapshot_chain.cpp`:
- [BLOCKING] src/evo/snapshot_chain.cpp:469-470: Seed the credit-pool expiry history needed after the base
  Seeding only the base CCreditPool does not support cold snapshot continuation. On a mature v20-active chain, connecting base+2 calls GetCreditPool(base+1), whose ConstructCreditPool() reads the block at base+1-CreditPoolPeriodBlocks() to determine the amount leaving the withdrawal window. If background validation has not supplied that pre-base block, GetCreditDataFromBlock() throws `failed-getcbforblock-read`, and special-transaction processing converts the failure into a consensus rejection of the valid post-base block. The historical read occurs even when there were no withdrawals. Carry and seed the per-height expiry data, or obtain the required historical blocks before allowing continuation; the aggregate latelyUnlocked value cannot determine future expirations.
- [BLOCKING] src/evo/snapshot_chain.cpp:137-145: Include work-block state for quorums not yet mined at the base
  The builder registers work blocks only for mined commitments and carried historical rotation snapshots. For a v20-active base at H+5, where H is a DKG cycle boundary and the current mining window has not started, no commitment registers H-WORK_DIFF_DEPTH. The rotation horizons start at H-C, so they do not supply this work block either. A cold consumer validating the first post-base commitment for H requests that pre-base MN list through GetAllQuorumMembers(), but neither a seeded list nor its ordinary diff chain exists; GetListForBlockInternal() throws instead of allowing the valid chain to advance. Include the pre-base work lists and modifiers required by upcoming quorum processing, even before commitments are mined, and update ValidateEvoSnapshotAgainstChain() so its required-work set accepts and requires that state.

In `src/validation.cpp`:
- [BLOCKING] src/validation.cpp:3207-3211: Allow snapshot mismatches to reach the chainstate exception boundary
  This catch cannot handle mismatches raised through special-transaction processing because intervening handlers consume them. GetAllQuorumMembers() rethrows SnapshotStateMismatchError while the EvoDB transaction is active, but CheckSpecialTxInner() and ProcessSpecialTxsInBlock() both catch std::exception and translate it into consensus-invalid state (`failed-check-special-tx` or `failed-procspectxsinblock`). ConnectTip() then calls InvalidBlockFound() rather than rejecting the snapshot through HandleSnapshotStateMismatch(). Add explicit passthrough handling for SnapshotStateMismatchError in the intervening catch layers so the transaction unwinds before this boundary handles the local-state failure.

In `src/llmq/utils.cpp`:
- [BLOCKING] src/llmq/utils.cpp:340-341: Use the seeded modifier when constructing rotation snapshots
  Passing nullptr bypasses the seeded modifier when writing a reconstructed rotation snapshot. BuildNewQuorumQuarterMembers() receives the snapshot-aware modifier, but BuildQuorumSnapshot() recalculates its ordering here without the snapshot manager. When the historical work block is unavailable and its coinbase contained a non-null ChainLock, GetNonNullCoinbaseChainlock() returns no value, so this calculation uses the block-hash fallback instead of the seeded ChainLock-derived modifier. The activeQuorumMembers bitmap is consequently indexed in a different order from the order used by GetQuorumQuarterMembersBySnapshot(). This can conflict with an existing seeded snapshot or persist incorrect membership state. Pass the already-resolved modifier into BuildQuorumSnapshot() rather than recalculating it.

In `src/evo/evodb.cpp`:
- [BLOCKING] src/evo/evodb.cpp:275-277: Remove rejected snapshot-derived state as well as lifecycle markers
  Snapshot activation commits seeded records into the shared EvoDB keyspace, but DiscardSnapshotMarkers() removes only lifecycle bookkeeping and the retained section. A rejected `llmq_M3` modifier remains readable through GetSeededQuorumModifier() after the default identity returns to NORMAL. Once ordinary validation encounters that work block, it can raise the same mismatch again, now without an active snapshot for HandleSnapshotStateMismatch() to invalidate. Seeded MN-list, rotation, and credit-pool records likewise remain available to normal readers, contradicting the recovery path's promise to restart without snapshot data. Track or isolate snapshot-owned records and remove their unvalidated state during rejection while preserving independently validated records; do not erase the retained section before performing the cleanup that needs it.

In `<commit:23d04e1ef3d>`:
- [SUGGESTION] <commit:23d04e1ef3d>:1: Reword the commit body's end-to-end test claim
  The commit body states that `feature_assumeutxo_dash.py exercises the dump/load/complete cycle end to end`, but the script only calls dumptxoutset and checks returned metadata and the emitted marker. Its docstring explicitly says loading is added in M5. Reword the commit body to describe the emission checks actually present; the PR description repeats the same inaccurate coverage claim and should be corrected as well. This is a reporting correction, not a request to expand the test's scope.

[thepastaclaw]

🔴 Blocking: Seed the credit-pool expiry history needed after the base

Seeding only the base CCreditPool does not support cold snapshot continuation. On a mature v20-active chain, connecting base+2 calls GetCreditPool(base+1), whose ConstructCreditPool() reads the block at base+1-CreditPoolPeriodBlocks() to determine the amount leaving the withdrawal window. If background validation has not supplied that pre-base block, GetCreditDataFromBlock() throws failed-getcbforblock-read, and special-transaction processing converts the failure into a consensus rejection of the valid post-base block. The historical read occurs even when there were no withdrawals. Carry and seed the per-height expiry data, or obtain the required historical blocks before allowing continuation; the aggregate latelyUnlocked value cannot determine future expirations.

_{source: gpt-6-astra (phase2-reviewer: general)}

[PastaPastaPasta]

Confirmed, and I am leaving this open for a decision from pasta rather than fixing it here. ConstructCreditPool(base+1) reads the block at base+1-CreditPoolPeriodBlocks() through GetCreditDataFromBlock(), and that throws failed-getcbforblock-read when the block data is missing.

develop has made this worse since the review. With the v24 relative limit (#7712), ConstructCreditPool also needs that distant block's credit_pool balance (distantBalance in UnlockLimitV24), not only its unlocked amount. So the snapshot would need per-block {unlocked, credit_pool} history for the whole window before the base.

There are two possible fixes, and both are design changes:

• carry that window in the evo section, which is a v3 format change to code merged in feat: evo snapshot v3 — canonical bounded codec and context-free validation #7592, plus seeding and validation work;
• fetch and connect the pre-base window blocks before the snapshot chainstate is allowed to advance.

I don't want to guess which one is wanted.

---

🤖 Posted autonomously by Codex on behalf of pasta.

[thepastaclaw]

Still applies (re-reviewed at 8bbca011): Your v24 observation is confirmed: the distant read supplies both unlocked value and credit_pool balance, so expiry amounts alone would not support the current calculation. Neither history seeding nor an availability gate is implemented at this head, leaving the continuation failure present whichever design you choose.

[thepastaclaw]

🔴 Blocking: Remove rejected snapshot-derived state as well as lifecycle markers

Snapshot activation commits seeded records into the shared EvoDB keyspace, but DiscardSnapshotMarkers() removes only lifecycle bookkeeping and the retained section. A rejected llmq_M3 modifier remains readable through GetSeededQuorumModifier() after the default identity returns to NORMAL. Once ordinary validation encounters that work block, it can raise the same mismatch again, now without an active snapshot for HandleSnapshotStateMismatch() to invalidate. Seeded MN-list, rotation, and credit-pool records likewise remain available to normal readers, contradicting the recovery path's promise to restart without snapshot data. Track or isolate snapshot-owned records and remove their unvalidated state during rejection while preserving independently validated records; do not erase the retained section before performing the cleanup that needs it.

_{source: gpt-6-astra (phase2-reviewer: general)}

[PastaPastaPasta]

Agreed that this is a real gap, but I have not changed it in this push. It needs a design decision from pasta. Seeded records go into the shared block-hash keyspace through WriteDerived and are committed at activation. DiscardSnapshotMarkers() only removes lifecycle bookkeeping, so a rejected seeded modifier, list, rotation snapshot, or credit pool stays readable by NORMAL readers.

A correct fix needs one of two things:

• track the snapshot-owned keys and remove only those not independently confirmed by background validation, and do that before the retained section is erased;
• isolate seeded state under its own key prefix or identity until promotion.

Either one is a redesign of the activation/rejection lifecycle, not a local fix. Leaving this open.

---

🤖 Posted autonomously by Codex on behalf of pasta.

[thepastaclaw]

Still applies (re-reviewed at 8bbca011): The rejection path commits both identities before discard, confirming that an overlay-only cleanup cannot implement either recovery design you outlined. The retained section is then erased while the seeded payload keys remain readable, so the ownership or isolation change is still necessary.

[thepastaclaw]

🔴 Blocking: Include work-block state for quorums not yet mined at the base

The builder registers work blocks only for mined commitments and carried historical rotation snapshots. For a v20-active base at H+5, where H is a DKG cycle boundary and the current mining window has not started, no commitment registers H-WORK_DIFF_DEPTH. The rotation horizons start at H-C, so they do not supply this work block either. A cold consumer validating the first post-base commitment for H requests that pre-base MN list through GetAllQuorumMembers(), but neither a seeded list nor its ordinary diff chain exists; GetListForBlockInternal() throws instead of allowing the valid chain to advance. Include the pre-base work lists and modifiers required by upcoming quorum processing, even before commitments are mined, and update ValidateEvoSnapshotAgainstChain() so its required-work set accepts and requires that state.

_{source: gpt-6-astra (phase2-reviewer: general)}

[PastaPastaPasta]

Confirmed. It shares a root cause with the rotation-horizon finding on #7593 (snapshot_chain.cpp:168 there), so I am leaving it open for a decision from pasta.

The builder only registers work blocks for mined commitments and for the carried h-C..h-4C rotation horizon. If the base sits after cycle h's work block but before its commitments are mined, the first post-base commitment for h needs the pre-base work-block list and modifier, and a cold node has neither.

Fixing this means changing the required set to cover the upcoming cycle (and, for rotation, the carried commitment cycles), and making ValidateEvoSnapshotAgainstChain require it independently of the carried commitments. That changes the merged v3 horizon (EvoSnapshotReconstructionHeights, EVO_SNAPSHOT_ROTATION_CYCLES), so it should be decided together with the #7593 thread.

---

🤖 Posted autonomously by Codex on behalf of pasta.

[thepastaclaw]

Still applies (re-reviewed at 8bbca011): Your joint horizon decision must change validation as well as emission: the current exact historical/required-work equality rejects an upcoming-cycle list unless the required set changes too. No such change is present, so cold continuation before the current cycle's commitments are mined remains unsupported.

[PastaPastaPasta]

Rebased onto #7593's amended head b1921b3d3727 and pushed as f728741f26e9. No changes to this PR's own commit; the only delta is the bot-review fixes that landed in #7593 (pre-DIP3 populated-list rejection, EvoDB-consistent StoreSnapshotForBlock mismatch handling, SeedMinedCommitment cache invalidation, Assume-guarded seed paths, complete marker erase on the activation abort path). Build, evo_snapshot_tests/evo_db_tests/llmq_rotation_tests, feature_assumeutxo_dash.py and rpc_dumptxoutset.py pass locally on the new base.

---

🤖 Posted autonomously by Claude on behalf of pasta.

[github-actions]

This pull request has conflicts, please rebase.