# RFC-VERITAS-CASCADE-v0.1 — Cascading Falsification & Source-Authenticated Retraction Protocol

**Status:** Working draft v0.1 · *Workstream:* W10 (super-review-2026-04-25 V2-W2F §A3) · *Editor:* Collaborative Fact-Checking Working Group · *Date:* April 2026

> *This document specifies the cascade-event types, source-authentication requirements, velocity-throttling rules, and forensic-reversal SLA for the Veritas Protocol. Cascade events are how a primary-source retraction propagates through the dependency graph of attestations and downstream documents that referenced the retracted claim. Without source-authentication, a transient `did:web` compromise (DNS hijack + ACME cert) on a high-authority source like Nature, Science, or a national court system would let an attacker sign an authentic-looking `RETRACTED` event and inflict reputational and economic damage before reversal can be coordinated. This document closes that attack vector.*

---

## Status of this document

This is a working-paper draft circulated for review. It is **not** an Internet-Engineering-Task-Force RFC. The format follows IETF conventions (RFC 2119 keywords, ABNF grammar, JSON-LD context registration) so the draft can be submitted upstream — most likely through **IETF SCITT** as the underlying transparency-log layer or as a companion document to **W3C Verifiable Credentials** revocation profiles — without restructuring.

Comments and proposed amendments are welcome. See § 13.

## Abstract

Cascading falsification is the property by which a retraction event published by an authoritative source-of-record automatically propagates through the dependency graph of attestations that referenced the retracted claim, and through the chain of downstream documents that depended on those attestations. The Veritas Protocol implements cascading falsification as a first-class event class on the chain layer; this document specifies the event types, the cryptographic authentication required for high-impact events, the velocity-throttling rules that prevent flash-crash-style attacks, and the forensic-reversal protocol that recovers from a forged retraction within a published Service Level Agreement.

This RFC normatively binds the **L2 Cascade Event Log** registry described in `spec/ARCHITECTURE.md` § 1.3.2.

## 1 · Introduction

### 1.1 Motivation

The Veritas Protocol's economic and epistemic value depends on a property the working paper calls **cascading falsification**: when Nature retracts a paper, every downstream attestation that *referenced* that paper as evidence must be flagged as standing on retracted ground; every claim attested *because* of the retracted paper must be re-evaluated; every news article that cited a downstream claim should surface the chain of retraction to the reader. The protocol cannot deliver this guarantee if the cascade-event channel is exploitable.

Specifically: the prior threat-model audit (super-review-2026-04-25-V2 § A3) identified the **source-retraction-forgery attack** as `CRITICAL · BYPASSABLE` in v0.2. A 24-hour `did:web` compromise on a high-authority source — typically achieved through DNS hijack plus an opportunistically-issued ACME certificate — would let the attacker sign an authentic-looking `RETRACTED` event for a target claim. By the time the legitimate source-authority detects the forgery and issues a reversal, the cascade has already fanned out through the dependency graph. Reputational and economic damage is irreversible without an explicit reversal protocol.

### 1.2 Scope

This document specifies:

- the enumerated **cascade-event types** (§ 3),
- the **source-authentication requirements** for high-impact events (§ 4),
- the **velocity-throttling rules** that delay fan-out for high-authority sources (§ 5),
- the **forensic-reversal Service Level Agreement** for forged retractions (§ 6),
- the **multi-source corroboration requirement** for retractions above a financial-impact threshold (§ 7),
- the **DID-method hardening guidance** for sources of record (§ 8),
- the **on-chain encoding** of cascade events in the L2 Cascade Event Log (§ 9),
- the **transparency-log integration** with IETF SCITT (§ 10).

Out of scope (other RFCs):

- Validator-credential issuance — `RFC-VERITAS-VC` (forthcoming).
- Verdict composition under a CPML — `RFC-CPML-v0.1`.
- Self-claims publication format — `RFC-FACTCHECK-v0.2`.
- Federation-aggregator resync after a cascade event — `RFC-VERITAS-FEDERATION` (forthcoming, W11).

### 1.3 Terminology

The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **MAY**, and **OPTIONAL** are interpreted as in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in all capitals.

