docs: align mainnet security policy and tokenomics runway notes.

Document no-budget launch security posture with evidence-driven gates, disclosure/triage requirements, and updated mainnet roadmap language. Add tokenomics supply-runway clarifications for docs and website handoff.

Made-with: Cursor

Author: TheNewAutonomy

docs/mainnet-roadmap.md

@@ -27,7 +27,7 @@ Canonical tracking:
 - **Epic**: `#262`
 - **Threat model**: `#271`
 - **Adversarial tests**: `#272`
-- **External review scope/remediation**: `#273`
+- **Security review scope/remediation + disclosure policy**: `#273`
 
 ### 3) Reliability/performance gate
 
@@ -62,7 +62,8 @@ Canonical tracking:
 
 ## Additions I recommend (not explicitly in the list, but mainnet-critical)
 
-- **Security review/audit scope** is tracked in `#273`.
+- **No-budget security model**: launch can proceed without paid audit if reproducible adversarial and reliability evidence gates are complete.
+- **Security review/disclosure scope** is tracked in `#273` (community reporting + triage workflow).
 - **Monitoring/alerting** is tracked in `#280`.
 - **Genesis / launch runbook** is tracked in `#279`.
 

docs/security-external-review-scope.md

@@ -1,6 +1,6 @@
-# External security review scope and remediation checklist (mainnet)
+# Security review scope and remediation checklist (mainnet)
 
-This document defines the minimum external security review package required for mainnet launch readiness.
+This document defines the minimum security review package for mainnet launch readiness under a no-budget launch model.
 
 Tracking:
 
@@ -9,9 +9,18 @@ Tracking:
 
 ## Objective
 
-Define a clear, auditable external review scope and a deterministic remediation workflow so findings can be triaged, fixed, verified, and signed off before launch.
+Define a clear, auditable review scope and a deterministic remediation workflow so findings can be triaged, fixed, verified, and signed off before launch.
 
-## In-scope components for external review
+## Launch model (explicit)
+
+- Catalyst v1 launch does **not** require a paid third-party audit or paid penetration testing.
+- Launch readiness instead depends on:
+  - reproducible adversarial evidence (`#272`)
+  - reliability/chaos evidence (`#274`, `#275`)
+  - documented residual-risk acceptance and operational controls
+- Post-launch, community-led review is explicitly encouraged and tracked through responsible disclosure workflow.
+
+## In-scope components for security review
 
 Reviewers should focus on code paths that can cause consensus safety failures, liveness failures, or critical asset compromise.
 
@@ -96,7 +105,7 @@ Out-of-scope items can be tracked separately, but must not block launch-gate sig
 
 ## Required review deliverables
 
-The external reviewer package must include:
+The review package should include (from internal testing and/or community reports):
 
 1. Scope and methodology summary.
 2. Finding list with severity and exploit preconditions.
@@ -114,17 +123,29 @@ For each finding:
 4. Add/extend deterministic regression tests.
 5. Run relevant package tests and checks.
 6. Document behavior changes in `docs/` when externally visible.
-7. Request reviewer retest or internal adversarial confirmation.
+7. Request retest by reporter/reviewer where possible, or run internal adversarial confirmation.
 8. Mark as resolved only with evidence attached.
 
 ## Evidence requirements before closing `#273`
 
-- reviewer scope document attached/linked
+- scope document attached/linked
 - findings table with statuses (open/fixed/accepted)
 - all Critical findings resolved
 - High findings resolved or explicitly accepted with mitigation notes
 - remediation commits and test evidence linked per finding
 
+## Community disclosure and triage baseline
+
+Before launch, define and publish:
+
+- a security contact channel (for example: dedicated email or issue template)
+- a report intake template (impact, reproduction, affected version)
+- severity mapping (Critical/High/Medium/Low) and response expectations
+- a triage SLA target for first response and status updates
+- disclosure guidance (private reporting preferred before coordinated public disclosure)
+
+After launch, continue publishing remediation evidence in-repo and maintain a public acknowledgement path for valid reports.
+
 ## Handoff to `#272`
 
 Any finding that requires adversarial validation must be mapped into executable scenarios in `docs/adversarial-test-plan.md` and tracked in `#272`.

docs/security-threat-model.md

@@ -6,7 +6,7 @@ It is the canonical input for:
 - `#262` epic: security threat model and adversarial test gate
 - `#271`: publish mainnet threat model and attack assumptions
 - `#272`: adversarial test execution evidence
-- `#273`: external review scope and remediation checklist
+- `#273`: security review scope and remediation checklist
 
 ## Security goals
 
@@ -84,7 +84,7 @@ It is the canonical input for:
   - min-peer maintenance with backoff/jitter
 - **Residual risk**:
   - stronger peer diversity and scoring still needed
-- **Verification path**: eclipse scenarios in `#272`; external review in `#273`.
+- **Verification path**: eclipse scenarios in `#272`; security review/triage process in `#273`.
 
 ### 5) Sybil pressure on economic eligibility
 
@@ -121,6 +121,15 @@ It is the canonical input for:
   - endpoint-level shaping and stricter cost controls need continuous hardening
 - **Verification path**: abuse workloads in `#272`.
 
+### 9) Vulnerability disclosure process failure
+
+- **Impact**: valid findings are delayed, mishandled, or disclosed unsafely.
+- **Current controls**:
+  - in-repo issue tracking and remediation evidence discipline
+- **Residual risk**:
+  - disclosure channel/SLA policy must be explicitly documented for launch
+- **Verification path**: disclosure/triage workflow definition under `#273`.
+
 ## Residual risks accepted for v1 (explicit)
 
 - Global internet-scale DDoS resistance is out of scope for protocol code alone.
@@ -133,6 +142,6 @@ To satisfy `#262` before launch:
 
 1. Threat model and assumptions are published and reviewed (`#271`).
 2. Adversarial test plan is executed with reproducible evidence (`#272`).
-3. External review scope and remediation workflow are defined (`#273`).
+3. Security review scope and remediation workflow are defined (`#273`), including community disclosure/triage policy.
 4. Residual risks are explicitly accepted or mitigated with owners and timelines.
 

docs/tokenomics-explainer-handoff.md

@@ -101,6 +101,10 @@ Yes. Eligible waiting workers receive a share of cycle rewards and can accrue fe
 
 No. Fee credits are non-transferable and scoped to the same sender identity.
 
+### Could Catalyst run out of tokens quickly?
+
+No. At the v1 mint rate (`1 KAT` every `20s`), the theoretical numeric supply ceiling is extremely far out (about `11,699 years`, based on `u64` atom representation). In practice, this is a long-run runway rather than a near-term limit.
+
 ## Verification snippet for operators
 
 Use this JSON-RPC call to display live tokenomics parameters:

docs/tokenomics-model.md

@@ -34,6 +34,17 @@ Rationale:
 - avoids governance complexity of dynamic inflation in early network phases
 - aligns with fair-launch objective
 
+## Supply runway (numeric limits)
+
+With `1 KAT` minted per successful `20s` cycle and `1 KAT = 1_000_000_000 atoms`:
+
+- theoretical max representable total supply is bounded by `u64` atoms:
+  - `18_446_744_073_709_551_615 atoms`
+  - `18_446_744_073.709551615 KAT`
+- at `1 KAT` per cycle, reaching that numeric ceiling would take about `11,699 years` of continuous successful cycles
+
+This means v1 does not have a practical near-term risk of "running out" of representable supply.
+
 ## Reward model
 
 Per successful cycle: