The problem Zeus - Proof of Energy solves

Energy generation data today is self-reported and siloed. When a solar farm claims it produced 500 MWh for a tax credit, or a utility reports renewable generation for REC issuance, there's no
independent way to verify those numbers. Auditors rely on spreadsheets. Regulators rely on trust. Fraud happens.

Zeus fixes this by creating a cryptographic proof layer for energy data:

• Operators register generation assets (solar, wind, hydro, smart meters) as on-chain NFTs with location, capacity, and metadata
• Readings from those assets are batched, Merkle-hashed, pinned to IPFS, and attested on-chain — creating an immutable, timestamped record
• Anyone can independently verify a specific reading against the on-chain Merkle root — no trust required
• Compliance reports are generated from verified data: capacity factor, uptime, generation totals, REC eligibility — all backed by on-chain proof
• Data marketplace lets buyers purchase verified energy data with escrowed payments that auto-settle when quality thresholds are met
• Financing triggers release payouts automatically when assets hit performance targets (e.g. "pay out 0.5 ADI if this solar array generates >40 kWh for 3 consecutive batches")

It works for individual operators uploading manually, or at enterprise scale — the platform includes an adapter for Esyasoft's MDM platform, which manages 25M+ meters globally.

Challenges we ran into

Challenges I ran into:

ADI Chain is not ZKsync Era. We initially configured the project with

@matterlabs/hardhat-zksync

and

zksolc

because ADI Chain is built on the ZKsync stack. Every deployment attempt failed
with a cryptic

execution reverted

during gas estimation. After hours of debugging (trying explicit gas limits, different deploy scripts, direct

zksync-ethers

factories), we finally dug into the
ADI docs and discovered that ADI uses the newer ZKsync OS/Atlas architecture, which is EVM gas-equivalent — it
accepts standard

solc

bytecode, not zksolc-compiled bytecode. Created a separate

hardhat.config.evm.ts

without the ZKsync plugin, recompiled with standard solc, and all 5 contracts deployed on
the first try.

Nonce race conditions. When the simulator sends readings for 4 devices in quick succession, the backend fires 4 on-chain transactions nearly simultaneously. The second and third transactions
would fail with "transaction nonce is not consistent" because the previous tx hadn't confirmed yet. Fixed by adding a transaction mutex that serializes all on-chain submissions through a promise
queue — each tx waits for the previous one to confirm before sending.

Node v24 + ZKsync tooling. Early in development,

@matterlabs/hardhat-zksync

would crash trying to download the zksolc compiler binary due to a

fetch maxRedirections

error in Node v24.
Worked around it by manually downloading the zksolc and zkvm-solc binaries and pointing to them via

compilerPath

in the Hardhat config. This ended up being moot once we switched to standard solc
for ADI deployment, but it cost a full day of debugging.