GCTS-1
Green Code Technical Standard 1

What GCTS-1 Governs

GCTS-1 is the technical measurement standard for The Green Code framework. It specifies the measurement methodology that operators must follow when calculating the Cr (Cost/Resource) denominator and the data inputs required for Bv (Benefit Value) attribution under the NBR formula.

GCTS-1 governs physical resource measurement. It does not govern:

• ✗ The economic valuation of benefits (that is NBR territory)
• ✗ Carbon pricing or emissions trading
• ✗ Worker safety, labor standards, or human rights provisions (see Rights Safeguards)
• ✗ Model performance benchmarking or AI quality metrics
• ✗ Cybersecurity or data privacy requirements

GCTS-1 applies to any compute deployment that elects or is required to calculate an NBR under The Green Code framework, regardless of deployment size. The rigor of audit requirements scales with deployment size as defined in §8.

Training Measurement Categories

When a deployment includes AI model training workloads (as distinct from inference serving), the following categories must be measured separately and reported as a distinct training-period subtotal within Cr.

Inference Measurement Categories

Inference (serving) workloads represent the ongoing operational resource cost of a deployed model. These are the primary Cr inputs for deployments that consume, rather than train, AI models.

Energy System Boundary

The GCTS-1 energy boundary defines what is included and excluded from energy measurement. The boundary is set to capture all electricity that the deployment causes to be consumed in the host region.

PUE Requirement

Power Usage Effectiveness (PUE) must be measured and disclosed for the reporting period. PUE is defined as total facility energy divided by IT equipment energy. It must be measured at the utility interconnect, not estimated from design parameters. PROPOSED

PUE is a disclosure requirement under GCTS-1. It is not itself a compliance criterion, but a falsified or unsupported PUE disclosure constitutes a measurement failure that invalidates the Cr calculation.

Water System Boundary

Water measurement under GCTS-1 distinguishes between water drawn, water consumed, and water returned. All three must be reported separately.

Aquifer-Specific Requirements

Deployments drawing from stressed aquifer systems — defined as aquifers where current withdrawal rate exceeds recharge rate — must additionally report:

1. Aquifer stress classification — the current drawdown rate relative to recharge rate, sourced from USGS or equivalent state geological survey, dated within 24 months.
2. Water source attribution — documented share of water drawn from aquifer vs. surface sources vs. municipal supply.
3. Aquifer impact model — a documented model of the deployment's long-run impact on the aquifer water table, reviewed by a licensed hydrologist, with assumptions made explicit.

The Texas County pilot operates in the Ogallala Aquifer system, which is confirmed to be in a stressed drawdown state. Any live deployment in that region triggers aquifer-specific reporting requirements. AQUIFER STRESS: VERIFIED

Idle Overhead Treatment

Hardware that is powered on but not actively serving workloads still consumes energy and, in some configurations, cooling water. GCTS-1 requires that idle overhead be measured and included in Cr, not excluded as non-productive consumption.

Hardware Lifecycle and Embodied Cost

Embodied carbon and resource cost refers to the energy, water, and material consumption associated with manufacturing the hardware the deployment uses, before that hardware is powered on. GCTS-1's approach to embodied cost is as follows:

Current Requirement (Proposed)

Operators must disclose the hardware inventory (model, quantity, manufacture date) and make a good-faith effort to source published embodied carbon figures for the hardware from the manufacturer or from published lifecycle assessment databases. This disclosure is required but does not directly enter the Cr calculation at this time. PROPOSED

Target State (Pending Methodology)

End-of-Life Treatment

Operators must document the intended disposal pathway for hardware at end of life. Hardware returned to the manufacturer's take-back program, processed by a certified e-waste recycler (R2 or e-Stewards certified), or refurbished for reuse may be disclosed as a Bv item under the Resource Recovery category. The Bv attribution methodology for hardware recovery is PENDING METHODOLOGY.

Audit Thresholds by G-Level

The Texas County proposed 50 MW deployment falls in the G-2 classification. G-2 audit requirements would apply if the pilot advances to active deployment.

