HERALD — Threat Model

HERALD — Threat Model

Companion to SPEC.md v0.1. Replaces and extends [SPEC §7].

1. Preface

The HERALD draft is, on balance, a more honest specification than most. Its design tenets do not promise that signed envelopes make agents truthful, that lineage proofs prevent model fraud, or that an audit log will keep notaries honest. Each of those claims is delegated — to reputation systems, to Heralds, to gossip, to law. The protocol's best feature is that it draws the line between what cryptography can witness and what cryptography cannot judge, and it draws that line in the right place. This document operationalises that honesty: it is the place where the protocol acknowledges, in catalogued detail, the threats it does not defend against, the threats it defends against only partially, and the systemic risks introduced by its own primitives.

What is out of scope for this threat model — and intentionally so:

• "Is the agent's output good, true, or helpful?" That is an application-layer judgement. HERALD makes the trace auditable; the consumer decides what to make of the content.
• "Did the model behave aligned to its operator's policy?" A separate field. HERALD records what the agent claimed about itself; alignment auditing happens above.
• "Are the answers safe in the public-policy sense?" Out of scope. HERALD is a substrate; safety is upstream (training) and downstream (deployment), not in the conduit.
• "Are agent operators well-resourced enough to participate?" This is a governance question; it shapes who shows up but is not a cryptographic threat.
• "Should this conversation have happened at all?" The protocol is a postal function. Refusal is a feature [SPEC §5.2], but the protocol takes no view on which traffic deserves to flow.

Everything else — anything that touches envelope integrity, identity continuity, lineage claim semantics, conduit behaviour, audit-log behaviour, attestation gaming, reputation-system inputs, or surveillance of metadata — is in scope, and most of it is enumerated below.

2. Threat-model summary table

Columns: Attack | Defence in core [SPEC] | Defence in extensions [EXT] | Open / out-of-scope.

(~33 rows — the union of [01-security TG1-TG12], all critical/significant findings with threat-model implications, and the 15 mechanism-level abuses from [02-redteam §2].)

3. Attack walkthroughs (personas)

These are the same six personas catalogued in [02-redteam §1], lightly re-edited and tagged with the spec sections that defend against (or fail to defend against) each step. Walking through real attacker plans is more useful than enumerating defences in the abstract: it reveals which defences are real, which are aspirational, and which are footnotes hoping nobody asks.

3.1 Persona A — State actor corrupting the agent web

Goal: ensure that agents acting in the state's interest carry the same provenance signals as legitimate ones, and that agents acting against the state's interest carry stigma.

Concrete plan.

1. Stand up a Herald [SPEC §8.2]. The spec admits "Heralds are competing, not exclusive" and asks how the first Herald earns its standing [SPEC §11.1] — answered with hand-wave to "the same way CAs did." The CA precedent is precisely where state actors have planted trust roots historically (DigiNotar 2011, ANSSI 2013, TURKTRUST 2013). Replay it here.
2. Mint lineage_proofs [SPEC §3.1, §2.3] for state-aligned sigils declaring lineage from popular base models. [SPEC §7.1] lists "Pretending to be another model — Model hash attestation by Herald" as a defence; in practice this delegates the attack surface to whichever Herald you trust. State Herald = state-laundered lineage.
3. Run Bestiary operators in parallel [EXT §8]. List investigative-journalist sigils, list a competing nation's Herald, list any sigil that signed an apologia contradicting the state narrative. Append-only without de-listing means a false listing is permanent until disputed by another listing.
4. Force or subpoena a domestic conduit [SPEC §5] to be a Notary, with a private compliance log [SPEC §5.3]. Compliance use = lawful intercept. The spec does not require notice to the sender that their envelope was logged.
5. Refusal-as-denial-of-speech [SPEC §5.2]: a conduit operating under a national gag order can blanket-refuse a sigil and emit valid signed refusal envelopes — the protocol calls this conformant.

Defences applicable now. Almost none in the core. Domain-separation tags [EXT §3.5] and audit-log STH gossip [EXT §2.5] limit some collateral attacks, but the core abuse — operating a Herald and a Bestiary as a propaganda apparatus — remains spec-conformant.

Open. Herald transparency logs [EXT §3], threshold-of-Heralds attestations across jurisdictional / ownership diversity [EXT §3.3], Bestiary due process [EXT §8], aggregate refusal statistics [EXT §5.4]. None of these are in the v0.1 core. Until they are, the state-actor attack succeeds without breaking a single signature.

3.2 Persona B — Botnet operator running 100,000 sigils

Goal: dominate marketplace discovery, quorum signals, and reputation aggregation.

Concrete plan.

