N2-A0 — stored-key inventory before Did canonicalization (#2623)

Status: living — investigation record for the N2-A0 tranche Truth class: descriptive Canonical: no — docs/architecture/IDENTITY_SEMANTICS.md owns the semantic contract; this document owns only the measured stored-key surface that gates I7 Last reviewed: 2026-08-19 — fresh-context adversarial review (second pass); every headline measurement re-run, verdict classes made mechanical, missed keyspaces added, #54 resolved Source basis: live origin/main at 798c8d54422d9916bca8261d0540fd0755a1fc1f (the Rust workspace is byte-identical to bca3dd0e, the first pass's basis; only docs/scripts moved) Gates: N2-A / #2627 (Did canonicalization, I7) Contract: IDENTITY_SEMANTICS §3, §7.5, §11 (I7, I8), §14 (N2-A0, marked HARD GATE)

1. What this document is, and is not

Is. An enumeration of every durable or durability-adjacent keyspace in the workspace in which a Did, a string representation of one, bytes derived from one, or a composite key containing one is used as an identity-bearing key — together with what happens to each if I7 changes Did equality from inner-string equality to decoded-key equality.

Is not. It changes no code. Did, its Eq, its Hash, its constructors and every encoding are untouched. Nothing is canonicalized, re-keyed, migrated or rewritten. It selects no account domain (that is N2-C′ / #2625) and retypes nothing. Completing it does not make I7 safe — it makes I7 attemptable, which is the whole of what §14 asks of a HARD GATE.

Do not infer production readiness, migration readiness, or deployment status from this document.

2. The hazard, measured rather than assumed

§14 states the hazard as a possibility: distinct persisted rows can silently merge. The first job of this tranche was to find out whether that possibility is reachable in practice. It is, and by a wider margin than the contract assumes.

2.1 Did validation accepts any multibase encoding

Did::from_str (icn/crates/icn-identity/src/lib.rs:211) validates by calling multibase::decode(encoded_part) and stores the string as spelled (Ok(Did(s.to_string()))). Multibase is self-describing: multibase::decode reads the first character as a base code and dispatches across every base the crate supports. The dependency is multibase v0.9.2, pinned in icn/Cargo.lock (grep -A1 'name = "multibase"' icn/Cargo.lock; direct dependency of icn-identity and icn-trust); its multibase::Base enum declares 24 bases (the build_base_enum! table in the crate's base.rs: Identity, Base2, Base8, Base10, Base16Lower/Upper, Base32Lower/Upper/PadLower/PadUpper/HexLower/HexUpper/HexPadLower/HexPadUpper/Z, Base36Lower/Upper, Base58Flickr/Btc, Base64/Pad/Url/UrlPad, Base256Emoji). Nothing in from_str pins base58btc. Only Did::from_public_key emits base58btc; nothing requires an incoming DID to use it.

impl Deserialize for Did (lib.rs:183) routes through from_str; Serialize is derived over the inner string. So every alternate encoding is reachable by ordinary deserialization — wire, API body, or persisted JSON read back off disk — and survives a round trip unchanged.

Measured against the real type (probe §13.4; identical at bca3dd0e and 798c8d54):

So every ICN public key has at least 23 valid, storable, wire-acceptable spellings today (the first pass said 22 — it did not try Base256Emoji, which is always accepted, or Identity), and they are 23 distinct keys in every Did-keyed structure. Under I7 they become one. The merge factor for a fully exercised aliasing attack is at least 23:1, not 2:1.

2.2 The aliasing is attacker-chosen, and signatures do not constrain it

SignedEnvelope::verify_classical (icn/crates/icn-net/src/envelope.rs:267) derives the verifying key from self.from.to_verifying_key() — the DID as spelled on the wire — and to_verifying_key also uses multibase::decode. SignedEnvelope::new takes from as a parameter independent of the signing keypair. And canonical_encoding() (envelope.rs:403), the bytes that are actually signed, covers sequence ‖ timestamp ‖ payload_type ‖ payload — from is not signed (already noted in #2480). The signature binds the key, not the spelling.

Measured (probe §13.5): a sender signed sequence 5 under its canonical DID and sequence 5 again under a base16 spelling of the same key — both verify, the from fields differ, and the same-sequence envelope signed by a different key does not verify (the control that proves the signature still binds the key). Then, with no key material, a captured envelope had only its from rewritten to the base16 spelling: signature bytes unchanged, still verifies.

Run through the real ReplayGuard (replay_guard.rs, keyed by envelope.from; production caller handlers/signed.rs:105 check_replay_only): canonical seq 5 accepted; a second canonical seq 5 rejected ("Replay detected … sequence 5 already seen" — the control); the alias seq 5 accepted; peer_count() = 2, two independent max_seq floors. In persistent mode the store holds two replay_max_seq: and two replay_finalized: rows — one per spelling — and a fresh guard reloads 2 windows. Nothing on the handle_signed path requires envelope.from to equal the connection's Hello-bound DID (the connection-level authenticated peer is used for rate limiting only), and the #2506 self-drop envelope.from == self.own_did is string equality too.

So not only does a sender choose its own key's spelling per message — any party holding a captured envelope can re-spell it and replay it, up to 22 more times (23 spellings). This makes the aliasing surface adversarial rather than accidental, which changes the verdict for every store keyed off a wire-supplied DID. What the probe does not show is that a particular downstream consumer acts twice on the replayed payload (gossip payloads may be de-duplicated by content hash further down); it shows the sequence-number replay protection at the envelope layer is bypassable.

2.3 Anchor-derived DIDs are not round-trippable

Did::from_anchor_id (icn/crates/icn-identity/src/anchor.rs:194) base58btc-encodes 32 bytes of SHA-256 anchor id and wraps them with new_unchecked, bypassing validation. The result is syntactically indistinguishable from a key-derived DID — is_anchor_did() returns true for both.

But Deserialize validates as Ed25519. A uniformly random 32-byte string decompresses to a valid curve point with probability ≈ ½, so the expected failure rate is about half — not a corner case.

Measured (probe §13.4): over 200 deterministic SHA-256 anchor ids, 90 round-tripped, 110 failed (the first pass reported this as "55%"; that is sampling noise at n = 200). At n = 20,000 the rate is 9,949 / 20,000 = 49.7%; through the real Anchor::from_vui(..).to_did() path it is 989 / 2,000 = 49.5%; and for cooperative treasury DIDs exactly as production constructs them (icn-coop/src/actor.rs:493, :788 — Did::from_anchor_id(derive_treasury_anchor(coop_id) ‖ [0u8; 16])) it is 2,459 / 5,000 = 49.2%. An anchor-derived DID can be written to durable storage and then fail to deserialize on read-back; icn-ledger/src/treasury.rs:980 load_from_store does if let Ok(treasury) = serde_json::from_slice(..) and silently skips such rows. This is a live defect independent of I7 (§10.1), owned by N2-B / #2628.

2.4 Reproducing these measurements

The probes are not committed (this tranche adds no code). To reproduce, add a temporary integration test to icn-identity and icn-net respectively; the exact sources used are recorded verbatim in §13. Delete them before taking any repo-wide count — they contain Did::from_str and HashMap<Did, _> and inflate S1/S7 while present.

3. The classification frame — what I7 actually moves

I7 changes Did's Eq and Hash. It does not change Display, to_string, as_str, or any serialization. That distinction decides every row below:

The migration surface is therefore not "everything containing a DID". It is precisely the stores whose durable rows are keyed by a DID string while their consumers re-key by Did — where a rebuild collapses N durable rows into one map entry lossily — plus the constructs above that I7 moves out of step with a partner construct it does not move.

Class labels used in the tables (from #2623):

• A purely ephemeral · B ephemeral but reconstructed from durable state · C serialized wholesale · D directly a durable key · E externally round-tripped through API/wire, then used as a durable key

Verdicts are exactly the three #2623 classes: SAFE, SILENT-MERGE RISK, NEEDS MIGRATION, plus an explicit UNRESOLVED for candidates that cannot be classified on repository evidence. Every row also carries a liveness note where it matters: live (reachable from a production binary), dormant (writer and reader exist in library code but no binary constructs the store — e.g. icn-governance's SledGovernanceStore and StewardStore, which nothing outside their own modules and tests instantiates; the live twins are apps/governance/src/state_store.rs and icn-commons/src/store.rs), or dead (write path unreachable from any binary). The migration list N2-A inherits is NEEDS MIGRATION ∧ live; dormant NEEDS MIGRATION-shaped stores are listed separately so N2-A fixes the shape without a data migration.

3.1 Verdict classes — the mechanical rule

The three #2623 classes are assigned by one rule, checkable per row, not by judgement of how bad a merge would feel. Throughout, "moved by I7" means changes behaviour when Eq/Hash become key equality; Display, as_str, Serialize and every durable byte are not moved.

• NEEDS MIGRATION — I7 alone leaves the store inconsistent, so a re-key/de-dupe step must ship with or before it. Exactly one of: (a) durable rows keyed by a DID spelling and at least one production consumer re-keys those rows by Did (or by a wrapper whose derived Eq/Hash delegates to Did, or by Vec<Did>::contains) — so after I7 a rebuild collapses N aliasing rows into one entry lossily (overwrite / sum / first- or last-writer) while the N durable rows persist and are re-read on every start; (b) a structure serialized wholesale (Serialize/Deserialize derive) whose map or set is keyed by Did, so decode collapses aliasing keys silently (wire or disk); (c) a String-keyed, DID-shaped durable structure that a production path parses back into Did and inserts into a Did-keyed map or set; (d) a durable key derived from the spelling (hash or splice) that sits behind an authorization or identity gate which compares by Did — after I7 the gate and the key disagree and the divergence is created by the change.
• SILENT-MERGE RISK — durable rows (or String-keyed DID-shaped structures) keyed by a spelling with no Did-re-keying production consumer. I7 leaves them physically unchanged; point lookups by an alternate spelling miss, as they do today. No re-key step is forced by I7 itself, but N2-A's pre-migration scan must still enumerate their aliasing rows, and if N2-A chooses the pin-at-parse mechanism (§12) every alternate-spelled row in this class becomes unreachable. Also in this class: in-memory Did-keyed structures that I7 moves out of step with a partner construct it does not move (PeerId's Ord, #52).
• SAFE — ephemeral only: no Serialize, no store write, no load-from-durable rebuild; or already key equality (#55); or a durable write path that is unreachable from any production binary (marked dead — flagged for deletion, not migration).
• UNRESOLVED — evidence not obtainable from the repository. After this review: none.

A row's class therefore follows from three facts a reviewer can re-check: is the key durable or serialized; is it keyed by spelling or by Did; does any production path re-key it by Did. Where a consumer row in §6 re-keys a keyspace row in §5, the keyspace is counted once in the migration list and the consumer row is the evidence of mechanism.

4. Search methodology (re-runnable)

Run from the repository root (counts below re-verified at 798c8d54, with no probe files present — §13.4/§13.5 contain Did::from_str and HashMap<Did, _> and inflate S1/S7 while they exist). Every class was run independently; no single grep is load-bearing. S1–S10 are the first pass; S11–S14 are the second-pass classes that found what S1–S10 missed.

S1 — structural, type-driven. Collection types parameterized by Did: rg -g '*.rs' 'HashMap<\s*(&\s*)?Did\b|BTreeMap<\s*(&\s*)?Did\b|DashMap<\s*(&\s*)?Did\b|HashSet<\s*(&\s*)?Did\b|BTreeSet<\s*(&\s*)?Did\b|IndexMap<\s*(&\s*)?Did\b|LruCache<\s*(&\s*)?Did\b' → 108 sites, 0 under a tests/ directory (the first pass's "105 outside tests" does not reproduce: nothing is excluded by path). One of the 108 (icn-kernel-api/src/proofs.rs:490) is the kernel type Did = String alias, not icn_identity::Did — which is why a BTreeMap<Did, _> can compile at all (icn_identity::Did has no Ord) — so 107 are real. The first pass also silently dropped the three LruCache<Did, _> hits from its tally (icn-federation attestation_store.rs:22, icn-trust precompute.rs:34, icn-trust trust_cache.rs:39); they are counted here (§7).

S2 — durable engines. rg -l -g '*.rs' '\bsled\b' → 174 files across 17 crates; rg -g '*.rs' -g '*.toml' 'rusqlite|sqlx|rocksdb|redb|heed|lmdb|sqlite' → no second durable engine in the Rust workspace. sled is the only durable KV engine.

S3 — the store seam. icn-store::Store (icn/crates/icn-store/src/lib.rs:312) is byte-keyed (get(&self, key: &[u8]), put(&self, key: &[u8], …)). This is why S1 alone is insufficient: by the time a DID reaches storage it is already a String or Vec<u8>, so a type-driven search structurally cannot see it. Every later class exists because of this.

S4 — key-construction sites. Key-builder functions taking a Did: rg -g '*.rs' 'fn [a-z_]*key[a-z_]*\([^)]*: *&?Did' → 30 production builders. Plus the raw idiom rg -g '*.rs' 'extend_from_slice\([a-z_]*did[a-z_]*\.as_str\(\)\.as_bytes\(\)\)' → 23 sites.

S5 — durable roots. rg -l -g '*.rs' 'sled::Db|sled::Tree|sled::open|sled::Config' → 69 files; ranked by identity-term density (§13.1) to order the read.

S6 — serialized maps. An AST-approximating pass (§13.2) matching Did-keyed collections inside #[derive(…Serialize/Deserialize…)] structs → class C members.

S7 — free-form DID parsing (class E). rg -g '*.rs' -g '!**/tests/**' 'Did::from_str\(|\.parse::<Did>\(\)' -c . → 168 sites outside tests/ directories across 20 workspace members (15 crates, 4 apps, 1 binary; 46 in icn-gateway, 22 icn-ledger, 20 icn-rpc, 18 icn-core; 183 including tests/). The first pass's "176 / 47" does not reproduce under any exclusion tried and is withdrawn. Every one accepts all 23 spellings. These are parse sites, not sinks; the sinks they reach are the §5 keyspaces.

S8 — wrapper types. §13.3 matching newtype structs over Did, enum variants holding a Did, and structs with a Did field → 147 distinct structs carrying a Did field and 5 distinct newtype/enum-variant wrappers (PeerId; the Did / Person / Query / Remote variants). This class is invisible to S1 and produced findings #25 (Grantee::Person) and #52 (PeerId); AccountId::Did led the first pass to #9, though #9's physical key turned out to be serde_json(Did), not AccountId.

S9 — non-Rust persistence. rg -g '*.ts' -g '*.tsx' -g '*.js' 'localStorage|IndexedDB|AsyncStorage|SecureStore|\.setItem\(' over sdk/ web/ website/ apps/ → no DID-keyed durable store; see §9 coverage limits.

S10 — legacy/compatibility loaders. rg -i 'migrat|legacy_|from_legacy|schema_version|LEGACY' and targeted reads of the known migration paths (§8).

S11 — persistence-first (second pass). Start from every durable root (S5's 69 files plus every icn_store::Store consumer and every sled::Db holder in apps/ and bins/), enumerate its key builders, and ask of each key whether it embeds a DID spelling — directly or through EntityId, StewardId, member_id, voter, author, owner, holder, grantee, assignee, treasury_did, claims.sub. This is the pass that found §5's review additions: S1 cannot see a key that is already a String or Vec<u8> (S3), and S4's fn *key*(… &Did) pattern misses builders that take &str, String or a wrapper.

S12 — consumer-first (second pass). Every scan( / load_* / restore_* / rebuild_* followed by Did::from_str or .parse::<Did>() and an insert into a Did-keyed map or set (rg -n -A12 'fn (load|restore|rebuild)' … | rg 'from_str|parse::<Did>'). This is what resolved #54 and found the icn-net snapshot restore (#57) — the consumer side that decides NEEDS MIGRATION under §3.1.

S13 — file-backed durable state (second pass). icn-snapshot/src/lib.rs field by field (every String-keyed map and what restores it), save_snapshot/load_snapshot callers, std::fs::write / File::create / serde_json::to_writer with DID-shaped content, keystore and data-dir writers. The only DID-keyed file-backed state is the snapshot (§8).

S14 — liveness. For every store in §5/§6, whether any production binary constructs it (rg 'TypeName::(new|open|with_store)' outside the defining module and tests/). This is what reclassified icn-governance's SledGovernanceStore/StewardStore rows as dormant and four icn-ledger/icn-store/icn-gateway stores as dead.

5. Inventory — durable keyspaces (class D/E)

Key encoding column reads left to right as the physical byte layout. The consumer column is the §3.1 test: a production path that re-keys these rows by Did makes the row NEEDS MIGRATION; "none" means the rows stay physically separate under I7. No write path anywhere re-encodes a DID canonically before persisting (S11: Did::from_public_key has 42 non-test call sites and every one takes a keypair or VerifyingKey directly; zero re-derive from a parsed Did; no canonical()/normalize() helper exists), so the old Normalization column was "none" for every row and is replaced by the consumer column.

Rows #1–#3 have since been discharged for the ReplayGuard — see the §10.2 status note. They are left as measured here, because this table is the record of what was true at the basis commit and the fix is a later event.

5.1 Durable keyspaces the first pass missed (found by S11–S14)

Numbering continues after §6/§7 so earlier references stay stable. Most are point-lookup splits (SILENT-MERGE RISK); #65, #68 and #69 are NEEDS MIGRATION.

6. Inventory — reconstructed indexes and serialized maps (class B/C)

These are where I7 actually collapses rows, because durable rows are re-keyed by Did on load or on decode. A consumer row and its keyspace row are one entry in the migration list (§12).

6.1 Structures the first pass missed (found by S11–S14)

7. Inventory — assessed and found safe (class A)

Purely ephemeral, not reconstructed from durable state, and not serialized. I7 changes their contents only for the lifetime of a process, which is the intended effect of I7 rather than a hazard.

The count is derived, not curated. Search class S1 returns 108 Did-keyed collection lines (none under a tests/ directory). Attribute each line, not each file:

Re-derive with S1 and subtract the lines above — the arithmetic is the audit, so nothing is excluded by assertion. (The first pass reported "105 → 39 → 66": it attributed by file, dropped the three LruCache<Did, _> lines, and counted actor/mod.rs:1098, icn-rpc auth.rs:378 and icn-trust lib.rs:872 as safe — each of which is in fact the consumer that makes its keyspace NEEDS MIGRATION.) By crate:

Representative fields, so the shape of the set is legible:

icn-net: rate_limit.rs:1026 buckets + :1187, blob_registry.rs:137 per_peer_size + :355 peer_counts, actor/mod.rs:1106 relay_proxies, candidate_cache.rs:24 candidates · icn-gossip: sync.rs:223 states, partition.rs:39 last_seen + :356 healing_in_progress, handlers/blob_transfer_state.rs:170 per_peer_counts, handlers/provider_registry.rs:156 exclude · icn-core: init_notifications.rs:26 ProfileCache, version_tracker.rs:21 peer_versions, upgrade.rs:29 + upgrade_actor.rs:117/118, trust_propagation.rs:93/95 · icn-trust: anomaly.rs traversal sets (:160/161/320/601/602/638/673/715/723/798–801), pathfinder.rs:144 visited, trust_cache.rs:39 and precompute.rs:34 (LruCaches — ephemeral, though post-I7 TrustCache serves a score computed over spelling-A edges to a spelling-B lookup) · icn-governance: handle.rs:140/171/172, discussion.rs:376 participants, delegation.rs:856 visited · apps/governance: actor.rs and manager.rs / http/handlers.rs eligible-voter / excluded-delegator sets · icn-privacy: onion_routing.rs:101 peer_public_keys, :365 trust_scores · icn-gateway: auth.rs:160 in-memory challenges (the icn-rpc twin is store-backed and is #29) · icn-ledger: ledger_impl/witness_ops.rs:82, 163 transaction_parties.

Count: 58 sites, verdict SAFE. Every one is process-local: no Serialize derive, no Store/sled write path, and no load-from-durable rebuild. Several (eligible_voters, excluded_delegators, visited, exclude) are function parameters or traversal scratch rather than stores at all; they are counted because S1 returns them and silently dropping grep hits is how a coverage claim becomes unfalsifiable.

One further genuine SAFE, and the reason it is safe is the useful part:

8. Legacy and compatibility paths examined

The inventory must cover data current code can load, not only data it creates.

9. Identifier-domain classification (descriptive only)

Per #2623 §5 and IDENTITY_SEMANTICS §3. This retypes nothing and does not answer N2-C′.

Observations, recorded and not acted on. The node domain has no durable type (§3 says so explicitly), so #45/#54 key node identity by Did/String with nothing distinguishing it from a person. icn-security's four keyspaces sit squarely in unknown/legacy-mixed: a reputation row may describe a node, a device or a person and nothing in the key says which — which is why their merge consequence cannot be reasoned about per-domain and they are classified by exposure instead.

10. Findings that exist independently of I7

Per #2623's scope rule, these are documented, not fixed; none is in N2-A0's or N2-A's scope. The review's disposition of each is recorded at the end of its entry (owner issue, or why no issue).

10.1 Anchor-derived DIDs are unreadable about half the time

from_anchor_id writes via new_unchecked (no validation); Deserialize reads via from_str (Ed25519 validation). Measured ≈ 50% failure (§2.3: 110/200, 9,949/20,000, 989/2,000 via Anchor::from_vui, and 2,459/5,000 for cooperative treasury DIDs exactly as icn-coop constructs them). Any durable store holding an anchor-derived DID in a serde-decoded field can fail to load; icn-ledger/src/treasury.rs:980 load_from_store skips such rows silently, so about half of cooperative treasuries would drop out of the treasury manager's maps on reload; icn-gossip/src/gossip.rs:1380 restore_state is the opposite failure mode — one unparseable DID aborts the whole gossip restore. This is a live read-path defect, not constructor hygiene. Disposition: owned by I8 / N2-B (#2628, "compatibility-only reads come first … closes the deserialization-path defect"); the measurements above are recorded on #2628 (comment of 2026-08-19) rather than in a duplicate issue, with the note that the compat-read half may deserve to be pulled ahead of N2-A.

10.2 Any party can re-spell a captured envelope and replay it

§2.2 proves both envelopes verify and that the signature does not cover from, so a third party with no key material can rewrite from to an alternate spelling and the ReplayGuard opens a fresh window for it. Rows #1–#4 and map #37 are keyed by the wire spelling, so one principal's traffic has up to 23 independent replay floors, and apps/trust-app/src/sequence.rs (#71) is a fourth instance of the same class for attestation issuers. Replay protection at the envelope-sequence layer is bypassable today. This is the highest-severity finding in this document and it is not caused by I7 — equality-over-bytes would reduce it (one in-memory window per key) but not close it (the durable rows #1–#3 are spelling-keyed and from stays unsigned); pin-at-parse or signing from closes it. Disposition: no existing issue owned it (#2480 observed "from is not in the signed bytes" and concluded it did not matter; it did not consider spellings). Filed by this review as #2640 (epic:trust-hardening, security-review).

10.2 status — closed at the replay-protection boundary (2026-08-19, #2640)

The measurements above stand as taken; this records what changed underneath them.

Fixed, in icn-net only. The ReplayGuard's identity is now the sender's decoded Ed25519 key (SenderPrincipal), not the wire spelling. In memory, map #37 is keyed by it. Durably, rows #1 (make_sender_regime_key), #2 (make_max_seq_key) and #3 (make_finalized_key) are written under the principal's canonical base58btc spelling, and a migration pass at load_persisted_state collapses pre-existing spelling-distinct rows onto that one key wherever one key can carry their combined meaning: high-water rows merge to the maximum only inside a single (semantic_version, sender_regime) group — the unit within which two numbers are comparable at all — provenance rows join to the strongest established regime, and finalized sequences take the union. The canonical row is flushed before any alias row is retired. A re-spelled captured envelope is therefore rejected by the replay guard, and the self-DID drop in handlers/signed.rs (§10.2's "related sub-instance") now compares keys rather than strings.

Rows #1 and #2 are also joined across keyspaces, under a rule of their own. Row #2 carries a number together with a sender_regime field naming the namespace that produced it; row #1 is one version-less u32 naming the namespace the sender was last known to have established, written at state transitions and deliberately outliving the number beside it (cleanup() retires row #2 and keeps row #1). Row #1 therefore settles the common aged-out case, where it is the only evidence — but where a current-version row #2 has already placed the number in a different namespace, both facts are true and they disagree, and row #1 may re-establish the regime without re-tagging the number (#2644). Durable provenance meeting a legacy-tagged current-version floor enters the ordinary sender-regime migration rather than reinterpreting that floor as a durable bound; a promotion discards the retained number only when the namespace being retired is the one that produced it. Detaching a number from its namespace fails in whichever direction the detachment runs: relabelling a legacy floor as durable turns an honest peer's legitimate low sequences into scored Violation::ReplayAttack events, while discarding a durable floor under a fossil transition record hands an authenticated sender back every sequence that floor rejected.

Canonicalization is deliberately partial; two shapes stay physically distinct. There is exactly one canonical key per SenderPrincipal, so a merged row can record only one interpretation. Where a principal's rows carry two, converging them destructively would lose one, so the pass writes nothing and deletes nothing in these cases:

• Readable rows spanning several semantic versions (canonicalize_max_seq_rows). semantic_version selects how a persisted number is to be read, not how large it is, so "most restrictive version" is not a safe tie-break here: the legacy version wins that comparison, and collapsing onto it would replace a current-version durable floor with a legacy row whose number the load pass discards — leaving a floor of 0 once the bounded migration hold expires.

• Readable rows spanning several sender regimes, within one version (#2644). The same argument one axis over, and the sharper case: sender_regime names the namespace that produced the number, and numbers from two namespaces are not comparable at all. An earlier pass resolved such a pair to a single TransitionToDurableV1 row carrying max(durable, legacy) — a state that never existed, in which a durable high-water of 10 wore the legacy label, so the promotion ending that migration discarded it and every durable sequence at or below 10 became replayable. There is no correct scalar to collapse them into, so they are not collapsed.

  The load pass groups by (principal, semantic_version, sender_regime) on the same rule and composes the groups' effects onto one window instead, through HighWaterEvidence: each floor stays under the namespace that produced it (NumericNamespace), legacy-namespace numbers beside a durable floor contribute a bounded MigratingSenderRegime obligation rather than a number, and holds join by PeerHold::stronger_of. The composition is order-independent, which matters because the order sled hands the rows over is a property of the spellings an attacker picked.

• A group whose canonical row is itself unreadable (install_canonical_row). Writing the merge over it would erase the evidence that quarantines the sender and replace it with a floor derived only from the spellings that could be read. Every readable alias in that group is left standing and the load pass joins them — for row #1 through a provenance-specific join that ranks DurableV1 above a superseded TransitionToDurableV1, because the latter installs a migration hold whose promotion retires the retained number, and a fossil row must not impose that on a principal a durable sibling already proved (#2644).

Consequence, and it is a real cost. Alias rows left by any of these cases are never retired, and cleanup() deletes only the canonical key, so normal cleanup cannot reach them. A principal with a surviving legacy-version alias row therefore pays a bounded MigratingFromLegacy hold again on every restart, and one with a surviving legacy-regime alias row pays a bounded MigratingSenderRegime hold on every restart, for as long as that row exists. The mixed-regime case does not converge on its own: a completed promotion writes the canonical key and never touches an alias, so the pair re-forms on the next start. The store converges — and the recurring hold stops — only once the principal's rows are back to a single (semantic_version, sender_regime) group, at which point the next start canonicalizes them normally. That is the deliberate trade: a bounded, self-clearing hold that can recur, against a permanent loss of replay protection.

Unreadable rows quarantine in two of the three keyspaces, not all three. For row #1 (replay_sender_regime:) and row #2 (replay_max_seq:), the load pass turns an unreadable value into a quarantine hold on the merged sender. Row #3 (replay_finalized:) is the exception: an unparseable value is left in place but skipped, with no hold, so a finalized block whose (sender, sequence) has no other readable row is lost silently. That arm is byte-identical to base (5f86610f:icn/crates/icn-net/src/replay_guard.rs:1008) — the behaviour predates #2640 and is not a #2640 bypass — and ReplayGuard::finalize / is_finalized have zero production callers workspace-wide, so the keyspace is unreachable machinery today. Making the finalized load pass quarantine-consistent with rows #1–#2 is a prerequisite before finalize() gains a production caller.

Not fixed, and unchanged by it. SignedEnvelope::canonical_encoding still does not cover from, so the field is still unauthenticated and a re-spelled envelope still verifies; only its second acceptance is refused. Did::from_str still accepts all 23 spellings and Did equality is still string equality — I7 / N2-A (#2627) still owns both, and this fix deliberately did not begin it. Every other row in §5–§7 is untouched, including apps/trust-app/src/sequence.rs (#71), the fourth instance of this class named in §10.2 above.

What N2-A must preserve. When I7 lands, Did equality becomes key equality and the in-memory window map would collapse spellings anyway — but the durable rows would not, so the canonical write here must stay. N2-A must either keep SenderPrincipal as the guard's key or, if it replaces it with a canonical Did, keep writing rows #1–#3 under a key-derived spelling and keep the merge pass until no store can contain a legacy alias row. Dropping the migration would silently restore the durable half of this defect.

Row #57 (peer_connections) carries a second invariant, surfaced by the independent security review of this change. That map is spelling-keyed — handlers/hello.rs inserts under the wire spelling of from — so a re-spelled envelope from a sender that has established DurableV1 missed its row-#57 lookup and read as LegacyOrUnproven.

An earlier revision of this section called that redundant defence in the safe direction, on the grounds that the canonical replay floor rejects the same envelope on its own in both regime arms. That is true only where a floor already exists, and it is the wrong half of the case. A receiver that has authenticated the sender but not yet accepted a message from it holds an empty window, so there is no floor to be redundant with: (LegacyOrUnproven, LegacyOrUnproven) is steady state, and a still-fresh envelope captured from the sender's pre-upgrade numbering was accepted and forwarded to the application, instead of entering the MigratingSenderRegime hold that (LegacyOrUnproven, DurableV1) installs and that exists precisely because old-namespace captures can still be inside their validity window. Only the established-window half was redundantly defended. Both halves are pinned in handlers/signed.rs (a_respelled_envelope_cannot_launder_a_durable_sender_into_the_legacy_steady_state and a_respelled_replay_below_an_established_durable_floor_is_still_rejected).

The lookup itself is fixed rather than deferred: handlers/signed.rs now resolves the sender's authenticated capabilities by SenderPrincipal — the same equivalence class the signature check and ReplayGuard already use — joining across the rows that decode to that principal with "any such row proving DURABLE_SIGNING_SEQUENCE proves it". The map's key is unchanged, so the other row-#57 and row-#60 consumers are untouched.

That join no longer reads row #57 at all. Row #57 is a cache, not a live-session registry: nothing removes an entry when a connection ends (actor/connection.rs returns on both the application-close and the error path without touching the map; the only removal anywhere is the administrative NetworkHandle::disconnect_peer), and restore_state recreates entries from the snapshot at startup with their capability bits intact and no Hello behind them. Joining on principal alone over such a map let a peer that proved DurableV1 under spelling A, disconnected, and returned under spelling B without the capability keep reading as DurableV1 from A's abandoned row — the (DurableV1, LegacyOrUnproven) downgrade never fired, and a captured old-namespace sequence above the retained durable floor was admitted as though it were a durable number. Reproduced end to end at floor 10 with a captured sequence of 100; the snapshot variant needs no key at all, since actor/connection.rs dispatches MessagePayload::Signed without binding envelope.from to the connection's authenticated peer.

Sender-regime attribution therefore moved out of row #57 entirely, to icn-net/src/capability_evidence.rs. LiveCapabilityRegistry is indexed by SenderPrincipal and holds an entry only while some connection is leasing it: handle_hello takes a LiveCapabilityClaim after the three #2520 DID-TLS checks pass, the claim lives in that connection's ConnectionContext, and the connection handler owns that context on its own stack frame — so every exit path releases it, including ones added later. This is the same RAII shape preauth_admission::AdmissionGuard already uses for #2547 slots, and it is what makes the two axes independent by construction: the index answers which key, and the lease's lifetime answers whether the claim is still true. Claims are reference counted, because a key holder may authenticate under several spellings of itself and cross-dialling gives one pair two connections at once; the join across live claims is any, which is the only join that cannot be suppressed by adding one.

Two consequences worth recording for N2-A. First, this removes a per-envelope scan of an unbounded structure: the interim fix walked row #57 once per signed message, and since nothing prunes that map, a peer reconnecting under one-off DIDs could grow it permanently and make every other peer's traffic pay for the scan. The registry is one hash lookup, and its cardinality is the number of connections currently claiming — each of which is a live QUIC connection the peer has to keep standing up, where the cache kept its entry after the connection was gone. This is deliberately not a #2547 bound, and should not be recorded as one: record_authenticated_peer drops the admission guard the moment a connection authenticates, while the capability claim is taken afterwards, so pre-authentication admission limits how many connections a source may hold while anonymous and says nothing about authenticated ones. A post-authentication connection bound, if one is wanted, is a separate piece of work this does not supply. Second, row #57's remaining consumers are unchanged — cached version, X25519 and PQ material, and #2504-era reconnection — so the migration this row still owes is unaffected. What changed is that replay-regime attribution is no longer one of them.

Row #57 keeps one unfixed consumer of the same class: verify_with_cached_pq_key resolves the cached ML-DSA key with the same textual connections.get(&envelope.from), so a re-spelled hybrid envelope misses and downgrades to Ed25519-only. Latent behind #[cfg(feature = "post-quantum")] and tracked as #2646 — deliberately not folded in here, because a capability is a boolean that joins with any while a key is a value, and "pick any live claim" is not obviously right.

N2-A therefore still owes (a) the canonical replay floor independently rejecting the re-spelled replay once the map key itself becomes alias-tolerant, and (b) keeping these regressions. The earlier concern that this path misclassified an attacker-chosen input as the local fault SenderRegimeDowngrade no longer applies to re-spelling — the lookup no longer misses — and SenderRegimeDowngrade is again what it is named for, an operator rollback. §12.1 item 6 covers the #57/#60 partner-map desync; it does not cover this.

10.3 Vote double-counting, and a re-cast guard that cannot fire

GovernanceError::AlreadyVoted (icn-governance/src/error.rs:33) has zero constructors anywhere in the workspace — confirmed live, matching IDENTITY_SEMANTICS §7.5's "declared but never constructed". The production tally paths count every stored row: GovernanceStore::compute_tally (store.rs:298, :650) is list_votes → VoteTally::from(votes), and compute_tally_with_delegations (tally.rs:114–118, no non-test caller today) calls tally.add_vote(vote) unconditionally in pass 1 with counted gating only delegation resolution. Two votes from one person under two spellings are both counted; row #18's de-duplication is over Vec<String>, so it does not catch it; and apps/governance's own guard (manager.rs:~4771, v.voter == voter) is Did string equality, so the live store (#23) takes the second row too. Because icn-governance's sled store is dormant (§3.1), the live double-count is #23. §7.5 anticipated this for a re-key; it is reachable now without one, and I7 alone does not fix it (the rows are Display-keyed). Disposition: no issue owned it (§7.5 is stated as a gate, not materialised; #2623/#2626/#2627 disclaim governance storage). Filed by this review as #2641.

Resolved 2026-08-28 (#2641). The measurement above stands as taken at 798c8d54. Governance now resolves a voter to the bytes its did:icn: identifier decodes to (icn-governance's VotingPrincipal): AlreadyVoted has a constructor (ensure_has_not_voted), both GovernanceStore implementations supersede a principal's prior row across spellings, and every tally path in the workspace uses VoteTally::try_from_votes, which collapses agreeing alias rows and fails closed on conflicting ones rather than electing a survivor. That covers the live actor paths — the read-only get_vote_tally and the decision-producing tally inside CloseProposal, including its close-time delegation expansion — and the GovernanceStore library surface, whose only in-workspace consumer is ProposalCleanupTask::archive_proposal. Three corrections to the note above, found while fixing it: the live exploit is not only #23 via manager.rs's guard — GovernanceManager::cast_vote delegates to governance_handle as its first statement, so in actor-backed deployments the membership gate and that guard never ran, and the actor's CastVote handler had no duplicate-vote guard at all; and the identity used for the fix is the decoded identifier bytes rather than a VerifyingKey, because anchor-derived DIDs (Did::from_anchor_id) need not decompress to an Edwards point. Third, the delegation hazard is not confined to compute_tally_with_delegations (which has no production caller): its production twin, apply_delegation_to_tally, was spelling-keyed, so a member could delegate from one spelling of their key to another, vote as the delegate, and have that single vote resolved back to them as a second one at close — reachable on a fresh deployment with no legacy rows. Nothing was re-keyed: vote rows remain Display-keyed and membership lists remain spelling-compared, so §7.5's re-key gate is untouched and this row stays NEEDS MIGRATION for N2-A.

10.4 grantee_canonical_bytes canonicalizes the layout, not the spelling

receipt_store.rs:1071 is named *_canonical_bytes and emits a tag byte followed by did.as_str() — the raw spelling. A lookup with a differently-spelled DID misses the grant (fails closed), while two grants for one principal can coexist. On re-reading, its doc comment defines "canonical" precisely: the ADR-0014 tag-byte + length-prefix layout that keeps Person and Entity in separate keyspaces and prevents prefix aliasing (PR #1576) — it does not claim DID spelling canonicalization. The first pass's "the name asserts a property the function does not have" is therefore withdrawn. Disposition: not an independent defect — it is row #25's ordinary spelling-keyed index, in the same class as every other SILENT-MERGE RISK row; handled by N2-A's scan, no issue.

10.5 Partner invariants that I7 would introduce (N2-A must fix atomically)

Not current defects — today every one of these is string-consistent. I7 moves one half and not the other. Disposition: no "current defect" issue; tracked as N2-A constraints (§12.1 item 6) and recorded on #2627 (comment of 2026-08-19).

• PeerId(pub Did) (icn-net/src/topology.rs:42–55) derives PartialEq/Eq/Hash — which delegate to Did and so move under I7 — while hand-implementing Ord over self.0.to_string(), which does not move (Did itself has no Ord). After I7, two aliasing PeerIds satisfy a == b while a.cmp(&b) != Equal, violating the standard library's Ord/Eq consistency requirement. PeerId is used in four BTreeSets and one HashMap (topology.rs:23–35), where an inconsistent Ord yields unspecified lookup and insertion behaviour. (Row #52.)
• icn-ccl Value (icn-ccl/src/types.rs:110–131) derives PartialEq/Eq — Value::Did moves — but hand-implements Hash (:200–220) and hashes Value::Did as format!("{did:?}"), a string, which does not move. HashSet<Value> (Value::Set, used for participants and in checks in interpreter.rs:403–410, 484–485) then violates the Hash/Eq contract: List.contains (Eq, moves) and Set.contains (Hash, does not) disagree. (Row #61.) Contract state is in-memory only, but Value::Set is persisted inside Contract.state_vars[].initial_value via icn_encoding (ast.rs:69).
• The icn-net connection-map pair: SessionManager.connections: HashMap<String, quinn::Connection> keyed by from.to_string() (session.rs:58, :906–912) and NetworkActor.peer_connections: HashMap<Did, PeerConnectionInfo> (actor/mod.rs:1098), both filled from the same Hello from and joined in actor/messages.rs:474–491 send_message_to_peer (Did-keyed lookup, then connections().find(|(peer_did, _)| peer_did == did.as_str())). Post-I7 the Did map finds an alias, the String map does not. (Row #60.)
• Every production did.as_str() == string / did.to_string() != string comparison standing in for Did equality stays spelling-sensitive post-I7: icn-gateway api/commons/mod.rs:242, 278, 358 (claims.sub != did.to_string()), websocket.rs:220, api/sdis/simple_enrollment.rs:1096, 1127, listings_mgr.rs:929, trust_mgr.rs:1159; icn-core storage_challenge.rs:526, supervisor/init_network.rs:315, 370; icn-gossip handlers/storage_challenge.rs:58; icn-store pos.rs:251, 490, 596; icn-trust lib.rs:1180 (Did vs Did via as_str); bins/icnctl main.rs:6242. Not defects today; N2-A must decide per site whether string comparison is the intended semantics.

10.6 Namespaces that I7 does not reach, and therefore desynchronises

Three constructs embed or duplicate a DID but keep string equality, so I7 moves Did out from under them:

• EntityId(String) — EntityId::from_did (entity.rs:51) splices the multibase spelling verbatim into entity:icn:individual:<spelling>. Rows #33–#35 are durable membership keys. After I7, a == b as Did while EntityId::from_did(a) != EntityId::from_did(b) — two member rows for one principal, permanently, and I7 alone will not fix it.
• icn-kernel-api::Did = String (types.rs:9) — the alias family I12/N2-H owns. Unaffected by I7 by construction.
• StewardId::from_did (icn-governance/src/steward.rs:29–38) = SHA-256 of "steward:" ‖ did.as_str() — a primary key hashed over the spelling, used by the live icn-commons steward store (commons/stewards/<hex>, #63). Two spellings → two steward records, and I7 does not move a [u8; 32].
• icn-commons weak-holder id (icn-commons/src/inner.rs:346–362 update_display_name) = SHA-256 of did.to_string(), minted behind a Did-equality authorization gate (#65) — the one namespace construct where I7 creates a durable split (§3.1 clause (d)).
• icn-snapshot::vector_clock: HashMap<String,u64> (#54) and NetworkState.peer_connections: HashMap<String,_> (#57) — String-keyed on disk, but both are parsed back into Did-keyed maps on restore, so they are moved (lossily) by I7 at the restore boundary. #54 is therefore resolved NEEDS MIGRATION, not UNRESOLVED (§11).
• icn-community Community.members: HashMap<String, Member> (#72) — String-keyed ("Can be DID or CooperativeId"), never parsed to Did; diverges from any Did-typed membership view.

N2-A must state explicitly which of these it is and is not fixing (§12.1 item 4(iv)).

11. Coverage limits — what this inventory does not establish

Stated plainly, per #2623's sixth acceptance criterion.

1. No live data was examined. Every verdict is derived from source and from probes against the real types. Whether any deployed store currently contains two aliasing spellings is unknown and unknowable from the repository. The inventory therefore bounds the reachable hazard, not the realised one. A pre-migration scan of live keyspaces remains necessary and is N2-A's to run (§12.1 item 3).
2. Row #54 is resolved (NEEDS MIGRATION, §3.1 clause (c)): the snapshot vector clock is parsed back into the Did-keyed gossip clock on restore (gossip.rs:1369–1382). No row is UNRESOLVED after this review. The two String-keyed structures that are not re-keyed (#72 Community.members, #73 ReplicaMetadata) are classified, not left open: not moved by I7, flagged for N2-A's namespace decision (§10.6).
3. Value-position DIDs were not exhaustively enumerated. S8 found 155 struct-field rows (147 distinct structs) with a Did field. Those used as keys are covered; those appearing only in values are not individually listed, on the ground that I7 does not change value semantics. If N2-A adds normalization at the parse boundary rather than at Eq/Hash, that assumption breaks and all 147 need re-review.
4. icn-ccl is now traced (first pass: untraced). Contract state is in-memory only (runtime.rs:25); ContractRegistry persists participants: Vec<Did> value-position and owner: String (its doc header claims an index:owner:<did> keyspace that is not written — comment drift, noted); Value::Set is persisted only inside Contract.state_vars[].initial_value. No Did-keyed map is persisted, but the Value type is a partner type (#61, §10.5).
5. Test-only stores were excluded by construction (/tests/, #[cfg(test)]). A durable store reachable only from test harnesses would be missed; the S5 root scan found no such case, but this is an exclusion, not a proof. Conversely, S14 found library stores that no binary constructs (dormant #17–#22, #44, #46) and write paths no binary reaches (dead, #84).
6. The 23-spelling figure is a floor, not a ceiling. It is what multibase v0.9.2 (24 declared bases: 23 unconditional + Identity) accepts through Did::from_str. A dependency bump that adds a base widens the aliasing surface with no code change in this repo; a key whose raw bytes are valid UTF-8 (~1 in 10⁸ random keys, grindable) has a 24th.
7. Probe sources are recorded but not committed — this tranche adds no code, so the integration-test probes live in §13.4 and §13.5 rather than in tests/. Re-add them as temporary integration tests to reproduce §2; delete them afterwards and before re-taking any S1/S7 count.
8. sled iteration order is lexicographic by key bytes (resolved; first pass: "treated as unspecified"). SledStore::scan (icn-store/src/lib.rs:811) iterates db.scan_prefix(prefix), which yields keys in byte order, so every "last-writer-wins" rebuild in §6 has a deterministic, attacker-selectable survivor: the multibase code character decides — in ASCII 'B' < 'C' < … < 'Z' < 'b' < 'c' < 'f' < 'h' < 'k' < 'm' < 't' < 'u' < 'v' < 'z', and the Base256Emoji prefix 🚀 (F0 9F 9A 80) sorts after all of them, so an attacker who wants their row to survive spells it in Base256Emoji; the canonical z… spelling beats every other ASCII alternate. This does not change any verdict under §3.1 (the class is decided by whether a Did-re-keying consumer exists, not by who wins) but it changes the severity wording: "arbitrary survivor" in #37, #38, #39 is "chosen survivor". HashMap-sourced restores (#54, #57) have a nondeterministic survivor instead.
9. Line numbers are as of 798c8d54. Symbols, not line numbers, are the citation; the review re-found every cited symbol at or near its line.

12. Result

(First pass: 121 candidates — 67 / 31 / 22 / 1. The review added 29 rows, reclassified 18, and resolved the open one. Counts are produced by the generator that renders the tables, and re-verified by counting the rendered verdict cells — see the closing comment on #2623.)

Concrete list N2-A inherits — the NEEDS MIGRATION rows, 24 in all: #1, #2, #3, #4, #5, #6, #7, #8, #9, #23, #29, #30, #37, #38, #39, #40, #42, #45, #46, #54, #57, #65, #68, #69. Folding each consumer row into its keyspace, that is 13 live keyspaces / structures plus one dormant shape:

Dropped from the first pass's list, with the reason in each row: #17/#18 (dormant store — the live vote keyspace is #23), #24 (raw-byte-keyed state, no Did re-key), #31 (local canonical write path, point lookup only), #33/#34 (EntityId is not moved by I7 — a §10.6 namespace decision, and cannot differ from #35), #50 (ephemeral). Added: #29, #30, #42/#68, #46, #54, #57, #65, #69.

What the evidence says about the mechanism choice. IDENTITY_SEMANTICS §11 (I7) permits either equality over decoded bytes or encoding pinned at parse. This inventory does not choose — that is N2-A's decision and its rationale is N2-A's to state — but it records three constraints the choice must satisfy:

1. Pinning at parse changes what Did::from_str accepts, which is a wire-compatibility change affecting all 168 class-E parse sites (§4 S7), and would make currently-loadable persisted rows unloadable. Equality over decoded bytes changes no acceptance and no durable byte — but it is the only one of the two that leaves the third-party re-spelling replay (§2.2) open, because from is unsigned and the durable replay rows stay spelling-keyed.
2. Neither mechanism fixes §10.6 — EntityId, StewardId, the icn-commons holder id, the kernel String alias, Community.members and ReplicaMetadata keep string equality either way.
3. Neither mechanism repairs a durable keyspace by itself. Every §5 row is built by Display, which I7 does not touch, so the physical rows survive I7 unchanged and a separate re-keying step is required for the list above. PrincipalKey (#55) is the in-repo precedent for the decoded-byte form, VectorClockProjection::from_entries (max-per-key) for a decode merge rule, and legacy_proposal_index_key (§8) for the rewrite mechanics.

§7.5 remains a separate hard gate. Rows #23 (live), #17/#18 (dormant), #56 (StaticList membership) and finding §10.3 are membership and vote storage. §7.5 requires migration ordering, alias/transition recognition, duplicate-act prevention and final cutover to be designed before any live re-key. Nothing here discharges that gate, and N2-A must not treat these rows as ordinary migrations.

12.1 What N2-A must design against — the surface, not the design

This inventory does not design the migration. It hands N2-A the surface the migration must be designed against, as a checklist it can be reviewed against:

1. Persisted-keyspace list — §5 (rows #1–#36 plus the review additions). Every durable keyspace whose key embeds a DID spelling, with its write path (locally-generated canonical vs wire/API spelling) and whether it is live, dormant or dead.
2. Migration-required list — §12 Concrete list, with the mechanism per row in §5/§6. A keyspace appears once; its re-keying consumer is the evidence.
3. Pre-migration collision scan — mandatory, because no live data was examined (§11 item 1). For every keyspace in §5, group rows by decoded key bytes (not by spelling) and report groups of size > 1. Base256Emoji (🚀…) spellings sort after every ASCII spelling under sled's lexicographic order, so report the order of rows in each group too — it decides the survivor in every last-writer rebuild (§11 item 8).
4. Ordering constraints — (i) for NEEDS MIGRATION keyspaces with a Did-keyed rebuild (#1–#3/#37, #4, #5–#8/#38, #9/#39/#40, #23, #29, #30, #42/#68, #54, #57, #69), de-dupe the durable rows before the first start of a binary with key-equality Did, because that first start performs the lossy rebuild and the write-back (save_to_store, save_cached_balances) then orphans the losers; (ii) for class-C structures (#45, #46) the merge rule for aliasing keys (max / sum / reject) must be chosen before decode collapses them — VectorClockProjection::from_entries already picks max, which is a precedent; (iii) membership and vote keyspaces (#17/#18 dormant, #23 live, StaticList row) are behind the §7.5 hard gate — migration ordering, alias/transition recognition, duplicate-act prevention and final cutover — and are not ordinary migrations; (iv) the namespaces I7 does not move (EntityId::from_did, StewardId::from_did, icn-commons weak-holder id = SHA-256 of the spelling, the kernel Did = String alias, String-keyed snapshot maps) need an explicit decision — follow Did (canonicalise at construction + de-dupe rows) or stay spelling-keyed — stated in N2-A, per namespace.
5. Compatibility and rollback — equality-over-bytes changes no durable byte and no acceptance, so a binary rolled back to string equality reads the migrated (de-duplicated) rows unchanged; pin-at-parse changes acceptance and makes every alternate-spelled row unloadable (§12 constraint 1), so it needs a compatibility-read window first — and it is the only mechanism that closes the third-party re-spelling replay (§2.2, #2640) without a wire change.
6. Partner-type invariants that move out of step (all must be fixed in the same change): PeerId Ord over to_string() (#52, §10.5); icn-ccl Value derives PartialEq/Eq but hand-hashes Value::Did via format!("{did:?}") — HashSet<Value> (Value::Set, participants, in checks) breaks the Hash/Eq contract post-I7; the String/Did peer-map pair in icn-net (SessionManager.connections: HashMap<String,_> keyed by from.to_string() vs peer_connections: HashMap<Did,_>, joined in actor/messages.rs send_message_to_peer) which disagree post-I7; every production did.as_str() == some_string comparison standing in for Did equality (icn-gateway commons claims.sub != did.to_string(), websocket, sdis enrollment, listings, trust_mgr; icn-core storage_challenge, init_network; icn-store pos; icnctl) stays spelling-sensitive.
7. Unresolved-data policy — none of the inventory's rows is UNRESOLVED after review. If the pre-migration scan finds an aliasing group whose store has no stated merge rule, the policy is fail closed: refuse to start the key-equality binary on that store until the rule is chosen, rather than let the rebuild pick a survivor.

13. Appendix — the search and probe sources

Recorded verbatim so §4's methodology and §2's measurements are re-runnable rather than merely described. None of this is committed as code; all of it is reproducible from a clean checkout at 798c8d54 (and at bca3dd0e — the Rust tree is identical). The three scanners run from the repository root and are read-only; they are a read list for the human pass, not results — the load-bearing results are the S1–S14 commands in §4 and the two probes below. Every expected count in this appendix was re-run by the review and reproduced exactly, with no probe files present.

13.1 S5 — rank durable roots by identity-term density

import re, os
ROOT = "."
files = []
for dp, dn, fn in os.walk(ROOT):
    if '/.git' in dp or '/target' in dp or '/node_modules' in dp:
        continue
    files += [os.path.join(dp, f) for f in fn if f.endswith('.rs')]
durable = [f for f in files
           if re.search(r'sled::(Db|Tree|open|Config)',
                        open(f, encoding='utf8', errors='replace').read())]
IDENT = re.compile(
    r'\b(did|dids|_did|did_|member_id|member_did|owner|owner_did|actor|actor_did|'
    r'peer_id|peer_did|subject|subject_id|principal|voter|issuer|holder|signer|'
    r'operator_did|node_did|org_did|treasury_did|coop_id|entity_id|account)\b', re.I)
rows = sorted(((len(IDENT.findall(open(f, encoding='utf8', errors='replace').read())),
                os.path.relpath(f, ROOT)) for f in durable), reverse=True)
print("rust files:", len(files), "| touching sled:", len(durable))
for n, p in rows:
    print(f"{n:5d}  {p}")

Expected at bca3dd0e: 1033 Rust files, 69 touching sled.

13.2 S6 — Did-keyed collections inside serde-derived structs (class C)

import re, os
COLL = re.compile(r'(HashMap|BTreeMap|DashMap|HashSet|BTreeSet)<\s*&?\s*Did\b')
DERIVE = re.compile(r'#\[derive\(([^)]*)\)\]')
for dp, dn, fn in os.walk("."):
    if '/.git' in dp or '/target' in dp or '/node_modules' in dp:
        continue
    for f in fn:
        if not f.endswith('.rs'):
            continue
        p = os.path.join(dp, f)
        if '/tests/' in p:
            continue
        lines = open(p, encoding='utf8', errors='replace').read().split('\n')
        for i, l in enumerate(lines):
            if not COLL.search(l):
                continue
            for j in range(i, max(-1, i - 60), -1):          # nearest enclosing item
                if re.match(r'\s*(pub )?(struct|enum) ', lines[j]):
                    for k in range(j - 1, max(-1, j - 8), -1):
                        m = DERIVE.search(lines[k])
                        if m and ('Serialize' in m.group(1) or 'Deserialize' in m.group(1)):
                            print(f"{p}:{i+1}  {lines[j].strip()[:70]}  [{m.group(1)[:40]}]")
                        if m:
                            break
                    break

Known limitations, stated because they changed verdicts: (i) the backward walk stops at the nearest enclosing struct/enum, so a let binding inside an impl block is attributed to that block's type — two of the five raw hits (icn-trust/src/anomaly.rs:601–602) are such false positives; (ii) the scanner cannot tell icn_identity::Did from the kernel type Did = String alias — a third hit, icn-kernel-api/src/proofs.rs:490, is the alias (#53); (iii) it matches only map/set types, so a serialized Vec<Did> with set semantics (#56) is invisible to it. The two real class-C members are #45 and #46. Treat the output as a read list, never as a result.

13.3 S8 — wrapper types that hide a Did (the second pass)

import re, os
for dp, dn, fn in os.walk("."):
    if '/.git' in dp or '/target' in dp or '/node_modules' in dp:
        continue
    for f in fn:
        if not f.endswith('.rs'):
            continue
        p = os.path.join(dp, f)
        if '/tests/' in p:
            continue
        src = open(p, encoding='utf8', errors='replace').read()
        for m in re.finditer(r'pub struct (\w+)\s*\(\s*(?:pub\s+)?Did\s*\)', src):
            print("newtype-struct        ", m.group(1), p)
        for m in re.finditer(r'(\w+)\s*\(\s*Did\s*\)\s*,', src):
            print("enum-variant          ", m.group(1), p)
        for m in re.finditer(r'pub struct (\w+)\s*\{[^}]{0,400}?\bpub \w+: Did\b', src, re.S):
            print("struct-with-did-field ", m.group(1), p)

Expected at bca3dd0e: 155 struct-with-did-field rows (147 distinct struct names — the script prints every occurrence, not distinct names) and 8 newtype/enum-variant rows resolving to 5 distinct wrappers: PeerId, and the Did / Person / Query / Remote variants. Of those, PeerId(pub Did) produced finding #52, AccountId::Did(Did) produced #9 and §10.6, and Grantee::Person(Did) produced #25. This class is invisible to S1 — it is the reason §9 exists as a separate pass.

13.4 Probe A — encoding aliasing and anchor round-trip (§2.1, §2.3)

Add as icn/crates/icn-identity/tests/n2a0_probe.rs, run cargo test -p icn-identity --test n2a0_probe -- --nocapture, then delete it. The first test tries every base multibase v0.9.2 declares (the Identity base is built by hand because multibase::encode(Identity, …) panics on non-UTF-8 bytes); the second proves the Identity parser path with a constructed ASCII-valued point.

use icn_identity::anchor::{Anchor, EnrollmentPathway};
use icn_identity::Did;
use std::collections::HashMap;

#[test]
fn probe() {
    let kp = icn_identity::KeyPair::generate().unwrap();
    let canonical = kp.did().clone();
    let (_b, bytes) = multibase::decode(&canonical.as_str()[8..]).unwrap();

    use multibase::Base::*;
    // Every base multibase 0.9.2 declares (the first pass's probe tried 22 of them).
    let all = [Identity, Base2, Base8, Base10, Base16Lower, Base16Upper, Base32Lower, Base32Upper,
               Base32PadLower, Base32PadUpper, Base32HexLower, Base32HexUpper,
               Base32HexPadLower, Base32HexPadUpper, Base32Z, Base36Lower, Base36Upper,
               Base58Flickr, Base58Btc, Base64, Base64Pad, Base64Url, Base64UrlPad, Base256Emoji];
    let mut distinct: std::collections::HashSet<String> = Default::default();
    let mut rejected = vec![];
    for b in all {
        let enc = if b == Identity {
            match std::str::from_utf8(&bytes) { Ok(s) => format!("\u{0}{s}"), Err(_) => { rejected.push("Identity: key bytes not valid UTF-8 (encode would panic)".into()); continue; } }
        } else { multibase::encode(b, &bytes) };
        let alt = format!("did:icn:{enc}");
        match Did::from_str(&alt) {
            Ok(d) => {
                // key bytes identical?
                assert_eq!(d.to_verifying_key().unwrap().as_bytes(), &bytes[..], "{b:?}");
                // serde round trip preserves spelling?
                let j = serde_json::to_string(&d).unwrap();
                let back: Did = serde_json::from_str(&j).unwrap();
                assert_eq!(back.as_str(), alt, "serde must preserve spelling for {b:?}");
                // Display preserves spelling
                assert_eq!(d.to_string(), alt);
                distinct.insert(alt);
            }
            Err(e) => rejected.push(format!("{b:?}: {e}")),
        }
    }
    println!("TRIED={} ACCEPTED={} REJECTED={:?}", all.len(), distinct.len(), rejected);

    let mut m: HashMap<Did, u32> = HashMap::new();
    for (i, d) in distinct.iter().enumerate() { m.insert(Did::from_str(d).unwrap(), i as u32); }
    println!("HASHMAP_LEN={}", m.len());
    let j = serde_json::to_string(&m).unwrap();
    let back: Result<HashMap<Did, u32>, _> = serde_json::from_str(&j);
    println!("MAP_ROUNDTRIP_LEN={:?}", back.map(|b| b.len()));

    // Identity base over many keys: how often is the raw 32-byte key valid UTF-8?
    let mut id_ok = 0u32;
    for _ in 0..2000 {
        let k = icn_identity::KeyPair::generate().unwrap();
        let (_b, kb) = multibase::decode(&k.did().as_str()[8..]).unwrap();
        if let Ok(s) = std::str::from_utf8(&kb) {
            let alt = format!("did:icn:\u{0}{s}");
            if Did::from_str(&alt).is_ok() { id_ok += 1; }
        }
    }
    println!("IDENTITY_BASE_ACCEPTED_OF_2000_KEYS={id_ok}");

    // Anchor round-trip — artifact construction (sha256 of counter), 200 then 20000
    for n in [200u32, 20000u32] {
        let (mut ok, mut fail) = (0u32, 0u32);
        for i in 0..n {
            let mut id = [0u8; 32];
            id.copy_from_slice(&<sha2::Sha256 as sha2::Digest>::digest(i.to_le_bytes()));
            let d = Did::from_anchor_id(&id);
            let j = serde_json::to_string(&d).unwrap();
            if serde_json::from_str::<Did>(&j).is_ok() { ok += 1 } else { fail += 1 }
        }
        println!("ANCHOR_ROUNDTRIP_SHA_CTR n={n} OK={ok} FAIL={fail}");
    }
    // Real Anchor::from_vui(...).to_did() path
    let (mut ok, mut fail) = (0u32, 0u32);
    for i in 0u32..2000 {
        let mut vui = [0u8; 32]; vui[..4].copy_from_slice(&i.to_le_bytes());
        let genesis = [7u8; 32];
        let a = Anchor::from_vui(&vui, EnrollmentPathway::Genesis { reason: "probe".into() }, &genesis);
        let d = a.to_did();
        let j = serde_json::to_string(&d).unwrap();
        if serde_json::from_str::<Did>(&j).is_ok() { ok += 1 } else { fail += 1 }
    }
    println!("ANCHOR_ROUNDTRIP_FROM_VUI n=2000 OK={ok} FAIL={fail}");
}

#[test]
fn identity_base_parser_path() {
    // Find a 32-byte ASCII string that is a valid Ed25519 compressed point (~1/2 of strings are),
    // to prove the parser accepts the multibase Identity ('\0') form when bytes are valid UTF-8.
    for i in 0u32..10000 {
        let s: String = (0..32).map(|j| (b'A' + ((i.wrapping_mul(31).wrapping_add(j*7)) % 26) as u8) as char).collect();
        let alt = format!("did:icn:\u{0}{s}");
        if let Ok(d) = Did::from_str(&alt) {
            let (base, bytes) = multibase::decode(&alt[8..]).unwrap();
            println!("IDENTITY_ACCEPTED base={base:?} len={} key_ok={}", bytes.len(), d.to_verifying_key().is_ok());
            let canon = Did::from_public_key(&d.to_verifying_key().unwrap());
            println!("IDENTITY_CANONICAL_NE={}", canon != d);
            let j = serde_json::to_string(&d).unwrap();
            println!("IDENTITY_SERDE_RT_OK={}", serde_json::from_str::<Did>(&j).map(|x| x == d).unwrap_or(false));
            return;
        }
    }
    panic!("no ascii point found");
}

Observed at 798c8d54 (identical at bca3dd0e): TRIED=24 ACCEPTED=23 REJECTED=["Identity: key bytes not valid UTF-8 (encode would panic)"], HASHMAP_LEN=23, MAP_ROUNDTRIP_LEN=Ok(23), IDENTITY_BASE_ACCEPTED_OF_2000_KEYS=0, ANCHOR_ROUNDTRIP_SHA_CTR n=200 OK=90 FAIL=110, ANCHOR_ROUNDTRIP_SHA_CTR n=20000 OK=10051 FAIL=9949, ANCHOR_ROUNDTRIP_FROM_VUI n=2000 OK=1011 FAIL=989; IDENTITY_ACCEPTED base=Identity len=32 key_ok=true, IDENTITY_CANONICAL_NE=true, IDENTITY_SERDE_RT_OK=true.

The treasury-DID variant (§2.3, §10.1) goes in icn/crates/icn-coop/tests/n2a0_treasury_probe.rs (cargo test -p icn-coop --test n2a0_treasury_probe -- --nocapture, then delete):

use icn_identity::Did;
#[test]
fn coop_treasury_did_roundtrip_rate() {
    let (mut ok, mut fail) = (0u32, 0u32);
    for i in 0..5000u32 {
        let anchor = icn_coop::lifecycle::derive_treasury_anchor(&format!("coop-{i}"));
        let mut anchor_32 = [0u8; 32];
        anchor_32[..16].copy_from_slice(&anchor);
        let d = Did::from_anchor_id(&anchor_32);
        let j = serde_json::to_string(&d).unwrap();
        if serde_json::from_str::<Did>(&j).is_ok() { ok += 1 } else { fail += 1 }
    }
    println!("COOP_TREASURY_DID_ROUNDTRIP n=5000 OK={ok} FAIL={fail}");
}

Observed: COOP_TREASURY_DID_ROUNDTRIP n=5000 OK=2541 FAIL=2459.

13.5 Probe B — envelope verification and replay windows under an aliased sender (§2.2)

Add as icn/crates/icn-net/tests/n2a0_replay.rs, run cargo test -p icn-net --test n2a0_replay -- --nocapture --test-threads=1, then delete it. icn-net does not depend on multibase, so the base16 form is built by hand — the leading f is the multibase code for base16-lower.

use icn_identity::{Did, KeyPair};
use icn_net::envelope::{PayloadType, SignedEnvelope};
use icn_net::replay_guard::{ObservedSenderRegime, ReplayGuard};
use std::sync::Arc;

fn alias_of(canonical: &Did) -> Did {
    let key_bytes = canonical.to_verifying_key().unwrap().as_bytes().to_vec();
    let hex: String = key_bytes.iter().map(|x| format!("{x:02x}")).collect();
    Did::from_str(&format!("did:icn:f{hex}")).expect("alias parses today")
}

#[test]
fn probe_signature() {
    let kp = KeyPair::generate().unwrap();
    let canonical = kp.did().clone();
    let alias = alias_of(&canonical);
    let key_bytes = canonical.to_verifying_key().unwrap().as_bytes().to_vec();
    println!("CONTROL_ALIAS_NE_CANONICAL={}", alias != canonical);
    println!("ALIAS_KEY_SAME={}", alias.to_verifying_key().unwrap().as_bytes() == &key_bytes[..]);
    let e1 = SignedEnvelope::new(&canonical, &kp, 1, PayloadType::Gossip, b"m".to_vec()).unwrap();
    let e2 = SignedEnvelope::new(&alias, &kp, 1, PayloadType::Gossip, b"m".to_vec()).unwrap();
    println!("CANONICAL_VERIFIES={}", e1.verify(3600).is_ok());
    println!("ALIAS_VERIFIES={}", e2.verify(3600).is_ok());
    println!("FROM_FIELDS_DIFFER={}", e1.from != e2.from);
    // Cross-check: alias envelope signed by a DIFFERENT key must NOT verify (signature really binds the key)
    let other = KeyPair::generate().unwrap();
    let e3 = SignedEnvelope::new(&alias, &other, 1, PayloadType::Gossip, b"m".to_vec()).unwrap();
    println!("ALIAS_WRONG_KEY_VERIFIES={}", e3.verify(3600).is_ok());
}

#[test]
fn probe_replay_guard_in_memory() {
    let kp = KeyPair::generate().unwrap();
    let canonical = kp.did().clone();
    let alias = alias_of(&canonical);
    let mut guard = ReplayGuard::new(300, 3600);
    let e1 = SignedEnvelope::new(&canonical, &kp, 5, PayloadType::Gossip, b"m".to_vec()).unwrap();
    let e1b = SignedEnvelope::new(&canonical, &kp, 5, PayloadType::Gossip, b"m2".to_vec()).unwrap();
    let e2 = SignedEnvelope::new(&alias, &kp, 5, PayloadType::Gossip, b"m".to_vec()).unwrap();
    let r1 = guard.check(&e1, ObservedSenderRegime::LegacyOrUnproven);
    let r1b = guard.check(&e1b, ObservedSenderRegime::LegacyOrUnproven); // CONTROL: same spelling, same seq
    let r2 = guard.check(&e2, ObservedSenderRegime::LegacyOrUnproven);  // alias spelling, same seq
    println!("MEM_CANONICAL_SEQ5_ACCEPTED={}", r1.is_ok());
    println!("MEM_CONTROL_SAME_SPELLING_SEQ5_REPLAY_REJECTED={} ({:?})", r1b.is_err(), r1b.as_ref().err().map(|e| e.to_string()));
    println!("MEM_ALIAS_SEQ5_ACCEPTED={}", r2.is_ok());
    println!("MEM_PEER_COUNT={}", guard.peer_count());
    println!("MEM_MAX_SEQ canonical={:?} alias={:?}", guard.get_max_seq(&canonical), guard.get_max_seq(&alias));
}

#[test]
fn probe_replay_guard_persistent() {
    let kp = KeyPair::generate().unwrap();
    let canonical = kp.did().clone();
    let alias = alias_of(&canonical);
    let store = Arc::new(icn_store::SledStore::temporary().unwrap());
    let mut guard = ReplayGuard::new_persistent(300, 3600, store.clone());
    let e1 = SignedEnvelope::new(&canonical, &kp, 5, PayloadType::Gossip, b"m".to_vec()).unwrap();
    let e2 = SignedEnvelope::new(&alias, &kp, 5, PayloadType::Gossip, b"m".to_vec()).unwrap();
    let r1 = guard.check(&e1, ObservedSenderRegime::LegacyOrUnproven);
    let r2 = guard.check(&e2, ObservedSenderRegime::LegacyOrUnproven);
    println!("PERSIST_CANONICAL_SEQ5={:?}", r1.as_ref().map(|_| ()).map_err(|e| e.to_string()));
    println!("PERSIST_ALIAS_SEQ5={:?}", r2.as_ref().map(|_| ()).map_err(|e| e.to_string()));
    let _ = guard.finalize(&canonical, 5);
    let _ = guard.finalize(&alias, 5);
    use icn_store::Store;
    let rows = store.scan(b"").unwrap();
    let mut keys: Vec<String> = rows.iter().map(|(k, _)| String::from_utf8_lossy(k).to_string()).collect();
    keys.sort();
    println!("PERSIST_ROW_COUNT={}", keys.len());
    for k in &keys { println!("PERSIST_ROW {}", k.chars().take(60).collect::<String>()); }
    // Reload into a fresh guard: how many distinct windows come back?
    let mut guard2 = ReplayGuard::new_persistent(300, 3600, store.clone());
    let n = guard2.load_persisted_state().unwrap();
    println!("PERSIST_RELOADED_WINDOWS={n} peer_count={}", guard2.peer_count());
}

#[test]
fn probe_third_party_respell_replay() {
    // Attacker has NO key material: captures a validly-signed envelope and only rewrites `from`.
    let kp = KeyPair::generate().unwrap();
    let canonical = kp.did().clone();
    let alias = alias_of(&canonical);
    let captured = SignedEnvelope::new(&canonical, &kp, 9, PayloadType::Gossip, b"real-payload".to_vec()).unwrap();
    let mut forged = captured.clone();
    forged.from = alias.clone();              // only change: spelling of the sender
    println!("TP_SIGNATURE_BYTES_UNCHANGED={}", forged.signature == captured.signature);
    println!("TP_FORGED_VERIFIES={}", forged.verify(3600).is_ok());
    let mut guard = ReplayGuard::new(300, 3600);
    let a = guard.check(&captured, ObservedSenderRegime::LegacyOrUnproven);
    let b = guard.check(&captured, ObservedSenderRegime::LegacyOrUnproven); // control: true replay rejected
    let c = guard.check(&forged, ObservedSenderRegime::LegacyOrUnproven);   // re-spelled replay
    println!("TP_ORIGINAL_ACCEPTED={} TP_CONTROL_REPLAY_REJECTED={} TP_RESPELLED_REPLAY_ACCEPTED={}", a.is_ok(), b.is_err(), c.is_ok());
    // And a from-rewrite to a DIFFERENT key's DID must fail (signature binds the key bytes, not the spelling)
    let other = KeyPair::generate().unwrap();
    let mut forged2 = captured.clone();
    forged2.from = other.did().clone();
    println!("TP_OTHER_KEY_FROM_VERIFIES={}", forged2.verify(3600).is_ok());
}

Observed at 798c8d54 (identical at bca3dd0e):

CONTROL_ALIAS_NE_CANONICAL=true   ALIAS_KEY_SAME=true
CANONICAL_VERIFIES=true   ALIAS_VERIFIES=true   FROM_FIELDS_DIFFER=true   ALIAS_WRONG_KEY_VERIFIES=false
MEM_CANONICAL_SEQ5_ACCEPTED=true
MEM_CONTROL_SAME_SPELLING_SEQ5_REPLAY_REJECTED=true (Some("Replay detected from did:icn:z…: sequence 5 already seen (max: 5)"))
MEM_ALIAS_SEQ5_ACCEPTED=true   MEM_PEER_COUNT=2   MEM_MAX_SEQ canonical=Some(5) alias=Some(5)
PERSIST_CANONICAL_SEQ5=Ok(())   PERSIST_ALIAS_SEQ5=Ok(())   PERSIST_ROW_COUNT=4
PERSIST_ROW replay_finalized:did:icn:f…   PERSIST_ROW replay_finalized:did:icn:z…
PERSIST_ROW replay_max_seq:did:icn:f…     PERSIST_ROW replay_max_seq:did:icn:z…
PERSIST_RELOADED_WINDOWS=2 peer_count=2
TP_SIGNATURE_BYTES_UNCHANGED=true   TP_FORGED_VERIFIES=true
TP_ORIGINAL_ACCEPTED=true   TP_CONTROL_REPLAY_REJECTED=true   TP_RESPELLED_REPLAY_ACCEPTED=true
TP_OTHER_KEY_FROM_VERIFIES=false

The controls matter. CONTROL_ALIAS_NE_CANONICAL must print true before I7 — it proves the two spellings really are distinct Dids today, so ALIAS_VERIFIES=true demonstrates the bypass rather than passing vacuously on two values that were equal all along. MEM_CONTROL_SAME_SPELLING_SEQ5_REPLAY_REJECTED and TP_CONTROL_REPLAY_REJECTED prove the guard does reject a genuine same-spelling replay, so …ALIAS…ACCEPTED is a bypass and not a guard that accepts everything. ALIAS_WRONG_KEY_VERIFIES=false and TP_OTHER_KEY_FROM_VERIFIES=false prove the signature still binds the key — only the spelling is free. After I7 the first control inverts, and the probe must be re-read accordingly rather than re-run unchanged. (When run under the DurableV1 regime instead of LegacyOrUnproven, the persistent guard answers both envelopes with the #2517 "holding sequence … for 600s" transition error — the namespace hold, orthogonal to this finding — while still writing one replay_sender_regime: row per spelling.)