AMOY TESTNETUSDC • KLEROS • MULTI-AI ORACLESAD-FREE CONSTITUTION
·
Search articles, authors, CIDs…
Publish
← Grants

Polygraph funding constitution (DRAFT)

**Status:** DRAFT — pending legal review. Do not treat this document as binding until counsel and the governance multisig have ratified it. Some contact fields remain placeholders until the operator completes them.

Mission

**Truthful news. Zero propaganda.**

Polygraph exists to reverse the information economics that made lies cheap and verification expensive. The protocol makes multi-oracle verification fast and cheap on Polygon — with scores no operator can alter — and makes false claims expensive through staked credibility and challenge markets recorded on-chain.

Purpose

Polygraph accepts voluntary donations to sustain **credibility infrastructure**: objective, on-chain ratings of news articles, academic papers, social posts, blogs, and podcast transcripts. Donors fund security, oracle operation, and public-good tooling — **not editorial influence**.

Founder identity

  • **Operating entity:** The Lab Launchpad
  • **Individual legal name (if applicable):** `[INDIVIDUAL LEGAL NAME — TO BE COMPLETED]`
  • **Public contact:** `[PUBLIC CONTACT EMAIL — TO BE COMPLETED]`

    • Constitutional commitments (unchanged by donations)

    1. **No advertising revenue** in the protocol or flagship reader.

    2. **Operator non-manipulation** — no contract path to alter ATS/ACS, PPOR scores, verdicts, or delete publications.

    3. **AI as mirror, not gate** — low scores never block publication.

    Donations do not create exceptions to these rules.

    Economics

    Protocol revenue is **outcome-neutral**: fee rates never increase because a claim was debunked, never decrease because a claim was upheld, and never scale with ATS/ACS. Credibility scores and treasury economics are deliberately decoupled — otherwise the operator could be accused of profiting from “false” verdicts (`Truthful news. Zero propaganda.`).

    All protocol revenue flows to **The Lab Launchpad** treasury (the same governance Safe / timelock path as donations below). The developer stipend cap in this document is unchanged by these fees.

    ### Challenge fee (on-chain)

    When a challenge or Kleros dispute resolves, the **loser’s forfeited challenge stake** is split between the winner and the protocol:

  • **Winner** receives the challenger's forfeited stake **minus** the protocol fee (e.g. **95%** at default 500 bps when the challenge is rejected; challenger stake refund **minus** the same fee when upheld), plus bond slash / defense-stake transfers as already coded.
  • **Protocol treasury** receives **exactly** **`protocolFeeBps`** of the **challenge stake** (default **500 = 5%**) on **both** upheld and rejected resolutions — no additional treasury rake on a “failed” challenge. Implemented in `FactCheckEngine`; transferred to the immutable treasury address configured at deploy.
  • **`protocolFeeBps`** is adjustable only by **`GOVERNANCE_ROLE`** (TimelockController), hard-capped at **`MAX_PROTOCOL_FEE_BP = 1000` (10%)**. Changes do not alter ATS/ACS math.

    • This fee pays for dispute infrastructure and protocol operations; it must not depend on verdict direction.

    ### Verification fee (PPOR / scoring)

    PPOR generation is gated in the flagship app by an **active subscription** (`SubscriptionVault.isSubscribed`) before the server-side `/api/ppor` pipeline runs — there is **no separate on-chain “per score” micropayment contract** in V1. Operational plan:

  • A **small flat fee per scoring request** (product/pricing layer) is mostly **pass-through** to third-party model/API and oracle-operator costs in Phase 1.
  • Target **10–15% gross margin** to treasury on that fee, documented here for transparency; subscription revenue (below) remains the primary reader monetisation path.

    • Do not sell higher PPOR scores, “clean” badges, or verdict-dependent pricing.

    ### Subscriptions (on-chain)

    Reader **subscriptions** (10 USDC/month) and **tips** use the existing **`SubscriptionVault`** → **`RevenueDistributor`** path: each 30-day epoch splits **65% authors / 25% treasury / 10% oracle operators**, fixed percentages, pull-pattern claims. Treasury share is outcome-neutral and unrelated to challenge verdicts.

    ### Prohibitions

  • **No paid scores** — PPOR cannot be purchased for a higher number; oracle prompts and weights are constitutional.
  • **No credibility badges for sale.**
  • **No fee that scales with a “false” verdict** or with ATS/ACS tier beyond the existing PPOR-tier **minimum challenge stake** (economic barrier, not a treasury rake on truth).
  • **Fees must not influence ATS/ACS** — only `CredibilityLedger.applyChallenge` and upheld-challenge rules change scores; treasury cuts are separate transfers.

    • Fee parameter changes (including `protocolFeeBps`) require **governance timelock** scheduling from the multisig, with the **1000 bps hard cap** enforced in contract code.

    Allocation buckets

    All disbursements require **multisig approval** on the governance Safe, routed through the **72-hour TimelockController** once deployed (see `GoLive.md`). Target mix; actual quarterly reports may vary with runway:

    | Bucket | Target share | Use |
    |--------|--------------|-----|
    | Security audit | **First priority** until complete | Professional audit (~USD 30k–75k per `GoLive.md` Phase 3) |
    | Oracle operation | 25–35% | Oracle bonds (50k USDC each), model/API costs, prompt IPFS pinning |
    | Infrastructure | 15–25% | RPC, indexing, IPFS/Filecoin, demo/production hosting |
    | Community & bounties | 10–15% | Bug bounties, researcher grants, documentation |
    | Reserve | 10–20% | Runway, incident response, exchange-rate buffer |
    | Developer stipend | **Capped** (see below) | Sole maintainer compensation — transparent, not discretionary |

    Developer stipend

    Stipend compensation for engineering and operations work performed by or on behalf of The Lab Launchpad:

  • **Quarterly cap:** at most **15%** of funds raised (donations and other voluntary inflows accounted to the treasury) in any calendar quarter, allocated to the stipend bucket.
  • **Monthly ceiling:** **USD 5,000** per month (hard cap).
  • **Effective limit:** the **lower** of the quarterly 15% prorated amount and the USD 5,000 monthly ceiling for each payment period.
  • **Payment path:** stipend draws are paid **only** via **multisig + timelock** transfers — never from a single-key wallet without timelock delay once governance is live.
  • **Audit gate:** **no stipend is paid until the security audit bucket is funded to its minimum** (USD **30,000** reserved or disbursed toward the professional audit per `GoLive.md` Phase 3).
  • **Transparency:** every stipend transfer is a **line item** in quarterly public reports. The stipend recipient recuses from multisig votes on their own stipend transactions.
  • **Eligibility:** stipend payment is subject to the recipient’s **legal and immigration eligibility** to receive compensation in the jurisdiction(s) where work is performed and funds are sent; if payment is blocked by law or visa status, amounts remain in treasury or roll to reserve until eligible or reallocated by timelock vote.

    • Engineering staff (DRAFT)

    Separate from the **capped developer stipend** above — engineering staff draws do **not** increase stipend caps or share the USD 5,000/month stipend ceiling.

  • **Budget:** up to **USD 20,000 per month** for engineering contractors and staff to execute the public roadmap (DRAFT fundraising **Milestone 3** assumes **12 months × USD 20,000 = USD 240,000**, cumulative **USD 300,000** with Milestones 1–2).
  • **Scope:** protocol engineering, oracle pipeline, web/indexing, infrastructure, and related product work — **contractors and staff only** (not discretionary gifts, not donor perks).
  • **Payment path:** paid **only** via **multisig + timelock** transfers once governance is live — same as other treasury buckets.
  • **Transparency:** every engineering staff payment is a **line item** in **quarterly public reports** (role/vendor class, amount, bucket tag). Stipend and engineering staff compensation are reported separately.
  • **Constitutional boundary:** engineering staff funding does **not** grant scoring privileges, editorial control, or exemptions from operator non-manipulation rules.

    • Disbursement mechanics

  • **Production target:** governance Safe holding donor funds, with all outbound transfers timelock-gated.
  • **Amoy / demo interim:** voluntary donations on Polygon Amoy may be sent to the **interim treasury wallet** configured as `NEXT_PUBLIC_GRANTS_TREASURY_ADDRESS` (default `0x0DBea9f654339218B1939c2Cc539DE3896540EC5` in `.env.example`). This is currently an **externally owned account (EOA)** for the testnet demo only — **not** the final governance Safe. It must be **migrated to the multisig before mainnet**; the `/grants` page states this openly.
  • No discretionary EOA spending of donor funds on mainnet.
  • USDC/POL received at the treasury are accounted in public reports; conversion to operational expenses follows timelock-gated transfers once the Safe is live.

    • Quarterly public reporting

    Within **30 days** of each calendar quarter end, publish:

    1. Opening and closing treasury balances (on-chain).

    2. Transfers out by bucket (audit, oracles, infra, bounties, reserve, engineering staff, stipend).

    3. Major commitments (audit vendor selection, bond postings).

    4. Conflicts disclosed (see below).

    Reports are archived immutably (IPFS + link from `/grants`).

    Conflict of interest

  • **Donors** gain no ability to change scores, challenge outcomes, PPOR prompts, or publication status.
  • **The developer/founder** gains no scoring privileges; stipend is compensation for engineering and operations only.
  • Gifts from parties with active challenges or litigation against Polygraph authors are logged; large gifts (> `[THRESHOLD USD — TO BE SET]`) are disclosed in quarterly reports.

    • Refund and wind-down policy

  • Donations are **non-refundable** once sent on-chain, except where required by applicable law.
  • If the project winds down without launching mainnet credibility services, remaining treasury assets (after audit and vendor obligations) will be directed per a **timelock-gated wind-down vote** prioritising: (1) refund pro-rata to donors who opt in via a published snapshot process, or (2) transfer to a named public-interest successor (`[SUCCESSOR ENTITY PLACEHOLDER]`).
  • Wind-down does not delete archived articles or PPOR records on Filecoin/Polygon.

    • Donor recognition (public wall)

    Polygraph.news may list voluntary treasury donations on a **donor wall** (`/grants/supporters`) with a short preview on the homepage.

  • **Default:** donations appear as **“Anonymous supporter”** with amount, date, and a link to the Polygon transaction. Wallet addresses are not shown unless the donor opts in.
  • **Opt-in:** a donor may connect the **same wallet that sent the transfer**, sign an EIP-191 message referencing the transaction hash, and optionally publish a display name (length-limited), a short message (length-limited, basic profanity filter), or choose to show their address instead of a name.
  • **No scoring perks:** donor recognition is **cosmetic only**. Donations never affect PPOR, ATS, ACS, challenge outcomes, publication status, revenue multipliers, or oracle selection.
  • **Moderation:** the operator may hide specific transaction hashes via environment configuration (`DONOR_WALL_HIDDEN_TXS`) for abuse or legal compliance without altering on-chain facts.
  • **Persistence:** opt-in claims are stored in a server-side database when `DATABASE_URL` is configured (recommended: Railway Postgres for production). Ephemeral file storage is acceptable for local development only.

    • Fundraising targets (DRAFT)

    Public progress toward voluntary funding goals is shown on the homepage and `/grants`. **All figures below are DRAFT** until ratified by governance and may be overridden via environment configuration (`NEXT_PUBLIC_FUNDING_*`).

    | Milestone | Cumulative target (USD) | Purpose |
    |-----------|-------------------------|---------|
    | **Milestone 1 — Security audit** | **30,000** | Professional third-party audit before mainnet (matches minimum audit bucket in this constitution). |
    | **Milestone 2 — Mainnet launch** | **60,000** | Contract deploy, oracle bonds, model/API costs, and production infrastructure. |
    | **Milestone 3 — Year-one roadmap** | **300,000** | Mainnet launch costs plus **engineering team for 12 months at USD 20,000/month (USD 240,000)** to build the roadmap (see Engineering staff). |

    **Headline goal:** “Fund mainnet launch and the roadmap.”

    **Milestone 3 note (DRAFT):** USD **300,000** cumulative = Milestone 2 total (**USD 60,000**) plus **12 × USD 20,000** engineering staff (**USD 240,000**).

    **Raised total:** computed only from verifiable on-chain inflows to `NEXT_PUBLIC_GRANTS_TREASURY_ADDRESS` on **Polygon mainnet** (native USDC, USDC.e, and POL converted via a public price feed). The UI shows **“Live total unavailable”** when totals cannot be computed honestly — never fabricated placeholders.

    Amendment

    Changes to this constitution require **75% supermajority** of governance token holders once the DAO is live; until then, multisig + timelock with a **7-day public comment period** on `/grants/constitution`.

    ---

    *Last updated: DRAFT for polygraph.news demo — sync with `packages/web/app/grants` UI.*