GridProof

Physics-checked renewable energy certificates with half-hourly carbon accounting, on-chain double-claim prevention, and browser-verifiable Merkle proofs.

Comment

GridProof — Renewable Energy Certificates You Can Actually Verify

Physics-checked, replay-proof, browser-re-verifiable renewable energy certificates built on real Great Britain offshore-wind data.

A renewable energy certificate is only as trustworthy as the meter reading behind it and the guarantee that it can only be claimed once. GridProof makes renewable energy certificate issuance independently verifiable through physical plausibility checks, half-hourly carbon accounting, Merkle proofs, and blockchain-enforced replay protection.

The Problem

Renewable energy certificates help organizations substantiate renewable electricity claims, but verifying the evidence behind those claims can be difficult. Inaccurate generation readings, coarse carbon accounting, and duplicate claims can undermine confidence in certificate systems.

Grid carbon intensity also changes throughout the day. Using a flat average can obscure the relationship between when renewable electricity is generated and how carbon-intensive the grid is at that moment.

Blockchain can preserve evidence and enforce rules, but it cannot magically establish whether an external meter reading is physically plausible or truthful.

I built GridProof to address these challenges by connecting real-world energy data, statistical physics checks, cryptographic proofs, and on-chain enforcement in one reproducible pipeline.

What Inspired Me

For the IEEE ClimateChain Global Hackathon 2026, I wanted to explore a practical question at the intersection of renewable energy, carbon markets, and blockchain:

What if anyone could independently verify a renewable energy certificate instead of simply trusting the issuer's dashboard?

Rather than building another energy-tracking interface or speculative token marketplace, I focused on the evidence behind each certificate: real generation measurements, physically plausible wind output, half-hourly grid carbon intensity, and cryptographic guarantees against duplicate issuance and retirement.

I built GridProof independently, implementing the complete system from data ingestion and statistical validation to Solidity smart contracts, a Python CLI, and a browser-based verifier.

The prototype uses three real Great Britain offshore wind BM units: Dudgeon, Burbo Bank Extension, and Race Bank.

How I Built It

GridProof follows a complete verification pipeline:

Fetch → Align → Validate → Merkle → Issue → Retire → Verify

1. Real-world energy and weather data

I integrated three public data sources:

  • Elexon: Settled half-hourly generation data using the B1610 dataset.
  • Open-Meteo: ERA5-based 100-metre wind data.
  • NESO: Electricity grid carbon-intensity data.

I aligned these datasets into half-hourly intervals and handled important edge cases, including negative import readings and daylight-saving transitions.

2. Statistical physics validation

I developed a statistical wind-power envelope using 11 months of historical data. For each wind-speed bin, the envelope uses the 99.5th percentile of observed capacity factors as an upper threshold.

I then evaluated March 2025 generation readings against this envelope and physical limits.

The system flags suspiciously high readings for further audit rather than automatically labelling them fraudulent. This distinction matters because unusual data is not, by itself, proof of misconduct.

3. Merkle-based certificate integrity

For every asset-day, I construct a Merkle tree from accepted half-hourly intervals. The resulting root provides a compact cryptographic commitment to the batch.

I deployed a Solidity registry to Ethereum Sepolia that records each asset-day's Merkle root, model hash, and snapshot hash. This lets an independent verifier check whether interval data matches the committed batch.

4. Blockchain-enforced replay protection

I implemented contract-level safeguards against duplicate issuance and repeated retirement.

  • An existing asset-day batch cannot be issued again: BATCH_EXISTS.
  • A previously retired half-hourly interval cannot be retired again: ALREADY_RETIRED.

During retirement, the contract calculates emissions using the interval's grid carbon intensity.

These checks enforce the prototype's uniqueness rules at the contract level rather than relying solely on the frontend.

5. Browser and CLI verification

I built both a Python CLI and a browser-based verifier.

The tools reconstruct Merkle roots from committed snapshots and compare them with the on-chain commitments. The CLI also supports live verification by re-fetching the public APIs.

Python, Solidity, and browser JavaScript use consistent leaf encoding and Merkle calculations, allowing the same underlying evidence to be checked across environments.

A particularly important edge case is 30 March 2025, when the British daylight-saving transition produced a 46-period day instead of the usual 48 half-hourly periods. GridProof verifies the race_bank_1 batch for that day successfully.

Results and Evaluation

I evaluated GridProof on real offshore-wind generation data for March 2025. All reported results are available in committed evaluation artifacts and can be reproduced using the project's verification scripts.