Required Evidence Artifacts

The following evidence artifacts must be produced, retained, and made available for audit. "Available for audit" means transmittable to an accredited auditor within 5 business days of request. Public availability requirements vary by artifact type and G-level.

• EA-01
  Utility interconnect meter records
  Time-stamped electricity consumption data from utility billing or smart meter API, covering the full reporting period at minimum monthly resolution. Daily resolution required for G-2 and above.
  
  PROPOSED
• EA-02
  Water meter records
  Intake and discharge meter readings at minimum monthly resolution for the full reporting period. Source identification (municipal, well, surface) required.
  
  PROPOSED
• EA-03
  Hardware inventory manifest
  Complete list of compute hardware (make, model, quantity, manufacture year, deployment date) and cooling infrastructure.
  
  PROPOSED
• EA-04
  Measurement plan
  Documented methodology for every measurement category used in the NBR calculation, including sensor specifications, calibration records, data collection process, and chain-of-custody for meter data.
  
  PROPOSED
• EA-05
  Pre-deployment baseline report
  Regional resource state characterization (energy grid conditions, water table, aquifer stress, local economic baseline) before deployment began. Independent review required for G-1 and above.
  
  PROPOSED
• EA-06
  Bv attribution records
  Source documentation for each claimed benefit item. See NBR §2 for attribution requirements. Required artifacts by benefit type: contracts, invoices, payroll records, utility agreements, procurement reports.
  
  PROPOSED
• EA-07
  PUE and WUE disclosure
  Computed PUE and WUE values with supporting calculation workbook showing numerator and denominator values and their sources.
  
  PROPOSED
• EA-08
  Conflict-of-interest declaration
  Signed declaration from any party involved in data collection, analysis, or reporting of any financial interest in the deployment.
  
  PROPOSED
• EA-09
  Auditor report (G-1 and above only)
  Signed findings from accredited third-party auditor. Must include: scope of work, methodology, exceptions and qualifications, summary NBR finding, and auditor's independence attestation.
  
  PROPOSED
• EA-10
  Aquifer impact model (stressed aquifer deployments only)
  Hydrologist-reviewed model of long-run aquifer impact. See §5 for requirements.
  
  PROPOSED

Data Freshness and Update Expectations

Data that exceeds its maximum age without refresh must be marked as stale in any public disclosure. Stale data may not be used to support an active NBR claim.

Gap 1 — 10:1 NBR Measurement Protocol PROPOSED

The GCTS-1 10:1 mandate requires every compliant Root-Node or model to demonstrate a 10-to-1 planetary return on investment. For every 1 unit of resource consumed for compute, the system must recover at least 10 units of verified planetary benefit. This section defines the exact formula, the physical performance gate, and the anti-gaming rules that enforce this mandate.

Physical Performance Gate — Hardware Attestation

The 10:1 ratio must be grounded in measured physical data, not modeled projections. The physical performance gate requires that all resource measurements be attested by hardware-level industrial telemetry before any NBR claim is computed.

Baseline Gaming Prevention Rules

Manipulating the counterfactual baseline is the primary vector for NBR inflation. GCTS-1 enforces the following anti-gaming rules. Violation of any rule invalidates the NBR claim for the reporting period and triggers a mandatory corrective audit.

Gap 2 — Tokenomics & Reserve Architecture PROPOSED

Physical Abundance Reserve (PAR) — State Machine

The PAR is the reserve control mechanism that governs WBT issuance and redemption. The solvency gate (CRpost ≥ 1.50) must be satisfied before any new WBT can be minted. If the post-mint Coverage Ratio falls below 1.50, the mint transaction is rejected.

Gap 3 — Cryptographic Implementation — ZKP Circuit Specification PROPOSED

The WBT mint path requires a zero-knowledge proof (ZKP) that the device measured W = 10 × E (water benefit = 10× energy cost) without revealing proprietary load curves or raw sensor data. The chosen architecture is Halo2 (PLONKish) over vanilla PLONK for superior flexibility in range checks, elliptic-curve operations, and nullifier handling.

