Verification Methodology
How Green Code Protocol data is collected, logged, and independently audited. Current implementation uses commercially available IoT hardware and established cryptographic logging. A zero-knowledge verification layer is under development — it is not production-deployed.
Current Verification VERIFIED
The following verification stack is commercially specified and operational. All components are available off-the-shelf; no custom silicon required.
● VERIFIED — Commercially available hardware
ARM Cortex-M4 Class Edge Nodes + Gateway Hardware
Acoustic sensors use standard IoT edge hardware in the ARM Cortex-M4 class — the same processor family used in industrial water monitoring, seismic sensors, and pipeline leak detection systems worldwide. Gateway hardware is industrial-grade x86 or Raspberry Pi class single-board computers — no proprietary hardware required.
Why this matters for procurement: All hardware is available from multiple vendors, has published datasheets, can be sourced competitively, and does not require an NDA or pilot agreement to evaluate. County engineering staff can review the full BOM before any hardware is ordered.
| Component | Specification | Status |
|---|---|---|
| Acoustic sensor node | ARM Cortex-M4 class MCU, battery or mains powered, IP67-rated housing | Commercially available |
| Local gateway | Industrial x86 or RPi 4 class, 4G/LTE or Ethernet backhaul | Commercially available |
| Detection method | Industry-standard acoustic leak-correlation | Final spec pending procurement |
| Power requirement | ≤20W per node (sensor + gateway) | Reference BOM available |
● VERIFIED — SHA-256 append-only logging + quarterly third-party audit
Tamper-Resistant Audit Log
Every sensor reading, NRW calculation, and data transmission event is written to an append-only timestamped log. Each log entry includes a SHA-256 hash of the prior entry — creating a hash chain that makes retroactive alteration detectable. The log is maintained on gateway hardware and mirrored to an independent server.
Chain integrity check: Any attempt to modify or delete a historical entry breaks the hash chain at that point. County utility staff can run the integrity check independently using the published open-source tool.
● VERIFIED — Audit process
Quarterly Third-Party Audit
Every 90 days, an independent auditor (utility staff member or contracted engineering firm) runs the hash-chain integrity verification, reviews sensor calibration records, and produces a signed audit statement. The audit statement is published to the public transparency ledger at /trust/.
Auditor independence: The auditor is selected and contracted by the county, not by Green Code Protocol. Audit scope, methodology, and findings are entirely under county control.
● VERIFIED methodology — IWA/AWWA M36
NRW Calculation: IWA/AWWA M36 Water Balance
Non-revenue water is calculated using the standard International Water Association / American Water Works Association M36 water balance methodology — the globally recognised industry standard for municipal water loss assessment. No proprietary formula is used.
Formula: System Input Volume − Authorised Consumption = Water Losses (Real + Apparent). Infrastructure Leakage Index (ILI) is calculated using AWWA M36 §4.3 — same method used by USEPA ENERGY STAR Water systems program.
Source: AWWA M36 Water Audits and Loss Control Programs, 4th Ed.
Current vs. Proposed Verification Stack
Current (VERIFIED)
- ARM Cortex-M4 class acoustic sensors
- SHA-256 append-only hash-chained log
- IWA/AWWA M36 NRW water balance
- Quarterly third-party audit (county-selected)
- All data visible to county staff in real time
- Open-source hash verification tool
- No proprietary hardware or software lock-in
Proposed Enhancement (PROPOSED)
- Zero-knowledge proof layer (Rust Bulletproofs)
- Proof-of-correctness without raw data exposure
- Cryptographic audit trail beyond SHA-256 logs
- Open repository — public circuit review
- Not production-ready; no performance claims made
- Does not replace physical sensor calibration
- Timeline: dependent on circuit development progress
Proposed Enhancement: Zero-Knowledge Verification Layer PROPOSED
A ZK verification layer is under development as a future enhancement to the current SHA-256 log system. It is not a replacement — it is an additional proof layer. The implementation is open-source.
● PROPOSED — ZK verification layer under development — not production-ready
Rust Bulletproofs Implementation
The ZK verification layer is being implemented using Rust with the Bulletproofs / Halo2 proving system. The circuit is designed to prove that a water-balance calculation was performed correctly, without exposing raw sensor readings. This addresses data-sharing concerns from utilities that cannot legally expose raw consumption data.
What ZK verification proves: That the NRW calculation was performed correctly on the actual sensor data. What it does not prove: That the physical sensor was calibrated correctly, was not tampered with, or that the input data was accurate. Physical audits remain required — the ZK layer supplements, it does not replace them. This is a fundamental property of all ZK systems (the Oracle Problem), not a limitation specific to this implementation.
Repository: Open — circuit code is publicly reviewable. Link published at /trust/ when available.
Status as of 2026-07-16: Circuit design phase. Not deployed. Not production-tested. No latency, proof size, or energy figures are claimed for this implementation at this stage. See GCTS-1 §PH-3 for planned ZK integration specification.
● PROPOSED — Not a replacement for physical audit
Why ZK Does Not Replace Physical Calibration
A zero-knowledge proof is a mathematical statement: "this computation was performed correctly." It says nothing about whether the physical input — the sensor reading — was accurate. If an acoustic sensor is miscalibrated, physically damaged, or incorrectly installed, the ZK proof will be mathematically valid and physically incorrect simultaneously.
This is why the quarterly third-party audit (Section 1) is retained even after ZK deployment. The audit covers sensor calibration, physical installation integrity, and data-entry validation — none of which can be handled by cryptography alone.