# 02 — Hybrid Architecture: Chain as Settlement, Federation as Transport

> *The blockchain answers "how do strangers coordinate?" The federation answers "how do friends compose?" Veritas needs both. The architecture keeps them in the right roles.*

## Summary

The v0.2 architecture splits the system into three layers:

```
+---------------------------------------------------------------+
| PROTOCOL LAYER · permissionless, chain-anchored               |
|                                                               |
| - claim records (content-addressed)                           |
| - attestation records (signed per-domain verdicts)            |
| - validator credential declarations (self-issued or issued)   |
| - cascade events (retraction propagation triggers)            |
| - payment settlement (utility token burn / service fees)      |
| - small, specific hard-list of operationally-refused shapes   |
+---------------------------------------------------------------+
                 ↑ reconciliation on TTL + cascade signal
+---------------------------------------------------------------+
| FEDERATION LAYER · aggregators, caches, editorial policy      |
|                                                               |
| - indexes chain events                                        |
| - composes per-CPML views                                     |
| - applies editorial filters (own policy, not protocol policy) |
| - serves cached responses at edge for low-latency grounding   |
| - propagates cascade events via libp2p gossip                 |
| - country-scoped chapters handle jurisdictional filters       |
+---------------------------------------------------------------+
                 ↑ fast cached reads; local CPML application
+---------------------------------------------------------------+
| CONSUMER LAYER · clients, agents, AI systems                  |
|                                                               |
| - consumer picks aggregator(s)                                |
| - consumer holds a CPML (local; optionally shared)            |
| - AI grounding calls hit cached per-domain snapshots          |
| - payment flow closes back to chain on billing cycle          |
+---------------------------------------------------------------+
```

## Why this split is the right shape

**Blockchain's strongest property** is *coordination in the absence of a mutually-acceptable fiduciary*. For the **permissionless write layer** — where mutually-hostile frames publish signed verdicts without any foundation deciding who is allowed — that property is the exact tool. The chain is the neutral substrate that cannot be captured by the foundation, because the foundation doesn't run it.

**Federation's strongest property** is *fast, editorially-policy-rich composition of known actors*. For the **read, compose, cache, and serve layer** — where an AI-grounding call needs a response in tens of milliseconds and an aggregator wants to filter according to its own editorial standards — federation is the exact tool. Chain queries are too slow for the hot path; trustless reads don't match the use case (consumers pick aggregators they trust).

**Reconciliation between the layers** happens on two triggers:
- **TTL expiry** — cached snapshots refresh periodically from chain state.
- **Cascade signal** — high-severity events (retractions reaching a quorum) propagate immediately via gossip and invalidate dependent caches.

This pattern — chain settlement + off-chain execution + settlement-driven invalidation — is the same pattern Ethereum rollups and many DeFi systems use for the same reason: the chain is the truth of last resort; most operations don't need to touch it directly.

## What lives on the chain

