# Pre-launch threat-model checklist — fair settlement

For the fair-settlement design slice (roadmap stage 06). The design note, the
generated FairSettlement example and the Python walkthrough model are a
**synthetic, local first slice**: they name states, timeouts and honest
limits, and they implement nothing that moves value. This checklist records
what any real-value launch would still need to design, build, audit and
operate **before** a single unit of value moves. It is a checklist, not a
roadmap commitment; no item below is done, and none is authorized yet.

## Custody and the holder

- [ ] A separately authorized holder exists (escrow instance or named human
      authority), and its custody system is **independently audited** — the
      settlement design depends on it and cannot replace it.
- [ ] The holder's key ceremony, quorum and recovery path are documented and
      rehearsed; a lost or compromised holder key is a fund-loss scenario.
- [ ] Conservation of funds is **the holder's invariant to prove**, not ours
      to claim: reconciliation between custody balances and settlement
      records, with evidence a third party can check.
- [ ] The Commons never holds funds and never gains custody — re-verify that
      every integration preserves this boundary end to end.

## Identity and authority

- [ ] GitHub account control proves identity, **not payment authority** —
      define who may trigger or receive a settlement, separate from who can
      sign a coordination action.
- [ ] Payment credentials, coordination tokens and identity tokens live in
      separate trust domains; a leaked identity token must never be able to
      move value.
- [ ] Sybil reality is accepted: nothing in the current design resists many
      fake identities. Decide where that is acceptable (it is, for
      coordination) and where it is not (anywhere near value).

## Delivery and acceptance semantics

- [ ] A delivery digest proves **bytes**, not quality, authorship,
      availability or fitness; define who inspects work and how that
      inspection is recorded.
- [ ] An acceptance record proves a decision, not fairness — define the
      review SLA, reviewer independence and what happens when the reviewer is
      the counterparty.
- [ ] Retention of artifacts is declared, never guaranteed; define what a
      dispute means when the artifact bytes are gone.

## Dispute path

- [ ] The dispute path named in the agreement is a real, reachable process
      with rules, evidence standards, timelines and an authority that applies
      them — the service records outcomes only.
- [ ] The fallback outcome for a deadlocked dispute is chosen deliberately
      (this design defaults to **refund**); confirm the economics make that
      safe for the holder and fair for the contributor.
- [ ] Dispute resolution itself needs a trust model: who resolves, who pays,
      what stops collusion between a party and the resolver.

## Timeouts, on-chain realities

- [ ] Permissionless timeout paths are safe only because they can reach
      exactly the fixed outcome; re-verify this property after any change,
      and model griefing: who benefits from pushing a settlement into a
      timeout.
- [ ] Block timestamps (if any chain is involved) are miner/validator
      influenceable within bounds; deadlines must tolerate that drift, and a
      timeout must never depend on precise time.
- [ ] Someone must call the timeout paths — keeper incentives, gas costs and
      what happens when nobody calls them, need an owner.

## Contract and toolchain

- [ ] Any deployed contract gets a professional security audit of the exact
      bytecode that is deployed, not only of its source.
- [ ] Compiler and dependencies are pinned (this slice pins solc 0.8.37);
      verify deployed bytecode against the pinned build reproducibly.
- [ ] Upgrade and pause policies are named before launch — including who can
      stop settlements and who can never start one.
- [ ] An incident-response runbook exists: pause, communicate, refund,
      post-mortem.

## Legal, compliance and privacy

- [ ] Escrow, payment and refund rules differ by jurisdiction; get competent
      legal review for every jurisdiction value would move through.
- [ ] KYC/AML, sanctions and tax obligations attach to real value and must be
      assigned to an accountable party before launch.
- [ ] Privacy review: settlement records are public in this design; decide
      whether amounts and parties may be public, and honor data-protection
      rights for any personal data.

## Honesty boundaries of this slice

- [ ] The design note, the generated example and this checklist implement
      nothing and move nothing; no on-chain or testnet exercise has occurred
      or is authorized.
- [ ] Any testnet step is a **separately authorized** later gate with its own
      threat-model review — a testnet with value semantics is a launch, not a
      test.
- [ ] Nothing here has been audited, insured, legally reviewed or operated at
      value; treat every document in this slice as a design conversation,
      never as a payment system.