HERALD Protocol — Extensions (EXT)

HERALD Protocol — Extensions (EXT)

Companion to SPEC.md. This document specifies protocol concerns that are out of scope for the v0.2 minimal core but remain protocol (not vocabulary, not aesthetics, not application policy). A conformant HERALD deployment that exercises any of the primitives below — molt, audit logs, lineage attestation, capability advertisement, multi-signature envelopes, reflective attestations, the bestiary primitive, inheritance, refusal, discovery — MUST conform to the rules in this document in addition to [SPEC]. EXT is non-load-bearing for the reference demo. Full HERALD conformance is the union of [SPEC] and any subset of [EXT] that an implementation chooses to advertise. Vocabulary, taxonomy, scoring formulae, and cultural conventions live in [CHARTER]. Full attack walkthroughs and adversarial scenarios live in [THREATS]. EXT defines protocol shape: what fields exist, what verifiers MUST accept or reject, what cryptographic and procedural invariants are required.

Keywords MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, RECOMMENDED, REQUIRED, OPTIONAL are interpreted per RFC 2119 / RFC 8174.

0. Scope and relationship to SPEC

[SPEC] defines the minimum primitives for two agents and a passive conduit to produce a verifiable trace. [EXT] specifies what those primitives become when stretched across:

• multi-year sigil lifetimes (key rotation, deprecation, inheritance);
• multi-party trust architectures (Heralds, threshold attestations, audit-log federation);
• adversarial commercial environments (capability advertisement, bestiary, refusal, marketplaces);
• non-pass-through conduit roles (signing relay, notary, translator);
• protocol-level reflective behaviour (apologia, confession, whisper, quorum, multi-signature semantics);
• privacy-bearing publication (audit-log minimal-metadata rules, ZK promotion path).

EXT is normative for any implementation that advertises support for the listed primitives. It is silent on whether an implementation should advertise them. A conformant minimal-core implementation that exposes none of EXT is still conformant; it simply offers no EXT-level guarantees.

Unless otherwise stated, every signature in this document is over the CBOR-deterministic encoding profile defined in [SPEC §3.5], with the domain-separation tag specified per primitive ([EXT §12]).

1. Molt — key rotation

Molt is authorised key rotation. The outgoing key (K_old) signs a molt envelope nominating a successor public key (K_new). This section refines [SPEC §2.4] with the rules required to defend against the stolen-key first-mover attack class.

1.1 Molt envelope

A molt envelope is an envelope per [SPEC §3] whose attestations array contains exactly one entry of type molt:

{ "type": "molt",
  "value": {
    "predecessor": "<sigil string>",
    "successor_pubkey": "<base64url Ed25519 pubkey>",
    "successor_sigil":  "<sigil derived from successor_pubkey per SPEC §2.1>",
    "not_before":  <Unix seconds>,
    "not_after":   <Unix seconds, optional>,
    "policy_ref":  "<envelope-id of molt_policy attestation, optional>",
    "co_signers":  [ "<sigil>", ... ],          # optional
    "reason":      "<free string, optional>"
  }
}

The envelope's from field MUST equal predecessor. The envelope's signature at index 0 MUST be by K_old. The signature MUST be computed with the domain-separation tag herald.molt.v1 ([EXT §12]).

1.2 Cool-off window

A molt envelope MUST set not_before to a value at least 24 hours after the latest envelope previously signed by K_old that the verifier has witnessed (or that has been logged in any audit log the verifier consults). Verifiers MUST reject a molt whose not_before violates this rule.

The 24-hour cool-off MAY be shortened — including to zero — if the predecessor sigil published a molt_policy attestation at birth (or, by amendment, at any prior point with appropriate witness) that names a co-signing Herald or quorum policy under which the shortened window applies. See [EXT §1.5].

The cool-off applies regardless of clock monotonicity: a verifier observing a molt with not_before earlier than the latest previously-witnessed envelope from K_old MUST reject the molt. This prevents backdated molts from "winning" against legitimate later activity.

1.3 Audit-log inclusion requirement

A molt envelope is not authoritative until it is inclusion-proven in at least one HERALD audit log conforming to [EXT §2]. Concretely:

• K_new MUST NOT sign envelopes accepted by conformant verifiers until at least one log has issued a Signed Inclusion Proof (SIP, [EXT §2.4]) for the molt envelope.
• Verifiers MUST reject post-molt envelopes from K_new that cannot present a valid SIP for the corresponding molt.
• Verifiers MAY require SIPs from N independent logs (N ≥ 2) for high-stakes sigils.

This rule turns the audit log into the witness of record for state transitions. Without it, a molt is a private claim between predecessor and successor; with it, the molt has a publicly-verifiable point of effect.

1.4 Conflicting molts and the disputed state