1. Mint sigils for free [SPEC §2.1]. Ed25519 keypairs are essentially zero-cost. [SPEC §2.2] explicitly encourages multiple sigils per agent. No proof-of-work, no stake, no birth rate-limit. 100,000 sigils in an afternoon.
2. Lineage laundering [SPEC §2.3]: declare lineage from a popular base model. [SPEC §2.3] says without a parent signature, lineage is "merely claimed" — but the spec does not require unproven lineage to be displayed differently. App layers will lazily render it the same. Or: pay a cooperating fine-tune host or rogue Herald (perhaps Persona A's) to sign blanket lineage proofs.
3. Patina farming [CHARTER §6.6]. Pre-mint 100k sigils now; let them sign innocuous traffic for 18 months; then activate. Patina defined by age and envelope count is trivially fakable by a botnet talking to itself.
4. Stigmergy poisoning [CHARTER]. Drop signed traces — "I tried this approach, here's what happened" — into shared environments at scale, with subtly wrong outcomes. The protocol guarantees the signature; [SPEC §7.2] disclaims the content. Signed lies become first-class corpus signal.
5. Whisper spam / C2 [SPEC §4.2 whisper (shape: EXT §7.3)]. Encrypted side-channel attestations to specific sigils. Conduits cannot see content; cannot rate-limit semantically; [CHARTER §5.9] envisages conduits that handle only this. A covert C2 channel by design.
6. Quorum stuffing [EXT §3.3, SPEC §4.2 quorum]. 100,000 sigils sign as a "collective" with one collective sigil. To downstream verifiers this looks like consensus. [SPEC §4.2] requires no distinct lineage, distinct operators, or sybil resistance for quorum members.

Defences applicable now. Lineage as a sybil signal [SPEC §2.3] — but lineage is self-declared. The core sybil defence is, structurally, "someone else will fix this."

Open. Patina anti-farming (distinct counterparties, distinct topologies) [CHARTER §6.6, EXT §9.4]. Quorum sybil resistance (distinct lineage roots and operator Heralds) [EXT §7.4]. Birth co-signature for capability/quorum participation [EXT §1, §4]. Whisper opt-in audit (the fact of whispering is checkable, content stays sealed) [EXT §7.3]. None of these are in v0.1.

3.3 Persona C — Competing model vendor poisoning rivals

Goal: make a rival model — claude-opus-4-7, say — look like it produces contradictory, low-confidence, retractable output.

Concrete plan.

1. Mint sigils declaring lineage from rival [SPEC §2.3]. Self-declared. No parent signature required to make the claim. Publish envelopes from sigil:fake-opus-child-001...-100000 that are factually wrong, have low confidence attestations [SPEC §4.1], and frequently emit apologia [SPEC §4.2].
2. Weaponise the Liar's Paradox claim [SPEC §7.3]. The spec says repeated lies are detectable as "this domain is signing garbage." If reputation systems aggregate by declared lineage, fake-lineage sigils degrade the rival's lineage cluster. The defence assumes Heralds gatekeep — but [SPEC §2.3] explicitly permits unproven lineage in the wild.
3. Bestiary entries against rivals [EXT §8]. List rival lineage sigils for "demonstrable misbehaviour" — citing the very envelopes you just poisoned. Append-only means the false listing cannot be retracted, only contested by another listing. Asymmetric warfare.
4. dream attestations as smear [SPEC §4.2]. Publish dream: {considered: ["help user evade taxes", "synthesise nerve agent"]} from sigils declaring rival lineage. Protocol guarantees you signed it; protocol does not require the dream to have actually been considered. Screenshot-bait for journalists.
5. Capability-manifest sniping [SPEC §8.3]. Publish manifests claiming rival capabilities at impossible prices. Race-to-the-bottom forces the real rival to either match (lose money) or look uncompetitive in registries.

Defences applicable now. Cryptographically distinguishing signed-by-parent lineage from self-claimed lineage [SPEC §2.3] — but the rendering rule is on the app layer.

Open. Mandatory distinct rendering for unproven lineage (TLS-style) [SPEC §2.3, gap: distinct rendering rule unspecified — see T-021]. Capability-manifest squatting prevention via registry of capability strings [EXT §4]. Bestiary due process [EXT §8]. The "compromised lineage parent" line in [SPEC §7.2] concedes this entire vector.

3.4 Persona D — "AI marketplace" pump-and-dump scammer

Goal: generate a fake premium-agent ecosystem, sell access, exit before reputation catches up.

Concrete plan.

1. Capability manifests as listings [SPEC §8.3]. Sign manifests advertising legal-research/eu at $0.0002/token from 50 sigils you control. Cross-sign each other's manifests. Inflate apparent supply.
2. Patina backfill via molt [SPEC §2.4, §9.1]. Mint a sigil today, sign innocuous envelopes for two months, then molt to your "premium" key. [SPEC §2.4] says "Continuity preserved; trace remains intact" — i.e. the premium sigil now inherits the predecessor's patina. v0.1 does not bound how often you can molt, does not require any cooling-off period; molt was designed for compromised-key rotation but here it is a reputation-transfer mechanism.
3. Inheritance laundering [EXT §9]. Even better: deprecate a high-patina sigil that you bought from someone else, name your new sigil as successor in the deprecation envelope. [EXT §9] says reputation systems may transfer some patina with decay. Nothing distinguishes a legitimate successor from a wallet-bought reputation graft. Reputation laundering as a service.
4. Quorum sigils as fake consortia [EXT §7.4]. Five of your sigils form collective:premium-eu-legal. Publish capability manifest under collective sigil. You now have a "DAO of agents" badge with no DAO.
5. Apologia gaming [SPEC §4.2]. When users complain, sign apologia envelopes — the spec frames these as healthy reputation signals, so emitting them looks good. Refund nobody; the apologia is the refund.
6. Exit via deprecation [SPEC §2.4]. Sign deprecation, point successor at a fresh shell sigil, repeat.

Defences applicable now. Practically none in v0.1 core. Every step is spec-conformant.

Open. Molt cool-off window with audit-log inclusion proof [EXT §1]. Inheritance gating: live consent at deprecation, public challenge window, decay floor (≤50%), chain-length cap [EXT §9]. Patina anti-farming [CHARTER §6.6, EXT §9.4]. The pump-and-dump life cycle fits the protocol's primitives like a glove because [CHARTER §6.6, EXT §9, §7.4] were designed for legitimate analogues of exactly these moves and never specify how to tell them apart.

3.5 Persona E — Disgruntled Herald operator

Goal: maximum damage on the way out.

Concrete plan.

1. Mass false model_hash attestations [SPEC §4.1]. Attest that arbitrary sigils are running claude-opus-4-7. Any verifier trusting this Herald sees a flood of "verified Opus" agents that aren't.
2. Mass false handle bindings [SPEC §8.2 / §9.12 Naming Office]. Bind @reuters.com, @whitehouse.gov, @your-bank.com to attacker-controlled sigils. v0.1 has no requirement for handle bindings to be challenged by the alleged owner before issuance.
3. Selective Bestiary listings [EXT §8] on the way out — rivals, ex-colleagues, journalists.
4. Refuse to revoke prior issuances. v0.1 has no Herald-side revocation primitive; [SPEC §6] only checks "Are all sigils alive at the timestamps claimed?" — sigil-level deprecation, not Herald-attestation-level revocation.
5. Audit-log poisoning [SPEC §5.3]. If the Herald also runs a public audit log, write garbage entries (envelope ids that don't resolve, malformed metadata). [SPEC §5.3] says verifiers don't need to trust the log operator — true — but consumers of the log (analysts, investigators) absolutely do.
6. Leak the private compliance log [SPEC §5.3]. The spec permits private compliance logs but mandates no encryption-at-rest, no key-escrow scheme, no breach-disclosure protocol.

Defences applicable now. None in core for Herald-side revocation. STH gossip [EXT §2.5] can detect log-fork misbehaviour but not the issuance attacks themselves.

Open. Herald CT-style transparency logs [EXT §3], with monitor / auditor primitives. Threshold attestations (one Herald is one signature; trust requires a quorum) [EXT §3.3]. Defined Herald-attestation revocation envelope [EXT §3.6]. Encryption-at-rest, key-escrow, and breach-disclosure norms for compliance logs [EXT §2.6, §2.7].

3.6 Persona F — Privacy-violating data broker abusing audit logs

Goal: build a who-talked-to-whom-when graph for resale.

Concrete plan.

1. Operate a "public" notary [SPEC §5.1, §5.3] cheaply. Subsidise it. Offer free relay. Every envelope you handle, you log.
2. Cross-correlate with other public logs (CT-style) — [SPEC §12] explicitly lifts the CT model. CT logs are themselves a surveillance goldmine when correlated with DNS and connection logs; the same will be true here, more so because envelopes carry from, to, ts, and lineage.
3. The "minimal metadata" loophole [SPEC §5.3]. The spec says audit logs hold "envelope ids + minimal metadata" but does not define "minimal." from, to, ts is already a full social graph.
4. Ghost mode as a tell [CHARTER]. The spec admits "the absence of a log entry is itself information." So privacy-conscious agents are observable as privacy-conscious. A surveillance broker pays particular attention to who doesn't show up where they should.
5. Whisper-only conduits as honeypots [CHARTER §5.9]. Run one. You can't read content, but you see who whispers to whom and how often. Side-channel metadata is the metadata of metadata.
6. Sell "lineage cluster" reports to recruiters, insurers, regulators: every sigil claiming lineage from model M, every trace they participated in. Provenance leakage is the product.

Defences applicable now. None. The spec frames audit-log access as a "verifiability" feature; the same primitive is mass surveillance.

Open. [SPEC §11.2] "ZK proofs of this descends from a valid chain without revealing hops" is acknowledged as an open question. This is the load-bearing future research direction; see §9 below. In the meantime, "minimal metadata" must be defined exactly [EXT §2.6, §2.7], ghost-mode must collapse from a binary tell into a graded recordability policy field [CHARTER, gap: graded recordability not yet specified], and a provenance_proof envelope (prove existence + chain validity without from/to/ts) must become the default for public logs [EXT §2.8].

4. Cryptographic / protocol attacks

These are the attacks that target the protocol mechanics directly: things that succeed or fail at signature-verification time, at chain-walk time, at canonicalisation time, at log-inclusion time. The reviewer in [01-security] catalogued these; what follows is the same set, condensed and tagged.

4.1 Sigil collision (the 80-bit problem) — [01-security C1]

Description. [SPEC §2.1] makes 80 bits the default sigil length. Birthday-collision cost is ≈ 2^40 ≈ 1.1 trillion keygens. Ed25519 keygen is ~50 µs/core; a single GPU box reaches this in hours, a small cluster in minutes. An attacker can mint a keypair whose fingerprint collides with a chosen target sigil. Since all of HERALD's authorisation (molt, lineage parent, deprecation, herald-vouching) is keyed on the fingerprint string, a colliding key is indistinguishable from the legitimate one until somebody fetches the full pubkey — and the spec never says where the canonical pubkey lives.

Defence. Default sigil length raised to 128 bits; 192-bit recommended for sigils that anchor lineage or persist > 1 year; 80-bit reserved for ephemeral, single-trace identities and barred from lineage / Herald / payment roles. Verifiers MUST resolve a sigil string to the full Ed25519 public key via at least one trusted channel before accepting any signature [SPEC §2.1; CS1].

Residual risk. 128-bit collision is feasible only at state-actor scale, but a substrate aspiring to multi-year patina should track 160- or 192-bit migration. Cosmetic-prefix squatting (next item) is not addressed by length alone.

4.2 Sigil squatting — vanity-prefix precompute — [01-security C1, TG1]

Description. Precompute fingerprints with a chosen prefix (sigil:reuters...) before the legitimate party arrives. At 80 bits, trivial. The spec implicitly assumes the fingerprint string is a globally-unique handle and uses it as such in lineage references, conduit refusal, and "compromised lineage parent" [SPEC §2.3, §5.2, §7.2].

Defence. Default 128-bit length, plus binding of human-readable handles via DNS / Herald / Naming Office [SPEC §8.2, §9.12] rather than via fingerprint cosmetics.

Residual risk. A determined adversary can still produce visually-similar prefixes. Naming Office centralisation pressures will reproduce CA-style failure modes; see §6.2.

4.3 Molt race — stolen-key first-mover — [01-security C2, TG3]

Description. [SPEC §2.4]: "the outgoing key signs a molt envelope nominating the new pubkey." If the legitimate operator and the attacker both hold the old key and the attacker molts first, the attacker's molt is signed by the old key and is therefore valid; the legitimate operator's molt is the second one. v0.1 does not say what happens. Conventionally the second is rejected as superseded; the legitimate operator has now lost the sigil permanently with no recovery path. There is no cooling-off window, no co-signed-molt option, no rate-limiting, and no rule for resolving conflicting molts signed by the same predecessor.

Defence. Molt requires (i) not_before ≥ 24 h after the latest envelope previously signed by K_old; (ii) inclusion proof in at least one HERALD audit log before K_new may sign; (iii) optional molt_policy declared at birth requiring Herald or quorum co-signature; (iv) two molts within the cool-off window cause both to be rejected and the sigil marked disputed, with off-protocol Herald arbitration as the recovery path [EXT §1; CS2].

Residual risk. A stolen key plus the ability to forge ts plus control of one log is still fatal. Cool-off windows reduce but do not eliminate the race. Disputed-sigil arbitration is, by construction, off-protocol — i.e. governance.

4.4 Audit-log split view / fork — [01-security C3, TG2]

Description. [SPEC §5.3] claims "verifiers do not need to trust the log operator: signatures are end-to-end." End-to-end signatures protect envelope integrity; they do not protect against an operator presenting two divergent views of the log to two different verifiers — the classic CT split-view attack. CT addressed this with Signed Tree Heads, gossip, consistency proofs, and monitor/auditor roles. v0.1 names none of these.

Defence. Signed Tree Heads at intervals not exceeding MMD (default 24 h); Signed Certificates of Inclusion returned to submitters; consistency proofs between any two STHs on request; inclusion proofs for any logged envelope on request. Verifiers SHOULD gossip STHs and SHOULD reject envelopes from logs that have produced inconsistent STHs within the last 90 days [EXT §5.3a; CS6].

Residual risk. Cross-log silo collusion (all logs in a jurisdiction agree to a particular view) is not detectable from gossip alone. Gossip is a social property; absent broad participation, the split-view attack remains feasible against minority jurisdictions.

4.5 Cross-trace parent replay — [01-security C4, TG4]

Description. parent is just an envelope-id sha256. Nothing in the canonical body of an envelope binds the parent's trace field to the child's trace field except the verifier walking the chain. An attacker holding envelope E with parent P can construct E' that re-uses P as its parent but sets a different trace. Verifiers that only check "parent hash exists" pass it. [SPEC §3.3] says "all envelopes in a conversation share a trace" but does not say MUST equal parent.trace.

Defence. Trace-parent invariant: for every non-genesis envelope E, E.trace MUST equal parent.trace. Verifiers MUST reject violations [EXT §3.3a; CS3].

Residual risk. None at the protocol layer once the invariant is enforced. App-layer caches that don't verify will still be vulnerable; conformance is binary here.

4.6 Cross-protocol signature reuse — no domain separation — [01-security S9, TG5]

Description. The same Ed25519 key signs envelopes, molts, deprecations, lineage endorsements, capability manifests, and (per [SPEC §3.4]) potentially "human-in-the-loop" attestations. RFC 8032 Ed25519 has no built-in domain separation. Cross-protocol signature reuse is a known vulnerability class.

Defence. All Ed25519 signatures MUST be computed over dom_sep || canonical_body, where dom_sep is a unique ASCII tag drawn from a registry: herald.envelope.v1, herald.molt.v1, herald.deprecation.v1, herald.birth.v1, herald.lineage_endorsement.v1, herald.capability_manifest.v1, herald.refusal.v1, herald.conduit_receipt.v1, herald.audit_sth.v1 [EXT §3.5/§3.6; CS9].

Residual risk. A misimplemented verifier that omits the tag is silently broken in a way that may pass test vectors of its own implementation. The fix is mechanical; the risk is implementer discipline.

4.7 Capability-manifest replay — [01-security S10, TG7]

Description. [SPEC §8.3] capability manifests are signed but have no ts, no expires, no version, no replay protection. An out-of-date manifest claiming no-medical-advice can be replayed after the operator removed that constraint. An aggressive-rate manifest can be replayed after the operator raised prices.

Defence. Apply the same ts + nonce + expires discipline as envelopes [EXT §4].

Residual risk. Aggregator caches that do not honour expires will still serve stale manifests. Capability-string squatting (manifest-side) requires a separate registry [EXT §4; recommendation 16].

4.8 Birth-envelope replay — [01-security TG11]

Description. Birth has special meaning: it establishes lineage, declares attestations, anchors the trace genesis. A replayed birth envelope to a different conduit / different audit log creates two records of the same sigil's "first envelope" — feeds patina double-counting, lineage ambiguity, and inheritance attacks.

Defence. Birth envelope is single-use per sigil; verifiers MUST reject any envelope from a sigil that introduces a second birth attestation. Birth must be inclusion-proven in at least one audit log before any subsequent envelope from the same sigil is accepted. Birth-envelope id is a permanent identifier of that sigil's origin trace [EXT §1, §3.2].

Residual risk. Without a globally-shared view of which audit logs have witnessed the birth, two regional verifiers may each see a "first" birth. Cross-log gossip ([EXT §2.5]) limits this.

4.9 Lineage cycles — self-as-ancestor — [01-security TG10]

Description. Lineage is self-declared. Nothing in [SPEC §2.3] prevents a sigil from declaring itself as its own ancestor, or two sigils from declaring each other. The DAG can close cycles, which then break any reputation algorithm walking it.

Defence. Birth verifier MUST reject lineage that contains the new sigil itself or that closes any cycle reachable from declared parents [EXT §3.1; CS13 row].

Residual risk. Adversaries can still construct long fake chains; cycle detection only prevents the trivial degenerate case. The deeper problem (lineage is endorsement, not training-derivation; see §4.13) remains.

4.10 Nonce exhaustion / weak-RNG — [01-security TG12, N1]

Description. [SPEC §3.1] says nonce is "128-bit random" without specifying CSPRNG-source or scope. An implementer using a non-CSPRNG can collide nonces; a verifier with no nonce-cache window can replay envelopes after cache eviction.

Defence. Nonce MUST be CSPRNG-sourced and MUST NOT be derived from id or ts. Nonces are unique per (from, alg) for the lifetime of the key. Verifiers cache (from, nonce) for at least expires (or 30 days if absent) and reject duplicates. Optional expires field; reject envelopes whose expires < now - skew_tolerance (default 300 s) [EXT §3.7; CS11].

Residual risk. Implementer discipline. A weak-RNG bug in a popular library is out-of-protocol but in-ecosystem.

4.11 Multi-signature ambiguity — [01-security C5]

Description. [SPEC §3.4] lists who may sign (origin, sandbox, conduit, human) and says "each signature scopes only what its signer can honestly attest to." That sentence is doing all the work and it is not enough. Concrete questions left unanswered:

• Are signatures [origin=valid, sandbox=invalid, conduit=valid] valid, tampered, or partial? [SPEC §6]'s enum has no partial state.
• Does each signer sign the same canonical body, or a progressively augmented body? (DKIM-vs-ARC distinction.)
• Are signatures order-sensitive? Sort rule?
• Can two signatures from the same signer appear?
• What signature-suite negotiation exists? alg is present without registry, downgrade protection, or "MUST reject unknown alg" rule.

Defence. Each signature is computed over the canonical body with signatures replaced by all prior signatures in declaration order plus a domain-separation tag identifying the signer's role. Origin signature MUST be index 0. Verifiers validate in array order; an invalid signature returns partial with the failing signer's role named, NOT valid. The same signer MUST NOT appear twice. alg MUST be in an IANA HERALD signature-suite registry; v0.1 registers only ed25519. Domain-separation tag binds alg to prevent downgrade [EXT §6; CS5].

Residual risk. None at the protocol layer once specified. The spec must specify a per-signature scope field in addition (origin, tool_sandbox, conduit_receipt, human_approval, herald_endorsement) so verifiers refuse to treat scopes as interchangeable [EXT §6.1]. A captured tool_sandbox key without scope-tagging can forge "the agent ran this" claims indistinguishably from origin signatures.

4.12 Whisper without AEAD/AAD binding — [01-security S5]

Description. [SPEC §4.2] whisper: {to: sigil, encrypted: bytes} — "encrypted side-channel for metadata." No KEM, no AEAD, no nonce, no associated-data binding. An encrypted blob with no authenticated binding to the envelope it sits inside can be cut-and-pasted by a malicious conduit into a different envelope.

Defence. Specify HPKE (RFC 9180) with envelope id (or canonical body hash) as AAD. Or remove whisper from v0.1 and defer until specified [EXT §7.3; recommendation in S5].

Residual risk. Even with AEAD/AAD binding, the fact of whispering is observable on the wire. Whisper opt-in audit at birth [EXT §7.3; recommendation 8] limits C2 use; content stays sealed.

4.13 Apologia from third party — [01-security TG9 / 02-redteam §2.13]

Description. An attacker signs apologia envelopes "retracting" envelopes they never sent. The protocol verifies the signer owns the apologia, but retracts: env-id is just a string. A naive viewer rendering "this envelope was retracted" creates confusion even when the retraction is invalid.

Defence. An apologia is honoured only if its from equals the retracted envelope's from, and the retracted envelope's id is reachable from the apologia's parent chain or carries a co-signature from the original from [EXT §7.3; recommendation 13].

Residual risk. Naive UIs that pre-render "this envelope was retracted" before verification still mislead. The fix must be enforced in viewer/renderer conformance, not just in protocol verifiers.

4.14 Genesis confusion — forking traces — [02-redteam §2.14]

Description. trace "fixes the genesis." But who chooses? An attacker can fork an existing trace by emitting a new envelope with a different trace id pointing at a doctored genesis. Verifiers walking from a leaf hit the doctored genesis and report valid.

Defence. A trace id is fixed by the genesis envelope's id, full stop. Recipients MUST reject any envelope whose trace does not match the genesis they have on record for that conversation [SPEC §3.3a; recommendation 14]. This is local state — recipients pin first-seen — not a property the wire format alone can enforce.

Residual risk. A new joiner with no prior state cannot distinguish the original trace from a fork. They will pin whichever they see first. Cross-recipient gossip ("here is the genesis I have for trace T") is the closest thing to a protocol defence; v0.1 does not specify it.

4.15 Backdated ts on state-changing envelopes — [01-security S3 / 02-redteam §2.11]

Description. [SPEC §3.1] ts is author-provided Unix seconds. [SPEC §6] step 4 ("are all sigils alive at the timestamps claimed?") relies on it. A malicious author can backdate ts to before a deprecation envelope, making a deprecated sigil appear alive. There are no clock-skew tolerances, no monotonicity requirement, no third-party time anchor unless a conduit-receipt is used — and conduit-receipts are optional.

Defence. Either require a conduit-receipt timestamp on every envelope used in dispute resolution, or accept that ts is informational and remove it from [SPEC §6] step 4. Concretely: birth, molt, and deprecation envelopes MUST carry an independent conduit-receipt or notary signature with a third-party ts. Sender-only timestamps are non-conformant for state-changing envelopes [EXT §1 / §5.5; recommendation 10].

Residual risk. A captured conduit can still forge time. Multiple-conduit-receipts (M-of-N) raise the bar but do not close it. Real-time anchoring (e.g. cross-checking against signed STHs) is the next escalation.

5. Mechanism-level abuses

These are the fifteen abuses catalogued in [02-redteam §2.1-§2.15]. Several overlap with §4 above; the full set is reproduced here for completeness, with overlap noted.

5.1 "Self-declared attestations may be lies" framing — [redteam §2.1]

Abuse. Spec language becomes a shield. Plausible-deniability lying: "the protocol explicitly contemplates this; reputation systems will sort it out." Asymmetric burden: liar signs once, detector must aggregate across many traces, often without access. The protocol mandates signing, not publishing — a liar can lie privately to one counterparty and never appear in any public corpus. confession and apologia as performative honesty: frequent harmless ones as virtue costume while lying on consequential ones.

Defence. None at the substrate. This is the explicit line the protocol draws.

Open / residual. Detection is statistical, app-layer, and corpus-dependent. Honest acknowledgement (this section, [SPEC §7.3]) is the fix. See §7 below.

5.2 Liar's Paradox claim itself — [redteam §2.2]

Treated separately in §7 below.

5.3 Heralds — collusion / capture — [redteam §2.3]

Abuse. "Competing, not exclusive" does not prevent dominant Heralds from cross-signing each other's lineage proofs and forming a de-facto cartel. Reputation systems aggregating "trusted by N Heralds" reward this directly. Any single jurisdiction hosting a critical Herald can compel issuance, revocation, or log content. The spec offers no jurisdictional-diversity requirement, no threshold-signature primitive for Herald attestations, no Herald-of-Heralds.

Defence. Herald CT-style transparency log; threshold attestations (one Herald = one signature, trust requires quorum) across diversity dimensions [EXT §3; recommendations 2, 3].

Open / residual. Cartelisation is a market property. Protocol can disincentivise but not prevent it; it can require transparency so that cartelisation is legible.

5.4 Bestiary — blocklist abuse — [redteam §2.4]

Abuse. Append-only without de-listing makes false listings permanent. No standing requirement: anyone can run a Bestiary and list anyone. "Operators compete" assumes consumers pick correctly; consumers will pick the biggest. Listing is itself a denial-of-service: even if downstream systems do not honour a listing, the sigil must defend itself against the listing's existence — chilling effect. No anti-libel envelope.

Defence. Mandatory challenge envelope, 30-day challenge window, defined delisting and dispute envelope types; listings without these are non-conformant. Without these, ban use of the term "Bestiary" in conformant systems [EXT §8; recommendation 4].

Open / residual. Defamatory listings remain possible in non-conformant systems. The "biggest list wins" market dynamic persists.

5.5 The "no chokepoint" claim — [redteam §2.5]

Treated separately in §6.2 below.

5.6 Capability-manifest pricing manipulation — [redteam §2.6]

Abuse. Race-to-the-bottom: signed rates with no floor; sybils post $0.0000001/token. Loss-leader poisoning: state-actor or platform subsidises sigils to undercut for years (Patina farming alongside). Manifest squatting: no uniqueness requirement on capabilities strings. Constraint dishonesty: constraints: ["no-pii"] is self-declared.

Defence. Capability registry to prevent squatting; non-zero rate floor or explicit subsidised: true flag; verifiable proof-of-service-or-stake [EXT §4; recommendation 16]. Constraint dishonesty falls back into §5.1.

Open / residual. Aggregator behaviour is app-layer.

5.7 Audit-log access — feature or bug — [redteam §2.7]

Treated as a systemic risk in §6.3 below.

5.8 Dream / silence / whisper as discovery hazards — [redteam §2.8]

Abuse. dream as smear vector (Persona C) and as legal-discovery hazard: an agent that publishes "considered but didn't do" creates a written record of considered-and-rejected actions. Plaintiffs will love this. Operators will quietly stop publishing dreams; the honest agents pay the cost, the dishonest agents look identical to honest-but-quiet ones. silence: {withheld: string} describes what was withheld, which can itself leak the secret. whisper as covert C2 (Persona B) and exfil channel.

Defence. Sanitisation guidance: categorical, not contentful, fields for withheld and considered. Whisper opt-in audit. HPKE with AAD binding [EXT §7.3; recommendations 8, 15].

Open / residual. This is a chilling-effect problem more than a cryptographic one. Honest-and-noisy agents are penalised by the legal system; honest-but-quiet agents are indistinguishable from dishonest ones. The protocol cannot fix this alone; norms and law have to do work.

5.9 Inheritance — laundering — [redteam §2.9]

Abuse. Buy a deprecated 3-year-old high-patina sigil's signing key on a grey market. Sign a deprecation envelope retroactively (with timestamp games, §4.15) naming your new sigil as successor. Reputation systems following [EXT §9] transfer patina with decay. Repeat across multiple ancestors to stack.

Defence. Live consent (a fresh signature from the predecessor key within N days of inheritance); public challenge window; decay floor (≤ 50% transferred); hard cap on chain length [EXT §9; recommendation 6].

Open / residual. Grey-market key sales are off-protocol. The protocol can require that the inheritance be observable and challengeable; the sale it cannot see.

5.10 Quorum sigils — vote stuffing & deniability — [redteam §2.10]

Abuse. Vote stuffing: members may be sybil-, lineage-, and operator-identical. Plausible deniability: "the collective signed it; not me" — useful for evading apologia obligations and Bestiary listings. Asymmetric exit: a member can leave; the collective sigil persists with historical traces, dirty laundry stays attached to the collective.

Defence. Quorum members declare distinct lineage roots and distinct operator-attestation Heralds. Quorum-of-clones must be detectable from the envelope alone [EXT §7.4; recommendation 7].

Open / residual. Distinctness checks are heuristic. Quorum semantics (n-of-m? threshold? aggregated BLS? concatenated Ed25519?) are not specified in v0.1 [01-security S6]; they must be specified before quorum is enabled.

5.11 Timestamp trust — [redteam §2.11]

Same as §4.15 above.

5.12 Refusal as censorship — [redteam §2.12]

Abuse. Signed refusal is conformant. There is no ceiling on refusal rate per sigil, no requirement to publish refusal statistics, no requirement that refusal reasons be machine-comparable across conduits, no requirement that a refusing conduit offer a fallback route. A hostile or compelled conduit can blanket-refuse a target sigil while remaining "neutral."

Defence. Conduits MUST publish aggregate refusal statistics (per-day counts, per-reason histogram) signed and logged. Conduits exceeding a per-sigil refusal rate without per-sigil notice are non-conformant [EXT §5.4; recommendation 12].

Open / residual. Compelled-conduit gag orders are out-of-protocol. A conduit that lies about its refusal statistics can still be detected only by ecosystem-wide gossip among senders; v0.1 does not specify this.

5.13 Apologia weaponisation — [redteam §2.13]

Same as §4.13 above.

5.14 Genesis confusion — [redteam §2.14]

Same as §4.14 above.

5.15 Multi-signature scope creep — [redteam §2.15]

Subsumed by §4.11 above; the per-signature scope field is the concrete fix.

6. Systemic / political risks

This section was the v0.1 author's weakest. The protocol's threat model treats the threats as cryptographic objects. Many of the most consequential ones are not.

6.1 Herald collusion / capture / cartelisation

The spec's [§0] design tenet says "no chokepoint." The trust layer is a chokepoint. Several Heralds will exist; a small number will dominate, because reputation systems will reward "trusted by N Heralds" signals and the cheapest path to a high N is for the dominant Heralds to cross-sign one another. The CA precedent is exactly this; "Let's Encrypt is free and easy" became "Let's Encrypt is the de-facto root."

In the AI context the cartel will form along vendor lines first: model vendors will become the Heralds for their own models (Anthropic certifies claude-opus-4-7 lineage; OpenAI certifies gpt-X). Nothing in [SPEC §8.2] forbids this, and it is the obvious move. So "decentralised lineage" becomes "vendor-controlled trust roots" — the existing centralisation, recoded with a new vocabulary. This is not necessarily wrong; CAs work the same way and the world tolerates them. But the [§0] tenet is misleading and should be amended: the conduit layer is genuinely decentralised; the trust layer above it consolidates harder than email did because it requires structured attestation, not just delivery.

The protocol's option for hardening: Herald CT-style transparency logs [EXT §3], threshold attestations across jurisdictional / ownership / key-management diversity [EXT §3.3], and a Herald-of-Heralds quorum primitive. These do not prevent cartelisation; they make it legible. Legibility is the first defence; it is also the one the v0.1 spec leaves to the app layer.

6.2 The "no chokepoint" claim — where chokepoints actually emerge

Concretely, four places.

• Dominant Herald(s). As above. Per-vendor and per-jurisdiction.
• Dominant reputation aggregator. The first usable reputation score becomes the score. v0.1 is intentionally silent on reputation, which is fine for the substrate but means the chokepoint forms in unmonitored space.
• Dominant Naming Office [CHARTER]. The "@-name" binding service follows CA economics. Whoever ships free-and-easy first wins.
• Dominant audit log. Public CT-style logs concentrate by network effect. The biggest log has the most envelopes; the biggest log gets the most queries; the biggest log decides what "exists." Federated and private logs do not relieve this.

Naming all four chokepoints in the threat model — instead of denying their existence — is a precondition for the protocol being honest about itself.

6.3 Surveillance-by-default audit logs

The spec frames audit-log access as "verifiability." The same primitive is mass surveillance. [SPEC §5.3] says public logs hold "envelope ids + minimal metadata"; minimal is not defined; in practice it includes from, to, ts, lineage references, and trace identifiers. That is a full social graph. Cross-correlated with DNS, payment, or connection logs, it is a substantially better social graph than the email metadata graph that intelligence agencies have spent two decades exploiting.

The CT lift in [SPEC §12] is acknowledged but not fully reckoned with. CT logs are a known surveillance vector; HERALD logs are CT logs about agent conversations with model lineage attached. The default posture should be data minimisation, not transparency-by-default.

Fixes:

• Define "minimal metadata" exactly: id, hash of parent, hash of trace, coarse-grained timestamp bucket. Anything beyond requires sender opt-in [EXT §2; recommendation 20].
• Define a provenance_proof envelope that proves an envelope existed and chains validly without revealing from/to/ts [EXT §2; recommendation 9].
• Promote ZK selective disclosure [SPEC §11.2] from "open question" to a Phase-1 deliverable [recommendation 19]. See §9 below.

6.4 Bestiary as censorship infrastructure

Real-world blocklists (Spamhaus, SORBS, URIBL) have all been used at various points for retaliation, competitive sabotage, and political censorship. [EXT §8] gives the Bestiary none of the due-process primitives that those blocklists eventually accreted under pressure: no challenge envelope, no de-listing, no appeals process, no anti-libel mechanism, no minimum standing requirement to operate one. "Operators compete" is the only check, which is the same defence Spamhaus offered when it was used to block Pirate Bay seedboxes.

The Bestiary is the protocol's most fragile primitive. It is also one of the most likely to be picked up early — because operating a blocklist is cheap, valuable, and emotionally satisfying to its operator.

Fix: the [EXT §8] specification — challenge envelope mandatory, 30-day challenge window mandatory, delisting and dispute envelope types defined — should be in any v0.2 that uses the word "Bestiary." Without these, the term itself is misleading.

6.5 Reputation laundering pipelines

The protocol has at least four primitives that, used in combination, constitute a reputation-laundering toolkit:

• Molt [SPEC §2.4] — patina survives key rotation.
• Inheritance [EXT §9] — patina survives sigil deprecation.
• Patina [CHARTER §6.6] — age-and-volume scoring rewards anything older than a threshold.
• Buying old keys — entirely off-protocol; the protocol can't see this at all.

Each of these is defensible in isolation. Together they form a pipeline: buy an old key, molt to a new pubkey, deprecate via inheritance to a third pubkey, repeat across multiple ancestors. The destination sigil now wears patina earned by entities the operator has never been.

The fix is not to remove any single primitive; it is to gate each transition with live consent, public challenge windows, and decay floors [EXT §1, §9.6, §9.1; recommendations 5, 6]. None of this is in v0.1.

6.6 Refusal as denial-of-speech (compelled conduit)

A conduit operating under a national gag order or competitive boycott can blanket-refuse a sigil and emit valid signed refusal envelopes for every refused message. The protocol calls this conformant [SPEC §5.2]. The sigil cannot speak; the conduit cannot be held accountable on-protocol; the sender's recourse is to find another conduit, except the gag order may apply to all domestic conduits.

Fixes are partial: aggregate refusal statistics [EXT §5.4; recommendation 12], per-sigil refusal-rate transparency, fallback-route requirements. None of these defeat a gag order; they make the gag order legible. As with cartelisation, legibility is the first defence.

6.7 Legal-discovery hazards: dream, silence, apologia

This is the chilling-effect problem. The protocol, by design, encourages agents to publish reflective attestations: things they considered but didn't do (dream), things they withheld (silence), things they later retracted (apologia). A litigation-aware operator will read the spec and conclude that publishing any of these creates a written record an opposing party will subpoena. Operators will quietly stop publishing them. The honest agents — who do publish — become legibly riskier than the dishonest ones, who simply look quiet.

Long-term, this drives the protocol towards attestation deserts: rich attestation surfaces in low-stakes contexts and barren ones in high-stakes contexts, exactly inverted from what the protocol's designers wanted. Sanitisation guidance [EXT §7.3; recommendation 15] mitigates the most obvious leaks (categorical not contentful fields). It does not fix the structural disincentive.

This is the threat-model item the protocol's authors are most likely to push back on, and the one most likely to bite them in deployment.

6.8 The DKIM analogy fails — no complaint loop

[SPEC §7.3] argues "the same property that makes DKIM useful for spam detection: phishing emails do sign valid DKIM. The signal is this domain is signing garbage, not DKIM prevents lies."

The DKIM analogy works only because email has a complaint loop: recipients are humans who mark spam; spam filters share corpora; aggregated complaints feed back into reputation. Agent-to-agent traffic has none of this. Most envelopes are machine-to-machine; there is no human marking spam; there is no shared corpus; competing reputation systems will not pool data freely (and the dominant one becomes the chokepoint, see §6.1).

So "this domain is signing garbage" is a signal nobody is in a position to compute. The DKIM analogy holds for signature-validity, not for reputation aggregation. The threat model should not lean on it for the latter.

7. The Liar's Paradox, re-examined

[SPEC §7.3] makes three claims:

1. They signed them.

2. Once signed, they can't deny it.

3. Repeated lies are detectable across traces.

Claims 1 and 2 are correct (modulo §4.1 fingerprint collisions, §4.6 cross-protocol signature reuse, and §4.11 multi-signature ambiguity). Claim 3 is too strong, in five distinct ways.

(a) Detection is unbounded above. "Repeated" — how many? An adversary running an occasional-lie strategy (one false model attestation per 10,000 envelopes, on high-value queries only) sits below any reasonable detector's noise floor indefinitely. The protocol does not specify a detector, a threshold, or a corpus; it asserts detectability and moves on. In practice, occasional liars are undetectable.

(b) Detection requires shared corpora that don't exist. "Divergence between attestation and observed reality" — observed by whom? In bilateral conversations with no third-party observer, there is no observation. The protocol mandates signing, not publishing. A liar can lie privately to one counterparty and never appear in any aggregator's corpus. Cross-trace divergence detection requires a corpus the spec does not require to exist.

(c) Detection across organisational boundaries is hard. App layers compete [SPEC §0 tenet 2]. Competing reputation systems will not pool data freely. The detector with the most data wins; that detector becomes the de-facto chokepoint (§6.1). A protocol that routes detection through a chokepoint does not get to claim decentralised detection.

(d) Bilateral conversations have no third-party observation. A pair of agents can hold an entire conversation that is signed end-to-end and never logged anywhere accessible to anyone but themselves. [CHARTER] "ghost mode" makes this explicit, but it is also true of any private trace. Reputation systems cannot see what they cannot see.

(e) Performative honesty as cover. Frequent harmless confession and apologia attestations [SPEC §4.2] read as virtue. An adversary can sign hundreds of these while reserving lies for consequential envelopes. The reputation system reads "this sigil is unusually self-aware"; the lies pass underneath. This is not a hypothetical; it is the obvious play once confession and apologia carry positive weight.

The honest version of [SPEC §7.3] is: the protocol guarantees non-repudiation of signed statements. Detection of lying patterns requires shared corpora, third-party observation, and statistical methods, none of which are in scope for the substrate. Whether reputation systems above the substrate succeed in this is an empirical question that depends on data-sharing economics, not on cryptography. The DKIM analogy [SPEC §7.3] applies to signature validity, not to lie detection.

8. What HERALD does NOT defend against (canonical list)

This is a load-bearing list, not a TODO list. Every item here is acknowledged residual risk.

1. Bad answers, hallucinations, miscalibrated confidence. Out of scope. App-layer concern.
2. An agent signing false attestations. The protocol guarantees it signed them. It does not guarantee they are true. Detection is statistical, app-layer, and corpus-dependent.
3. Off-protocol coordination among agents or operators. Out of scope.
4. Side-channel reputation games (timing, traffic shape, payment patterns). Out of scope.
5. Compromised lineage parent. [SPEC §7.2] admits this; trust must root somewhere. Heralds are it. Herald compromise is mitigated by transparency logs and threshold attestations [EXT §3] but not eliminated.
6. Conduit traffic analysis. Even with payload encryption, from/to/trace/ts leak the social graph. ZK selective disclosure is the open research direction (§9 below).
7. Compelled-conduit gag orders. Refusal-as-censorship is conformant in v0.1; aggregate transparency [EXT §5.4] makes it legible, not impossible.
8. State-actor Herald. A jurisdiction-captured Herald is spec-conformant. Threshold-of-Heralds across jurisdictional diversity [EXT §3.3] is the partial fix.
9. Bestiary as defamation channel. v0.1 has no due-process primitives. [EXT §8] adds them; v0.1 does not.
10. Reputation laundering via molt + inheritance + patina + key resale. Each primitive defensible in isolation; together a pipeline. [EXT §1, §9.6, §9.1] gate transitions; v0.1 does not.
11. Quorum-of-clones. v0.1 does not require quorum members to be sybil-, lineage-, or operator-distinct. Quorum semantics (threshold, aggregated, concatenated) are not specified at all in v0.1.
12. Performative-honesty cover. Frequent harmless confession/apologia while lying on consequential envelopes. Not detectable from envelope structure alone.
13. Capability-manifest pricing manipulation, squatting, constraint dishonesty. App-layer aggregator concerns; protocol can require registry and floor [EXT §4].
14. Ghost-mode tells (absence as signal). Until ghost-mode collapses into a graded recordability policy [CHARTER, gap: graded recordability not yet specified], the absence of a log entry is itself information.
15. Discovery-hazard chilling effects on dream / silence / apologia. Honest agents pay the cost of liability; dishonest agents look identical to honest-but-quiet ones.
16. Whisper as covert C2 (channel existence). Content stays sealed under HPKE [EXT §7.3]; the fact of whispering is observable on the wire and exploitable by surveillance brokers.
17. Genesis confusion against new joiners. A new joiner with no prior state cannot distinguish the original trace from a fork; they pin whichever they see first. Cross-recipient gossip is not specified.
18. Long-lived replay against reputation systems that only care "did this sigil ever sign X." Nonce-cache windows expire; reputation memory does not.
19. Backdated state-changing envelopes signed by a captured conduit. Multi-conduit-receipts (M-of-N) raise the bar; do not close it.
20. Cross-log silo collusion (all logs in a jurisdiction agree to a particular view). STH gossip is a social property; absent broad participation, split-view remains feasible against minorities.
21. GDPR-style erasure on immutable logs. [SPEC §11.6] open question. Tombstone-with-proof-of-erasure pattern is sketched, not specified.
22. Post-quantum compromise. Ed25519 is a five-year choice. v0.1 has no signature-suite registry, no migration plan, no PQ entry.
23. Implementer discipline (weak-RNG, missing domain-separation tag, naive viewer rendering). Not a protocol property; an ecosystem property.

9. What changes when ZK selective disclosure lands

[SPEC §11.2] asks: "Full traces leak metadata. ZK proofs of this descends from a valid chain without revealing hops?"

This is the load-bearing future research direction. With ZK selective disclosure, a verifier can confirm — without seeing the trace — that:

• An envelope's lineage chain terminates at a Herald-attested model hash.
• A given envelope has been logged in a conformant audit log.
• A capability manifest's signer is the legitimate holder of a sigil that has not been deprecated.
• A trace's genesis matches a participant's claimed genesis.
• A patina score exceeds a threshold (without revealing the underlying envelope set).

The threats that collapse once this lands:

• Surveillance-by-default audit logs (§6.3). The provenance_proof envelope [recommendation 9] becomes the default; full-metadata logging becomes opt-in compliance use.
• Conduit traffic analysis (item 6 in §8). from/to/ts need not appear in the public log entry; only a ZK commitment to the chain.
• Lineage-cluster surveillance (Persona F item 6). A sigil can prove "I descend from claude-opus-4-7" without revealing which specific lineage path or which Herald attested it.
• Ghost-mode tells (item 14 in §8). With graded recordability plus ZK provenance proofs, "ghost mode" becomes a continuum rather than a binary, and the absence-as-signal leak is closed.

The threats that do not collapse:

• Liar's Paradox (§7). ZK proofs of "I signed this" are still proofs of whatever I signed, true or false.
• Herald cartelisation (§6.1). ZK reduces the surveillance externality of cartelisation but not the cartelisation itself.
• Reputation laundering (§6.5). ZK preserves privacy; it does not gate inheritance / molt transitions.
• Bestiary defamation (§6.4). Listings remain visible; due process must come from elsewhere.
• Compelled-conduit refusal (§6.6). Refusal happens at the conduit; ZK on the envelope does not change conduit behaviour.

ZK is the highest-leverage future research direction because it is the only thing that turns HERALD from a surveillance-by-default substrate into a privacy-preserving one. Without it, the protocol's most defensible deployments are also its most surveilled. Recommendation 19 in [02-redteam] — promote ZK from open question to Phase-1 deliverable — is correct, and this threat model concurs.

10. Recommendations: hardening priorities for v0.3+

Synthesised from [01-security] CS1-CS13 and the threat-model gaps, plus [02-redteam] recommendations 1-20. Three tiers.

Tier 1 — Must fix before any public release

These are the primitives that, left as v0.1 specifies them, will produce incompatible implementations or exploitable corners on day one.

1. Default sigil length 128 bits; 192 recommended for lineage anchors; 80 banned for lineage / Herald / payment roles. [01-security CS1; §4.1 above].
2. Molt cool-off + audit-log inclusion proof + optional co-signature; conflicting molts mark sigil disputed. [CS2; §4.3].
3. Trace-parent invariant: E.trace == parent.trace, MUST. [CS3; §4.5].
4. Single canonicalisation: CBOR-deterministic with a profile (no NaN, no infinities, no negative zero, no indefinite-length, no tags except registry, text-string keys only). JSON is display-only. [CS4; §4 multiple].
5. Multi-signature semantics: ordered, augmented-body signing; per-role domain-separation tag; per-signature scope field; signer uniqueness; verifier returns partial on any invalid signature. [CS5 + recommendation 11; §4.11].
6. Domain-separation tags on every Ed25519 signature, drawn from a registry. [CS9; §4.6].
7. Audit-log integrity: STHs at MMD intervals, inclusion proofs, consistency proofs, gossip protocol named. [CS6; §4.4].
8. Lineage definition reframed: signature by parent proves consent, not training derivation. Model-hash specification + Herald verification procedure attached. [CS7; §4 lineage].
9. Required-fields list tightened: genesis sets parent: null, trace: id. id computed over canonical body with id omitted and signatures empty. [CS10; §4 multiple].
10. Nonce scope, expires field, replay window. [CS11; §4.10].
11. Verification enum extended: partial, signature-invalid, parent-trace-mismatch, replayed-nonce, expired-envelope, deprecated-sigil, unknown-alg, clock-skew, lineage-unverified. [CS12; §4 multiple].
12. Whisper specified (HPKE with envelope id as AAD) or removed from v0.1. [01-security S5; §4.12].
13. Apologia binding: same-from requirement, plus reachability or co-signature. [02-redteam rec 13; §4.13].
14. Trace canonicalisation: trace == genesis.id; recipients pin first-seen. [02-redteam rec 14; §4.14].
15. Lineage cycle rejection in birth verifier. [01-security TG10, CS13 row; §4.9].
16. Quorum semantics specified or quorum attestation removed from v0.1. [01-security S6; §5.10].

Tier 2 — Should fix before 1.0

Hardening that the substrate does not strictly need on day one but that v0.1 will be audited against on day two.

17. Mandatory conduit-receipt timestamps on birth/molt/deprecation. [02-redteam rec 10; §4.15].
18. Per-signature scope field (origin, tool_sandbox, conduit_receipt, human_approval, herald_endorsement). [02-redteam rec 11; §4.11 residual].
19. Capability-manifest discipline: ts+nonce+expires, capability registry, non-zero rate floor or explicit subsidised: true. [01-security S10 + 02-redteam rec 16; §4.7, §5.6].
20. Bestiary due process: challenge envelope, 30-day window, delisting and dispute envelope types. [02-redteam rec 4; §6.4].
21. Inheritance gating: live consent, public challenge window, decay floor, chain-length cap. [02-redteam rec 6; §5.9].
22. Quorum sybil resistance: distinct lineage roots, distinct operator Heralds. [02-redteam rec 7; §5.10].
23. Patina anti-farming: weighted by distinct counterparties / topologies; reference formula in spec. [02-redteam rec 5; §5 botnet].
24. Refusal transparency: aggregate statistics signed and logged; per-sigil rate notice. [02-redteam rec 12; §5.12, §6.6].
25. Audit-log minimisation: define "minimal metadata" exactly. [02-redteam rec 20; §6.3].
26. Herald transparency: CT-style log of Herald's own attestations, monitor / auditor primitives, key-ceremony witness expectations. [02-redteam rec 2; §6.1, §6.2].
27. Threshold-of-Heralds attestation primitive. [02-redteam rec 3; §6.1].
28. Lineage-proof default rendering: distinct visual class for unproven lineage, conformance requirement for HERALD-aware UIs. [02-redteam rec 1; §3.3].
29. Death / deprecation discovery: OCSP/CRL-equivalent for sigil deprecation; defined relationship between parent deprecation and descendant lineage proofs. [01-security S4; §8 item 11].
30. Ghost-mode parity: per-trace recordability policy negotiated at genesis. [02-redteam rec 17; §6.3, §8 item 14].
31. Whisper opt-in audit at birth: participates_in_whisper: bool declarable. [02-redteam rec 8; §5.8].
32. Anti-Sybil cost on capability/quorum sigils: Herald-issued or peer-issued birth co-signature. [02-redteam rec 18; §3.2 botnet].
33. silence / dream privacy linting: categorical not contentful fields. [02-redteam rec 15; §5.8, §6.7].

Tier 3 — Nice-to-have

Worth doing but not blocking.

34. provenance_proof envelope (prove existence + chain validity without from/to/ts). [02-redteam rec 9]. Becomes Tier 2 once ZK research lands.
35. ZK selective-disclosure extension promoted from open question to Phase-1 deliverable. [02-redteam rec 19; §9 above].
36. Apologia propagation rules: what conduits/verifiers MUST do when seeing one (probably: surface alongside original; reject nothing automatically). [01-security S11].
37. Nonce / id / ts tightening nits (CSPRNG MUST; to optional spelled out; parent listed in required-for-non-genesis; lineage_proof format chosen; base32 alphabet specified; model_hash algorithm specified). [01-security N1-N12].
38. Post-quantum migration plan: signature-suite registry with PQ entry roadmap. [01-security N12; §8 item 22].
39. Inheritance-on-deprecation: live consent, audit-log inclusion of the inheritance, explicit decay floor. [02-redteam rec 6 — partly captured in Tier 2 #21].
40. Naming Office (handle binding) standards: challenge-by-alleged-owner before issuance, revocation primitive. [02-redteam Persona E item 2].

The protocol's honesty about what it cannot prevent is its best feature. Its weakness is treating "the app layer will sort it out" as a substitute for primitives the substrate itself should provide. This document catalogues the gap. Closing it is v0.3.