nullifier     : Poseidon(device_sk, epoch)
device_pubkey : compressed EC point (33 bytes)
mint_amount   : u64 — WBT tokens to mint
epoch         : u64 — reporting window ID

sig_r, sig_s  : ECDSA/EdDSA signature components
device_sk     : device private key (for nullifier)
E             : energy drawn (Joules, fixed-point)
W             : water benefit (litres, fixed-point)

// Step 1: Range checks on witnesses (Halo2 lookup table)
assert E ∈ [0, MAX_ENERGY]     // prevents overflow in W computation
assert W ∈ [0, MAX_WATER]      // range-check via Halo2 lookup gate

// Step 2: Enforce the 10:1 ratio (PLONKish custom gate — no float)
assert W == 10 * E              // integer-scaled fixed-point

// Step 3: Bind mint_amount to proven W value
assert mint_amount == W / SCALE_FACTOR  // WBT = litres / 1000

// Step 4: Verify device signature over (device_pubkey, E, W, epoch)
assert ECDSA_verify(device_pubkey, msg_hash, sig_r, sig_s) == true

// Step 5: Construct nullifier to prevent epoch replay
assert nullifier == Poseidon(device_sk, epoch)

Known Failure Modes & Mitigations

Gap 4 — Security & Smart Contract Audit Registry

Reentrancy Guards — Mint Path (Checks-Effects-Interactions)

The mint path is the highest-risk function in the WBT contract. The Checks-Effects-Interactions (CEI) pattern plus a nonReentrant modifier are required:

// Pattern: Checks-Effects-Interactions (CEI)
function mint(proof, publicInputs) external nonReentrant {

  // 1. CHECKS — validate proof and solvency gate FIRST
  require(zkVerifier.verify(proof, publicInputs), "ZK proof invalid");
  require(!nullifierRegistry[publicInputs.nullifier], "Nullifier reused");
  require(par.coverageRatioPost(publicInputs.mintAmount) >= 150, "CRpost < 1.50");

  // 2. EFFECTS — update ALL state before any external call
  nullifierRegistry[publicInputs.nullifier] = true;
  totalSupply += publicInputs.mintAmount;
  balances[msg.sender] += publicInputs.mintAmount;

  // 3. INTERACTIONS — emit event after all state changes
  emit WBTMinted(msg.sender, publicInputs.mintAmount, publicInputs.epoch);
}

Audit & Verification Requirements

Gap 5 — Lifecycle Resource Cap (LRC) — Scope 3 Embodied Carbon PROPOSED

GCTS-1's original operational boundary capped hardware power consumption at 20 W operational cap for compliant edge devices. The Lifecycle Resource Cap (LRC) upgrades this to a cradle-to-grave accountability framework that adds Scope 3 embodied carbon — manufacturing, extraction, and semiconductor fabrication — directly to the NBR denominator (Cr).

Scope 3 Embodied Carbon Categories

The following upstream Scope 3 categories are included in the LRC amortization and must be sourced from manufacturer lifecycle assessment (LCA) data or published industry databases (ecoinvent, IEEE LCA datasets):

Cradle-to-Grave Amortization — NBR Denominator Integration

// Embodied carbon per reporting period (added to Cr denominator)
E_emb_period = (C_fab + C_extract + C_mfg + C_logistics + C_eol)
               ÷ T_life     // total hardware lifecycle (years)
               × U_frac     // deployment's utilization fraction of hardware
               × P_frac     // reporting period as fraction of year

// Updated Cr denominator (replaces §7 disclosure-only requirement)
Cr_lrc = Cr_operational + E_emb_period

// Updated NBR with full LRC — must still satisfy 10:1 mandate
NBR_lrc = Bv ÷ Cr_lrc    // NBR_lrc ≥ 10 required for certification

Gap 6 — Ratification & Signatory Pathway

GCTS-1 certification requires ratification by three independent signatory tiers. Each tier represents a distinct accountability domain. All three signatures are required — no tier may be waived. The current status of all three signature blocks is NOT RATIFIED / INTERNAL DRAFT.

Changelog

See Also