# RFC-VERITAS-FEDERATION-v0.1 — Aggregator Resync, Reorg, Partition Tolerance

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

> *This document specifies how federation aggregators in the Veritas Protocol handle chain reorgs, gossip-network partitions, eclipse attacks, checkpoint-sync bootstrapping, and recovery from extended disconnection. The federation layer is the fast read path for AI-grounding queries; without a published resilience contract, an attacker who controls a subset of aggregators can serve stale or inconsistent state to a slice of the consumer population.*

---

## Status of this document

Working draft. Comments at § 10. Format follows IETF conventions; intended upstream as input to a future "transparency-network resilience" working group.

## Abstract

The federation layer (`spec/ARCHITECTURE.md` § 1.4) is N≥5 independently-operated aggregators that subscribe to the L2 Cascade Event Log and the L2 Attestation Registry, maintain edge-cached materialised views per consensus domain, and serve composed verdicts to consumers in tens-of-milliseconds. The chain layer is the cold path of settlement and authority; the federation layer is the hot path of read traffic. Attacks on the federation layer (eclipse, partition, slow-poisoning) are distinct from attacks on the chain layer; this document specifies the resilience contract that aggregators MUST honour and consumers MAY rely on. It binds the chain-reorg handling, the gossip-eclipse defence, the consumer-facing freshness indicator, the periodic checkpoint-snapshot publication, and the catch-up protocol for disconnected aggregators.

## 1 · Introduction

### 1.1 Motivation

The V2 super-review threat-model audit (V2-W2F § A7 + ancillary findings A12, A14) flagged the federation layer as the soft underbelly of the otherwise chain-anchored architecture: even if the chain is healthy, an aggregator can be eclipsed (its peer set replaced with attacker-controlled peers), slow-poisoned (its cached state delayed selectively), or partitioned (its peer set split such that it sees only a subset of events). The protocol's "tens-of-milliseconds latency" promise creates time pressure that attackers can exploit — an aggregator that waits for full consensus on every event will fall behind the latency budget; an aggregator that fans out before consensus risks serving stale or forged state.

Without a published contract, every aggregator implements ad-hoc resilience and consumers cannot reason about what they are trusting.

### 1.2 Scope

Specifies:

- **Chain-reorg handling** (§ 3) — finalisation depth, rollback procedure for cached aggregations.
- **Eclipse defence** (§ 4) — multi-relay subscription requirement, cross-aggregator divergence detection.
- **Consumer-facing freshness indicator** (§ 5) — what the response envelope tells the consumer about how fresh the answer is.
- **Checkpoint-sync** (§ 6) — daily Merkle-root snapshots; new-aggregator bootstrap.
- **Disconnect-recovery** (§ 7) — protocol for an aggregator returning from extended disconnection.
- **Cascade-event ordering** (§ 8) — interaction with `RFC-VERITAS-CASCADE-v0.1` § 5 velocity throttling.

Out of scope:

