Skip to main content
The canonical threat model is docs/THREAT-MODEL.md: assets, adversaries, what is and isn’t protected, how, and the code or test that enforces each row. The security review with findings is docs/SECURITY-REVIEW.md. This page summarises both and holds the mainnet gate checklist.

Trust assumptions

Stated first, because every guarantee depends on them. Full text: THREAT-MODEL.md §Trust assumptions.
  1. Deposit mode: the coordinator sees bid amounts live. It holds the UFVK to scan. Trustees hold no viewing key. Use sealed-reveal mode to hide prices from the coordinator until the reveal window. Deposit sizes stay visible.
  2. The coordinator samples nk and rivk and holds the UFVK (encrypted with SF_DATA_KEY). That is viewing power, not spending power.
    • A database dump plus SF_DATA_KEY gives an attacker every escrow’s notes in both directions, so sealing breaks for deposit-mode amounts, and refund addresses leak. Funds don’t move.
    • Two trustee shares give spend signatures. Building a spend also needs the escrow FVK, which lives only in the coordinator database under SF_DATA_KEY.
  3. Trustees sign blind. They receive the sighash and α, not the PCZT, so they can’t check what a refund or payout pays. A malicious or compromised coordinator plus two trustees signing as instructed can redirect escrowed funds. This is the most important gap before mainnet.
  4. Liveness. Refunds need the organiser to publish, the coordinator to build, and two trustees to sign. Any of them can delay. Funds stay in the escrow meanwhile.
  5. The published UIVK is permanent. After publish, every deposit’s amount and memo (code, commitment, refund address) and every reveal (price, salt) is readable by anyone, forever. Senders are not, and outgoing refunds are not.

Threat model summary

Each row’s mechanism and enforcing code: THREAT-MODEL.md.

Key custody

The custody table (where each key lives and what stealing it gives) is in SECURITY-REVIEW.md §Key handling. One addition from this review: the escrow FVK components nk and rivk are generated by the coordinator (3 Escrow key construction), and the PCZTs the coordinator builds are not shown to trustees.

Findings

From the review on 2026-10-15 (SECURITY-REVIEW.md): Found while writing these docs (2026-11-13), not yet fixed:

Open items from the review

Mainnet gate checklist

This is the canonical list; 10 Roadmap links here. Each item MUST be done before an auction holds mainnet funds.
  • Trustee-side transaction verification (D1). Trustees receive the PCZT, check every output against the refund plan derivable from the published result and UIVK (amounts, refund addresses, denominations) and the payout address, and refuse to sign otherwise.
  • Per-auction value caps, enforced by the coordinator at creation and shown on the auction page.
  • Independent trustees: three different operators on separate infrastructure, not one operator’s machines.
  • External review of the escrow signing path (FROST over PCZT α, apply_signatures) and the DKG relay.
  • Rate limiting on public endpoints (Caddy).
  • CSP decision: nonce-based strict CSP, or a recorded acceptance of 'unsafe-inline'.
  • FROST ciphersuite from an upstream-published crate, replacing reddsa =0.5.2 and the deprecated fixed-α sign (3 upstream risk).
  • Clean, reproducible WASM builds (D2): every BUILD.json with "source_dirty": false, reproduced by the CI wasm job.
  • Off-site encrypted backups drilled on the production host (evidence/backup-drill.md lists what isn’t drilled yet).
  • Rescan performance on real blocks measured for the 3,500-block audit target (evidence/perf.md).
  • Expiry handling for broadcast batches (D3).