From 5387687ec2eb099171bc1bc22e112d3c8e7f32a9 Mon Sep 17 00:00:00 2001 From: TaprootFreak <142087526+TaprootFreak@users.noreply.github.com> Date: Thu, 20 Aug 2026 23:52:21 +0200 Subject: [PATCH 1/3] Describe v1 assurance as harness and in-spec soundness Living assurance, conformance, and residual-review wording now points at those artefacts without extra restatements. --- docs/assurance.md | 4 ++-- docs/paper-conformance-analysis.md | 8 ++++---- docs/paper-conformance-remediation.md | 4 ++-- docs/specification.md | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/assurance.md b/docs/assurance.md index 8341915..ef69d7c 100644 --- a/docs/assurance.md +++ b/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). There is **no** human-gated audit step for v1; 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. For v1 the executable conformance harness — pinned vectors, negative controls, and the A-to-Z suite — is the independent check. There is **no** human-gated audit step. +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". diff --git a/docs/paper-conformance-analysis.md b/docs/paper-conformance-analysis.md index ef892a6..8d14f2e 100644 --- a/docs/paper-conformance-analysis.md +++ b/docs/paper-conformance-analysis.md @@ -27,7 +27,7 @@ Selected remediation proposal: [`zk-coins/docs#96`](https://github.com/zk-coins/ **Post-baseline architecture decision.** After the specification baseline reviewed here, [`research@f392fa0`](https://github.com/zk-coins/research/blob/f392fa0e4f55d68e6135e7eced15ef719118e545/zkcoins-design/ACCUMULATOR_SELF_PUBLISH.md) accepted on-chain half-aggregated state nullifiers, Bitcoin first occurrence and conditional NAV as the project plan of record. That later decision does not retroactively change this audit's findings against `docs@6816fc3`; it controls their selected remediation. `docs#96` is aligned to it, and the former full-batch-envelope alternative is rejected because it would retain the serialized `prev_root` writer. -**Register maintenance note (2026-07-22).** The audit text on this page is a pinned snapshot against `docs@6816fc3`; superseded v1-gate wording in §§5–10 MAY be corrected so it does not contradict living policy, while remaining historical audit phrasing stays superseded and is not release-governing. The **register table below is the living deviation index** the [contribution rule](https://github.com/zk-coins/docs/blob/develop/CONTRIBUTING.md) points to: a **Status (current develop)** column tracks each row against the current normative specification, and rows **D-17–D-20** register the accepted v1 boundaries adopted on 2026-07-22. Where a row's *Current specification* column still describes the retired pre-#97 construction, the **status column is authoritative** for what holds today. Sections 5–12 below (perspectives, evidence tables, recommended status) are part of the pinned snapshot and are **not** release-governing: the v1 release gates are solely the [Paper-Conformance Remediation](/paper-conformance-remediation) Gates A–C, the [Assurance Roadmap](/assurance) gates, and the [implementation-mandate runbook](/implementation-mandate) — none of which contains an external-review step (project decision 2026-07-22). For rows graded AMBER in the historical columns whose Status (current develop) is CURRENT/DECIDED/ACCEPTED, the v1 disposition is the [Risks](/risks) verdict table plus the executable harness — the historical grade is not a v1 gate. In particular, former "obtain an external audit" / "subject to external audit" gate wording in §§8–10 has been corrected under the MAY-correct policy above and is **not** a v1 release gate — an autonomous implementer follows the Gates A–C / Assurance / runbook path, which has no external-audit step (project decision 2026-07-22). +**Register maintenance note (2026-07-22).** The text on this page is a pinned snapshot against `docs@6816fc3`; superseded v1-gate wording in §§5–10 MAY be corrected so it does not contradict living policy, while remaining historical phrasing stays superseded and is not release-governing. The **register table below is the living deviation index** the [contribution rule](https://github.com/zk-coins/docs/blob/develop/CONTRIBUTING.md) points to: a **Status (current develop)** column tracks each row against the current normative specification, and rows **D-17–D-20** register the accepted v1 boundaries adopted on 2026-07-22. Where a row's *Current specification* column still describes the retired pre-#97 construction, the **status column is authoritative** for what holds today. Sections 5–12 below (perspectives, evidence tables, recommended status) are part of the pinned snapshot and are **not** release-governing: the v1 release gates are solely the [Paper-Conformance Remediation](/paper-conformance-remediation) Gates A–C, the [Assurance Roadmap](/assurance) gates, and the [implementation-mandate runbook](/implementation-mandate) (project decision 2026-07-22). For rows graded AMBER in the historical columns whose Status (current develop) is CURRENT/DECIDED/ACCEPTED, the v1 disposition is the [Risks](/risks) verdict table plus the executable harness — the historical grade is not a v1 gate. An autonomous implementer follows the Gates A–C / Assurance / runbook path (project decision 2026-07-22). ## 0. Executive summary @@ -205,7 +205,7 @@ The research repository already contains a Plonky3 migration investigation, whil **Required actions:** 1. Decide whether v1 intentionally ships on deprecated Plonky2. *(Closed for v1: project decision 2026-07-22 pins `plonky2 = "1.1.0"`; see [Paper-Conformance Remediation](/paper-conformance-remediation) F-05.)* -2. If yes, vendor and maintain the full trusted code base. There is no external-audit gate; v1 assurance is the conformance harness and the in-spec soundness argument. +2. If yes, vendor and maintain the full trusted code base. v1 assurance is the conformance harness and the in-spec soundness argument. 3. Benchmark the exact `C` and `C_balance` circuits, not proxy circuits, and publish the node `build-report.md` ([Implementation Mandate §4](/implementation-mandate)) — still open; the artefact exists on the open node PR, but is not merged to `develop` and is not yet a benchmark publication. 4. Publish proof-size/proving-time distributions at maximum supported bounds. *(Verifier-data digests for `C` and `C_balance` per network are already pinned in V.4 from the reference implementation on open [`node#231`](https://github.com/zk-coins/node/pull/231); that branch is not merged to `develop`.)* @@ -336,7 +336,7 @@ The existing Apalache certificate targets [`docs@ed7fdece`](https://github.com/z Model checking also composes axiomatized cryptographic properties; it does not establish that Poseidon, Plonky2 recursion, non-native BIP-340 gadgets or the implementation satisfy those axioms. Liveness and indistinguishability properties have explicit scope reductions. -The project’s own [Assurance Roadmap](/assurance) lists security definitions, paper reductions, and machine checking as the verification staircase; for v1 the release-gating artefacts are the in-spec soundness argument and the executable harness. There is no external-audit gate. +The project’s own [Assurance Roadmap](/assurance) lists security definitions, paper reductions, and machine checking as the verification staircase; for v1 the release-gating artefacts are the in-spec soundness argument and the executable harness. **Required actions:** @@ -463,7 +463,7 @@ A deviation is not adequately supported merely because the specification contain 1. Complete publisher incentive analysis. 2. Define and test DA retention/retrievability. 3. Test independent failure domains rather than replica count alone. -4. There is no external-audit gate; v1 assurance is the conformance harness and the in-spec soundness argument. +4. v1 assurance is the conformance harness and the in-spec soundness argument. ## 10. Release decision diff --git a/docs/paper-conformance-remediation.md b/docs/paper-conformance-remediation.md index 4e0b058..7151230 100644 --- a/docs/paper-conformance-remediation.md +++ b/docs/paper-conformance-remediation.md @@ -41,7 +41,7 @@ A later coordinator lane may offer optional constant-size batching only if the d ## Findings and mandatory disposition -**F-01, F-02, F-04 and F-06 are resolved in the normative spec** by PR #97: the on-chain `(Pk_i, R_i)` state nullifier ([spec §3.1](/specification#31-the-on-chain-object), [§1.7.10](/specification#1710-half-aggregation-with-commitments-nisshac-normative)), first-occurrence rebuild from Bitcoin alone ([spec §3.6](/specification#36-chain-scanning)), predecessor-nullifier anchoring of every state-advancing transition including issuance ([spec §2.1](/specification#21-the-compliance-predicate), [§2.3.1](/specification#231-mint--issuance), [§3.10](/specification#310-transaction-states)), and replication reserved for private bearer data ([spec §4.6](/specification#46-data-availability)). What remains open is the executable-conformance evidence (canonical vectors, Gate B) and F-08's commit-pinned status matrix; F-05 and F-07 are closed by project decision (see the table below), and Gate C contains no external-review step (project decision 2026-07-22). The **selected disposition** column records the design decision each finding drove; the **release gate** column records what still gates mainnet. +**F-01, F-02, F-04 and F-06 are resolved in the normative spec** by PR #97: the on-chain `(Pk_i, R_i)` state nullifier ([spec §3.1](/specification#31-the-on-chain-object), [§1.7.10](/specification#1710-half-aggregation-with-commitments-nisshac-normative)), first-occurrence rebuild from Bitcoin alone ([spec §3.6](/specification#36-chain-scanning)), predecessor-nullifier anchoring of every state-advancing transition including issuance ([spec §2.1](/specification#21-the-compliance-predicate), [§2.3.1](/specification#231-mint--issuance), [§3.10](/specification#310-transaction-states)), and replication reserved for private bearer data ([spec §4.6](/specification#46-data-availability)). What remains open is the executable-conformance evidence (canonical vectors, Gate B) and F-08's commit-pinned status matrix; F-05 and F-07 are closed by project decision (see the table below). The **selected disposition** column records the design decision each finding drove; the **release gate** column records what still gates mainnet. | ID | Severity | Problem | Selected disposition | Release gate | |---|---:|---|---|---| @@ -282,7 +282,7 @@ PR #97 applied the following edits to the normative spec; this map remains the t - the reference instantiation and backend are final and frozen for v1 ([spec §1.7.8](/specification#178-reference-instantiation-status-final-for-v1), [§1.7.9](/specification#179-proof-system-parameters-normative)); - a vulnerability disclosure process is published ([SECURITY.md](https://github.com/zk-coins/docs/blob/develop/SECURITY.md)). -By explicit project decision (2026-07-22) there is **no** human-gated audit or proof-review step in Gate C; the executable Gate-B evidence plus the in-spec arguments above are the v1 assurance basis. +The executable Gate-B evidence plus the in-spec arguments above are the v1 assurance basis. No real-value deployment proceeds until all three gates are complete. diff --git a/docs/specification.md b/docs/specification.md index c24a73c..c98c928 100644 --- a/docs/specification.md +++ b/docs/specification.md @@ -577,7 +577,7 @@ This section pins one concrete, implementable convention for everything otherwis **v1 freeze (normative).** The v1 protocol surface is **frozen** in two classes with distinct effectiveness points on the [Path to mainnet runbook](/implementation-mandate). **From runbook step 3 (vectors pin):** the circuit shape of `C` and `C_balance` (public-input layout, the [§2.5](#25-circuit-dimensioning-normative) bounds, the [§2.6](#26-in-circuit-non-native-cryptography-normative) relations), the §1.7 encodings and serializations, and every Poseidon-dependent pinned value — the class that **carries digests and lineages**. `IssuanceTerms_v2` ([§6.5](#65-issuance--token-standards), [§2.1 clause 3](#21-the-compliance-predicate)) is part of the **initial** v1 circuit build, not a later addition. Once the reference implementation generates and pins `circuit_digest(C)` and `circuit_digest(C_balance)` ([§1.7.9](#179-proof-system-parameters-normative), [V.4](#v4-poseidon-derived-values)), any change to any element of this class defines a **new protocol version** with new digests and new lineages; v1 artefacts are never edited in place. **From runbook step 7 (public testnet):** additionally the [§7](#7--wire-formats--node-interfaces) wire formats. From that point nodes that are not jointly updated run for the first time; a wire change thereafter produces identical version names under different rules and is therefore a real version conflict — any change to a §7 wire format after step 7 defines a **new protocol version**. **Between step 3 and step 7** an addition to the §7 wire formats that touches **neither** a circuit element **nor** a pinned vector **nor** a digest is **not** a new protocol version; it **MUST** be introduced by a specification PR that states why the addition is required. The open, additive `GET /v1/token//provenance` read ([§7.5](#75-node-rest-api-normative), [§4.6](#46-data-availability) Class B) is exactly such an addition — read-only, unauthenticated, and changing no existing format. Between those steps no foreign node and no lineage carries value (the project is green field — [Implementation Mandate §0](/implementation-mandate); rollback before runbook step 10 is free — [Path to mainnet](/implementation-mandate)), so a wire freeze protects nothing while forcing a full rebuild of the vector series (the tag prefixes `"zkCoins/v1/…"` enter every Poseidon digest). The digest- and lineage-carrying class is **not** relaxed by this separation: it remains absolute from step 3. -**Residual review target (normative note).** v1 has **no** human-gated audit step ([Assurance Roadmap](/assurance)). Of the v1 construction, the one element the mandatory differential-test below discharges (project decision 2026-07-22) is the **in-circuit arithmetization of the RFC-6962 log-consistency verifier** ([§3.7](#37-the-nullifier-accumulator)): its data-dependent recursion (split points driven by the bits of the two log sizes) is unrolled to `≤ 2·H_MAX` slots with select gates, and a subtly wrong split-point or peak-bagging would let it accept a **non-prefix**, collapsing the transitive-anchoring soundness ([§2.1 clause 1](#21-the-compliance-predicate)). The reference implementation **MUST** differential-test the gadget against an independent RFC-6962 reference at **every** `2ᵏ−1`, `2ᵏ`, `2ᵏ+1` size boundary for **`k = 0…63`** — the **generated log-boundary suite** of [V.11](#v11-nullifier-accumulator-log-vectors). That suite tests the **split-/peak-bagging LOGIC** of the consistency and inclusion gadgets with **given/symbolic subtree-root fixtures** (the O(log n) boundary subtree roots per case — Poseidon-dependent, hence ``), **not** by materialising Θ(n) leaves for large `n`. Small hand-listed sizes (`n ≤ 9`) **MAY** fully materialise; high-`k` cases **MUST NOT** require Θ(n) leaf evaluation. The suite is part of the **v1 freeze differential-test** (this section) and **feeds the D-05 release gate** (in-circuit differential-test of the RFC-6962 log-consistency + inclusion arithmetization — [Paper-Deviation Analysis D-05](/paper-conformance-analysis)). The inclusion **PATH** gadget ([§3.7](#37-the-nullifier-accumulator)) shares the same data-dependent split-point arithmetization (driven by the position bits, `≤ H_MAX` audit-path hashes) and is covered by the **same** differential-test discipline and the V.11 vectors (hand-listed smoke set **and** the symbolic-subtree-root suite for all `k`). The abstract relation is peer-reviewed (RFC 6962 / RFC 9162 log consistency); only its Poseidon-over-Goldilocks in-circuit realisation is v1-new. +**Residual review target (normative note).** Of the v1 construction, the one element the mandatory differential-test below discharges (project decision 2026-07-22) is the **in-circuit arithmetization of the RFC-6962 log-consistency verifier** ([§3.7](#37-the-nullifier-accumulator)): its data-dependent recursion (split points driven by the bits of the two log sizes) is unrolled to `≤ 2·H_MAX` slots with select gates, and a subtly wrong split-point or peak-bagging would let it accept a **non-prefix**, collapsing the transitive-anchoring soundness ([§2.1 clause 1](#21-the-compliance-predicate)). The reference implementation **MUST** differential-test the gadget against an independent RFC-6962 reference at **every** `2ᵏ−1`, `2ᵏ`, `2ᵏ+1` size boundary for **`k = 0…63`** — the **generated log-boundary suite** of [V.11](#v11-nullifier-accumulator-log-vectors). That suite tests the **split-/peak-bagging LOGIC** of the consistency and inclusion gadgets with **given/symbolic subtree-root fixtures** (the O(log n) boundary subtree roots per case — Poseidon-dependent, hence ``), **not** by materialising Θ(n) leaves for large `n`. Small hand-listed sizes (`n ≤ 9`) **MAY** fully materialise; high-`k` cases **MUST NOT** require Θ(n) leaf evaluation. The suite is part of the **v1 freeze differential-test** (this section) and **feeds the D-05 release gate** (in-circuit differential-test of the RFC-6962 log-consistency + inclusion arithmetization — [Paper-Deviation Analysis D-05](/paper-conformance-analysis)). The inclusion **PATH** gadget ([§3.7](#37-the-nullifier-accumulator)) shares the same data-dependent split-point arithmetization (driven by the position bits, `≤ H_MAX` audit-path hashes) and is covered by the **same** differential-test discipline and the V.11 vectors (hand-listed smoke set **and** the symbolic-subtree-root suite for all `k`). The abstract relation is peer-reviewed (RFC 6962 / RFC 9162 log consistency); only its Poseidon-over-Goldilocks in-circuit realisation is v1-new. #### 1.7.9 Proof-system parameters (normative) From b2a6d567c99e2e12701d7c0af07a42ba8ddab62d Mon Sep 17 00:00:00 2001 From: TaprootFreak <142087526+TaprootFreak@users.noreply.github.com> Date: Fri, 21 Aug 2026 00:00:26 +0200 Subject: [PATCH 2/3] Drop the leftover Gate-C assurance aside Keep the sentence on harness and in-spec arguments only. --- docs/paper-conformance-remediation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/paper-conformance-remediation.md b/docs/paper-conformance-remediation.md index 7151230..f1cff74 100644 --- a/docs/paper-conformance-remediation.md +++ b/docs/paper-conformance-remediation.md @@ -216,7 +216,7 @@ Desirable post-v1 cryptographic write-ups (a quality goal, **not** a v1 release - privacy under the now chain-visible transaction count, rotating keys and commitments; - correctness of the concrete recursive circuit and implementation. -Model checking cannot replace primitive proofs; v1 ships without an implementation audit or gating formal proofs by project decision — the executable harness (Gate B) and the in-spec arguments are the v1 assurance basis ([Assurance Roadmap](/assurance)). +Model checking cannot replace primitive proofs; the executable harness (Gate B) and the in-spec arguments are the v1 assurance basis ([Assurance Roadmap](/assurance)). ## 8. Required negative controls From 0a995357054a4b4a9db713955e4415cfe62fad4b Mon Sep 17 00:00:00 2001 From: TaprootFreak <142087526+TaprootFreak@users.noreply.github.com> Date: Fri, 21 Aug 2026 00:04:22 +0200 Subject: [PATCH 3/3] Tighten leftover living asides after review Keep Gate C as the executable V.11 path and drop the non-action item from the P3 list. --- docs/paper-conformance-analysis.md | 3 +-- docs/paper-conformance-remediation.md | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/paper-conformance-analysis.md b/docs/paper-conformance-analysis.md index 8d14f2e..2a25af6 100644 --- a/docs/paper-conformance-analysis.md +++ b/docs/paper-conformance-analysis.md @@ -205,7 +205,7 @@ The research repository already contains a Plonky3 migration investigation, whil **Required actions:** 1. Decide whether v1 intentionally ships on deprecated Plonky2. *(Closed for v1: project decision 2026-07-22 pins `plonky2 = "1.1.0"`; see [Paper-Conformance Remediation](/paper-conformance-remediation) F-05.)* -2. If yes, vendor and maintain the full trusted code base. v1 assurance is the conformance harness and the in-spec soundness argument. +2. If yes, vendor and maintain the full trusted code base. 3. Benchmark the exact `C` and `C_balance` circuits, not proxy circuits, and publish the node `build-report.md` ([Implementation Mandate §4](/implementation-mandate)) — still open; the artefact exists on the open node PR, but is not merged to `develop` and is not yet a benchmark publication. 4. Publish proof-size/proving-time distributions at maximum supported bounds. *(Verifier-data digests for `C` and `C_balance` per network are already pinned in V.4 from the reference implementation on open [`node#231`](https://github.com/zk-coins/node/pull/231); that branch is not merged to `develop`.)* @@ -463,7 +463,6 @@ A deviation is not adequately supported merely because the specification contain 1. Complete publisher incentive analysis. 2. Define and test DA retention/retrievability. 3. Test independent failure domains rather than replica count alone. -4. v1 assurance is the conformance harness and the in-spec soundness argument. ## 10. Release decision diff --git a/docs/paper-conformance-remediation.md b/docs/paper-conformance-remediation.md index f1cff74..4095192 100644 --- a/docs/paper-conformance-remediation.md +++ b/docs/paper-conformance-remediation.md @@ -276,7 +276,7 @@ PR #97 applied the following edits to the normative spec; this map remains the t ### Gate C — assurance - the specification's soundness summary ([spec §2.4](/specification#24-soundness-summary)) and security-properties summary ([spec §6.7](/specification#67-security-properties-summary)) exist, every clause reference they cite resolves, every Requirement 1–13 has a row, and D-17–D-19 appear in the [§6.7 precise privacy statement](/specification#67-security-properties-summary), D-16 is stated in [spec §3.9](/specification#39-finality-and-reorg-handling), and D-20 has its row in the [Risks](/risks) verdict table (machine-checkable link/row checks); -- **D-05** passes its release gate: the **V.11 differential-test** of the in-circuit RFC-6962 log-consistency/inclusion arithmetization against an independent reference ([spec §1.7.8](/specification#178-reference-instantiation-status-final-for-v1), V.11) — executed at the negative-controls / conformance step ([Implementation Mandate](/implementation-mandate) step 5/6) as part of the executable gate, not a separate human review — alongside the existing D-16/D-17–D-20 checks above; +- **D-05** passes its release gate: the **V.11 differential-test** of the in-circuit RFC-6962 log-consistency/inclusion arithmetization against an independent reference ([spec §1.7.8](/specification#178-reference-instantiation-status-final-for-v1), V.11) — executed at the negative-controls / conformance step ([Implementation Mandate](/implementation-mandate) step 5/6) as part of the executable gate — alongside the existing D-16/D-17–D-20 checks above; - **D-05 network-parameter agreement gate:** `network-params.json` is a byte-exact canonical artefact (spec §3.6); every node MUST load the pinned per-network `activation_height` and refuse readiness (`/health/ready` `503`) on mismatch; and a conformance test MUST confirm two independent nodes scanning the same tip from the **same** pinned `activation_height` produce the identical `(size, mth)` / `nav_root`, while a **differing** `activation_height` diverges them **whenever a valid nullifier is admitted in the interval between the two heights** — the conformance fixture **MUST** include at least one such nullifier so the divergence is observably guaranteed — the executable check for the parameter-agreement residual (D-05 (iv)). - the [Risks](/risks) verdict table has no open and no broken row; - the reference instantiation and backend are final and frozen for v1 ([spec §1.7.8](/specification#178-reference-instantiation-status-final-for-v1), [§1.7.9](/specification#179-proof-system-parameters-normative));