About the Project
GreenProof started with a simple question: can a supplier prove that a product meets environmental requirements without exposing the exact location of their farm?
Environmental compliance can require sensitive supply chain information. A supplier may need to demonstrate that their production is outside protected areas, uses permitted land, and satisfies predefined environmental constraints. However, sharing exact coordinates and other private business data with every auditor creates an unnecessary privacy problem.
I built GreenProof as a prototype for solving this problem with zero knowledge proofs.
What I built
GreenProof combines real public geospatial data with a ZK verification system.
The supplier enters private information such as their exact coordinates, production quantity, supplier ID, and secret. The backend retrieves environmental evidence from real public sources, including OpenStreetMap, Overpass, and ESA WorldCover through Terrascope.
The browser then generates a Groth16 zero knowledge proof using a Circom circuit. The circuit verifies conditions such as:
- the location being inside the supported geographic region
- the location not being inside a detected protected area
- the land cover classification being allowed
- production staying below the defined threshold
- the supplier commitment being valid
- the environmental evidence being cryptographically bound to the private coordinates
The auditor receives the verification result and environmental evidence provenance, but does not receive the supplier's exact coordinates, production quantity, or secret.
How I built it
The backend is written in Rust and handles the environmental evidence lookup and verification workflow.
The ZK layer uses Circom, circomlib, Poseidon hashing, and Groth16. The frontend is built with React and TypeScript, with proof generation performed in the browser.
A key part of the implementation was making sure that the environmental evidence was not simulated with hardcoded values. I connected the application to real external geospatial services and made the system fail closed when the source cannot provide usable data.
The hardest part
The most difficult part was integrating the ESA WorldCover data correctly.
Initially, the Terrascope WMS endpoint returned:
band_1 = 250
It looked like a land cover class, but it was actually the red channel of an RGB visualization. The RGB value 250, 0, 0 corresponds to the official WorldCover visualization color for class 50, Built-up.
This caused the ZK circuit to reject the witness because the project only allows class 40, Cropland.
I had to trace the complete pipeline from the external WMS response through the Rust normalization code, evidence hash, frontend input, and finally the Circom constraints. I also added regression tests so that unsupported or incorrectly interpreted environmental data cannot silently become a fabricated classification.
Another challenge was adapting the WMS request itself. The service required WMS 1.3.0, additional parameters such as STYLES and TIME, and GeoJSON as the information format.
What I learned
The project taught me that building a ZK application is not only about writing the circuit. Many difficult problems happen at the boundaries between real world data, APIs, data normalization, cryptographic commitments, and the circuit itself.
I also learned the importance of failing closed. If an environmental data source returns something unexpected, GreenProof should reject the evidence rather than inventing a fallback value that could make a proof appear valid.
The ZK circuit proves consistency with the environmental evidence retrieved by the application. It does not independently verify satellite imagery or protected area boundaries inside the SNARK. The underlying geospatial datasets and external services remain trust assumptions.
The current prototype also focuses on a limited geographic region and a small set of environmental constraints.
Why I built it
The goal of GreenProof is to explore a different model of environmental compliance:
prove the required facts without unnecessarily revealing the private data behind them.
I believe this approach could eventually be useful for privacy preserving environmental compliance, sustainable supply chains, and other situations where organizations need to verify real world claims without exposing sensitive operational information.
Built With
- circom
- esa-worldcover
- groth16
- openstreetmap
- react
- rust
- typescript
- zero-knowledge
- zero-knowledge-proofs
Log in or sign up for Devpost to join the conversation.