- Aggregator-to-consumer transport security (TLS, SSL pinning, MCP transport — covered by the MCP transport spec).
- Aggregator reputation math (each operator's editorial concern; not normative here).
- L2 chain-level consensus (Base L2's own consensus is assumed; this RFC presupposes Base finalisation guarantees).

### 1.3 Terminology

Standard BCP 14. Domain-specific:

- **Aggregator** — federation-layer node that subscribes to chain events and serves consumers.
- **Reorg** — a change in the canonical chain history (Base L2 sequencer fault, dispute resolution) that invalidates cached state computed under the old history.
- **Eclipse** — an attack in which a victim is connected only to attacker-controlled peers.
- **Partition** — gossip-network splitting that leaves an aggregator with a subset of peers.
- **Checkpoint** — a published Merkle-root snapshot of attestation/cascade state at a specific chain height, attested by N aggregators.

## 2 · Architecture context

```
L2 CHAIN LAYER (Base)
  │
  ├── reorg events (rare; specified by Base L2 sequencer behaviour)
  ├── attestation-registry events
  └── cascade-event-log events
       │
       ├── (subscribe) ───────────────────────────────┐
       │                                              │
L3 FEDERATION LAYER ─┬── Aggregator α ─── reorg-aware feed
                     ├── Aggregator β ──── divergence detection
                     ├── Aggregator γ ──── checkpoint cosig
                     ├── Aggregator δ ──── consumer freshness
                     └── Aggregator ε ──── catch-up sync
                                              │
                                              ▼
L4 CONSUMER (browser ext / MCP grounding / CPML profile)
  │
  └── multi-relay subscription requirement (§ 4)
```

Each aggregator subscribes to the chain through multiple independent relays. Consumers MAY query a single aggregator OR multiple aggregators (the protocol does NOT centralise consumer-side multi-aggregator subscription, but operators may choose to multi-subscribe for divergence detection).

## 3 · Chain-reorg handling

### 3.1 Finalisation depth

An aggregator MUST NOT serve to consumers any attestation or cascade event whose enclosing chain block has fewer than F confirmation blocks, where F is the finalisation-depth parameter. Default values:

| Chain | F (default) | Approximate wall-clock |
|---|---|---|
| Base L2 (Optimistic Rollup) | 64 blocks | ~ 130 seconds |
| Optimism mainnet | 64 blocks | ~ 130 seconds |
| Arbitrum One | 50 blocks | ~ 13 minutes (Arbitrum's longer block time) |

These values are tuned to "deeper than any expected reorg under normal operation"; they are governance parameters and may be revised through dispute-panel review as empirical data accumulates.

For cascade events, the velocity-throttle window of `RFC-VERITAS-CASCADE-v0.1` § 5 takes precedence — the cascade-throttle is much longer than the finalisation depth for high-impact events, so an aggregator complying with the cascade-throttle is automatically compliant with finalisation depth.

### 3.2 Reorg detection

An aggregator detects a reorg when its subscribed relay reports a chain height that has rewritten any block within the F-confirmation window the aggregator has been tracking.

Upon reorg detection, the aggregator MUST:

1. Pause new consumer responses for any query whose answer would touch the reorged blocks.
2. Compute the rollback set: every cached attestation/cascade-event computation that referenced events from the reorged blocks.
3. Re-fetch the canonical events from the new chain history.
4. Recompute the affected per-consensus-domain materialised views.
5. Resume consumer responses.

Reorg-handling MUST be transparent to the consumer: the response envelope's `_meta.freshness` field surfaces whether the response was computed under a reorged history (a notice the consumer can choose to highlight).

### 3.3 Rollback for `cascade:RETRACTED_BY_SOURCE` under reorg

A `cascade:RETRACTED_BY_SOURCE` event under reorg has special handling: if the reorg removes the cascade event from the chain history, the aggregator MUST issue a `cascade:REVERSED_BY_REORG` notice to consumers who received the original event. This is distinct from `cascade:REVERSED_BY_FORENSIC_RECOVERY` (per `RFC-VERITAS-CASCADE-v0.1` § 6) — a reorg-reversal is not a forgery indication; it is a chain-level instability indicator that itself merits dispute-panel review if it occurs more than once in a quarter.

## 4 · Eclipse defence

### 4.1 Multi-relay subscription requirement

Each aggregator MUST subscribe to the chain through at least **3 independent relays** representing at least 2 distinct relay-operator organisations. Reference relay sets are published by the foundation; aggregators MAY subscribe through additional non-foundation relays for stronger guarantees.

The 3-relay minimum defends against single-relay-operator compromise: even if one relay returns falsified events, the divergence between relays is detectable.

### 4.2 Cross-aggregator divergence detection

The federation operates a **divergence-monitoring service** that compares each aggregator's published view at sampled cuts in time. The service:

- Polls each aggregator every 60 seconds for its `view_root` — a Merkle root over the aggregator's current materialised views per consensus domain.
- Detects divergence: any aggregator whose `view_root` disagrees with N-1 of the others is flagged.
- Publishes a divergence alert on the foundation's transparency channel.
- Triggers dispute-panel review if divergence persists beyond 5 minutes.

Aggregators MUST publish their `view_root` at the polling endpoint. Refusal-to-publish is itself a divergence signal.

### 4.3 Consumer-side multi-aggregator queries

Consumers MAY query 2+ aggregators in parallel and compare responses. Reference client implementations support this pattern as `query-with-divergence-detection`. The user-facing freshness indicator (§ 5) surfaces any cross-aggregator disagreement to the consumer.

The protocol does NOT mandate consumer-side multi-querying; it is a deployment choice. The MCP grounding adapter reference implementation defaults to single-aggregator query for latency reasons but exposes a `multi_aggregator: true` flag for higher-trust deployments.

## 5 · Consumer-facing freshness indicator

Every response from an aggregator MUST include `_meta.freshness` in the response envelope:

```json
{
  "_meta": {
    "freshness": {
      "source_aggregator": "did:web:aggregator-alpha.example",
      "view_height": 18437291,
      "view_age_seconds": 7,
      "view_root": "0x...",
      "finalisation_depth_at_view": 64,
      "in_reorg_window": false,
      "in_cascade_throttle": false,
      "checkpoint_anchored": true,
      "last_checkpoint_age_hours": 12.4
    }
  }
}
```

### 5.1 Required fields

- `source_aggregator` — the DID of the aggregator that served the response.
- `view_height` — the chain height the materialised views were computed at.
- `view_age_seconds` — wall-clock seconds since the view was computed.
- `view_root` — the Merkle root of the response-relevant subtrees of the aggregator's view.
- `finalisation_depth_at_view` — confirmation depth applied (per § 3.1).
- `in_reorg_window` — true if the response touches blocks within the reorg-window-tail; consumer SHOULD treat with low confidence.
- `in_cascade_throttle` — true if the response includes a cascade event that has not yet cleared the velocity throttle; consumer MUST treat the cascade-event reference as preliminary.
- `checkpoint_anchored` — true if the view height is at or beyond the most-recent published checkpoint (§ 6).
- `last_checkpoint_age_hours` — wall-clock hours since the most-recent checkpoint was published.

### 5.2 Consumer surfacing

Reference consumer implementations surface the freshness indicator in three patterns:

- **Browser extension**: small icon in the response card; green = fully fresh, amber = in reorg window OR cascade throttle, red = checkpoint-stale.
- **MCP grounding adapter**: includes the indicator in the `_meta` block returned to the AI laboratory client.
- **CPML profile file UI**: displays a freshness-history chart over the last hour of queries.

## 6 · Checkpoint-sync

### 6.1 Periodic snapshots

The federation publishes a checkpoint snapshot at a regular cadence: every 24 hours. A checkpoint is a Merkle root over the canonical attestation-registry state at a specific chain height, co-signed by N-of-M aggregators (default N=3, M=5).

Checkpoints are published at `https://veritas-protocol.example/checkpoints/v0.3/` as JSON-LD documents:

```jsonld
{
  "@context": "https://veritas-protocol.example/federation/v0.1",
  "@type": "FederationCheckpoint",
  "checkpoint_height": 18437000,
  "checkpoint_timestamp": "2026-04-28T00:00:00Z",
  "attestation_registry_root": "0x...",
  "cascade_event_log_root": "0x...",
  "validator_credential_registry_root": "0x...",
  "co_signers": [
    "did:web:aggregator-alpha.example",
    "did:web:aggregator-gamma.example",
    "did:web:aggregator-epsilon.example"
  ],
  "signatures": [...]
}
```

### 6.2 Use of checkpoints

Checkpoints serve three functions:

1. **New-aggregator bootstrap** — a new federation-layer operator can join the federation by trusting the most-recent checkpoint and replaying only forward events from there, rather than replaying the full chain history from genesis.
2. **Disconnect-recovery anchor** — a long-disconnected aggregator (§ 7) re-anchors from the most-recent checkpoint.
3. **Cross-aggregator divergence anchor** — the divergence monitor of § 4.2 uses checkpoints as the canonical reference; aggregator views that diverge from the most-recent checkpoint by more than the cumulative event-set since the checkpoint are flagged.

### 6.3 Checkpoint co-signature requirements

A checkpoint requires N-of-M co-signatures from independent aggregators. Default: 3-of-5. Co-signers MUST represent at least 2 distinct legal jurisdictions and at least 2 distinct institutional operators (preventing a single operator from dominating multiple co-signature roles).

If the federation has fewer than M aggregators (early-network condition), checkpoints are co-signed by N-of-(available); the threshold relaxes proportionally and is annotated in the checkpoint document.

## 7 · Disconnect recovery

An aggregator may disconnect from the chain and gossip layers due to network partition, host maintenance, or operator-driven downtime. Upon reconnection:

### 7.1 Catch-up protocol

1. Aggregator reads the most-recent published checkpoint (§ 6).
2. If the checkpoint is older than the aggregator's last-known view, the aggregator anchors at the checkpoint and re-fetches forward events from chain.
3. If the checkpoint is newer than the aggregator's last-known view, the aggregator anchors at the checkpoint and discards its prior cached views (they would have been computed under stale state).
4. The aggregator re-fetches forward events from chain to current head, applies them in order, and rebuilds materialised views.
5. The aggregator resumes serving consumers only when its view height is within F of chain head (per § 3.1).

### 7.2 Staleness window

The published staleness window is **48 hours**: an aggregator that has been disconnected for less than 48 hours can re-anchor from the most-recent checkpoint and rebuild without rescanning. Beyond 48 hours, rebuilding may require multi-checkpoint replay; operators MAY choose to fully re-bootstrap (§ 6.2) instead.

The 48-hour window is a governance parameter; operators that anticipate longer disconnections SHOULD bootstrap rather than catch-up.

### 7.3 Re-joining the federation

After catch-up, the aggregator re-publishes its `view_root` (§ 4.2) and re-enters the divergence-monitoring rotation. If divergence is detected, dispute-panel review is triggered before the aggregator resumes consumer queries.

## 8 · Cascade-event ordering

The interaction between this RFC and `RFC-VERITAS-CASCADE-v0.1`:

- A cascade event at chain height H is NOT served to consumers until BOTH:
  - the chain block at H has reached finalisation depth F (§ 3.1), AND
  - the velocity throttle of `RFC-VERITAS-CASCADE-v0.1` § 5 has elapsed (which is generally a multiple of F for high-impact events).

- An aggregator that detects a reorg removing a cascade event MUST issue `cascade:REVERSED_BY_REORG` (§ 3.3).

- Cascade events are NEVER served as preliminary (in cascade throttle) without `_meta.in_cascade_throttle: true`.

## 9 · Conformance

### 9.1 Aggregators

Aggregators MUST:

- Subscribe through ≥3 independent relays representing ≥2 distinct relay-operator organisations (§ 4.1).
- Apply finalisation depth F per § 3.1.
- Detect and handle reorgs per § 3.2.
- Publish their `view_root` at the divergence-monitoring polling endpoint (§ 4.2).
- Include the `_meta.freshness` block on every response (§ 5).
- Co-sign federation checkpoints when included in the co-signer rotation (§ 6).
- Implement the catch-up protocol of § 7 for re-connection.

Non-conformant aggregators are removed from the foundation's listed-federation set and from consumer reference-client default subscriptions.

### 9.2 Consumers

Consumers SHOULD:

- Surface the `_meta.freshness` indicator to the user.
- Treat `_meta.in_reorg_window: true` as low-confidence and SHOULD warn the user.
- Treat `_meta.in_cascade_throttle: true` as preliminary and SHOULD NOT propagate the cascade event downstream until throttle clears.
- Optionally multi-aggregator query (§ 4.3) for higher-trust deployments.

## 10 · Comments and amendments

Comments welcomed at the contact form. Amendments to finalisation-depth, throttle-window, or checkpoint-cadence parameters require dispute-panel review.

## 11 · References

- `spec/ARCHITECTURE.md` § 1.4 (federation layer) and § 6.5 (this RFC's stub).
- `spec/cascade/RFC-VERITAS-CASCADE-v0.1.md` § 5 (velocity throttle) + § 6 (forensic reversal interaction).
- `spec/factcheck/RFC-FACTCHECK-v0.2.md` § 4.1 (canonical-hash, used for view-root computation).
- `super-review-2026-04-25-v2/V2-W2F-threat-model.md` § A7 + A12 + A14 — audit findings this RFC closes.
- IETF RFC 8949 — CBOR (referenced for compact view-root encoding).
- W3C JSON-LD 1.1 — for response-envelope serialisation.

---

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