Invariants / CN-MITHRIL-01

CN-MITHRIL-01

CN constraint enforced

A Mithril-sourced seed may bootstrap only after a verified binding: the Mithril manifest's attested {network_magic, genesis_hash, certified_point, certificate_hash} is cross-checked against the INDEPENDENTLY-minted BootstrapAnchor (minted from the operator's --json-seed UTxO + genesis, a different origin than the Mithril cert), and fails closed on any field mismatch BEFORE storage initializes. The Mithril STM multisig is verified by the RED mithril-client (acquisition infra) and is NEVER a BLUE trust root; no mithril/STM crate is imported under any BLUE crate path.

Source: docs/clusters/PHASE4-N-Y/S1-mithril-import-authority.md; S7-real-mithril-binding.md
Cluster: PHASE4-N-Y
Introduced in: PHASE4-N-Y

Enforcement trace

Code

Tests 5

mithril_binding_rejects_certified_point_other_than_seed_point
mithril_anchor_rejects_field_mismatch
mithril_import_fail_closed_blocks_storage_init
mithril_bootstrap_verifies_before_storage_init
mithril_bootstrap_fails_closed_on_seed_point_mismatch

CI 2

Cross-references

Strengthened in

Attack rationale

If Mithril provenance were a BLUE trust root, a forged/wrong-point snapshot would seed an attacker-chosen ledger. If the binding compared a value to itself (the S1 tautology, fixed in S7), a snapshot certified at a different chain point than the seed dump would bind successfully. The cross-check against the independently-minted anchor closes both. PHASE4-N-Z wires the production composition (bootstrap_from_mithril_snapshot) so the binding runs verify-before-bootstrap end-to-end, with a containment gate (DC-MITHRIL-02) preventing the seed_point origin from being laundered back to the manifest.