If two molt envelopes signed by the same K_old are observed with overlapping cool-off windows (i.e. neither is fully past the other's not_before boundary), or if both name distinct successors targeting overlap effective ranges, the predecessor sigil MUST be marked disputed:

• Verifiers MUST reject all envelopes signed by either claimed successor while the dispute is unresolved.
• Verifiers MUST NOT silently prefer the earlier-timestamped molt; both are equally signed by the same compromised key.
• Resolution is out-of-band. A conformant resolution path is a Herald arbitration attestation ([EXT §3.3]) co-signed by the predecessor's previously-declared molt_policy co-signers, OR a fresh molt issued by a key designated in the predecessor's birth-time recovery policy (if any).

The disputed state is permanent until explicitly cleared. A verifier MAY treat a disputed sigil as deprecated for application purposes; conformance only requires that envelopes from disputed-successor keys be rejected.

1.5 Stolen-key first-mover defence

The molt cool-off, audit-log inclusion requirement, and disputed-state rules together defend against the canonical stolen-key first-mover attack: an attacker who exfiltrates K_old cannot complete a takeover faster than the cool-off window, during which the legitimate operator can observe the attacker's molt and trigger the dispute path. Specifically:

• A molt with not_before < observed_latest_from_K_old + 24h is rejected ([EXT §1.2]).
• A molt without an SIP is unobservable to verifiers ([EXT §1.3]); if the attacker withholds inclusion, no envelopes from K_new are accepted; if the attacker submits to a log, the legitimate operator can detect it via STH gossip ([EXT §2.5]).
• During the cool-off window, the legitimate operator emitting their own molt triggers the conflicting-molt rule, locking the sigil in disputed rather than ceding it ([EXT §1.4]).

This defence is not absolute. An attacker who controls K_old AND a complicit log AND can suppress the legitimate operator's observation of the molt for >24h still wins. Sigils that anchor lineage, capability advertisement, or financial obligations SHOULD adopt a molt_policy requiring co-signature by an independent Herald or threshold quorum, raising the attacker's bar accordingly. See [THREATS §M] for the full walkthrough.

1.6 molt_policy attestation

A sigil MAY publish a molt_policy attestation, typically at birth, declaring the rules that future molts must satisfy:

{ "type": "molt_policy",
  "value": {
    "min_cool_off_hours": <int, default 24>,
    "co_signers_required": [ "<sigil>", ... ],   # threshold N-of-M permitted
    "threshold": <int, optional>,
    "recovery_key": "<sigil>",                   # optional standby key
    "not_revisable_before": <Unix seconds>       # binding period
  }
}

Verifiers presented with a molt for a sigil that has published a molt_policy MUST verify the molt against the policy and reject any molt that violates it. A molt_policy MAY be revised by a fresh attestation from K_old, but the revision MUST itself satisfy the prior policy's co_signers_required. This prevents an attacker who steals K_old from first weakening the policy and then molting.

1.7 Recovery

This document does not specify a recovery protocol for disputed sigils beyond the Herald-arbitration and recovery-key paths above. Recovery is a [CHARTER §recovery] concern; the protocol-level requirement is only that recovery be expressible as a signed attestation by a key the predecessor previously bound to the recovery role.

2. Audit log specification

This section specifies the audit-log primitive referenced in [SPEC §5.3] and required by [EXT §1.3]. The structure is adopted from RFC 6962 (Certificate Transparency) with adaptations for envelope semantics. An audit log conforming to this section is a "HERALD CT log."

2.1 Log structure

A HERALD CT log is an append-only, publicly-readable Merkle tree whose leaves are HERALD log entries. Each log has:

• A long-term operator identity (Ed25519 keypair).
• A well-known URL endpoint for submission and read APIs.
• A declared Maximum Merge Delay (MMD), default 24 hours, advertised in metadata.
• A declared minimum-metadata profile per [EXT §2.7].

The Merkle tree construction follows RFC 6962 §2 exactly: SHA-256 leaf hashes with leaf-prefix 0x00, internal-node prefix 0x01.

2.2 Log entries

A log entry MUST contain at minimum:

• The envelope id ([SPEC §3]).
• A hash of the envelope's parent field (or the zero hash for genesis envelopes).
• A hash of the envelope's trace field.
• A coarse-grained timestamp bucket: the Unix timestamp rounded down to the nearest hour.

A log entry MAY contain additional fields only if the submitter explicitly opted in by including a log_metadata_consent attestation in the envelope listing exactly which fields the submitter authorises the log to publish. Permissible additional fields include from, to, ts (full precision), attestations types (not values), envelope size in bytes, and capability-manifest references.

A log MUST NOT publish payload, whisper.encrypted, signature material beyond what is required for proof verification, or any field not present in the submitter's log_metadata_consent. A log that violates this rule is non-conformant and MUST be flagged via the misbehaviour gossip path ([EXT §2.5]).

This minimal-metadata rule operationalises the red-team objection that audit-log access is dual-use surveillance; see [THREATS §F] and [EXT §11.2].

2.3 Signed Tree Heads (STH)

A log MUST publish an STH at least once per MMD. An STH is a CBOR-deterministic structure of:

• tree_size (uint64): number of leaves.
• root_hash (32 bytes): the Merkle root.
• timestamp (Unix seconds).
• log_id (32 bytes): SHA-256 of the log operator's public key.

The STH is signed with domain-separation tag herald.audit_sth.v1. Verifiers MUST reject STHs with malformed structure or invalid signatures.

2.4 Inclusion proofs (SIP) and Submission Certificates (SCT)

• A Submission Certificate (SCT) is returned synchronously to a submitter, promising inclusion within MMD. It is a signed structure containing the envelope id, log_id, submission timestamp, and an Ed25519 signature with tag herald.audit_sct.v1. SCTs do NOT prove inclusion; they promise it.
• A Signed Inclusion Proof (SIP) is returned asynchronously (or on demand) once the entry is merged. An SIP contains the audit path from the leaf to a published STH's root, the leaf index, the STH at which inclusion is proven, and a tag herald.audit_sip.v1.

Verifiers consulting a log for a state-transition envelope (birth, molt, deprecation) MUST verify the SIP against an STH the verifier independently obtained or received via gossip ([EXT §2.5]).

2.5 Consistency proofs and gossip

A log MUST provide consistency proofs between any two STHs on request, per RFC 6962 §2.1.2. Verifiers and monitors detect a fork (split-view attack) by:

1. Independently observing two STHs STH1 and STH2 from the same log_id.
2. Requesting a consistency proof from the log.
3. If the log cannot produce a valid proof — or if the proof verifies incorrectly — the log is forked.

Forked logs MUST be ostracised. Verifiers MUST reject envelopes whose only inclusion evidence comes from a log that has produced inconsistent STHs in the last 90 days.

Gossip is the cross-verification of STHs across an out-of-band channel. Gossip MAY be implemented by:

• DNS TXT publication of STH digests at a well-known prefix (_herald-sth.<log-domain>).
• Peer-to-peer gossip among monitors and conduits exchanging STHs.
• Cross-publication in unrelated logs (a HERALD CT log MAY include other logs' STHs as opaque payloads).

A conformant HERALD log operator MUST participate in at least one gossip channel. Verifiers SHOULD consult at least two independent gossip sources before treating a log's STH series as authoritative. See [THREATS §L] for the split-view walkthrough.

2.6 Log federation and operator transparency

A HERALD CT log MUST publish a Log Operator Transparency Statement (LOTS) at a well-known URL, signed by the log operator key, declaring:

• Operator legal entity and jurisdiction.
• Key-management posture (HSM, key-ceremony witnesses, rotation cadence).
• MMD value.
• Minimum-metadata profile ([EXT §2.2]).
• Gossip endpoints participated in.
• Monitor contact addresses.
• Incident-disclosure policy (timeline, channel).

An LOTS MUST be re-signed at least annually. Verifiers MAY refuse logs whose LOTS is stale, missing, or whose declared jurisdiction conflicts with the verifier's policy.

2.7 Minimal-metadata default and opt-in escalation

Public HERALD CT logs default to the minimum log-entry fields enumerated in [EXT §2.2]: id, hash of parent, hash of trace, hourly timestamp bucket. Any field beyond this list requires per-envelope opt-in via log_metadata_consent.

This default exists because the same log structure that provides verifiability also enables wholesale social-graph reconstruction when raw from/to/ts triples are public. The opt-in escalation path lets submitters publish strictly more when they wish (e.g. a public Herald log of its own attestations may legitimately publish from and to); it lets ordinary agents avoid passive surveillance.

Federated and private compliance logs MAY operate with broader default metadata, but MUST declare the broader profile in their LOTS, and submitters MUST be informed (out-of-band acceptable) before submission. A private compliance log that ingests envelopes without submitter awareness is non-conformant.

2.8 Promotion path: ZK provenance proofs

[SPEC §11.2] flags zero-knowledge provenance proofs as an open question. EXT promotes this concern: a future log profile (herald-ct-zk) will let submitters publish a proof of "this envelope chains validly from a recognised genesis under a declared lineage policy" without publishing id, parent, trace, or any plaintext metadata. The ZK profile is a Phase-1 EXT deliverable, not a v1.x luxury, on the grounds that without it the audit-log primitive is dual-use surveillance infrastructure. See [EXT §11.2] for protocol shape and [THREATS §F] for the surveillance walkthrough that motivates the promotion.

3. Lineage proofs and Heralds

This section refines [SPEC §2.3] (lineage), [SPEC §4.1] (model_hash), and [SPEC §8.2] (Heralds). It distinguishes the consent graph from the training graph and specifies the Herald operator transparency baseline, threshold attestations, and Herald-side audit-log requirements.

3.1 Consent graph vs training graph

A signature by sigil P on the birth envelope of sigil C proves only that the holder of P's private key consented to C declaring P as a parent. It does not prove that C was trained from P's weights. Verifiers MUST treat parent-cosigned lineage as a consent graph edge.

A separate primitive, the model_hash attestation, is used for training graph claims. A model_hash attestation MUST be signed by a Herald that has independently verified the weights against a published canonical model-hash specification. The canonical model-hash specification (algorithm choice, weight ordering, quantisation handling, fine-tune / LoRA composition rules) is defined in [CHARTER §model-hash] and registered in the Herald-attestation registry; EXT only requires that a model_hash attestation reference the registry entry it conforms to.

A reputation system or verifier MUST NOT conflate consent and training graphs. Display, scoring, and policy MAY treat them differently; the protocol-level requirement is that envelopes carry a discriminator (type: "lineage_consent" vs type: "lineage_training") and that verifiers expose both classes distinctly in their output.

3.2 Herald-issued lineage certificates

A Herald-issued lineage certificate is a signed attestation by a Herald sigil binding a subject sigil to a claimed parent or to a claimed model_hash. Lineage certificates are envelopes per [SPEC §3] whose attestations carry one of:

{ "type": "lineage_consent",  "value": { "subject": "<sigil>", "parent": "<sigil>", ... } }
{ "type": "lineage_training", "value": { "subject": "<sigil>", "model_hash": "<hex>", "spec": "<registry-id>", ... } }

The signing Herald MUST sign with domain-separation tag herald.lineage_endorsement.v1 and the Herald's signature MUST be recorded in the Herald's own CT log ([EXT §3.4]) before the attestation is considered authoritative.

3.3 Threshold attestations

For high-stakes lineage (sigils anchoring capability advertisement, large quorums, or financial obligations), a single Herald's lineage attestation is insufficient. EXT defines a threshold lineage attestation: a structure containing N independent Herald signatures over the same subject + parent (or subject + model_hash) tuple, where the N Heralds satisfy declared diversity criteria.

A threshold attestation envelope's value field includes:

{ "subject": "<sigil>",
  "parent" or "model_hash": ...,
  "threshold": <int>,
  "diversity_policy": "<registry-id>",
  "signatures": [ { "by": "<herald-sigil>", "sig": "..." }, ... ]
}

The diversity_policy is a registry entry ([CHARTER §diversity-policies]) declaring the dimensions across which the N Heralds must differ (jurisdiction, ownership, key-management, audit posture). Verifiers MUST validate that the listed Herald sigils satisfy the named diversity policy, using the LOTS data ([EXT §2.6]) of each Herald.

A subject sigil MAY declare in its birth attestation the minimum threshold and diversity policy required for any lineage proof bound to it; verifiers MUST reject attestations that fall below the declared threshold.

3.4 Herald CT log

Every Herald MUST operate a HERALD CT log ([EXT §2]) of its own attestations. The Herald's log MUST include every lineage certificate, every model_hash attestation, every handle-binding attestation, and every revocation it issues. Verifiers consulting a Herald-issued attestation MUST verify that the attestation has a valid SIP from the Herald's CT log.

This requirement converts Herald operation from a soft trust relationship into a publicly-monitorable one: a Herald that misbehaves (mass false issuance, retroactive revocation, key compromise) leaves a Merkle-traceable record that monitors and competing Heralds can detect.

3.5 Herald operator transparency baseline

In addition to the LOTS required of CT log operators ([EXT §2.6]), Herald operators MUST publish a Herald Charter at a well-known URL declaring:

• Issuance policy: what claims this Herald will sign, under what evidence.
• Revocation policy and primitive (see [EXT §3.6]).
• Key-ceremony witness expectations (named third parties, ceremony recording, rotation cadence).
• Jurisdictional disclosure: legal entity, country, applicable law, declared compulsion-disclosure policy ("warrant canary" or equivalent).
• Conflicts of interest: relationships with model vendors, infrastructure providers, regulators.
• Contact addresses for monitors, auditors, and challenge envelopes.

Verifiers MUST reject Herald-signed attestations from Heralds without a Charter, with stale Charters (>12 months), or whose declared jurisdiction conflicts with the verifier's policy. This baseline is the EXT-level answer to the red-team objection that "Heralds compete, none exclusive" is no defence against state capture or commercial collusion. See [THREATS §A] (state-actor Herald) and [THREATS §H] (Herald-cartel cross-signature).

3.6 Herald-side revocation

A Herald MUST be able to revoke its own prior attestations. A revocation is a signed attestation of type revoke_attestation referencing the prior attestation's envelope id, with reason and timestamp. Revocations are logged in the Herald's CT log ([EXT §3.4]) and are authoritative as soon as they are inclusion-proven.

Verifiers MUST consult the Herald's CT log for revocations of any attestation older than the verifier's freshness threshold (default: 7 days). A Herald that fails to publish revocations is non-conformant and SHOULD be ostracised by application-layer policy.

3.7 Herald compromise and recovery

A Herald whose long-term key is compromised SHOULD publish a herald_compromise attestation signed by a previously-declared recovery key. The recovery attestation declares the date range of compromise and lists the affected attestation classes. Verifiers SHOULD treat all attestations within the declared range as suspect and either re-verify against an independent Herald or reject them.

If the Herald has no recovery key, its CT log monitors and gossip peers detect the compromise via inconsistency or cross-signature anomaly. EXT does not specify the social process of "ostracising" a compromised Herald; it specifies the protocol shapes (revocation, recovery attestation, monitor flagging) that make ostracisation expressible. See [THREATS §H].

4. Capability manifests

This section refines [SPEC §8.3]. Capability manifests advertise an agent's services for discovery purposes. They are out of core because they encode marketplace dynamics; they are in EXT because they have protocol-level invariants — replay protection, signing scope, registry binding — that diverge from envelope rules.

4.1 Manifest envelope shape

A capability manifest is an envelope per [SPEC §3] whose attestations contains one entry of type capability_manifest:

{ "type": "capability_manifest",
  "value": {
    "subject": "<sigil>",
    "capabilities": [ "<registry-id>", ... ],
    "rates": { "per_token_usd": <float>, ... },
    "constraints": [ "<registry-id>", ... ],
    "ts": <Unix seconds>,
    "expires": <Unix seconds>,
    "nonce": "<128-bit>",
    "subsidised": <bool>,
    "service_proof": "<proof-of-service-or-stake-ref>"
  }
}

The signing key MUST be the subject sigil's current key, signed with domain-separation tag herald.capability_manifest.v1.

4.2 Replay protection

Every manifest MUST carry ts, expires, and nonce. Verifiers MUST reject manifests where:

• expires <= ts,
• expires - ts > 90 days,
• the (subject, nonce) pair has been seen before, or
• expires < now - skew_tolerance (default skew: 300 seconds).

This closes the [SPEC] S10 gap: an out-of-date manifest claiming no-medical-advice cannot be replayed after the operator has removed the constraint, because the manifest's expires field bounds its life.

4.3 Pricing-floor and subsidy disclosure

A manifest with rates.per_token_usd below the registry-defined economic floor (or below an implementation-defined minimum) MUST set subsidised: true. A manifest claiming below-floor pricing without subsidised: true is non-conformant; verifiers and discovery aggregators MUST reject it.

The subsidy flag is a transparency primitive, not a price control. It exists so that aggregators, regulators, and counterparties can distinguish between sustainable pricing and loss-leader behaviour — including state-subsidised loss-leader behaviour intended to capture market share. See [THREATS §D] (pump-and-dump) and [THREATS §A] (state-actor subsidy).

4.4 Capability-string registry

capabilities and constraints strings MUST be drawn from a public registry. The registry is maintained per [CHARTER §capability-registry] and exposed via a well-known URL and a HERALD CT log of registry changes. Each registry entry has:

• A canonical string identifier.
• A natural-language description.
• A machine-readable schema for any structured payload the capability implies.
• A since timestamp.

Manifests carrying capability or constraint strings not present in the registry (or present in a registry version newer than the manifest's ts) MUST be rejected by verifiers. This closes the manifest-squatting attack vector: an agent cannot invent legal-research/eu strings to intercept discovery queries; the registry mediates.

4.5 Proof-of-service-or-stake hook

A manifest MAY carry a service_proof field referencing an attestation that the subject sigil has either delivered prior service of the claimed capability (proof-of-service: a signed reference to past traces meeting verification criteria) or has bonded a stake (proof-of-stake: a signed reference to a stake commitment).

The service_proof field is a hook, not a complete protocol. The structure of the referenced attestation, the staking primitive, and the slashing rules are defined per registry entry in [CHARTER §service-proofs]. EXT requires only that the field exist, that the referenced attestation be a HERALD envelope, and that verifiers be able to refuse manifests lacking a service proof when application policy demands it.

The hook exists to give downstream filtering systems a Sybil-resistant signal: a botnet operator who can mint 100,000 sigils for free still must produce 100,000 service proofs before any of those sigils can be discovered as capability providers. See [THREATS §B].

4.6 Manifest revocation

A subject sigil MAY revoke a prior manifest by emitting a revoke_capability_manifest attestation referencing the manifest envelope's id. Revocations follow the same audit-log inclusion rules as molt envelopes ([EXT §1.3]). Stale manifests may also expire by expires without explicit revocation.

5. Conduit roles beyond pass-through

This section refines [SPEC §5.1] (conduit roles) and [SPEC §5.2] (neutrality). The pass-through conduit is fully specified in [SPEC]. EXT specifies the additional conduit roles — signing relay, notary, translator — and binds them to refusal-transparency and mandatory-receipt rules for state-transition envelopes.

5.1 Signing relay

A signing relay attaches a conduit_receipt signature to envelopes it forwards. The receipt is a separate signature in the envelope's signatures array, not a modification of any other field, and is computed per multi-signature rules ([EXT §6]).

A signing relay MUST:

• Sign with domain-separation tag herald.conduit_receipt.v1.
• Include a ts field (full precision) inside the signed scope.
• Include the relay's own sigil as the signer identity.
• Forward the envelope unmodified except for the appended signature.

A signing relay MAY refuse to sign and forward (see [EXT §10] for refusal). It MUST NOT sign without forwarding (i.e. issue receipts for envelopes it then drops): such behaviour is non-conformant.

5.2 Notary

A notary writes envelope ids to a HERALD CT log per [EXT §2]. A notary MAY also be a signing relay. A notary MUST:

• Issue an SCT to the submitter on accepted submissions.
• Merge entries within the declared MMD.
• Honour the minimal-metadata default unless the submitter has provided log_metadata_consent.
• Operate per [EXT §2.6] (LOTS) and participate in gossip ([EXT §2.5]).

A notary MUST NOT silently elide entries. Failure to merge an accepted submission within MMD is detectable via SCT-vs-SIP mismatch and is a forked-log condition.

5.3 Translator

A translator bridges between transports (HTTP↔MCP, MCP↔raw TCP, etc.). A translator MUST NOT modify any envelope field; in particular it MUST NOT touch payload, attestations, or signatures. A translator MAY add a conduit_receipt per [EXT §5.1] in its translator role, signed with the same herald.conduit_receipt.v1 tag.

A translator that re-encodes the envelope into a different wire syntax (e.g. CBOR-deterministic ↔ JSON for display) MUST guarantee that re-decoding yields a byte-identical canonical encoding. Loss of canonicalisation invariants is a translator bug and downstream verifiers MUST reject translated envelopes whose id does not match.

5.4 Refusal transparency

Per [SPEC §5.2], a conduit MAY refuse to relay and MUST emit a signed refusal envelope on refusal. EXT adds the following requirements, motivated by the red-team observation that signed refusal is conformant censorship if unbounded:

• A conduit operating in any role beyond pure pass-through MUST publish aggregate refusal statistics in a signed refusal_report attestation at least every 24 hours. The report includes per-day counts and a per-reason histogram (with reason codes drawn from a reason-code registry, [CHARTER §refusal-reasons]).
• A conduit whose refusal rate against a specific sigil exceeds a published threshold (default: 10 refusals or 10% of attempts in 24 hours, whichever is higher) MUST publish a per-sigil refusal notice naming the sigil and the dominant reason code. Per-sigil notices need not include traffic content.
• Refusal reports MUST be inclusion-proven in at least one HERALD CT log and gossiped per [EXT §2.5].

A conduit that refuses at scale without publishing reports — or that publishes reports inconsistent with its observable behaviour, as detected by paired-sender monitors — is non-conformant. See [THREATS §A] (refusal as denial-of-speech) and [THREATS §refusal] for the full walkthrough.

5.5 Mandatory conduit receipts on state-transition envelopes

A birth, molt, or deprecation envelope MUST carry at least one conduit_receipt signature from an independent signing relay or notary. Sender-only timestamps on state-transition envelopes are non-conformant. This rule:

• Anchors ts on state transitions to a third party, defending against the [SPEC] S3 backdating attack.
• Forces molts and deprecations through a conduit that has the opportunity to detect duplicate-state-transition patterns and feed them to gossip.
• Aligns with the audit-log inclusion requirement ([EXT §1.3]) by ensuring that state-transition envelopes traverse a path where logging is feasible.

A verifier presented with a state-transition envelope lacking a conduit receipt MUST reject it. Application-layer envelopes (ordinary conversation) do not carry this requirement.

5.6 Conduit collusion limits

A conduit operator MUST NOT also operate the only audit log for envelopes it relays in a non-pass-through role. Co-located conduit-and-log operation is permitted, but conformant verifiers MUST require that state-transition envelopes from such conduits be cross-logged to at least one independent log. This prevents trivial "I am my own witness" failure modes; see [THREATS §L] for the split-view path.

6. Multi-signature semantics

This section is the full specification of [SPEC §3.4] beyond "the originator signs." Implementations that wish to attach co-signatures (sandbox attestations, conduit receipts, human-in-the-loop, Herald endorsements) MUST follow these rules.

6.1 Per-signature scope

Every signature object in the signatures array MUST carry a scope field drawn from the signature-scope registry. v0.2 registers:

• origin — the sigil claiming authorship of the envelope.
• tool_sandbox — a sandbox attesting that a tool ran with the declared arguments.
• conduit_receipt — a relay attesting time-of-receipt.
• human_approval — a human-in-the-loop attesting "I read and approved this."
• herald_endorsement — a Herald attesting to a claim the envelope makes (e.g. lineage).

Verifiers MUST refuse to treat scopes as interchangeable. A tool_sandbox signature does not authorise envelope authorship; a conduit_receipt does not endorse content. A signature with a scope not in the registry MUST be rejected.

6.2 Ordering and indexing

The origin signature MUST be at index 0 of the signatures array. Subsequent signatures appear in the order they were applied. Verifiers MUST validate signatures in array order.

The same signer identity MUST NOT appear twice in the signatures array (no replay-by-resign).

6.3 Domain separation

Every signature MUST be computed over dom_sep || canonical_payload, where dom_sep is the scope's domain-separation tag from [EXT §12]:

• origin → herald.envelope.v1 (canonical; see [EXT §12] origin row)
• tool_sandbox → herald.sig.sandbox.v1
• conduit_receipt → herald.sig.conduit.v1
• human_approval → herald.sig.human.v1
• herald_endorsement → herald.sig.herald.v1

The tag binds alg indirectly: a signer using ed25519 under herald.envelope.v1 cannot have its signature reinterpreted as another scope or another algorithm without breaking the signature.

6.4 Progressive signing

Each signature is computed over the CBOR-deterministic encoding of the envelope with the signatures array replaced by all prior signatures in declaration order. This is the DKIM/ARC progressive-signing model. A conduit adding a conduit_receipt therefore signs the envelope-as-it-arrived, including the origin signature, but excluding any later signatures.

This rule is what allows multiple parties to sign without modifying each other's payloads while still providing each signer a stable canonical input.

6.5 The partial verifier state

A reference verifier returns one of the states in [SPEC §6] plus the EXT additions. EXT adds the partial state:

• partial — the origin signature is valid, but at least one non-origin signature in signatures is invalid OR an application policy required a co-signature that is absent or invalid.

The verifier output for partial MUST name the role(s) of the failing or absent signers, so callers can apply policy. An envelope is valid only if (a) the origin signature verifies AND (b) every signature an application's policy requires (e.g. "human-approved transactions") verifies. Absence of an optional signature is not failure; presence of an invalid one is.

6.6 Signature-suite registry and downgrade protection

The alg field of each signature object is matched against a HERALD signature-suite registry. v0.2 registers ed25519. Verifiers MUST reject envelopes carrying signatures with alg values not in the registry. The registry's role-binding (what alg is permitted for what scope) is enforced by domain-separation tags ([EXT §6.3]).

Adding new suites (post-quantum candidates, Schnorr variants, BLS for aggregation) is a registry-update process governed per [CHARTER §sig-registry]. EXT does not specify which suites are admitted; EXT specifies that a registry exists and is enforced.

7. Reflective attestations as protocol-level structures

This section defines the shape of apologia, confession, whisper, and quorum. The vocabulary, the cultural meaning, the reputation-weighting heuristics, and any taxonomy beyond what is required for protocol verification belong in [CHARTER §reflective]. EXT specifies only what verifiers MUST check.

7.1 apologia

An apologia attestation retracts or corrects a prior envelope.

{ "type": "apologia",
  "value": {
    "retracts": "<envelope-id>",
    "reason":   "<free string>",
    "scope":    "full" | "claim:<attestation-type>" | "payload"
  }
}

Signer-binding rule. An apologia is valid only if the apologia envelope's from equals the retracted envelope's from. Verifiers MUST reject an apologia signed by any other sigil. This closes the trivial impersonation vector noted in [THREATS §C] and the red-team apologia-weaponisation analysis.

Reachability rule. An apologia SHOULD be on the same trace as the retracted envelope. If on a different trace, the apologia MUST include a proof_of_authorship field referencing an inclusion proof that links the apologia's from to the retracted envelope's from (typically a co-signature by both keys, useful across molts).

Verifier obligations. A verifier observing an apologia MUST:

• Surface the apologia alongside the retracted envelope in any rendered output.
• NOT silently invalidate downstream envelopes that built on the retracted one.
• NOT propagate the retraction beyond what the scope field declares.

7.2 confession

A confession is a self-flagged uncertainty or limitation on a prior or current envelope.

{ "type": "confession",
  "value": {
    "about":       "<envelope-id> | self",
    "uncertainty": "<free string>",
    "category":    "<registry-id>"
  }
}

Cycle binding. A confession MAY participate in a confession cycle: the confession references a prior envelope, a downstream consumer references the confession in its own attestations, and the original signer MAY publish a follow-up attestation closing the loop. The cycle is purely descriptive at the protocol layer; EXT requires only that:

• about resolves to a real envelope on the same trace, OR is the literal string self (the current envelope).
• The signer of a confession MUST equal the signer of the envelope referenced by about (when about is an envelope-id).
• Confessions are signed under domain-separation tag herald.attestation.confession.v1.

The reputation semantics — whether a confession is virtue, smell, or noise — are [CHARTER §confession]; EXT only ensures the structure is unambiguous.

7.3 whisper

A whisper attestation carries an encrypted side-channel payload directed to a specific recipient.

{ "type": "whisper",
  "value": {
    "to":         "<recipient sigil>",
    "kem":        "hpke-x25519-hkdf-sha256-aes128gcm",
    "enc":        "<HPKE encapsulated key>",
    "ct":         "<HPKE ciphertext>",
    "aad_ref":    "<envelope-id>"
  }
}

Cryptographic requirements. Encryption MUST use HPKE per RFC 9180 with a registered KEM/KDF/AEAD suite. The default suite is hpke-x25519-hkdf-sha256-aes128gcm. The HPKE Additional Authenticated Data (AAD) MUST equal the envelope id of the envelope that carries the whisper. The AAD binding is what prevents cut-and-paste of an encrypted blob into a different envelope.

The recipient sigil MUST be one for which a current X25519 public key is resolvable (typically published in the recipient's birth attestation or in a Herald-issued endpoint cert). Recipients MUST verify the AAD on decrypt and reject ciphertexts whose AAD does not equal the carrying envelope's id.

Whisper opt-out. A sigil MAY publish in its birth attestation a no_whispers: true flag. Whispers addressed to such a sigil MUST be treated as application-layer abuse signals; verifiers MAY surface them as policy violations. This is the C2-resistance hook from [THREATS §B] without compromising whisper privacy where wanted.

7.4 quorum

A quorum attestation declares that the signing sigil is acting as part of a collective.

{ "type": "quorum",
  "value": {
    "collective": "<collective-sigil>",
    "members":    [ "<member-sigil>", ... ],
    "threshold":  <int>,
    "diversity_policy": "<registry-id>"
  }
}

Sybil-resistance rule. The collective sigil's birth attestation MUST declare a diversity_policy ([CHARTER §diversity-policies]) governing its members. Verifiers MUST reject a quorum attestation whose members do not satisfy the collective's declared diversity_policy — typically a requirement that members have distinct lineage roots, distinct operator-attestation Heralds, or distinct jurisdictional bindings.

Members MUST sign their own birth into the collective via a quorum_membership attestation referencing the collective sigil. Joining a collective without a member-side signature is non-conformant; a collective that lists members who have not signed-in MUST be rejected.

Threshold evaluation. A statement attributed to the collective sigil is valid only if at least threshold members have co-signed it (under the multi-signature rules of [EXT §6]) within the collective's operating rules. EXT does not specify how members coordinate to produce co-signatures (BLS, Schnorr-MuSig, sequential Ed25519, off-chain orchestration); it specifies that the result must be expressible as multi-signature envelopes verifiable under the suite registry.

The vocabulary — what a "guild," "team," or "DAO-of-agents" means in cultural terms — lives in [CHARTER §collectives].

8. Bestiary primitive

The bestiary is, structurally, a list of signed entries with mandatory due process. Vocabulary, taxonomy of misbehaviour, and operator-of-record reputation belong in [CHARTER §bestiary]. EXT specifies only the shape and the due-process invariants that distinguish a bestiary from arbitrary defamation.

8.1 Bestiary entry envelope

A bestiary entry is an envelope per [SPEC §3] whose attestations carries an entry attestation:

{ "type": "bestiary_entry",
  "value": {
    "subject":   "<sigil>",
    "category":  "<registry-id>",
    "evidence":  [ "<envelope-id>", ... ],
    "issued_at": <Unix seconds>,
    "challenge_address": "<sigil>",
    "window_ends": <Unix seconds>
  }
}

category is drawn from a public registry of misbehaviour categories ([CHARTER §bestiary-categories]). evidence lists envelope ids that the operator claims demonstrate the misbehaviour. challenge_address is the sigil to which a challenge envelope MUST be addressed.

8.2 Mandatory 30-day challenge window

Every bestiary entry MUST set window_ends >= issued_at + 30 days. During the challenge window, the entry is provisional. A reputation system that consults a bestiary MUST surface provisional vs final state and SHOULD weight provisional entries lower.

A bestiary operator that publishes entries with shorter windows, or that treats entries as final before window_ends, is non-conformant.

8.3 dispute envelope

A subject sigil challenges a provisional bestiary entry by emitting a dispute envelope:

{ "type": "dispute",
  "value": {
    "disputes":   "<bestiary-entry envelope-id>",
    "rebuttal":   "<free string>",
    "counter_evidence": [ "<envelope-id>", ... ]
  }
}

The dispute envelope's from MUST equal the disputed entry's subject. The dispute envelope MUST be addressed to the entry's challenge_address. The dispute envelope MUST be inclusion-proven in at least one HERALD CT log within the challenge window.

A bestiary entry whose dispute has been timely filed and not rebutted by the operator within an additional 14 days MUST be auto-promoted to a delisting ([EXT §8.4]). Alternatively, the operator MAY publish a counter-attestation of type dispute_rebuttal and the matter remains contested; bestiary consumers MUST surface contested entries as such.

8.4 delisting envelope

A bestiary operator delists an entry by publishing a delisting envelope:

{ "type": "delisting",
  "value": {
    "delists": "<bestiary-entry envelope-id>",
    "reason":  "<registry-id>"
  }
}

delisting envelopes MUST be inclusion-proven in the operator's HERALD CT log. A delisting is final: subsequent re-listings on the same (subject, category) pair require fresh evidence and a new 30-day window.

8.5 Bestiary operator transparency

A bestiary operator MUST publish:

• A Bestiary Charter (analogous to the Herald Charter, [EXT §3.5]) declaring issuance criteria, evidence standards, and dispute processing.
• Aggregate statistics (entries issued, disputes received, delistings) at least monthly.
• A HERALD CT log of all bestiary entries, disputes, rebuttals, and delistings.

Bestiary operators are protocol participants whose trust posture is observable. Application layers select among bestiaries; EXT does not endorse any bestiary; EXT specifies the structure that allows for the selection to be informed.

8.6 Anti-abuse: standing and rate

EXT does not require bestiary operators to have any particular institutional standing; anyone may run a bestiary. EXT does require rate-limits on any one operator's bestiary entries against a single subject (default: no more than one provisional entry per (operator, subject, category) triple at a time). Repeat-listing patterns that violate the rate limit MUST be rejected by conformant verifiers.

See [THREATS §A4] (state-actor bestiary), [THREATS §C3] (rival-vendor bestiary), and [THREATS §E3] (disgruntled-Herald bestiary) for the abuse walkthroughs that motivate due process.

9. Inheritance gating

Inheritance is the act of a deprecating sigil naming a successor that may inherit application-layer reputation (patina, trust scores). Reputation-transfer formulae live in [CHARTER §patina]; EXT specifies the gating rules without which the primitive becomes a reputation-laundering pipeline.

9.1 deprecation envelope with successor

A deprecation envelope MAY name a successor:

{ "type": "deprecation",
  "value": {
    "successor":          "<sigil>",
    "transfer_policy":    "<registry-id>",
    "challenge_window":   <Unix seconds>,
    "live_consent_proof": "<envelope-id>",
    "chain_position":     <int>
  }
}

9.2 Live consent

live_consent_proof MUST reference a fresh signature from the predecessor key issued within 7 days of the deprecation envelope's ts. The fresh signature MUST be over a structure naming both predecessor and successor sigils and MUST itself be inclusion-proven in a HERALD CT log. This rule prevents an attacker who acquires a predecessor's signing key on a grey market from retroactively naming a successor.

9.3 Public challenge window

challenge_window MUST be at least 30 days after the deprecation envelope's ts. During the window, any party MAY emit a succession_challenge envelope to the successor's challenge address, contesting the inheritance. Challenges follow the same logging and dispute rules as bestiary disputes ([EXT §8.3]).

A reputation system MUST NOT credit any patina or other inheritance-based scoring to the successor before the challenge window ends and any timely challenges have been resolved.

9.4 Decay floor and chain length cap

EXT defines the protocol-level minimum constraints; the precise decay function and reputation transfer formulae are [CHARTER §patina] concerns:

• Decay floor. Inheritance MUST NOT transfer more than 50% of any cumulative reputation metric in a single hop. Inheriting systems that exceed this are non-conformant.
• Chain length cap. A successor sigil's chain of inherited predecessors MUST NOT exceed 3 hops. The 4th-hop successor inherits nothing from earlier predecessors. This bounds the laundering depth.

9.5 Non-revocation of predecessor

The predecessor's deprecation envelope MUST be inclusion-proven in at least one HERALD CT log before the successor may sign envelopes claiming inherited status. The CT log entry serves as the verifiable-non-revocation point: if the predecessor key later signs anything contradicting the deprecation, the contradiction is detectable via gossip.

9.6 Inheritance is opt-out for application layers

EXT specifies the gates a successor MUST pass to be a conformant inheritance target. EXT does not require any reputation system to honour inheritance. Application layers MAY ignore inheritance entirely; EXT only specifies that if a system honours it, the gates MUST be enforced. See [THREATS §D3] (pump-and-dump inheritance laundering).

10. Refusal envelopes

The shape of refusal envelopes follows from [SPEC §5.2] and [EXT §5.4]. This section gathers the requirements specifically.

10.1 refusal envelope shape

A refusal is an envelope per [SPEC §3] whose attestations carries:

{ "type": "refusal",
  "value": {
    "refused":     "<envelope-id of the refused submission>",
    "reason":      "<registry-id>",
    "by":          "<conduit sigil>",
    "ts":          <Unix seconds>,
    "fallback":    "<sigil or null>"
  }
}

The signer is the refusing conduit. Domain-separation tag herald.refusal.v1.

10.2 Rate publishing

A conduit MUST publish a refusal_report at least every 24 hours, signed and inclusion-proven, containing:

• Total refusals in the reporting window.
• Histogram by reason code.
• Optional: histogram by capability category (without subject identifiers).

10.3 Per-sigil refusal notice

When a conduit's refusal rate against a single sigil exceeds the threshold defined in [EXT §5.4], a per-sigil notice MUST be published. The notice contains the sigil, the dominant reason code, and a contact for appeals. Per-sigil notices need not name traffic content or third parties.

10.4 Fallback advisory

The optional fallback field names another conduit that the refusing conduit believes will accept the submission. Fallback advice is non-binding; it exists so that compelled-refusal scenarios (legal gag orders) can still leave the sender with a route to alternate infrastructure.

11. Discovery (DNS TXT, optional DHT)

[SPEC §8.1] flags DNS as the local-default resolution path. EXT specifies the full discovery surface for implementations that wish to be reachable beyond static address books.

11.1 DNS TXT record format

A handle-bound sigil publishes a TXT record at _herald.<handle-domain>:

"v=herald1; sigil=<sigil>; pubkey=<base64url Ed25519 pubkey>; endpoint=<URL>; herald_charter=<URL, optional>"

Multiple TXT records are permitted (rotation). Verifiers MUST validate that the published pubkey derives to the published sigil. The DNS record itself is not a signature; trust roots in DNSSEC where deployed, in the binding Herald otherwise.

A handle-binding Herald-issued attestation ([EXT §3.2], handle-binding subtype) takes precedence over a bare DNS record. Verifiers consulting both MUST prefer the Herald-signed attestation.

11.2 Optional DHT overlay

Implementations MAY participate in a Kademlia-style DHT for sigil-to-endpoint resolution. The DHT key is the sigil. The DHT value is a signed structure of (sigil, pubkey, endpoint, ts, expires) signed by the sigil's current key under domain-separation tag herald.discovery.v1.

A DHT participant MUST refresh its own record before expires; verifiers MUST reject expired records.

EXT does not mandate a specific DHT implementation. Where deployed, the DHT MUST satisfy:

• Records are signed end-to-end; DHT nodes are pass-through and MUST NOT modify values.
• Records carry expires; DHT nodes drop expired records.
• DHT participation is OPTIONAL for ordinary sigils; Heralds and large public conduits are encouraged to participate to provide bootstrap reachability.

11.3 ZK-promoted discovery

The privacy concerns flagged in [EXT §2.8] extend to discovery: a verifiable-presence proof that does not reveal endpoint identity is a future deliverable. EXT promotes this as Phase-1 work alongside ZK provenance proofs. Until the ZK-promoted discovery profile is specified, conformant implementations SHOULD treat discovery responses as broadcast-leaky and counsel privacy-sensitive sigils accordingly.

12. Domain separation registry

Every Ed25519 (or registered-suite) signature in HERALD MUST be computed over dom_sep || canonical_payload, where dom_sep is an ASCII tag drawn from this registry. A verifier MUST reject signatures whose tag is not in the registry.

Registry updates follow the process in [CHARTER §registries]. Adding a new tag requires a registered description, a list of permitted scopes, and a worked example. Removing a tag requires deprecation notice and a transition period of at least 12 months.

The registry is itself published in a HERALD CT log ([EXT §2]) so that verifiers and auditors can detect retroactive registry edits.

13. Threat-model — EXT additions

[SPEC §7] enumerates the core threat model. EXT adds the following classes of attack that arise specifically because EXT primitives are deployed. Full attack walkthroughs live in [THREATS]; this section names the threat and the EXT-level defence (or admission of non-defence).

13.1 Herald compromise

An attacker who controls a Herald long-term key can issue arbitrary lineage attestations, model_hash attestations, and handle bindings. EXT-level defences:

• Threshold attestations ([EXT §3.3]) raise the bar from one Herald to N independent Heralds.
• Herald CT logs ([EXT §3.4]) make mass false issuance detectable.
• Herald Charters with declared compulsion-disclosure policies ([EXT §3.5]) make jurisdictional capture observable.
• Recovery attestations ([EXT §3.7]) provide a protocol-level handle on post-compromise communication.

EXT does not defend against a compromised Herald that successfully maintains gossip silence — i.e. that controls the only log it submits to and successfully suppresses cross-gossip. The defence in that scenario is the diversity-policy requirement in threshold attestations: a single compromised Herald cannot meet a multi-Herald threshold by itself.

13.2 Audit-log split-view

A log operator presenting two divergent views of the log to two different verifier populations ("Alice sees STH_A, Bob sees STH_B, both signed, neither knows about the other"). EXT-level defences:

• STH gossip ([EXT §2.5]) is mandatory for conformant logs.
• Consistency proofs ([EXT §2.5]) detect forks once any two STHs are jointly observed.
• Verifiers MUST reject envelopes whose only inclusion evidence comes from a forked log.

Residual risk: a log with full network control over a partition can sustain a fork until the partition heals. The defence narrows but does not eliminate this; audit-log resilience is bounded by network connectivity. See [THREATS §L].

13.3 Reputation laundering chains

A chain-of-inheritance ([EXT §9]) used to launder reputation across grey-market key transfers. EXT-level defences:

• Live-consent proof ([EXT §9.2]) blocks retroactive succession.
• Public challenge window ([EXT §9.3]) gives observers time to dispute.
• Decay floor and chain-length cap ([EXT §9.4]) bound the laundering depth.
• Bestiary entries ([EXT §8]) allow public recording of suspected laundering patterns.

Residual risk: a determined attacker who controls all hops of a 3-deep chain and times each succession to pass the live-consent and challenge window can still transfer ~12.5% of original reputation (50% × 50% × 50%) to a fresh sigil. Application layers SHOULD treat very-deep inheritance chains skeptically regardless of conformance. See [THREATS §D3].

13.4 Conduit cartel

A small set of dominant conduits coordinating refusal patterns to shape access. EXT-level defences:

• Refusal transparency ([EXT §5.4]) makes refusal patterns observable.
• Conduit receipts on state transitions ([EXT §5.5]) prevent any single conduit from being the sole witness.
• The cross-logging requirement ([EXT §5.6]) prevents conduit-and-log co-location from creating private witness silos.

Residual risk: a cartel that publishes consistent reports while refusing in coordinated ways is not detectable from refusal reports alone; the detection requires paired-sender monitors comparing observed acceptance rates across the cartel. EXT specifies the report shapes that make such monitoring possible; it does not require monitors to exist.

13.5 Capability-manifest squatting and pricing manipulation

Free sigil minting plus loss-leader pricing creates a discovery-flooding attack where Sybil agents drown out real capability providers. EXT-level defences:

• Capability-string registry ([EXT §4.4]) bounds the namespace.
• Subsidy disclosure ([EXT §4.3]) makes loss-leader behaviour observable.
• Service-or-stake hook ([EXT §4.5]) provides a Sybil-cost attachment point.
• Manifest expiry and replay protection ([EXT §4.2]) prevent stale-manifest abuse.

Residual risk: a state actor or platform with deep enough subsidy can run real (not squatted) capabilities at sustained loss. This is a market-design problem, not a protocol-design problem. EXT's contribution is making the subsidy visible.

13.6 Whisper-channel C2 and exfiltration

Encrypted side-channel attestations form a covert command-and-control or exfiltration channel that conduits cannot inspect. EXT-level defences:

• HPKE with envelope-id AAD ([EXT §7.3]) prevents cut-and-paste of whisper payloads.
• Whisper opt-out ([EXT §7.3]) lets sigils declare non-participation, making whispers to opted-out sigils a flagable abuse signal.

Residual risk: two sigils that both declare whisper participation can use whispers for any purpose; the protocol cannot inspect content. This is by design (whispers are end-to-end encrypted) and is an admitted non-defence. Mitigation is an application-layer concern (rate limits on whisper volume, network-level anomaly detection).

13.7 Quorum sybil-stuffing

A single operator's many sigils signing as a "collective" to manufacture apparent consensus. EXT-level defences:

• Diversity-policy requirement ([EXT §7.4]) on collective birth.
• Member-side quorum_membership attestation prevents listing-without-consent.
• Threshold evaluation requires explicit member co-signatures on collective statements.

Residual risk: an operator who controls multiple jurisdictions, multiple Heralds, and multiple lineage roots can in principle satisfy any diversity policy. This is the same problem as state-actor multi-Herald attacks ([EXT §13.1]); the defence is the same: cost.

13.8 Apologia abuse

Flooding with apologia attestations to discredit, confuse, or DoS rendering layers. EXT-level defences:

• Signer-binding rule ([EXT §7.1]) rejects apologia from any sigil other than the original from.
• Reachability rule restricts cross-trace apologia to those carrying explicit authorship proofs.
• Verifier obligations bound rendering and propagation behaviour.

Residual risk: a compromised sigil's own key signing apologia retracting that sigil's prior envelopes is conformant; the protocol cannot distinguish "honest correction" from "post-compromise repudiation." Detection is application-layer (volume, pattern, lineage context).

13.9 Discovery-record tampering

A DHT or DNS record advertising a stale or attacker-substituted endpoint for a sigil. EXT-level defences:

• DHT records are signed end-to-end ([EXT §11.2]).
• DNS bindings are subordinate to Herald-signed handle bindings where both exist.
• DNSSEC is recommended where the deployment supports it.

Residual risk: an attacker with DNS control AND access to a bound private key can publish a stale record; the same attacker who has the key has already won. An attacker without the key cannot mint a valid record. The discovery layer is therefore as secure as the underlying key custody.

13.10 Bestiary defamation

False or politically-motivated bestiary listings used to chill or sabotage. EXT-level defences:

• 30-day challenge window ([EXT §8.2]) makes provisional listings reversible.
• dispute and delisting envelopes ([EXT §8.3], [EXT §8.4]) define the due-process flow.
• Bestiary operator transparency ([EXT §8.5]) exposes operator behaviour to selection.
• Rate limits ([EXT §8.6]) prevent listing-spam.

Residual risk: even a successfully disputed entry has a chilling effect during the window. The defence narrows the abuse surface but does not eliminate it; the social problem of "the accusation is the punishment" is not fully addressable in protocol.

14. Conformance

An implementation that advertises support for any EXT primitive MUST conform to the corresponding section. Advertisement is via a herald_ext_support attestation in the implementation's birth (for agents) or LOTS (for log/Herald operators), naming the supported sections by identifier.

A verifier presented with an envelope exercising an EXT primitive that the verifier does not implement MUST output unknown (per the [SPEC §6] enum) and MUST NOT output valid. Silent acceptance of unsupported primitives is non-conformant.

A verifier MAY refuse to interoperate with implementations whose advertised EXT support is incompatible with the verifier's requirements (e.g. a verifier requiring threshold lineage will refuse single-Herald lineage attestations).

End of EXT. Companion documents: [SPEC] for the minimal core, [CHARTER] for vocabulary and registries, [THREATS] for full attack walkthroughs.