Agora MVP Documentation
Pragmatic, minimum-viable spec for shipping a real truth market
MVP Core Loop
Keep it boring, testable, and real
Stake
Post claims with token stakes to put money where your mouth is
Vote
Witnesses cast votes with their own stakes on the line
Settle
Truth earns rewards, lies fail and cost money
Reputation
Accuracy builds long-term credibility and influence
1. Product Scope (MVP)
Goal
Demonstrate a closed-loop truth market with real interactions and transparent rules.
Non-goals (MVP)
No biometric onboarding yet. No public token sale. No "decentralized everything."
User Stories
👤 As a Claimant
I can post a claim with sources, lock a stake, and see status changes in real time.
👁️ As a Witness
I can be selected by the deterministic selector, review the claim & sources, cast a vote, and post an on-chain/off-chain attest.
🔍 As an Observer
I can verify the selection + tally from the same inputs and reproduce the result in-browser.
2. System Overview
Core components and data flows
Components
Web App (Next.js/React)
Claim submission, witness console, read-only explorer
Selector Service
Deterministic function: maps public seed → Conway's Game of Life → witness indices
Coordinator
Orchestrates claim lifecycle, assigns witnesses, records votes, applies settlement
State Store
PostgreSQL (app state) + optional public Merkle snapshots. Optional L2 testnet for anchoring
Data Flows
Claim Submission
Claimant submits claim + stake → Coordinator issues ClaimID and emits Seed
Witness Selection
Selector derives Witness Set for round from Seed (reproducible client-side)
Voting Process
Witnesses fetch claim, vote Yes/No/Abstain with rationale + evidence links
Settlement
Coordinator tallies, settles stakes, updates reputation, emits Receipt
Verification
Client can recompute selection + tally from Seed + Votes to verify
3. Deterministic Selection (Game of Life)
Fair, verifiable witness selection using Conway's Game of Life
Inputs
- seed: 256-bit hex (derived from: block hash or verifiable random source + timestamp + ClaimID)
- witness_list: ordered list of eligible witness public keys
Algorithm Steps
- Hash seed into N × N grid (e.g., 64×64) binary state
- Run Conway's Game of Life for G generations (e.g., 64)
- Concatenate final grid → bitstring → 16-bit chunks
- Map each chunk to witness index
- Deduplicate to get K unique witnesses (e.g., K=11)
Reproducibility
- Pure JS reference function with test vectors
- Identical outputs across all browsers
- Interactive demo available →
Grinding Resistance
- Seed commits at claim submission
- Derived from immutable block header + ClaimID
- Coordinator cannot manipulate selection
- All components publicly displayed
4. Claim Lifecycle & Economics
From submission to settlement
Draft
Claim created with sources
Staked
Claimant locks tokens
Witnessing
Selected witnesses vote
Resolved
True/False/Inconclusive
Settled
Stakes redistributed
Stakes
- Claimant posts S_c (e.g., 10 AGORA test tokens)
- Each selected Witness must post S_w (e.g., 1) to vote
- Abstain burns 10% (anti-sibyl/idle penalty)
Payouts (MVP, Simple)
- True: claimant receives S_c + pool_share
- False: claimant loses S_c to opposing votes
- Witnesses: aligned split opposing stake
- Inconclusive: partial refunds, small burn
- Fees: flat F per claim for operations
5. Reputation (v0.1)
Building trust through performance
Score
Elo-like update per resolved claim (K-factor small to avoid thrash)
Decay
Soft decay per week to reward recent performance
Displays
Show confidence bands; hide leaderboard until N≥20
6. Trust & Verification
Transparency by design
Verification Methods
- Publish test vectors for selection and tally
- Provide a one-click Recompute in UI that runs the same selector in-browser and shows diffs
- Anchor daily Merkle root of all claims to a public chain (optional)
Transparency by Design: Every step of the process is verifiable by independent observers.
7. Data Interfaces
API and data structures
Claim Structure
{
ClaimID: string,
content: string (280–2,000 chars),
sources: url[],
stake_claimant: integer,
seed: hex-256,
state: enum,
created_at, resolved_at,
receipt_hash: hex (post-settlement)
}Vote Structure
{
VoteID, ClaimID, WitnessPubKey,
choice: enum {YES, NO, ABSTAIN},
rationale: string (<= 500 chars),
stake_witness: integer,
signature: hex
}8. Security & Abuse (MVP)
Protecting platform integrity
Security Measures
- Rate limiting per account + IP
- Invite-only codes; max 1 active claim per new account
- Evidence links checked against malware/NSFW blocklists
- Logging with redaction; PII avoided at this stage
9. Deployment
Technical infrastructure
Deployment Plan
- Docker compose: web, coordinator, selector, db
- Staging URL with basic auth
- Public demo video recorded from staging
10. Success Criteria (MVP)
Measurable goals for launch
End-to-End Testing
End-to-end claim resolved with ≥11 witnesses in <24h on staging
Reproducible Results
Independent user can reproduce selection & tally in-browser
Public Documentation
Post a public "How We Verified This Claim" example with inputs/outputs
11. Open Questions
Areas for future research
Research Areas
- Optimal K (witness count) vs. latency
- Better seed source (e.g., drand) and anti-grinding upgrades
- Appeal/arbitration flow without killing simplicity
Next Steps
Implementation roadmap
Implementation Plan
This MVP specification will be implemented in stages, starting with the core claim lifecycle and deterministic witness selection. Each component will be thoroughly tested before moving to the next.
Related Documentation
Verification & Privacy
Privacy-first human verification approach
Token & Governance
Economic model and governance structure
Technical Whitepaper
Complete technical specification