DC-EPOCH-08

DC derived enforced

The activation SOURCE WINDOW is named-role-typed, durable-lineage-pinned, and complete/ordered/bounded (S3f-4d-1). The window that produces an activation candidate is NOT generically "epoch N": the completed epoch whose admitted blocks the window drives over (source_epoch) is distinct from the epoch whose leadership reads the activated view (target_epoch), related by the Cardano Mark->Set snapshot lag. ActivationSourceWindow names every role (source_epoch, source_window_start, source_window_end, snapshot_phase, target_epoch, source_window_anchor, lineage_pin). The lag lives in ONE named constant LEADERSHIP_SNAPSHOT_LAG_EPOCHS (a PROOF OBLIGATION), applied only via target_epoch_for_source -- never an inline source+k. validate_source_window fails closed unless the blocks are: non-empty; within [start, end] (bounded); strictly increasing by slot (ordered, no duplicate); a CONTIGUOUS chain (block[0].prev_hash == source_window_anchor, block[i].prev_hash == block[i-1].hash -- so no block is missing = complete); the last block's hash == lineage_pin (pinned to the selected ChainDB lineage tip); and target_epoch == the explicit source->target mapping. NO peer/network read, wall-clock, or async side channel influences the window.

Source: docs/clusters/EPOCH-CONSENSUS-VIEW/SLICE-3f4d-live-flip.md (S3f-4d-1); user directive 2026-06-21 (durable ChainDB source only; named roles; the Mark/Set lag is a proof obligation)
Introduced in: EPOCH-CONSENSUS-VIEW-S3f-4d-1

Enforcement trace

Code

Tests 8

target_epoch_is_the_explicit_lag
valid_window_passes
empty_window_fails_closed
out_of_window_block_fails_closed
unordered_and_duplicate_fail_closed
missing_block_breaks_the_chain
anchor_and_lineage_pin_fail_closed
wrong_target_epoch_fails_closed

CI 1

ci_check_eview_source_window.sh

Cross-references

Attack rationale

The candidate must be derived ONLY from the selected, admitted durable chain -- never a peer/file/cache/reconstructed range: the window is pinned by source_window_anchor (the pre-window tip the first block links to) AND lineage_pin (the tip the last block IS), and every intermediate link is checked (block[i].prev_hash == block[i-1].hash), so a missing/duplicate/out-of-window/forked block fails closed BEFORE a candidate is produced. The Mark->Set off-by-one is structurally prevented: target_epoch is never an inline source+k -- it is the single LEADERSHIP_SNAPSHOT_LAG_EPOCHS constant via target_epoch_for_source, and validate_source_window rejects any window whose target_epoch is not that mapping. The exact lag is an explicit proof obligation, not a buried assumption.

Evidence notes

Introduced at EPOCH-CONSENSUS-VIEW S3f-4d-1 (2026-06-21), the first sub-slice of the live flip. The named-role window type + the pure validation + the explicit source->target mapping -- HERMETIC, no live behaviour. 8 fail-closed proofs + ci_check_eview_source_window.sh; cargo test -p ade_node --lib (epoch_source_window 8) green. The user flagged the Mark/Set off-by-one as load-bearing: the lag is one auditable constant marked PROOF OBLIGATION (=2, the Set-phase 2-epoch leadership lag), pinned by the snapshot-timing proof + the live leadership-schedule proof. Next: S3f-4d-2 (candidate derivation: window -> drive_window_aggregate -> form_mark_snapshot -> bind), then S3f-4d-3 (the live orchestration + flip), gated on the two live proofs.