Trust-minimized electricity meter protocol ⚡︎

1. The Problem

Tokenization offers clear advantages, yet progress remains limited across most sectors. In developed countries, regulatory and KYC requirements protect investors but limit innovation. In emerging markets, where tokenization projects could have the highest impact, security tokens are often unregulated. However, the lack of oversight creates opportunities for fraud and makes it hard to trust project claims.

The problem we set out to solve is how to enable the tokenization of energy infrastructure, such as solar parks, in low-trust environments. Without relying on auditors or regulators, there must be a way to prove that energy is being produced as claimed. Our goal is to make that data verifiable, tamper-resistant, and accessible on-chain.

2. The Solution

WattWitness is a hardware protocol that cryptographically signs electricity data and records it on-chain, providing verifiable proof of energy generation or consumption by signing data at the source and relaying it to smart contracts via Chainlink Functions.

While originally designed for the tokenization of solar parks in low-trust environments, WattWitness could power peer-to-peer prosumer microgrids using on-chain kWh tokens or enable native tokenization of CO₂ certificates generated as a byproduct of renewable energy production.

Pitch Deck - Project Summary - Dashboard

Tech Stack

Hardware: ESP32 + Shelly EM + Raspberry Pi 4 + ATECC608
Data Relay: Python/MQTT + Secure Signing + PostgreSQL
Oracle Layer: Chainlink Automations + Functions
Blockchain: Avalanche Fuji Testnet
Smart Contracts: Solidity / Foundry
Frontend: TypeScript / React

Chainlink Functions & Smart Contract

When a new installation is set up, the WattWitnessDataLoggerFactory deploys a WattWitnessDataLogger contract, which stores all installation readings on-chain. During deployment, installation details are written to the contract’s state.

WattWitness uses Chainlink Automation to regularly trigger Chainlink Functions, which call our API to fetch 20 of the oldest pending readings not yet stored on-chain. The Chainlink Function then invokes the fulfillRequest fallback on the WattWitnessDataLogger, updating its Merkle Tree and emitting an event per reading.

Due to Chainlink Functions Server Limits (256-byte return size and 300,000 gas callback limit), we cannot store all reading data directly as state variables. Instead, readings are compacted into a Merkle Tree with key data, and events are emitted for easy access by applications and front ends.

A backend service listens for the BatchProcessed event from the WattWitnessDataLogger. When triggered, it marks the relevant readings as is_on_chain = true and records the transaction hash and block number.

Data Signing

Every 10 seconds, our ESP32 microcontroller gets a new payload from our electricity meter, signs it using the private key of the ATECC608, and broadcasts the signed data to our Python backend running on the Raspberry Pi.

This data includes: Current Power Flow, Total Wh, timestamp, and the signature. It’s then saved in a local PostgreSQL database. Every 5 minutes, these readings are aggregated and recorded on-chain.