Release: develop -> main

CONTRIBUTING.md

@@ -60,7 +60,8 @@ docs/
 │   ├── paper-conformance-analysis.md    # Living deviation register + pinned audit snapshot
 │   ├── paper-conformance-remediation.md # Gates A–C
 │   ├── lightning-bridge.md       # Off-by-default operator extension (Lightning)
-│   └── mail-bridge.md            # Off-by-default operator extension (mail)
+│   ├── mail-bridge.md            # Off-by-default operator extension (mail)
+│   └── group-chat.md             # v2 Marmot/MLS group overlay — NOT applicable in v1
 ├── src/css/custom.css            # Theme overrides (Bitcoin orange)
 ├── static/img/                   # Favicon, logos
 ├── docusaurus.config.js          # Site config

README.md

@@ -26,7 +26,7 @@ zkCoins spans several repositories; the specification in this repo covers all of
 |---|---|---|
 | **App · Explorer** | end-user wallet (NIP-05 `user@domain` receive identity) · public explorer web-app | [`zk-coins/app`](https://github.com/zk-coins/app) · `zk-coins/explorer` *(planned)* |
 | **SDK** | thin TypeScript client — on-device keys, signing, node/API calls | [`zk-coins/sdk`](https://github.com/zk-coins/sdk) |
-| **zkCoins API** | the sole public REST surface — features `wallet`, `explorer`, `publisher`, Lightning and mail bridges, each switched on by the operator | [`zk-coins/api`](https://github.com/zk-coins/api) |
+| **zkCoins API** | the sole public REST surface — features `wallet`, `explorer`, `publisher`, and Lightning and mail bridges, each switched on by the operator; `group_chat` is a **v2 feature — NOT applicable in v1** | [`zk-coins/api`](https://github.com/zk-coins/api) |
 | **zkCoins node** | trustless kernel, gRPC only — scan · accumulator · verify · prove · store · publisher · Nostr transport | [`zk-coins/node`](https://github.com/zk-coins/node) |
 | **bitcoind · Nostr relay** | Bitcoin L1 settlement and ordering · off-chain transport and data availability | upstream (own or external) |
 

docs/architecture.md

@@ -79,6 +79,8 @@ Each feature is off until the operator enables it, and `GET /v1/info` advertises
 | `lightning_bridge` | Lightning ⇄ zkCoins swaps at the operator edge ([Lightning bridge](/lightning-bridge)) |
 | `mail_bridge` | SMTP interop for the account's NIP-05 identifier ([Mail bridge](/mail-bridge)) |
 
+`group_chat` is a **v2 feature — NOT applicable in v1** ([Group chat](/group-chat)).
+
 Publishing and proving are kernel work in every case; the feature opens the door, the kernel does the job and owns the state.
 
 ## Deployments

docs/assurance.md

@@ -11,7 +11,7 @@ title: Assurance Roadmap
 Two distinct failure classes threaten the protocol, and they need different instruments:
 
 - **Incentive failures.** Every role behaves as specified only if behaving as specified is that actor's best strategy. Cryptographic proofs do not cover this: a protocol can be mathematically sound and still fail in production because rational operators act differently than the design assumes. Incentive failures surface only once the network is live and someone exploits them — and a live decentralized system cannot simply be patched. They must be found **before** launch, by analysis.
-- **Implementation failures.** The specification can be right and the code wrong. zkCoins deliberately runs a **single protocol implementation** (the Rust node; the TypeScript SDK independently re-implements only the client-side primitives — derivation, hashing, and signing). There is no second full implementation to cross-check against, so the independent view a second client would provide must come from elsewhere: the executable conformance harness — the specification's pinned test vectors, their negative controls, and the A-to-Z suite of the [Implementation Mandate](/implementation-mandate). By explicit project decision v1 ships **without an external audit**; the harness and the specification's internal soundness argument ([spec §2.4](/specification#24-soundness-summary)) carry that assurance weight.
+- **Implementation failures.** The specification can be right and the code wrong. zkCoins deliberately runs a **single protocol implementation** (the Rust node; the TypeScript SDK independently re-implements only the client-side primitives — derivation, hashing, and signing). There is no second full implementation to cross-check against, so the independent view a second client would provide must come from elsewhere: the executable conformance harness — the specification's pinned test vectors, their negative controls, and the A-to-Z suite of the [Implementation Mandate](/implementation-mandate). The harness and the specification's internal soundness argument ([spec §2.4](/specification#24-soundness-summary)) carry that assurance weight.
 
 Both workstreams follow the project's standing rule: whatever they change flows through this repository as a spec PR first ([Implementation Mandate](/implementation-mandate)).
 
@@ -38,7 +38,7 @@ The path to "demonstrably secure", in order — each step builds on the previous
 
 1. **Security definitions.** Precise statements of what *secure* means for zkCoins: no forgery, no double-spend, and privacy of amounts, assets, and participants expressed as indistinguishability properties — stated precisely enough to capture the linkability gaps [Risks](/risks) already documents (intra-transaction co-output visibility via the shared `output_coins_root`, and pre-anchor disclosure of `Pkᵢ` to a chosen publisher, and — under the deferred fee mechanism only — cross-transition publisher linkage via the fee-coin `ash` chain), so v1's actual unlinkability guarantee is neither over- nor under-stated. The definitions become part of the [Specification](/specification).
 2. **Paper proofs.** Reductions showing the protocol meets those definitions under standard assumptions (hash security, discrete log/Schnorr, the proof system's soundness and zero-knowledge). Written up, published, and reviewable. For v1, publication of these proofs is a quality goal, **not a release gate** (project decision: no human-gated mainnet step); the release-gating artefacts are the in-spec soundness argument and the executable harness.
-3. **Machine-checked verification.** Machine-checked proofs or model checking for the protocol state machine where feasible. By explicit project decision there is **no external audit** for v1: the executable conformance harness — pinned vectors, negative controls, and the A-to-Z suite — stands in for the independent check a second implementation or an external audit would otherwise provide.
+3. **Machine-checked verification.** Machine-checked proofs or model checking for the protocol state machine where feasible. For v1 the executable conformance harness — pinned vectors, negative controls, and the A-to-Z suite — is the independent check.
 
 :::info Proofs cover the model, not the code
 A security proof establishes that the *specified* protocol is sound. That the *running* code implements the specified protocol is established separately — by the pinned conformance vectors and the end-to-end suite the [Implementation Mandate](/implementation-mandate) requires. Only both halves together justify the claim "demonstrably secure".