# Research 06 -- GitHub & Developer-Community Prior Art for Veritas v0.2

**Scope**: Verify and evaluate open-source repositories and developer-community discussions relevant to the v0.2 target designs: (a) hybrid chain + federation; (b) CPML (consensus profile markup); (c) consensus quiz MVP; (d) investigation market.
**Method**: ~35 WebSearch queries + direct repo/docs fetches. All stars, licenses, and languages verified against repo pages as of 2026-04-20.
**Audience**: engineers choosing what to fork, what to borrow, and what to avoid.

---

## Executive summary

The good news: nearly every primitive Veritas needs already exists as battle-tested open source. There is no need to invent a transparency log (use Rekor / SCITT), a labelling event schema (NIP-32, ATProto labels), a federated moderation UI (Ozone), a bridging-based consensus ranker (Community Notes), a deliberation engine (Polis), an optimistic-oracle-for-claims (UMA OOv3, Reality.eth), a juried-dispute resolver (Kleros), an onchain-attestation registry (EAS), or a grounding/eval library (RAGAS, TruLens, Vectara HHEM).

The bad news: every one of these systems has scar tissue that Veritas needs to learn from. Ozone has well-documented operational pain at Bluesky scale (cursor-skip incidents, labeller restart bugs, firehose cost). UMA's Polymarket oracle was captured by whale voters on the $237M Zelenskyy-suit market and again on a UFO market, producing wrong-answer resolutions even when public evidence was unambiguous. Pol.is stalled after vTaiwan's celebrated 2015-2019 run and the codebase has had limited maintenance velocity. Community Notes' bridging algorithm is mathematically elegant but has known cold-start and polarization failure modes. Snapchain's 10k TPS comes with a 200GB snapshot and a non-trivial hub-operator barrier.

For Veritas, this means: **reuse aggressively at the primitive layer, resist reuse at the governance layer**. Wire Rekor-style transparency + EAS-style attestations + NIP-32-style labels into the Veritas chain+federation; but design the investigation market with explicit defenses against the UMA-whale capture pattern, and design CPML with awareness of how Community Notes diverges in the long tail.

---

## 1. AT Protocol / Ozone -- federated labellers

**Repos**:
- `bluesky-social/ozone` -- https://github.com/bluesky-social/ozone -- TypeScript 99.6%, dual MIT/Apache-2.0, ~513 stars, ~86 forks, 15 releases, v0.1.104 April 2026, 667 commits on main.
- `bluesky-social/atproto` -- https://github.com/bluesky-social/atproto -- TypeScript, MIT.

**What it is**: Ozone is Bluesky's open-source moderation/labeller service. A labeller attaches *labels* (small typed JSON tags) to accounts, posts, lists, or feeds. Clients declare which labellers they trust in request headers, and the AppView attaches the relevant labels to responses. This is exactly the "multiple overlapping attestations, composed client-side" pattern Veritas wants for CPML.

