On a micro-grid, two neighbours trading electricity is not an accounting problem. It is a control problem wearing accounting's clothes. Supply and demand have to meet at the right frequency, and a ledger that records only money has recorded only half of what happened.
Energy Blocks came out of a cybersecurity research internship at the C3i Center, IIT Kanpur, where the question was whether a permissioned ledger could make power sharing between households both verifiable and billable.
Why the frequency is on the ledger
A transaction here is a transfer of kilowatt-hours at a frequency band. That second half is the interesting part. Grid frequency is the shared signal that tells you whether the system is balanced: drifting low means demand is outrunning supply. If the band is recorded alongside the energy, then billing and grid health are answerable from the same source of truth, and nobody has to be trusted to report either one honestly afterwards.
Why Fabric
The first version of this idea (Electrify) ran on a blockchain engine I wrote from scratch, and it was the right way to learn the problem. It was the wrong way to run it.
Proof-of-work across four nodes is theatre. Clock drift between small devices makes block ordering ambiguous. Gossip without back-pressure floods the slowest participant first.
Permissioned membership, a pluggable ordering service, and chaincode that can be unit-tested like ordinary code. All the properties the toy version was silently missing.
Writing the naive engine first was still worth it. It told me which properties I actually needed before a framework hid them from me — which is the same reason I now prefer to write a thin version of any runtime before adopting one.
Source and deployment scripts are on GitHub. The chaincode is the part worth reading; the surrounding app is a thin client over it.