1. **Claim records as content-addressed hashes.** The full claim text may be on-chain (cheap enough on L2) or only its hash, with text stored in content-addressed off-chain storage (IPFS, Arweave, or HTTPS-addressable).
2. **Attestation records as signed statements.** Signature binds validator DID to claim hash + domain + verdict.
3. **Validator credential declarations.** Any party can publish a self-issued credential; third-party endorsements (e.g., IFCN signatory attestations over a validator's identity) are themselves attestation records.
4. **Cascade events.** Signed retraction events with the dependent-claim list they target, quorum-attested.
5. **Economic flow.** Utility-token payments, treasury deposits, burn-for-USDT events, validator compensation distributions.
6. **Hard-list refusal markers.** The narrow operational-refusal list is itself a chain-published document, so consumers know what the substrate refuses to represent.

## What does *not* live on the chain

1. **Evidence artefacts.** Raw source files, PDFs, images, interviews. On-chain would be expensive, GDPR-hostile, and unnecessary. Stored off-chain, content-addressed, redundantly pinned.
2. **CPML files.** User-owned, local-first, shareable peer-to-peer. Never centralised on-chain.
3. **Aggregator editorial policies.** Published by each aggregator as their own document; referenced by chain only if the aggregator chooses to register.
4. **Country-chapter filter lists.** Chapter-local; published by the chapter; not protocol-imposed.
5. **Reputation graphs.** Computed by aggregators from chain data; cached and re-derivable. Reputation math is open-source and auditable, but not stored as chain state.
6. **Personal data in any form.** GDPR Art 17 hard incompatibility with immutable ledgers. Personal data never reaches the chain.

## What changes between v0.1 (federation-only) and v0.2 (hybrid)

| Aspect | v0.1 | v0.2 |
|---|---|---|
| Write layer | Federated, credentialed | Chain-anchored, permissionless |
| Validator credentialing | Foundation-issued only | Self-issued + third-party endorsed + foundation-issued; all first-class |
| Economic flow | Grant-funded stipends | Utility token with treasury buyback; multi-stream revenue |
| Cascade propagation | libp2p gossip | libp2p gossip + chain settlement of retraction events |
| Hostile frames | Tolerated if they meet foundation standard | First-class; write layer is permissionless |
| Foundation role | Editorial arbiter | Reference-aggregator operator (one of several) + hard-list steward |
| Time to ship | 12–18 months | 24–36 months |
| Infrastructure cost | ~US$500K/year | ~US$1–2M/year (chain + treasury ops + federation) |
| Regulatory exposure | Low (federation only) | Medium (token + treasury; jurisdiction choice matters) |

The v0.2 architecture is more expensive and slower to ship. The argument for paying the extra cost is that v0.1 does not actually deliver on the plural-verdict promise when frames include mutually-hostile actors; v0.2 does.

## Critical analysis

**1 — Are we just re-inventing Ethereum rollups?** Somewhat. The L2 settlement + fed-execution pattern is well-trodden in DeFi. The protocol-specific part is the schema of what's on-chain (attestations, cascades, validator credentials, not DeFi positions) and the consumer-side CPML composition layer. Borrowing the pattern is a feature, not a bug — it reduces invention.

**2 — Does the fast-read path ever need the chain?** In the hot path for AI grounding, no. The chain is slow; the cache is fast. This means *the chain's security properties don't protect grounding-time reads directly.* An aggregator-level compromise could serve wrong data even if the chain is correct. Response: aggregator responses must include cryptographic proofs (merkle proofs of chain state, validator signatures, etc.) that the client can verify. Verification is fast (sub-millisecond); fetch is cached; security is preserved.

**3 — Cascade propagation is dual-path. Does dual-path create inconsistency?** Yes, transiently. The gossip path reaches subscribed consumers in seconds; the chain settlement reaches block inclusion in minutes. In the window between the two, a consumer can see the cascade via gossip but chain-based verifiers haven't confirmed it. Response: cascade events carry both a signed gossip message and an expected chain confirmation window. Consumers can show `CASCADE_PENDING` immediately and upgrade to `CASCADE_CONFIRMED` after chain inclusion. No consistency is lost; the UX surfaces the state honestly.

**4 — Economic viability of the chain operations.** At ~$0.001 per attestation on a modern L2, a million attestations/year costs $1,000. A hundred million costs $100K. At scale, chain costs are real but not prohibitive. Validator compensation, foundation ops, and aggregator hosting dominate the budget. Chain cost is a rounding error on the full economic model.

**5 — Regulatory exposure from bridging tokens to fiat.** Treasury buyback of utility tokens is the regulatory pressure point (`03-tokenomics-design.md`). The hybrid architecture is no worse than any oracle network that settles payments on-chain, but it is worse than a pure federation that never touches tokens at all. Mitigation: token jurisdiction is a design choice made at Phase II (MiCA-registered EU entity is current leading candidate).

**6 — Two layers to audit instead of one.** Each architectural layer has its own audit surface: chain contracts + aggregator code + cache infrastructure + CPML resolver + client applications. Response: this is necessary work; the budget accounts for it.

## Related work (to be enriched by architect agent)

- **Ethereum rollup architectures (Optimism, Arbitrum, Base)** — optimistic + ZK rollup patterns.
- **AT Protocol labellers (Bluesky Ozone)** — permissionless-label + consumer-subscription pattern.
- **Nostr** — permissionless-event + relay-federation pattern.
- **Lens Protocol** — Arbitrum-settled social graph + off-chain read API.
- **Farcaster Hubs** — federated Merkle log.
- **Sigstore (Fulcio + Rekor)** — short-lived-credentials + transparency log, closely analogous to the validator-credential + attestation-log pattern.
- **Chainlink CCIP and Functions** — oracle work coordination with on-chain settlement and off-chain execution.

## Open questions

- Exact schema for chain-level events. Do we store claim text on-chain (cheap on L2, stable long-term) or only claim hashes (cheaper, requires off-chain resolution)?
- Fraud-proof window for optimistic-rollup choice. Seven-day fraud-proof period of Optimism / Arbitrum / Base vs shorter ZK rollup finality. Which fits Veritas's tolerance for cascade-settlement latency?
- Role of Celestia-style data-availability layers if attestation volume scales beyond EVM rollup comfort.
- Can third-party aggregators *fork* the chain state and operate their own view with different filter rules, or is there one canonical chain and aggregators diverge only at read/display time?

## What we'd build

- `veritas-contracts` — Solidity (or Move / Cairo) smart contracts for attestation registry, cascade log, validator credential registry, payment flow.
- `veritas-chain-deploy` — deployment tooling for Base / Optimism / Arbitrum.
- `veritas-aggregator` — indexes chain events, composes per-domain views, serves REST API.
- `veritas-cache` — edge-CDN materialised snapshots per consensus domain.
- `veritas-mcp-adapter` — surfaces aggregator as a Model Context Protocol server for AI agents.
- `veritas-proof-verifier` — client library that verifies cryptographic proofs (merkle + signature) against cached responses.