Metric Result
Generation included in the evaluation 159.7 GWh
Flat-average emissions estimate 23,371 tCO2e
Half-hourly emissions estimate 19,054 tCO2e
Flat-average overstatement 22.66%
Asset-day batches verified 93/93
Claims checks passed 14/14
Held-out false-flag rate 0.31% for Burbo Bank Extension; 0% for Dudgeon and Race Bank
Detection recall at 2× artificial inflation Approximately 30–36%
Daylight-saving test 46 periods verified successfully

Why the emissions result matters

Across the evaluated 159.7 GWh of offshore-wind output, the flat-average calculation produced 23,371 tCO2e, compared with 19,054 tCO2e using half-hourly accounting.

That is a 22.66% overstatement relative to the half-hourly result.

This demonstrates how temporal aggregation can materially affect carbon-accounting results. It is a finding from this specific dataset and methodology, not a universal claim that flat-average accounting always overstates emissions by the same amount.

Tamper and replay tests

I also tested failure cases rather than evaluating only successful verification:

  • Snapshot tampering: Changing one kWh in a copied snapshot causes verification to fail and identifies the affected asset, date, and interval.
  • Duplicate issuance: Attempting to issue an existing batch reverts with BATCH_EXISTS.
  • Duplicate retirement: Attempting to retire the same interval twice reverts with ALREADY_RETIRED.
  • Cross-environment verification: The browser and CLI can reconstruct the same committed Merkle roots.

These tests demonstrate the integrity and replay-protection properties implemented in the prototype.

What I Learned

Building GridProof taught me that trustworthy blockchain applications depend on much more than smart contracts.

First, data provenance matters as much as cryptography. A Merkle proof can establish that a reading matches a committed dataset, but it cannot independently prove that the original reading was truthful.

Second, time resolution matters in carbon accounting. Half-hourly generation and carbon-intensity data can produce materially different results from calculations based on flat averages.

Third, cross-environment determinism is difficult but essential. Python, Solidity, and browser JavaScript must agree on data encoding, hashing, and Merkle-tree construction. A small serialization mismatch can invalidate an otherwise correct proof.

Finally, I learned the importance of publishing limitations alongside results. A system that reports its blind spots is more useful to auditors than one that presents every anomaly flag as definitive evidence of fraud.

Challenges and Limitations

Making heterogeneous data consistent

Generation, weather, and carbon-intensity sources have different schemas and time conventions. I had to align them into a common half-hourly representation and explicitly handle daylight-saving transitions, missing observations, and negative import readings.

Avoiding false confidence in anomaly detection

The statistical envelope is useful for flagging readings for audit, but it is not a universal detector of manipulated measurements. My sensitivity tests show recall of approximately 30–36% at 2× artificial inflation, with lower recall for smaller inflation factors. Some inflated readings remain inside the envelope's blind regions.

I publish these limitations rather than presenting the detector as infallible.

Accounting for trust outside the blockchain

The prototype still trusts its oracle, external data providers, and issuer key. Blockchain commitments make the resulting data re-checkable, but they do not eliminate those trust assumptions.

Keeping the prototype reproducible

I included snapshots, models, batches, receipts, and evaluation results in the repository so that reviewers can inspect the evidence and reproduce the reported checks. I also separated local testing from Sepolia operations to avoid accidentally modifying the deployed testnet registry during local verification.

Technology Stack

  • Python: Data ingestion, statistical validation, Merkle construction, CLI, and evaluation.
  • Solidity: Certificate registry, issuance controls, and retirement safeguards.
  • Ethereum Sepolia: On-chain batch commitments and contract execution.
  • JavaScript: Browser-based certificate verification.
  • Public APIs: Elexon, Open-Meteo, and NESO.
  • Cryptographic verification: Merkle trees and hashes for tamper-evident data commitments.

The prototype uses public data and does not require paid API keys or dedicated GPU hardware.

What's Next?

GridProof is a proof of concept covering three offshore-wind assets and one evaluation month. Before production use, it would need:

  • Independently operated or multi-party data oracles.
  • An audited smart contract and stronger issuer governance.
  • Grid-specific adapters for additional energy and carbon-intensity sources.
  • Broader validation across longer time periods and additional generation technologies.
  • Further work on detection sensitivity, blind regions, and operational scalability.

A full certificate marketplace, token transfers, solar generation, and non-GB grids are outside the current scope.

Try GridProof

The live browser-verifier link and demo video can be added once their final URLs are available.

Final Thoughts

GridProof is my attempt to make renewable energy certificates more transparent by connecting physical plausibility checks, time-specific carbon accounting, and cryptographic verification.

The central idea is simple: a certificate should not require blind trust. Its underlying data should be inspectable, its integrity should be independently verifiable, and its retirement should be protected against replay.

GridProof: trust the evidence behind the certificate, not just the certificate itself.

Built With

Share this project:

Updates

Submission history