**Architecture**:
- Labeller = HTTP service + Ozone UI (Next.js) for a moderator team.
- Labels flow over the atproto firehose as an event stream; AppViews subscribe via cursor.
- Each labeller signs its labels; clients verify the signature chain back to the labeller's declared identity.
- "Stackable moderation": the end user picks labellers, their client combines the outputs. [Bluesky stackable moderation HN thread (39684027)](https://news.ycombinator.com/item?id=39684027).

**Production lessons (from GitHub discussions)**:
- [atproto discussion #3915](https://github.com/bluesky-social/atproto/discussions/3915): when a labeller restarts, AppView can skip labels in the cursor gap. "When Bluesky reconnected without a cursor, it skipped labels that should have been applied during the downtime."
- [discussion #3317](https://github.com/bluesky-social/atproto/discussions/3317): community feedback that "the abstraction of a labeler might have made sense for Bluesky internally, but releasing it publicly as-is feels rushed and not fitting to capabilities and assumed responsibilities of community moderation accounts." Proposal: distinct `moderation account` type.
- Bluesky's own moderation labeller has privileged firehose access. Third-party labellers must rate-limit, which makes "automated labeling at full-firehose scale across all locales" hard for outside teams.
- Developer experience complaint consistently raised: "ingesting labels is pretty bad right now" -- SDK is thin, reconnection logic is client-code.

**What Veritas can reuse**:
1. The `labeller -> label event -> signed payload -> client-side composition` flow maps 1:1 onto Veritas attestation composition for CPML.
2. The Ozone UI (moderator queue + takedown workflow) is a near-drop-in for the investigation-market commissioner's UI: swap "takedown" for "publish verdict", swap "report" for "commission".
3. The firehose + cursor pattern is a solved federation-read problem; mirror it instead of reinventing.

**What to avoid**:
- Cursor-based event streams silently drop labels on operator error; Veritas must require `verified_at` timestamps on every label and a periodic Merkle-root checkpoint so clients can detect gaps.
- Do not replicate Bluesky's "moderation labeller" special-casing; design a uniform labeller API from day one.

**Verdict**: **ADOPT** the labeller model for Veritas v0.2 CPML composition. **TRIAL** Ozone as the investigation-market UI (likely forkable).

---

## 2. Nostr -- NIP-32 / NIP-56 / NIP-51

**Repo**: `nostr-protocol/nips` -- https://github.com/nostr-protocol/nips -- public spec repo, multiple implementations.
**Relevant NIPs**: [NIP-32 Labelling](https://nips.nostr.com/32) (kind:1985), [NIP-56 Reporting](https://nips.nostr.com/56), [NIP-51 Lists](https://nips.nostr.com/51).

**NIP-32 (the directly analogous primitive)**:
- Event `kind: 1985`.
- Two indexable tags: `L` = namespace, `l` = label value within that namespace.
- Targets via standard Nostr tags: `e` (event), `p` (pubkey), `a` (addressable), `r` (relay), `t` (topic).
- Publishers encouraged to use ISO standards or reverse-domain (`com.example.ontology`) for namespaces.
- Special namespace `ugc` = user-generated content labels.

This is essentially Veritas's attestation envelope minus the transparency log. The `L`/`l` namespace-plus-value shape is a very clean pattern for multi-vocabulary attestations (e.g. `L=org.veritas.epistemic`, `l=grounded`; or `L=iso-3166`, `l=UA`).

**NIP-56**: reports reuse `L`/`l` from NIP-32, so "this is a report of type X" and "this is a label of type X" share structure. Veritas's "investigation commission" + "investigation result" pair map cleanly.

**NIP-51**: generic list events. Useful for user-owned allowlists/denylists of labellers -- which is exactly what CPML needs for "which validators do I trust."

**Community note**: NIP-32 was added via [PR #532](https://github.com/nostr-protocol/nips/pull/532) after debate about whether to extend NIP-56 instead -- the final design chose separation (labels != reports) and this has held up. Useful precedent: Veritas should separate the *attestation* primitive from the *report* primitive even when they share structure.

**What Veritas can reuse**:
- The `L`/`l` double-tag scheme is strictly better than a flat label string; adopt it.
- Reverse-DNS namespacing convention.
- Separation of report vs. label (NIP-56 vs. NIP-32) as an architectural guide.

**Verdict**: **ADOPT** NIP-32 tag shape as the CPML attestation envelope.

---

## 3. Farcaster / Snapchain -- federated hub model

**Repos**:
- `farcasterxyz/hub-monorepo` -- https://github.com/farcasterxyz/hub-monorepo -- TypeScript 91.7%, Rust 8.1%, MIT, 830 stars.
- `farcasterxyz/snapchain` -- https://github.com/farcasterxyz/snapchain -- Rust, MIT. The canonical replacement for Hubble.

**What it is**: Hubble was the original Farcaster hub (TypeScript CRDT replication over gRPC). Snapchain (Rust, launched April 2025) replaced it with a Tendermint-fork consensus (Malachite) producing ordered blocks at **10,000+ TPS, 780ms finality at 100 validators**. This is genuinely world-class throughput for a social-graph layer.

**Federation model**:
- Hubs/Snapchain nodes form a validator set.
- Client applications read from any node; trust assumption is that the set as a whole is honest.
- Messages are content-addressed and signed by user FIDs.

**Lessons developers have reported**:
- [BlockEden 2025 retrospective](https://blockeden.xyz/blog/2025/10/28/farcaster-in-2025-the-protocol-paradox/): Farcaster's original 2022 projection was that annual hub-operator cost would reach **$575,000 in 2026 and $6.9M in 2027** at 5% weekly user growth. The Snapchain rewrite was largely driven by this cost curve; TypeScript + CRDT replication didn't scale linearly.
- Snapchain's **200GB snapshot** and 2-4h sync times are "manageable but non-trivial barriers to independent hub operation." In practice most Farcaster infrastructure is operated by Merkle + a handful of partners; this is federation in theory, oligarchy in practice.
- Rust rewrite reliably outperformed TypeScript 10-50x on indexing/replication-heavy workloads. Bluesky independently hit the same wall and shipped a Rust indexer (Wintermute) for 10k+ records/sec vs sequential TS consumers.

**What Veritas can reuse**:
- The *shape* of hub federation (any client can read from any node, signatures guarantee authenticity) is exactly the Veritas federated-read model.
- Lesson: the control-plane ordering layer (chain) should be small and fast; the data-plane replication should be a separate Rust-class service. Don't try to put attestations on the ordering layer.

**What to avoid**:
- Do not build replication in TypeScript. Bluesky and Farcaster independently converged on Rust for the indexer.
- Do not assume 200GB-snapshot-and-sync is acceptable for validator onboarding; Veritas should target a <10GB bootstrap.

**Verdict**: **ADOPT** the hub federation *architecture*, **HOLD** on the Snapchain-specific tooling until post-MVP.

---

## 4. Lens Protocol -- L2-settled social graph

**Repo**: `lens-protocol/core` -- https://github.com/lens-protocol/core -- Solidity, dual MIT/GPL.

**What it is**: Lens V1 ran on Polygon, V2 on Arbitrum, V3 (2025-2026) migrated to a *dedicated L2* on ZK Stack with Avail DA. Core primitive: an onchain social graph (profile NFTs, follow NFTs, post/comment NFTs) with off-chain metadata over IPFS/Arweave.

**Relevance**: closest existing analog to Veritas's "L2 smart contracts + federated off-chain data" split. Lens has demonstrated that the pattern works at scale (~hundreds of thousands of profiles, millions of interactions).

**Lessons**:
- [BlockEden 2026-01 analysis](https://blockeden.xyz/blog/2026/01/15/decentralized-socialfi-farcaster-lens-protocol-web3-social-graph/): Lens V3's migration from Polygon was prompted by gas costs on high-frequency writes. Veritas attestations are higher-volume than Lens posts; any L1 or general-purpose L2 is wrong. Need a purpose-built rollup or a private rollup with permissionless read.
- Off-chain metadata over IPFS has *data availability risk*; many Lens-era IPFS CIDs are now unreachable because no one pinned them. Veritas must assume federated mirroring (libp2p + explicit operator incentives), not IPFS.

**What Veritas can reuse**:
- Content-addressed off-chain data with onchain pointers is the right data-plane pattern.
- Lens's permissioned-write / permissionless-read split maps to Veritas validator vs. client.

**Verdict**: **ASSESS** -- good case study, not a fork target. Lens's contracts are too tied to NFT semantics.

---

## 5. Sigstore / Rekor / Fulcio -- transparency-log + short-lived credential

**Repos**:
- `sigstore/rekor` -- https://github.com/sigstore/rekor -- Go 92.7%, Apache-2.0, 1.1k stars. V1 maintenance; **V2 active dev uses tile-based log via Trillian-Tessera**, borrowed from Certificate Transparency.
- `sigstore/fulcio` -- https://github.com/sigstore/fulcio -- Go, Apache-2.0, certificate authority issuing **short-lived** code-signing certificates bound to OIDC identity.
- `sigstore/cosign` -- Go, Apache-2.0, client.

**Why this matters for Veritas**: the Sigstore trio is the single closest architectural analog to the Veritas validator credential + attestation model. Specifically:
- **Fulcio** = short-lived cert bound to OIDC identity. No revocation problem because certs are valid for minutes. Matches Veritas's desired "validator proves identity once per session, signs attestations during session window."
- **Rekor** = append-only transparency log. Anyone can audit "was this signature made while the cert was valid?" without trusting a central party.
- The trust root is managed via **TUF** (The Update Framework), a well-studied multi-sig rotating root-of-trust.

**Lessons from production**:
- Rekor V1 backed by Trillian. V2 is re-architecting around tile-based logs because Trillian's **operational cost and backup size** scaled poorly past ~100M entries. Veritas attestation volume will be higher than Sigstore signature volume; **start with tile-based logs (Tessera or SCITT's emerging patterns) rather than general Merkle trees.**
- Sigstore public instance has 99.5% availability SLA and a 100KB attestation cap. Useful baseline numbers for Veritas's own service targets.
- [Sigstore privacy blog post](https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0/): OIDC email in the cert is publicly visible in Rekor. Privacy lesson: Veritas should never embed user identity in the log envelope; use rotating pseudonymous validator keys anchored to an EAS attestation.

**What Veritas can reuse**:
1. **Tile-based transparency log.** Don't roll your own Merkle tree. Either fork Trillian-Tessera or wait 3-6 months and fork the IETF SCITT reference implementation.
2. **Short-lived credential pattern.** Validator gets a 24h cert at login; attestations are valid if signed during the cert's window; no revocation list needed.
3. **TUF-style rotating trust root.** For the Veritas root keys.

**Verdict**: **ADOPT** -- this is the strongest reuse story in the whole research set.

---

## 6. SCITT (IETF) -- supply-chain transparency, directly generalizable

**Repos**:
- `ietf-wg-scitt/draft-ietf-scitt-architecture` -- https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture -- IETF draft, 1,268 commits, latest draft-11 March 2025.
- `ietf-wg-scitt/draft-ietf-scitt-scrapi` -- REST API draft.
- `ietf-scitt/` org -- reference implementations, COSE Merkle Tree Proofs prototype.

**What SCITT is**: IETF's generalization of "transparency service" beyond software supply chain. Core primitives:
- **Signed Statement** = `COSE_Sign1` (CBOR-encoded signed blob).
- **Transparent Statement** = Signed Statement + receipt from a Transparency Service.
- **Transparency Service** = the log + verification API.

SCITT is deliberately domain-agnostic. An "issuer makes a signed statement about a subject, a log records it, a verifier checks both" is *exactly* Veritas's "validator issues an attestation about a claim, Veritas chain records it, a client composes a verdict."

**Status**: Draft stage but mature. Microsoft, IBM, Dell, CNCF all have early implementations in the `ietf-scitt` org.

**Lessons**:
- [Issue #46 (Consolidate Log and Ledger)](https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/46): long thread on whether the transparency log can also be the ledger. Resolution: *no, separate them*. Ledger is ordering, log is auditability. Veritas should not collapse these.
- [Issue #69 (URLs for Transparent Statements)](https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/69): practical guidance on content-addressed vs. URL-addressed statements. Veritas should content-address.
- COSE over JSON: CBOR is faster and smaller for signed payloads. Veritas attestations should be COSE_Sign1, not JWS/JWT.

**What Veritas can reuse**:
- Directly fork SCITT data-model for attestations and receipts. Match their CDDL definitions (`signed_statement.cddl`, `transparent_statement.cddl`) so that any SCITT tooling works on Veritas data unmodified.
- Adopt the SCITT verifier's policy engine pattern (per-domain verification policies).

**Verdict**: **ADOPT** as the canonical data-model for Veritas attestations. Align the wire format with SCITT so the IETF ecosystem can inspect Veritas logs.

---

## 7. OpenFactCheck / FEVER / MultiFC / Vectara HHEM -- grounding benchmarks

**Repos**:
- `mbzuai-nlp/OpenFactCheck` / `yuxiaw/OpenFactCheck` -- https://github.com/mbzuai-nlp/OpenFactCheck -- Python, open-source unified factuality evaluation framework. Ships with **FactQA** (6,480 examples from seven datasets covering 482 domains and three error types) and **FactBench** (aggregating FactOOLQA, FELmWK, FactCheckBench, HaluEval).
- `awslabs/fever`, `sheffieldnlp/naacl2018-fever` -- FEVER dataset (185,441 claims from Wikipedia). The canonical academic fact-verification baseline.
- `vectara/hallucination-leaderboard` -- https://github.com/vectara/hallucination-leaderboard -- Python, Apache-2.0, **3.2k stars**. Summarization-hallucination benchmark. Uses HHEM-2.3 classifier. 7,700-article unpublished dataset.
- `Cartus/Automated-Fact-Checking-Resources` -- curated links to publications.

**Vectara leaderboard current state (2026-04-20)**:

| Model | Hallucination Rate |
|-------|-------------------|
| Antgroup Finix S1 32B | 1.8% |
| GPT-5.4-nano | 3.1% |
| Gemini 2.5 Flash Lite | 3.3% |
| Gemini 2.5 Pro | 7.0% |
| Claude Sonnet 4 | 10.3% |

Claude's relatively-high hallucination rate on this specific summarization benchmark is worth noting -- Veritas shouldn't default to a single model for grounding checks.

**Community critiques** (from the leaderboard's own FAQ + Vectara's [HHEM 2.1 blog](https://www.vectara.com/blog/hhem-2-1-a-better-hallucination-detection-model)):
- Benchmark only tests *summarization-level* faithfulness, not general factuality.
- Dataset is unpublished to prevent overfitting -- but this means independent verification is impossible.
- HHEM is binary; real hallucination is continuous.

**What Veritas can reuse**:
- **OpenFactCheck + FactBench** as the evaluation harness for any "AI-grounding measurement" rollup inside CPML. It's the best-maintained unified harness we have.
- **FEVER** as the ground-truth dataset for Veritas's first "grounding" validator training if we ever train our own classifier.
- **HHEM-2.1-Open** (on HuggingFace) as an easy summarization-faithfulness oracle for one of Veritas's built-in attestations.
- **RAGAS** / **TruLens** for the RAG-pipeline evaluation inside the AI-grounding stack (https://github.com/truera/trulens -- Python, Apache-2.0).

**Verdict**: **ADOPT** OpenFactCheck + FEVER + HHEM as the initial grounding-measurement stack. **TRIAL** RAGAS/TruLens for production RAG evaluation.

---

## 8. CPML-analog: Solid / FOAF / 8values

**Solid project** (https://solidproject.org/, `solid/` + `solid-contrib/` + `inrupt/` GitHub orgs):
- Solid Pods = personal data stores. Tim Berners-Lee's decentralized-web project.
- As of October 2024, stewardship moved to the **Open Data Institute** (relevant: project remains alive but with reduced velocity; early enthusiasm has cooled).
- `inrupt/solid-react-sdk` -- TypeScript, MIT, the best-maintained client SDK.
- `openwallet-foundation-labs/solid-data-wallet` -- a React Native white-label Solid wallet.

**FOAF** (Friend-of-a-Friend ontology): the original 2000-era RDF vocabulary for personal-profile data. Properties: `foaf:name`, `foaf:knows`, etc. Solid uses FOAF in WebID Profile documents.

**8values** (https://github.com/8values/8values.github.io): pure JS political quiz with four axes (Economic, Diplomatic, Civil, Societal), each scored 0-100 on two opposing values (Equality vs Markets, Nation vs Globe, Liberty vs Authority, Tradition vs Progress). MIT-licensed. ~40 questions; scoring is a simple weighted-sum per axis. Minimal dependency footprint; entire quiz is one HTML file + one JS file.

Relatives on the same template: `9axes`, `10groups`, `SapplyValues`, `LeftValues`, `AltValues`, `PoliticalTests` -- a cluster of teenagers-and-political-nerds projects, same MIT license, same scoring pattern.

**Ethereum Attestation Service (EAS)** (https://github.com/ethereum-attestation-service/eas-contracts):
- Solidity, MIT. The generalized onchain attestation registry.
- `SchemaRegistry.sol` lets anyone register an attestation schema (e.g. "grounding quality = {score: uint8, sources: bytes32[]}").
- `EAS.sol` issues attestations against a schema.
- Resolver contracts allow payment-on-attestation and onchain validation.
- This is *already* a working "user can hold a portfolio of signed attestations" system. For Veritas, EAS's schema-registry pattern is directly reusable for CPML fields.

**What Veritas can reuse for CPML**:
1. **FOAF/Solid ontology patterns** for the identity layer of CPML -- user profile as content-addressed RDF, not a DB row.
2. **8values scoring template** for the Consensus Quiz MVP. Literally fork `8values.github.io`, swap in Veritas's 10 questions, change the axes. 2-3 days of frontend work.
3. **EAS schema registry** for CPML field definitions -- each CPML component is an attestation schema, each validator's output is an attestation. CPML becomes "the bundle of EAS attestations a user trusts/signs."

**Verdict**:
- **ADOPT** EAS as the CPML attestation registry -- this is the single highest-leverage reuse for v0.2.
- **ADOPT** 8values as the quiz MVP UI template.
- **ASSESS** Solid -- correct philosophy, questionable velocity; fork the SDK pieces you need, don't commit to the ecosystem.

---

## 9. Pol.is -- deliberation / consensus finding

**Repo**: `compdemocracy/polis` -- https://github.com/compdemocracy/polis -- **AGPLv3 (with section-7 exception)**, 1.2k stars, 251 forks. Multi-language: JavaScript 26%, Python 23%, TypeScript 22%, Jupyter 19%, Clojure 4%.

**What it is**: the open-source wiki-survey tool used by [vTaiwan](https://compdemocracy.org/case-studies/2014-vtaiwan/) to pass legislation on Uber, Airbnb, alcohol sales, and other contested policy. Key design choice: **no reply threading**. Users post comments and agree/disagree/pass on others' comments. PCA clustering groups participants, surfaces consensus comments across clusters.

**Architecture**:
- Server (Node), math-service (Python + Jupyter notebooks), client (JS/TS), Delphi module, PostgreSQL. Docker Compose for dev.
- The clustering algorithm is in the **math-service** as Python. Uses PCA + k-means. Full methodology in ["Polis: Scaling Deliberation by Mapping High Dimensional Opinion Spaces"](https://compdemocracy.org).

**Lessons (community)**:
- vTaiwan's peak was 2015-2019. The platform still runs but velocity dropped after Audrey Tang's administration transition. [Democracy-Technologies retrospective](https://democracy-technologies.org/participation/consensus-building-in-taiwan/).
- Pol.is scales to ~thousands of participants per conversation; harder beyond that (computational, facilitation).
- **AGPLv3 is a significant licensing constraint**: any Veritas deployment embedding Pol.is code must open-source the embedding.
- The "no replies" design is universally praised by practitioners and is almost certainly right for Veritas's opposite-view-surfacing feature.

**What Veritas can reuse**:
1. The **math-service clustering** (Python, PCA + k-means on agree/disagree matrices) for CPML's "community matching" feature. It's the right algorithm for the right problem.
2. The **"no replies" UX pattern** for Veritas's opposite-view surfacing.
3. The **consensus-comment surfacing** algorithm ("comments that bridge clusters") -- this is the same bridging idea Community Notes uses, but older and simpler.

**What to avoid**:
- Do not fork the whole Polis server -- AGPLv3 viral license is bad for Veritas's open-ecosystem goals.
- Extract just the math-service clustering under a clean-room rewrite (AGPLv3 covers the code, not the algorithm). Cite [Small, Bjorkegren, Erkkilä, Shaw, Megill 2021].

**Verdict**: **ASSESS** -- excellent algorithm, hard license. Port the math to a clean-room implementation.

---

## 10. Prediction-market / investigation market -- Kleros, UMA, Reality.eth

**Kleros** (https://github.com/kleros + https://github.com/kleros/kleros-v2):
- V1 live on Ethereum mainnet since 2018, 1000+ cases, 760+ active jurors, 23 courts. V2 repo: **80 stars** (the community activity is elsewhere -- V1 contracts + docs), TypeScript 83% + Solidity 16%, MIT.
- Jurors self-select into subcourts, stake PNK, are drawn proportional to stake. ERC-792 (arbitrator) + ERC-1497 (evidence) standards.
- Fees: arbitration fee paid by the losing party; jurors paid from fee pool.
- Appeal mechanism with escalating deposits -- expensive to appeal frivolously.

**UMA Optimistic Oracle V3** (https://github.com/UMAprotocol/protocol):
- Solidity 19%, JS/TS 80%, AGPL-3.0, 462 stars. Dispute arbitration via DVM (token-holder vote, 48-96h window).
- Polymarket's resolution oracle.
- `UMAprotocol/dev-quickstart-oov3` is the integration template -- small, readable, forkable.

**Reality.eth** (https://reality.eth.limo/, RealityETH/monorepo):
- Crowd-sourced optimistic answer mechanism. Answer posted with bond, challengers can post counter-answers with higher bonds. Unchallenged answers finalize; disputed answers escalate to an *arbitrator contract* (can be Kleros, DAO, individual).
- Clean separation: Reality.eth is the escalation game, Kleros is the final arbiter. This is a much cleaner composition than UMA's all-in-one DVM.

**Major production lessons -- Polymarket/UMA oracle disputes**:
1. **$237M Zelenskyy-suit market (June 2025)**: Zelenskyy wore what was visually a black suit-like outfit at NATO. UMA oracle resolved "No" citing "lack of credible reporting consensus." Market had **$242M volume**; UMA token market cap was **$95M**. Top-10 UMA holders controlled ~30% of typical voter turnout. [CoinDesk analysis](https://www.coindesk.com/markets/2025/07/07/polymarket-embroiled-in-usd160m-controversy-over-whether-zelensky-wore-a-suit-at-nato). The oracle can be cheaper to capture than the market it resolves.
2. **Ukraine mineral-deal market (2025)**: UMA whale "tycoon" manipulated oracle vote, falsely settled market, ~$7M loss. Polymarket publicly confirmed UMA reached the wrong outcome. [Orochi Network post-mortem](https://orochi.network/blog/oracle-manipulation-in-polymarket-2025).
3. **UFO market (2025)**: whales forced "YES" vote "without evidence." [Cryptoslate coverage](https://cryptoslate.com/polymarket-faces-major-credibility-crisis-after-whales-forced-a-yes-ufo-vote-without-evidence/).
4. **UMA's response**: moved Polymarket to "Managed Optimistic Oracle V2" with a whitelist of 37 proposer addresses. This centralizes the layer UMA was trying to decentralize.

**Implications for Veritas's investigation market**:
- **Oracle token economics must have market cap at least 10x the resolution stake** -- ideally with stake locked for multi-month windows so short-term capture attempts lose money. UMA's 1x ratio was the root cause.
- **Do not let commissioners and resolvers be the same entity class**. UMA voters were also bet-holders with direct financial incentive. The Nash equilibrium of honest voting breaks instantly.
- **Prefer Reality.eth's composition pattern**: optimistic answer + escalation + *separate* arbiter contract. Don't collapse all three roles.
- **Whitelisted professional proposers is not a failure mode -- it's a plausible equilibrium.** Veritas's validators are already intended to be professional; don't pretend "anyone can propose" when the reality is "only professionals can."

**What Veritas can reuse**:
1. **Kleros's ERC-792/ERC-1497** as the arbitrator-interface standard between Veritas investigation market and external arbiters. Don't invent a new interface.
2. **Reality.eth's escalation game** as the optimistic layer -- bonds + liveness period + arbiter fallback. Well-documented.
3. **UMA's `dev-quickstart-oov3`** as a reference for how to integrate an optimistic oracle into your own contract (even if you don't use UMA itself).

**What to avoid**:
- Monolithic all-in-one dispute resolution (UMA DVM pattern). Layer the game.
- Token-weighted voting by the resolution token. Use reputation-weighted voting or time-locked staking.

**Verdict**:
- **ADOPT** Reality.eth's escalation composition pattern.
- **TRIAL** Kleros as the arbiter-of-last-resort for Veritas investigations.
- **HOLD** on UMA OOv3 -- well-engineered contracts but broken economics.

---

## 11. Community Notes -- bridging-based ranking

**Repo**: `twitter/communitynotes` -- https://github.com/twitter/communitynotes -- Python 89% + Jupyter 11%, Apache-2.0, **1.8k stars**. All notes, ratings, and contributor data are released daily.

**Algorithm**: matrix factorization on the `(rater, note) -> rating` matrix. Each rater and each note gets a learned *factor* (approximate ideological position) and an *intercept* (baseline helpfulness). The **intercept**, not the raw score, is what ranks notes -- a note earns status "Helpful" only if raters across the factor-space (i.e. across ideological clusters) rate it helpfully. This is the formal "bridging" mechanic.

**Open-source status**: algorithm is genuinely open. The repo maintainers warn "we're unlikely to merge minor documentation/typo cleanup" because of heavyweight deployment, but the code is real production code.

**Known failure modes** (per [Jonathan Warden's analysis](https://jonathanwarden.com/understanding-community-notes/) and [HN thread 38939660](https://news.ycombinator.com/item?id=38939660)):
- **Cold start**: new notes on new topics often stall at "Needs More Ratings" indefinitely.
- **Polarization escape**: when a topic's raters are nearly entirely one-cluster, any note gets a uniform rating and no bridging signal is measurable.
- **Attack detection is statistical, not certain**: raters attempting coordinated attacks get classified via the polarization factor; this is robust in the mean but porous at the tail.
- **Slow**: notes typically take hours to days to reach Helpful status -- too slow for breaking-news misinformation.
- **Gaming via polarization-baiting**: attackers can intentionally write notes that get cross-cluster agreement by being true-but-misleading.

**What Veritas can reuse**:
- The bridging matrix-factorization algorithm is the right primitive for "which CPML attestations have cross-cluster consensus." Fork the `scoring/src` folder.
- The decision to open-source the algorithm (and data) is a strong reputation play for Veritas -- do the same.

**What to improve over Community Notes**:
- Bridging only *detects* consensus; it doesn't *investigate* contested claims. That's exactly where Veritas's investigation market complements CPML.
- Combine bridging (cheap, continuous, low-recall) with investigation market (expensive, episodic, high-confidence) in a two-tier system.

**Verdict**: **ADOPT** bridging for the cheap-continuous tier of Veritas consensus measurement.

---

## 12. Grounding libraries / RAG / MCP fact-checking servers

**Production-grade eval libraries**:
- `truera/trulens` -- Python, Apache-2.0. The RAG Triad: context relevance, groundedness, answer relevance. Best documentation in class.
- RAGAS (via community) -- Python, reference-free metrics.
- LangChain + LlamaIndex -- both integrate RAG but in 2026 community sentiment has shifted to **"frameworks are being displaced by MCPs and agent SDKs"** ([dev.to 2026 retrospective](https://dev.to/lycore/langchain-vs-llamaindex-in-2026-what-we-actually-use-and-why-52eb), [MindStudio blog](https://www.mindstudio.ai/blog/llm-frameworks-replaced-by-agent-sdks)). The winning pattern is LlamaIndex for ingest/retrieval + LangGraph for orchestration, with MCP as the integration layer.

**Fact-checking MCP servers (all small, all early)**:
- `devshark/fact-checker-mcp` -- Wikidata verification.
- `carlisia/mcp-factcheck` -- validates claims against MCP spec (niche).
- `adityapawar327/news-factchecker-mcp` -- Python + Gemini + web search, confidence scores.
- `ag2-mcp-servers/fact-check-tools-api` -- auto-generated MCP wrapper for Google's Fact Check Tools API.

**Veritas MCP adapter design guidance (from these precedents)**:
- Return structured verdict objects (claim, verdict, confidence, sources) not free text. All existing fact-check MCPs converge on this.
- Expose a single `verify(claim) -> verdict` tool; don't overload.
- Cite sources with URLs so the caller can display provenance -- this is non-optional.

**Verdict**: **TRIAL** TruLens for Veritas's own RAG evaluation. Build a Veritas MCP adapter with the structured-verdict shape used by the existing fact-check MCPs.

---

## 13. libp2p / GossipSub -- p2p gossip for the federation layer

**Repo**: `libp2p/specs` + `libp2p/go-libp2p-pubsub` + Rust/Elixir/Python bindings.

**Status**: production in Filecoin, Ethereum (consensus layer), IPFS. Peer-scoring + mesh management is well-tested. Covert Flash Attack tests (reputation-building then coordinated eclipse) are part of the standard adversarial test suite.

**What Veritas needs to know**:
- Use **gossipsub v1.1** (peer-scoring) not v1.0.
- Set **D_out** (outbound-only peer quota) to prevent full inbound takeover. This is a configuration choice, easy to miss.
- Use **opportunistic grafting** to recover from eclipse attempts.
- Per-topic scoring with pluggable application-specific score.

**What Veritas should reuse directly**:
- Use go-libp2p or rust-libp2p for the edge-cache gossip layer. Do not reinvent.
- Adopt the 200-line `peer_score_params` template from [the v1.1 spec](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md).

**Verdict**: **ADOPT** -- no credible alternative.

---

## 14. Ethereum Attestation Service (EAS) -- onchain attestation registry

Already referenced in section 8. Critical enough to call out explicitly:

`ethereum-attestation-service/eas-contracts` -- https://github.com/ethereum-attestation-service/eas-contracts -- Solidity, MIT. **This is the single most-reusable contract for Veritas's CPML.** Any Veritas CPML field is an EAS schema; any validator attestation is an EAS attestation against that schema; any CPML view is an index over EAS attestations. Deploy Veritas's EAS instance on the Veritas L2; every CPML primitive is one schema registration away.

---

## Community threads worth watching

1. **[bluesky-social/atproto discussions](https://github.com/bluesky-social/atproto/discussions)** -- the ATProto labeller community is the single richest source of operational experience for federated moderation. Specifically discussions #3317 (community moderation feedback), #3915 (cursor-skip incidents), and #3049 (call for developer projects).
2. **[IETF SCITT WG (ietf-wg-scitt org)](https://github.com/ietf-wg-scitt)** -- the architecture and scrapi drafts + issues. Join the WG mailing list. Veritas is *exactly* the kind of domain SCITT aims to generalize to.
3. **HN threads on Polymarket/UMA disputes** (July 2025) -- the [CoinDesk Zelenskyy-suit coverage](https://www.coindesk.com/markets/2025/07/07/polymarket-embroiled-in-usd160m-controversy-over-whether-zelensky-wore-a-suit-at-nato) and the [Orochi post-mortem](https://orochi.network/blog/oracle-manipulation-in-polymarket-2025) are required reading for any Veritas investigation-market designer.

---

## Pitfalls developers have publicly reported

1. **Token-weighted oracle governance is captured by the market it resolves when the resolution stake exceeds the token market cap** (UMA/Polymarket, 2025, multiple markets, tens of millions in wrong-answer resolutions). Fix: decouple resolver token from market token; enforce time-locks; cap per-market stake at a small fraction of oracle market cap.
2. **Cursor-based event replay in federated labellers silently drops data on operator restart** (ATProto/Ozone, March 2026, discussion #3915). Fix: Merkle-root checkpoints on every replay window; clients detect and repair gaps.
3. **Transparency logs on general-purpose Merkle trees (Trillian-style) scale poorly past ~100M entries** (Sigstore Rekor V1 -> V2 migration, 2025-2026). Fix: start with tile-based logs (Trillian-Tessera, SCITT reference) from day one.

---

## Top 8 repositories to fork or borrow from for Phase I

1. **`ethereum-attestation-service/eas-contracts`** -- CPML attestation registry. Highest-leverage single fork. https://github.com/ethereum-attestation-service/eas-contracts
2. **`sigstore/rekor` + Trillian-Tessera** -- transparency log for Veritas attestations. https://github.com/sigstore/rekor
3. **`ietf-wg-scitt/draft-ietf-scitt-architecture`** -- wire-format + data-model. Implement a SCITT-compliant Transparency Service so the IETF ecosystem can inspect Veritas. https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture
4. **`bluesky-social/ozone`** -- moderator/investigator UI. Fork as starting point for commissioner dashboard. https://github.com/bluesky-social/ozone
5. **`twitter/communitynotes`** (specifically `scoring/src`) -- bridging-based consensus scorer for the cheap continuous tier. https://github.com/twitter/communitynotes
6. **`compdemocracy/polis`** (math-service only, clean-room re-implementation) -- PCA + k-means for community matching. https://github.com/compdemocracy/polis
7. **`8values/8values.github.io`** -- quiz MVP UI template. 2-3 days to Veritas-branded quiz. https://github.com/8values/8values.github.io
8. **`mbzuai-nlp/OpenFactCheck` + `vectara/hallucination-leaderboard`** -- the grounding-measurement evaluation harness + HHEM classifier for the AI-grounding rollup inside CPML. https://github.com/mbzuai-nlp/OpenFactCheck and https://github.com/vectara/hallucination-leaderboard

---

## Verdict matrix

| System | Layer | Verdict |
|---|---|---|
| Ozone + ATProto labellers | Federation, labeller UI | ADOPT |
| NIP-32 tag shape | Attestation envelope | ADOPT |
| Farcaster Snapchain | Hub architecture | ADOPT (pattern), HOLD (tooling) |
| Lens Protocol | L2-settled social graph | ASSESS |
| Sigstore Rekor/Fulcio | Transparency log + short-lived creds | ADOPT |
| IETF SCITT | Wire format, data model | ADOPT |
| OpenFactCheck + HHEM + FEVER | Grounding eval | ADOPT |
| EAS | CPML attestation registry | ADOPT |
| Solid / FOAF | CPML identity / ontology | ASSESS |
| 8values | Quiz MVP UI | ADOPT (fork) |
| Pol.is | Community matching algo | ASSESS (clean-room port) |
| Community Notes bridging | Cheap consensus tier | ADOPT |
| Kleros (ERC-792) | Arbiter interface | TRIAL |
| Reality.eth | Escalation composition | ADOPT |
| UMA OOv3 | Monolithic optimistic oracle | HOLD |
| libp2p gossipsub v1.1 | P2P data-plane gossip | ADOPT |
| TruLens / RAGAS | RAG evaluation | TRIAL |
| Fact-check MCP servers (various) | Adapter shape template | TRIAL |

---

## References (selected)

- Bluesky stackable moderation -- https://bsky.social/about/blog/03-12-2024-stackable-moderation
- ATProto label query API -- https://docs.bsky.app/docs/api/com-atproto-label-query-labels
- ATProto labeller community discussion -- https://github.com/bluesky-social/atproto/discussions/3915
- NIP-32 spec -- https://nips.nostr.com/32 ; PR #532 -- https://github.com/nostr-protocol/nips/pull/532
- Sigstore security model -- https://docs.sigstore.dev/about/security/
- Sigstore privacy -- https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0/
- SCITT architecture draft -- https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/
- Polymarket/UMA Zelenskyy-suit controversy -- https://www.coindesk.com/markets/2025/07/07/polymarket-embroiled-in-usd160m-controversy-over-whether-zelensky-wore-a-suit-at-nato
- Orochi Polymarket post-mortem -- https://orochi.network/blog/oracle-manipulation-in-polymarket-2025
- Farcaster Snapchain retrospective -- https://blockeden.xyz/blog/2025/10/28/farcaster-in-2025-the-protocol-paradox/
- Farcaster vs Lens analysis -- https://blockeden.xyz/blog/2026/01/15/decentralized-socialfi-farcaster-lens-protocol-web3-social-graph/
- Community Notes bridging explainer -- https://jonathanwarden.com/understanding-community-notes/
- GossipSub v1.1 spec -- https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md
- GossipSub v1.1 evaluation -- https://blog.ipfs.io/gossipsubv1.1-eval-report-and-security-audit/
- Vectara HHEM blog -- https://www.vectara.com/blog/hhem-2-1-a-better-hallucination-detection-model
- TruLens RAG Triad -- https://www.trulens.org/getting_started/core_concepts/rag_triad/
- EAS docs -- https://docs.attest.org/
- vTaiwan case study -- https://compdemocracy.org/case-studies/2014-vtaiwan/