push-unblock: forge fmt repo-wide (clears the pre-push gate); remove ScheduledEmitter (+test) — one-shot genesis is the supply model, contract was SUPERSEDED/NOT-DEPLOYED since 07-29, reference preserved at tag scheduled-emitter-ref; SECURITY.md proxy line corrected (UUPS via GovernedUpgradeable — reviewer's catch); ECONOMIC_INVARIANTS.md gains the Supply Model section; slither baseline pruned of emitter entries; carries the owed 08-20 SECURITY.md/baseline changes

ECONOMIC_INVARIANTS.md

@@ -10,6 +10,18 @@ These invariants are intended to be **testable** (unit/fuzz/property tests) and
 
 ---
 
+## 0. Supply Model (one-shot genesis) <!-- patch_pushunblock_supplymodel -->
+
+Genesis mints the entire allocation once (patch_oneshot_genesis). Thereafter,
+total supply changes ONLY through StakeEngine accrual: mint and burn via
+VSPToken, authorized by Authority (StakeEngine is exempt from the time-based
+supply cap in VSPToken — an engine-side accrual error is therefore not bounded
+by the token, which is why the accrual math and the mint path must be reviewed
+together). There is NO scheduled emission and no other minter. ScheduledEmitter,
+the superseded price-independent schedule design (never deployed, never wired),
+was removed from the tree on 2026-08-21; the reference implementation is
+preserved at git tag `scheduled-emitter-ref`.
+
 ## I. Token Conservation & Accounting Invariants (StakeEngine)
 
 ### I.1 Contract balance matches staked totals

SECURITY.md

@@ -1,49 +1,95 @@
 # Security Policy
 
-## Supported Versions
-The VeriSphere protocol is under active development. Only the latest commit on
-the `main` branch is considered supported.
+Verisphere is pre-launch, unaudited software. We take security reports
+seriously and would rather hear about a problem than not.
 
-Security fixes will be applied immediately upon discovery.
+## Reporting a vulnerability
 
-## Reporting a Vulnerability
-If you discover a vulnerability in any VeriSphere smart contract, script,
-repository, or deployment process:
+**Email: security@verisphere.co** — or, if you prefer GitHub, use the
+repository's **Report a vulnerability** button (Security tab → Advisories),
+which opens a private channel visible only to maintainers.
 
-1. Do **not** create a GitHub issue.
-2. Instead, email:
+Please include:
 
-   security@verisphere.co
+- what the issue is and where (file/function/contract),
+- how to reproduce it — a failing test, a transaction trace, or a script is
+  ideal, but a clear written walkthrough is fine,
+- what an attacker gains, and roughly how hard it is,
+- your assessment of severity, if you have one.
 
-3. Include:
-   - A clear description of the issue
-   - Steps to reproduce (if applicable)
-   - Contract addresses or code locations
-   - Whether the vulnerability is theoretical or exploitable
-   - Your public wallet address (for possible bounty eligibility)
+Please **do not** open a public issue or PR for a security problem, and please
+don't post it on social media before we've had a chance to respond.
 
-We will acknowledge reports within 48 hours.
+## What you can expect from us
 
-## Smart Contract Security Expectations
-The core contracts follow these principles:
+| Stage | Target |
+|---|---|
+| Acknowledgement that a human has read it | 3 business days |
+| Initial assessment (confirmed / not reproduced / need more info) | 10 business days |
+| Fix or documented mitigation for confirmed issues | as fast as the severity warrants — we'll tell you the plan |
+| Public disclosure | coordinated with you, normally after a fix ships |
 
-- Minimal trusted roles
-- No upgradeable proxies in MVP
-- Deterministic authorization via Authority.sol
-- No unbounded loops over user data
-- No external calls inside state-mutating logic except VSP token transfer calls
+We will tell you honestly whether we agree with your severity rating and why.
+If we disagree, we'll explain our reasoning rather than quietly downgrading it.
+If we can't reproduce it, we'll say what we tried.
 
-Formal verification and third-party audits are planned before mainnet launch.
+## Safe harbour
 
-## Bounty Program
-VeriSphere will reward security disclosures that materially improve protocol
-safety.
+We will not pursue legal action against anyone who, in good faith:
 
-Qualifying classes include:
-- Critical loss of funds
-- Unauthorized mint/burn
-- Post or stake manipulation
-- Incorrect access control on any contract
-- Economic attacks that bypass intended staking dynamics
+- tests only against **testnet deployments** or their own local fork,
+- does not access, modify, or exfiltrate other users' data or funds,
+- does not degrade the service for others (no sustained load testing, no spam
+  against the relay or public endpoints),
+- gives us a reasonable opportunity to fix the issue before disclosing it.
 
-Thank you for helping secure VeriSphere.
+If you're unsure whether something is in scope, ask first — that also counts
+as good faith.
+
+## Scope
+
+Upgradeability, so you know what you are testing: the core protocol contracts
+(StakeEngine, ScoreEngine, PostRegistry, LinkGraph, ProtocolViews) are
+UUPS-upgradeable via GovernedUpgradeable, authorized through Authority, with
+upgrades running through script/Upgrade.s.sol and the storage-layout check.
+VSPToken and Authority themselves are not proxied.
+<!-- patch_pushunblock_proxyline: added 2026-08-21; the pre-rewrite doc
+     falsely claimed "No upgradeable proxies in MVP". -->
+
+**In scope**
+- Protocol contracts in `VeriSphereVSP/core` (`src/`) — token, registry,
+  staking, scoring, governance, and the deployment scripts under `script/`.
+- The application backend in `VeriSphereVSP/app` — the API, relay/forwarder
+  path, content moderation, indexer, and rate limiting.
+- The frontend in `VeriSphereVSP/frontend` and the Verity browser extension.
+
+**Out of scope**
+- `src/mock/` and anything documented as rehearsal-only infrastructure.
+- Issues that require compromising a user's own device, wallet, or browser.
+- Findings from automated scanners without a demonstrated impact.
+- The economics of losing a stake: staking against a claim that later loses is
+  the protocol working as designed, not a vulnerability.
+- Third-party services (RPC providers, AMM venues, the chain itself).
+
+## Known and accepted
+
+- **The contracts are unaudited.** This is disclosed to users and is not itself
+  a finding. Reports of specific exploitable bugs in unaudited code are very
+  much welcome.
+- **Governance is currently a single key** on testnet. Findings that assume a
+  compromised governance key are understood; findings that let a non-governance
+  actor reach governance-only behaviour are in scope and serious.
+
+## Rewards
+
+We do not currently run a paid bug bounty; the project is pre-revenue and we'd
+rather promise nothing than promise what we can't pay. What we do offer:
+public credit in the advisory and this repository (or anonymity, your choice),
+and a direct line to the maintainers. If a report prevents material loss, we
+will discuss a discretionary reward case by case.
+
+## Disclosure history
+
+| ID | Date | Summary | Status |
+|---|---|---|---|
+| VSP-SEC-001 | 2026-08-19 | Mid-window accrual asymmetry in `StakeEngine`: settlement scales rewards by elapsed epochs and applies them to the lot set present at settlement, so with `snapshotPeriod > EPOCH_LENGTH` a late joiner could capture a full window's rewards (and an early leaver could dodge a full window's decay). Not reachable at the deployed 1-day period. Reported by [@ibnu76](https://github.com/ibnu76). | Fixed — `MAX_SNAPSHOT_PERIOD` capped to `EPOCH_LENGTH`; regression tests added |