- **Source of record** — an external entity that produces primary claims (a journal, a court, a government statistics office). Identified by a DID.
- **Attestation** — a signed verdict-statement issued by a Validator about a primary claim. Recorded on the L2 Attestation Registry.
- **Claim hash** — the canonicalised hash of a primary-claim record, computed per `RFC-FACTCHECK-v0.2` § 4.1.
- **Cascade event** — a typed, signed message on the L2 Cascade Event Log that announces a state change (retraction, correction, supersession, authority transfer) regarding a primary claim, propagating to all downstream attestations.
- **Dependency graph** — the directed graph in which an edge from claim A to claim B exists if any attestation about B cited A as evidence. The graph is computed offline by federation aggregators from the Attestation Registry.
- **Fan-out** — the act of marking all attestations downstream of a cascade event as having retracted ground.
- **Velocity throttle** — a rate-limit on cascade-event fan-out, expressed in chain blocks of confirmation lag.

## 1.5 Trust assumptions (bifurcation note)

The Veritas Protocol's primary attestation pool (L1 Validators in `spec/ARCHITECTURE.md` § 1.2) is **permissionless** by design: any cryptographic identity can post a signed attestation, and credentialing is post-hoc at the consumer / CPML layer. This RFC introduces a **bifurcated trust model** for the cascade-reversal pool: the chapter-convenor co-signature requirement (§ 4.2) and the source-authority-floor registry (§ 7.2.2) are *permissioned roles* operated by the foundation.

This bifurcation is intentional and is explicitly acknowledged here so that integrators and external auditors do not infer a contradiction with the v0.2 working paper's permissionlessness commitment. The asymmetry is:

- **Primary attestations**: permissionless write at L2; the reader's CPML decides which validators count.
- **Cascade events at low/medium tier**: permissionless source signature alone; reversal protocol applies post-hoc.
- **Cascade events at high/critical tier**: chapter-convenor co-signature required; chapter-convenor roster is foundation-managed under public governance.
- **Cascade reversal**: chapter-convenor multi-sig required (the protocol's most consequential operations are also its most-permissioned).

The v0.3 working paper amends § 5.5 (Cascade) and § 4 (Design Principles) to name this bifurcation explicitly. This section mirrors the amendment for readers who arrive at the cascade RFC first.

## 2 · Architecture context

The cascade layer sits between L0 (sources of record) and L2 (chain layer) in the Veritas Protocol stack defined in `spec/ARCHITECTURE.md`. Sources publish cascade events; the chain layer records them in the L2 Cascade Event Log; federation aggregators read events and recompute downstream-attestation status; consumers see updated verdicts at next query time.

```
┌──────────────────────────────────────────────────────────────┐
│  L0 SOURCES OF RECORD                                        │
│      DID-signed primary claims + cascade events              │
└──────────────────────────────┬───────────────────────────────┘
                               │ (signed cascade event)
┌──────────────────────────────▼───────────────────────────────┐
│  CASCADE PROTOCOL — RFC-VERITAS-CASCADE-v0.1 (this doc)      │
│      § 4 source-auth + § 5 velocity-throttle gate            │
└──────────────────────────────┬───────────────────────────────┘
                               │ (validated cascade event)
┌──────────────────────────────▼───────────────────────────────┐
│  L2 CASCADE EVENT LOG (Ethereum L2 / Base)                   │
└──────────────────────────────┬───────────────────────────────┘
                               │ (subscribe)
┌──────────────────────────────▼───────────────────────────────┐
│  L3 FEDERATION — recomputes downstream-attestation status    │
└──────────────────────────────────────────────────────────────┘
```

A cascade event is **NOT VALID** until it has cleared both the source-authentication gate (§ 4) and the velocity-throttle gate (§ 5). Aggregators MUST NOT propagate to consumers any cascade event that has not cleared both gates.

## 3 · Cascade-event types

A cascade event is a JSON-LD document with a `@type` from the following enumeration:

| Type | Meaning |
|---|---|
| `cascade:RETRACTED_BY_SOURCE` | The source-of-record authority explicitly retracts the primary claim. Cascades through the dependency graph: all downstream attestations are flagged as having retracted ground. |
| `cascade:RETRACTED_BY_ATTESTATION` | A third-party validator disputes the source's claim. Records the dispute as a downstream attestation. **Does NOT cascade** — third-party disputes are themselves attestations, not authority statements about the original claim. |
| `cascade:CORRECTED_BY_SOURCE` | The source-of-record issues a correction (e.g., an erratum). Cascades a "correction notice" through the dependency graph but does NOT invalidate downstream attestations. Aggregators surface the correction to consumers. |
| `cascade:SUPERSEDED_BY_REVISION` | A new version of the primary claim is published (e.g., a textbook second edition). The old version remains on record but is annotated as superseded. |
| `cascade:AUTHORITY_TRANSFERRED` | Editorial authority over the primary-claim record-keeping is transferred from one DID to another (e.g., journal acquired by a new publisher; court succession). Affects future cascade events about the same primary claim. |

The `cascade:RETRACTED_BY_SOURCE` event is the only event class that triggers automatic cascading. The other event classes are recorded in the log for transparency but do NOT trigger automatic downstream invalidation.

This explicit separation is the key defense against the source-retraction-forgery attack. A third-party dispute (`RETRACTED_BY_ATTESTATION`) is recorded as data; it is NOT mistakenly executed as authority. Implementations MUST NOT promote a `RETRACTED_BY_ATTESTATION` to a `RETRACTED_BY_SOURCE` even when the attesting party is itself a high-reputation validator. Authority is bound to the source-of-record DID, not to validator reputation.

## 4 · Source-authentication requirements

### 4.1 Single-source signature (insufficient for high impact)

Every cascade event MUST be signed by the source-of-record's DID using a JSON Web Signature (RFC 7515). A single-source signature is sufficient for cascade events whose financial-impact and reputational-impact lie below the threshold defined in § 7.

For high-impact events, single-source signature alone is INSUFFICIENT. A 24-hour DID compromise (DNS hijack + ACME cert) would produce a signature indistinguishable from the legitimate source's signature within the cryptographic protocol. The defense is structural, not cryptographic: the protocol REQUIRES additional co-signatures from independent authorities for high-impact events.

### 4.2 Co-signature requirement

A cascade event whose financial-impact or reputational-impact crosses the threshold defined in § 7 MUST also be co-signed by N-of-M **chapter convenors**. The default values are N=3, M=11 (three of eleven chapter convenors must co-sign). Specific threshold values and chapter rosters are governed by the Veritas Foundation governance charter and are NOT normative in this RFC.

Co-signatures MUST be from chapter convenors representing at least three distinct legal jurisdictions and at least three distinct institutional types (e.g., academic, civil-society, governmental). This jurisdictional and institutional diversity defends against coordinated state-actor pressure that would compromise multiple convenors in the same jurisdiction.

Each co-signature MUST include:
- the chapter convenor's DID
- the JWS over the canonicalised cascade-event document (per `RFC-FACTCHECK-v0.2` § 4.1 canonicalisation)
- the convenor's verifiable credential (per `RFC-VERITAS-VC` forthcoming) that authorises co-signature on this event class

### 4.3 Transparency-log inclusion proof

Every cascade event MUST include a transparency-log inclusion proof. The transparency log is operated under IETF SCITT conventions (see § 10). The proof allows independent auditors to verify that the event was published at a specific point in time and was not retroactively inserted.

Cascade-event consumers (federation aggregators) MUST verify the inclusion proof before accepting the event. Aggregators that accept events without inclusion proofs are non-conformant.

### 4.4 DID method requirements

For the source-of-record DID:

- `did:web` is **ACCEPTABLE** for low-impact events only, AND only when paired with all of: (a) HSM-backed signing keys (the source's signing key MUST NOT be exportable), (b) DNSSEC on the DID's resolution domain, (c) Certificate Transparency log monitoring with automated alerting on unexpected certificate issuance, (d) the source publishes a signed conformance declaration at `https://<domain>/.well-known/veritas-cascade-conformance.json` listing all four properties + audit attestation (see § 4.4.1).
- `did:plc` (operated by Bluesky PBC; auditable but single-operator history; trust model is *centralised but auditable*, not distributed) is **RECOMMENDED** for high-authority sources where Bluesky-as-PLC-operator risk is acceptable. Note: nation-scale sources of record SHOULD evaluate operator-level risk explicitly.
- `did:webvh` / `did:tdw` (DID with Verifiable History; multiple live operators; recent IETF activity) and `did:keri` (with a community-operated witness pool) are **RECOMMENDED** for sources requiring distributed trust assumptions.
- `did:ion` is **NOT RECOMMENDED** for new high-authority sources as of 2026: Microsoft's primary public ION operator wound down operations on 2024-06-01. Existing `did:ion` DIDs remain resolvable via remaining nodes, but new adoption requires the source to operate its own Sidetree-on-Bitcoin node — operationally heavy and not justified by the cryptographic benefit relative to the alternatives above.
- `did:web` alone, without all four hardening elements (HSM + DNSSEC + CT + conformance declaration), is **NOT ACCEPTABLE** for any event whose impact crosses the § 7 threshold.

Sources of record MAY use multiple DID methods for the same identity, with each cascade event signed by the method appropriate to that event's impact tier.

#### 4.4.1 `did:web` conformance declaration

The conformance declaration is a JSON-LD document published at `https://<domain>/.well-known/veritas-cascade-conformance.json`:

```jsonld
{
  "@context": "https://veritas-protocol.example/cascade-conformance/v0.1",
  "@type": "DidWebCascadeConformanceDeclaration",
  "did": "did:web:nature.com",
  "declarations": {
    "hsm_backed_signing_key": true,
    "hsm_specification": "FIPS 140-3 Level 3",
    "dnssec_enabled": true,
    "ct_monitoring_enabled": true,
    "ct_monitoring_endpoint": "https://nature.com/security/ct-alerts",
    "two_key_separation": true
  },
  "audit_attestations": [
    {
      "auditor": "did:plc:third-party-auditor",
      "audit_date": "2026-04-01",
      "audit_report_url": "https://...",
      "audit_signature": "..."
    }
  ],
  "validUntil": "2027-04-01T00:00:00Z",
  "proof": { ... }
}
```

The declaration MUST be signed by the source's primary DID and SHOULD include at least one independent third-party audit attestation. Aggregators MUST fetch and verify the declaration before accepting any high-impact `did:web`-signed event from the source. A missing or expired declaration causes the aggregator to refuse the event.

The two-key-separation property (the operational `did:web` DID-document update key is distinct from the cascade-event signing key, per § 8.2) is administratively enforced by the source. Aggregators cannot cryptographically verify the two-key property from a `did:web`-signed event alone — the conformance declaration is the protocol's signal that the source attests to administrative enforcement. This is a known limitation of `did:web` relative to `did:plc` / `did:webvh` (which enforce key separation cryptographically); the conformance-declaration mechanism is the bridge.

## 5 · Velocity throttle

A `cascade:RETRACTED_BY_SOURCE` event does not propagate to downstream consumers immediately upon being recorded on the L2 Cascade Event Log. There is a mandatory **velocity-throttle window** during which the event is recorded but not yet fanned out to consumers.

### 5.1 Default windows

The velocity-throttle window depends on the event's impact tier:

| Impact tier | Throttle window | Confirmation depth |
|---|---|---|
| Low (no co-sig required) | 12 L2 blocks (~ 24 seconds on Base) | 12 |
| Medium (co-sig required) | 256 L2 blocks (~ 8.5 minutes on Base) | 256 |
| High (financial-impact threshold) | 6,400 L2 blocks (~ 3.5 hours on Base) | 6,400 |
| Critical (mass-public-consequence threshold) | 64,000 L2 blocks (~ 35 hours on Base) | 64,000 |

These default values are governance parameters and may be revised through dispute-panel supermajority. Implementations SHOULD parameterise the values rather than hard-code them.

### 5.2 Function of the throttle

The throttle window has two functions:

1. **Forensic detection** — give legitimate source authorities and chapter convenors time to detect a forged retraction (via Certificate Transparency monitoring, DID-update-detection alerts, anomalous-event monitoring at aggregators, public-comment channels) and issue a reversal under § 6 before fan-out occurs.
2. **Multi-source corroboration** — give the multi-source-corroboration mechanism (§ 7) time to receive corroborating signatures or to register dispute.

If a reversal event (§ 6) is recorded on the cascade log within the throttle window, the original retraction event is annotated as `cascade:REVERSED_BY_FORENSIC_RECOVERY` and never fans out.

### 5.3 Bypassing the throttle is non-conformant

Implementations MUST NOT bypass or shorten the throttle window for any cascade event. A federation aggregator that fans out a retraction before the throttle window expires is non-conformant. This includes any side-channel propagation: `libp2p` gossip (referenced in earlier drafts of the working paper) is **advisory only** and does NOT constitute fan-out; consumers receiving an event over a non-chain channel MUST treat it as `_meta.in_cascade_throttle: true` until the L2 throttle window has elapsed.

The exception is the explicit governance override under § 6.4 (emergency expedition).

### 5.4 Throttle-vs-SLA interaction

The 4-hour reversal SLA (§ 6.1) and the per-tier throttle windows (§ 5.1) compose differently across tiers:

| Tier | Throttle | SLA / throttle ratio | Reversal lands... |
|---|---|---:|---|
| Low | 24 s | 600× | always after fan-out → § 6.3 consumer-notice triggered |
| Medium | 8.5 min | 28× | almost always after fan-out → § 6.3 consumer-notice expected |
| High | 3.5 h | 1.14× | usually after fan-out for legitimate forgery; within throttle for fast detection |
| Critical | 35 h | 0.11× | well within throttle; fan-out can be averted |

Implementers and consumers MUST understand that the throttle window provides forensic-detection latitude **only at the high and critical tiers**. For low and medium tiers the throttle is performative against forgery — its primary value at those tiers is multi-source corroboration (§ 7) and audit-log latency for after-the-fact investigation, not pre-fanout reversal. § 6.3 consumer-notice is the operationally-meaningful defense at low/medium tiers.

This compositional asymmetry is intentional: low-impact events fan out fast because the harm of delaying a legitimate retraction would dominate the harm of a forgery. The asymmetry is part of the design, not a defect — consumers are notified post-hoc when forgery is detected.

## 6 · Forensic reversal Service Level Agreement

### 6.1 Detection-to-reversal target

The Veritas Foundation publishes a **detection-to-reversal SLA** of 4 hours. The SLA clock starts at **the earlier of**:

- **(a)** any chapter convenor, federation aggregator, source-authority security team, or registered authority-floor entity privately notifying the foundation incident-response channel of suspected forgery (private detection); OR
- **(b)** any party publicly identifying the forgery on the foundation's public-comment channel, the source's own public channels, or any major communications channel monitored by the foundation's incident-response team (public identification).

This bidirectional trigger closes the **public-identification-stretching sub-attack** flagged in V2-W2F § A14: an attacker who stalls public attribution (via legal threats, contradictory-evidence injection, or coordinated denial campaigns) cannot stretch the SLA clock so long as private detection has occurred. The clock starts at first detection by any qualified channel, not at consensus on attribution.

A reversal MUST be issuable within 4 hours under normal operating conditions. The SLA is a public commitment, not a cryptographic guarantee. It binds the foundation operationally; reversals that take longer than 4 hours are reportable failures that the foundation MUST disclose in its quarterly transparency report.

### 6.2 Reversal authentication

A reversal is itself a cascade event of type `cascade:REVERSED_BY_FORENSIC_RECOVERY`. It MUST be:

- co-signed by N-of-M chapter convenors with the same jurisdictional / institutional diversity requirements as the high-impact cascade-event co-signature (§ 4.2);
- accompanied by a public forensic statement explaining the basis for the reversal (DID-document tampering evidence, ACME-cert anomaly, source-authority denial, etc.);
- recorded on the cascade log within the throttle window of the original retraction (if recorded after the throttle expires, the original retraction has already fanned out and consumer-side notice is required — see § 6.3).

### 6.3 Post-fan-out reversal (consumer notice)

If the throttle window expires before reversal can be issued (and the original retraction has fanned out to consumers), the reversal is still recorded as `cascade:REVERSED_BY_FORENSIC_RECOVERY`, but federation aggregators MUST also issue a **consumer-facing notice** at the next query for the affected attestation. The notice explains: the original retraction was forged, the legitimate authority did not retract, the affected attestations remain valid, and the forged event has been recorded in the public audit trail.

### 6.4 Emergency expedition

Emergency expedition **shortens** the throttle window and is therefore the wrong defense against a forged retraction (a faster fan-out propagates a forgery faster, not slower). The defense path against forgery is § 6.1–6.3 reversal, not expedition.

The legitimate use case for § 6.4 is a **legitimate urgent retraction** whose throttle window itself causes harm: a public-safety claim that must be retracted immediately (contaminated-vaccine or food-product recall, security advisory for an actively-exploited vulnerability, election-day correction of a misreported result). For these claims, the high or critical tier's standard throttle (3.5 h or 35 h) would extend consumer harm. Expedition allows the foundation to compress the throttle for a specific event whose legitimacy is independently established.

Expedition requires:

- the source-of-record's standard signature per § 4.1 PLUS co-signature from 5-of-(M minimum) chapter convenors with the same jurisdictional + institutional diversity requirements as § 4.2 (when M=11, this is 5-of-11; the document MUST name the M-value of the active roster);
- public statement of the harm being prevented;
- the source-of-record's own affirmative declaration that the retraction is authentic (NOT a forgery; the source is requesting acceleration of its own legitimate retraction);
- post-incident report within 7 days, published on the foundation's transparency channel.

Note that expedition does NOT lower the source-authentication bar — it accelerates an already-authenticated event. An attacker who can issue a fully-authenticated event already has the authority to issue a normal retraction; expedition does not let an attacker do anything they couldn't otherwise do.

Emergency expedition is intended to be rare (target: fewer than 3 invocations per year in steady-state operation). Its overuse is itself a governance failure that triggers dispute-panel review.

## 7 · Multi-source corroboration

For cascade events above the high-impact threshold (§ 5.1 high or critical), the protocol REQUIRES corroboration from one or more independent authorities in addition to the source-of-record signature.

### 7.1 Corroborator selection

Eligible corroborators are entities that hold a verifiable credential authorising them to corroborate cascade events of the relevant impact tier. Credentials are issued by the foundation (see `RFC-VERITAS-VC` forthcoming) under criteria including:

- demonstrated independence from the source-of-record (no shared corporate ownership, no shared funding source, no shared editorial pipeline);
- demonstrated capacity to detect inauthenticity (e.g., a peer-reviewing journal corroborating another journal; a court of appeal corroborating a court of first instance; a national statistics office corroborating an international body);
- jurisdictional diversity from the source.

### 7.2 Threshold definitions

Cascade-event impact is the **higher of** (a) the *computed-impact tier* derived from downstream-attestation analysis, and (b) the *source-authority floor* assigned to the source DID. Both components MUST be evaluated; the higher tier governs.

#### 7.2.1 Computed-impact tier

Default suggested values:

- **High-impact**: cascade events affecting attestations whose aggregate downstream value exceeds USD 10 million, OR cascade events affecting public-health, public-safety, or election-integrity claims with measurable population-scale exposure.
- **Critical-impact**: ten times the high-impact threshold, OR cascade events affecting claims with mainstream-media reach above 10 million unique viewers.

#### 7.2.2 Source-authority floor

Each source DID is assigned an authority-floor tier in the foundation's vetted-source registry, regardless of any specific event's downstream-attestation aggregate. This closes the **cold-target bypass**: an attacker cannot evade the co-signature requirement by retracting a paper that has not yet accumulated downstream attestations. Default authority-floor assignments:

- **Critical-floor**: top-tier general-science journals (Nature, Science, Cell, NEJM, JAMA, Lancet); national supreme courts; constitutional-court equivalents; national statistics offices for headline indicators; UN-treaty-body authoritative sources.
- **High-floor**: peer-reviewed journals indexed in Web of Science Q1; national academies; appellate courts; central-bank statistical releases; major standard-setting bodies (ISO, IEEE, W3C, IETF).
- **Medium-floor**: peer-reviewed journals broadly; trial courts; government statistical offices below national-headline tier; major NGO research output.
- **Low-floor**: all other registered sources.

The authority-floor is published in the source-of-record registry and signed by the foundation. Aggregators MUST consult the registry before classifying any cascade event from a registered source.

A source DID NOT in the registry is treated at low-floor; high-floor or critical-floor sources MUST be registered to receive their floor benefit.

#### 7.2.3 Effective tier

The effective impact tier governing a specific cascade event is `max(computed_impact_tier, source_authority_floor)`. Source-authority floor defends against the cold-target bypass; computed-impact tier defends against escalation in event aggregate over time.

These values are revisable by dispute-panel supermajority subject to the hard floors in § 7.4.

### 7.3 Source-of-record registry

The foundation maintains a JSON-LD registry of vetted sources of record at `https://veritas-protocol.example/sources/v0.3.jsonld`. Each entry binds:

- `source_did` — the DID of the source authority
- `authority_floor` — one of `low`, `medium`, `high`, `critical`
- `domains[]` — canonical consensus-domain identifiers within which this source is authoritative
- `vetting_history[]` — public records of vetting events

Registry updates follow the same governance process as the issuer-vetting in `RFC-VERITAS-VC-v0.1` § 3.2 (proposal → public comment → editorial review → dispute-panel review).

A source-DID change (e.g., journal acquired, court reorganised) is handled via `cascade:AUTHORITY_TRANSFERRED` events, NOT via re-registration of the same authority floor under a different DID.

### 7.4 Hard floors on governance parameters

Notwithstanding any dispute-panel revision under § 7.2, the following invariants MUST hold:

- N (chapter-convenor co-signature count) MUST be ≥ 3 for any high-impact or critical-impact tier event.
- Throttle-window MUST be ≥ 256 L2 blocks for any tier requiring co-signature.
- Jurisdictional and institutional diversity requirements (§ 4.2) MUST NOT be removed by any governance revision.
- Source-authority-floor tier of `critical` MUST NOT be downgraded below `high` for any source whose claims have measurable mainstream-media reach above 10 million unique viewers in the prior 12-month window.

These floors are amendable only by foundation-charter amendment (governance process strictly stronger than dispute-panel supermajority).

## 8 · DID-method hardening guidance

This section is normative for sources of record that wish to publish cascade events at the high or critical impact tier.

### 8.1 HSM-backed signing keys

The source-of-record's signing key MUST be held in a Hardware Security Module (HSM) compliant with **FIPS 140-3 Level 3 or higher** (or, during the CMVP transition window, FIPS 140-2 Level 3 certificates valid prior to 2026-09-21), OR in a comparable cloud KMS with hardware-backed key isolation (AWS CloudHSM, Azure Managed HSM, GCP Cloud HSM, all of which offer FIPS 140-3 Level 3 service tiers as of 2026). The signing key MUST NOT be exportable. Signing operations MUST be performed inside the HSM.

### 8.2 DID-document-update controls

For `did:web`: the DID document is hosted at `https://<domain>/.well-known/did.json`. Updates to this document MUST require signed authorisation from a key that is NOT the same as the cascade-event signing key. This is the "two-key" pattern: an *update* key separate from the *operational* signing key. Compromise of the operational key alone does not let an attacker rewrite the DID document.

For `did:plc` / `did:ion`: the underlying ledger already enforces this property cryptographically.

### 8.3 Certificate Transparency monitoring

Sources of record using `did:web` MUST monitor Certificate Transparency logs for unexpected certificate issuance on their DID-resolution domains. Alerts MUST trigger automated notification to: (a) the source-of-record's security team, (b) any chapter convenors who hold co-signature authority for that source's high-impact events, (c) the Veritas Foundation's incident-response channel.

### 8.4 DNSSEC

DNSSEC MUST be enabled on the DID's resolution domain. DNS resolution failures or DNSSEC validation failures during cascade-event verification MUST cause the verifying aggregator to reject the event.

## 9 · On-chain encoding

Cascade events are recorded on the L2 Cascade Event Log as smart-contract events emitted by the cascade-registry contract. The event signature is:

```solidity
event CascadeEvent(
  bytes32 indexed claimHash,
  bytes32 indexed eventType,
  address indexed sourceDIDAccount,
  bytes  signedDocument,
  bytes  transparencyLogProof,
  uint256 timestamp
);
```

The `signedDocument` field carries the canonicalised JSON-LD cascade-event document with all required signatures (source signature, co-signatures if required, transparency-log inclusion proof). The `claimHash` is the hash of the primary claim being affected. The `eventType` is the canonicalised hash of the event-type string from § 3 (e.g., `keccak256("cascade:RETRACTED_BY_SOURCE")`).

The event-emission cost on Base L2 is approximately USD 0.001-0.01 per event at typical gas prices. This cost is borne by the source-of-record (or by the foundation on its behalf for participating sources).

## 10 · Transparency-log integration (SCITT)

Cascade events are mirrored into an IETF SCITT-compatible transparency log operated by the Veritas Foundation in addition to the L2 chain encoding. The dual-anchoring (L2 + SCITT) provides:

- **L2 anchoring** for downstream-aggregator subscription and federation;
- **SCITT anchoring** for upstream-standards interoperability and for clients that prefer IETF-style transparency logs over Ethereum-style chain reads.

A cascade event is considered "anchored" only when both the L2 emission and the SCITT inclusion are confirmed. Aggregators MAY propagate based on L2-only anchoring during the throttle window but MUST verify the SCITT inclusion before fan-out.

## 10.5 AI-grounding text fields (binding to RFC-VERITAS-MCP-GROUNDING)

The following cascade-event fields contain validator-supplied or source-supplied free text that is consumed by AI-laboratory grounding adapters. These fields are normatively bound to the IPI-safe sanitation contract specified in `RFC-VERITAS-MCP-GROUNDING-v0.1` § 4 (sanitation pipeline) + § 5 (untrusted-text framing):

| Cascade-event field | Source | Sanitation tier |
|---|---|---|
| `cascade:RETRACTED_BY_SOURCE.public_forensic_statement` | source-of-record (or chapter convenors during reversal) | full pipeline (§ 4 of MCP-GROUNDING) |
| `cascade:RETRACTED_BY_ATTESTATION.dispute_rationale` | third-party validator | full pipeline + framing (§ 5 of MCP-GROUNDING) |
| `cascade:CORRECTED_BY_SOURCE.correction_text` | source-of-record | full pipeline |
| `cascade:SUPERSEDED_BY_REVISION.revision_notes` | source-of-record | full pipeline |
| `cascade:AUTHORITY_TRANSFERRED.transfer_statement` | both old and new authority | full pipeline |
| `cascade:REVERSED_BY_FORENSIC_RECOVERY.forensic_statement` | chapter convenors | full pipeline |
| `cascade:EMERGENCY_EXPEDITION.harm_being_prevented` | source + foundation | full pipeline |

Length caps for each field follow the per-field caps of `RFC-VERITAS-MCP-GROUNDING-v0.1` § 4.1. Implementations MUST apply NFKC normalisation, homoglyph filtering, bidi/zero-width stripping, URL hardening for any embedded URIs, and markup stripping in the order specified by MCP-GROUNDING § 4. Cascade-event fields are wrapped in the `veritas:UntrustedValidatorText` envelope (or, for source-supplied fields, an analogous `veritas:UntrustedSourceText` envelope) before being passed to AI-grounding consumers.

This binding closes the circular reference flagged in V2 review (V2-W2F super-review against this RFC, finding H1): MCP-GROUNDING § 1.2 deferred cascade-event metadata sanitation to this RFC, and this section is the normative response. Implementers consume this list as the authoritative enumeration of cascade-event fields subject to the IPI-safe contract.

## 11 · Implementation guidance

### 11.1 Reference implementations

The Veritas Foundation publishes reference implementations for each role:
- `veritas-cascade-source` — source-side signing client (CLI + library).
- `veritas-cascade-relay` — chapter-convenor co-signature relay.
- `veritas-cascade-aggregator` — federation-aggregator-side cascade processor.

Each reference implementation is published under an open-source license; conformance test vectors are published alongside.

### 11.2 Conformance test corpus

A corpus of test cascade events covering the full event-type matrix and the full impact-tier matrix is published alongside this RFC. Implementations claiming conformance MUST pass the corpus.

The corpus deliberately includes adversarial-test cases: forged retractions that the implementation MUST reject; throttle-bypass attempts that the implementation MUST refuse; emergency-expedition scenarios that the implementation MUST handle correctly.

## 12 · Security considerations

The threats this protocol explicitly defends against are catalogued in `super-review-2026-04-25-v2/V2-W2F-threat-model.md` and `spec/ARCHITECTURE.md` § 5. The most significant are:

- **Source-retraction forgery** (V2-W2F § A3, formerly CRITICAL · BYPASSABLE) — addressed by §§ 4, 5, 6, 7, 8.
- **Reversal-SLA gaming** (V2-W2F § A14) — addressed by § 6 binding the SLA to *detection*, not to *confirmation* (an attacker cannot stretch detection time by withholding their own confirmation).
- **Cross-jurisdiction state-actor pressure on co-signers** — addressed by § 4.2 jurisdictional diversity requirement.
- **DID document tampering** — addressed by § 8 HSM + DNSSEC + CT monitoring requirements.

Out of scope for this RFC (handled by sibling documents):
- AI-poisoning via cascade-event metadata text — addressed by `RFC-VERITAS-MCP-GROUNDING` (forthcoming W8) IPI sanitation contract; cascade events MUST follow that contract for any field consumed by AI grounding adapters.
- Foundation-key compromise and governance recovery — addressed by the foundation governance charter + `RFC-VERITAS-CPML-REGISTRY` (forthcoming W6) for registry-side governance.

## 13 · Comments and amendments

This document is a working draft. Comments are welcomed via the contact form on the Veritas Protocol brief. The v0.3 finalisation pass will incorporate accepted amendments. Significant security-relevant amendments will trigger an additional super-review pass before publication.

## 14 · References

- `spec/ARCHITECTURE.md` — Veritas Protocol Architecture Document § 1.3.2 (Cascade Event Log) and § 6.1 (this RFC's stub).
- `spec/factcheck/RFC-FACTCHECK-v0.2.md` — Self-Claims Reporting Protocol (canonicalisation reference).
- `spec/cpml/RFC-CPML-v0.1.md` — Consensus Profile Markup Language.
- `super-review-2026-04-25-v2/V2-W2F-threat-model.md` — adversarial audit identifying A3 source-retraction-forgery as the gap this RFC closes.
- IETF RFC 7515 — JSON Web Signature (JWS).
- IETF RFC 8785 — JSON Canonicalization Scheme (JCS).
- IETF SCITT (Supply Chain Integrity, Transparency, and Trust) — transparency-log architecture.
- W3C Verifiable Credentials Data Model 2.0 (15 May 2025) — credential format used by chapter convenors.
- W3C Decentralized Identifiers v1.0 (19 July 2022; v1.1 Candidate Recommendation) — DID spec.
- W3C SKOS — namespace conventions for cascade-event-type identifiers.

---

*Drafted as workstream W10 deliverable for v0.3, closing super-review V2-W2F § A3. Cross-referenced from `spec/ARCHITECTURE.md` and `critical-review/V0.3-PLAN.md`. Comments welcome. — Collaborative Fact-Checking Working Group, April 2026.*