Decentralized truth-verification infrastructure
A public-good protocol for establishing verifiable consensus through cryptoeconomic guarantees
TruthBounty is a decentralized protocol for submitting evidence-backed claims, coordinating community verification, and resolving outcomes through transparent staking, reputation, settlement, reward, slashing, and dispute rules.
TruthBounty treats truth verification as public infrastructure. No backend operator, database administrator, or frontend application is permitted to independently create or finalize authoritative protocol outcomes.
The blockchain is the canonical single source of truth for all protocol state.
Smart contracts own:
- claim existence and lifecycle;
- verification votes and stake accounting;
- consensus and settlement outcomes;
- slashing, rewards, and treasury allocations;
- disputes and authoritative reputation commitments.
Off-chain systems index and present this state, but must not replace it.
- enforce the canonical protocol state machines and economic rules;
- emit versioned events for every authoritative transition;
- expose versioned ABIs and deployment-address manifests;
- use governance-controlled roles, parameters, pauses, and upgrades.
- consume finalized blockchain events;
- build deterministic PostgreSQL read models that are rebuildable from chain history;
- provide SIWE authentication, IPFS services, caching, search, notifications, analytics, and WebSocket updates;
- never independently create claims, votes, verdicts, settlements, rewards, or finalization state.
- connects supported EVM wallets through Wagmi/Viem;
- submits every state-changing action directly to canonical contracts;
- displays transaction submission, confirmation, indexing, and final UI state;
- consumes versioned ABIs, addresses, events, and indexed APIs.
All implementations must preserve the following rules:
- Claims originate on-chain through a user-signed transaction.
- Votes and stakes are recorded and enforced on-chain.
- Settlement is deterministic and cannot be overridden by the backend.
- No reward exists without verifiable protocol participation.
- Slashed value has an exhaustive, auditable accounting destination.
- Reputation influences protocol behavior only through an approved commitment and verification mechanism.
- Critical transitions emit sufficient events for deterministic reconstruction.
- Derived databases are disposable and rebuildable from finalized events plus explicitly non-authoritative metadata.
- Frontend and API integrations use the same versioned contract release.
- A PR that violates an invariant must be rejected or redesigned.
TruthBounty is split across four independently versioned repositories:
| Repository | Responsibility |
|---|---|
truthbounty-protocol |
Canonical specification, architecture, governance, invariants, audits, and cross-repository planning |
truthbounty-contract |
Smart contracts, tests, deployment modules, ABIs, events, and address manifests |
truthbounty-api |
SIWE, IPFS, indexing, PostgreSQL projections, cache, query APIs, notifications, and analytics |
truthbounty-frontend |
Wallet integration, direct contract interactions, transaction UX, and indexed read experiences |
See repos.md for the allowed dependency direction and detailed ownership boundaries.
- TruthBounty Protocol V2 Specification
- TruthBounty V2 Engineering Blueprint
- ADR-0001 — Canonical TruthBounty V2 Contract Topology
- TruthBounty V2 Audit Reconciliation
- Drips Stellar Wave Operations
- TruthBounty V2 Master Backlog
- TruthBounty V2 Issue Dependencies
- V2-EPIC-SC-001 — Canonical Contract Topology and Deployment
The proposed V2 specification, engineering blueprint, clean-slate master backlog, dependency graph, and first contract epic are available for maintainer review. All issue source files remain unactivated candidates until their governing documents, dependencies, scope, security requirements, tests, and complexity are approved. Existing GitHub issues are historical records only and are not part of the V2 execution backlog.
This repository owns documentation and cross-repository governance only. It must not contain:
- Solidity or application TypeScript;
- deployment scripts or runtime configuration;
- database schemas;
- implementation-specific tests;
- copied ABIs or environment-specific addresses.
Protocol-rule changes must be documented here before implementation repositories adopt them.
- Read the current protocol decisions, audit baseline, and Wave operations policy.
- Work only from a newly approved clean-slate V2 issue; existing repository issues must not be reopened, modified, relabelled, or activated for V2.
- Confirm that the new issue is not duplicated and that all upstream dependencies are satisfied.
- Identify the canonical contract release and governing protocol documents.
- Implement in the owning repository.
- Test protocol invariants, security controls, and integration behavior.
- Link the implementation PR to the new V2 issue and its governing documents.
Code existence alone does not satisfy an issue. Acceptance criteria, tests, integration, documentation, and protocol invariants must all pass.
- Optimism / EVM: canonical V2 execution and settlement environment.
- IPFS: content-addressed evidence and metadata storage.
- World ID: optional Sybil-resistance signal, subject to the protocol specification.
- Drips Stellar Wave: open-source contribution and funding programme only. Participation does not change TruthBounty's runtime architecture.
- Stellar / Soroban: not part of the TruthBounty V2 runtime, wallet stack, contracts, settlement, or deployment targets.
Report security-sensitive findings privately to the maintainers before public disclosure when exploitation could place users or funds at risk.
Protocol deployment is blocked until canonical contract composition, roles, treasury accounting, event schemas, and migration controls pass review.
MIT — open-source, forkable, and community-driven.
Truth is not free—but it should be worth defending.