In the last few months, I've been working on something that, quite frankly, I have struggled to name. At first glance, it feels like a rollup—a validity rollup, to be precise. But then again, it also feels like an oracle. Sometimes, it even starts to resemble a zk coprocessor or some strange hybrid between them all. In truth, what we are building may not fit neatly into any one of these categories, and that's precisely why I want to talk about it.

The m3tering protocol is an infrastructure protocol built for decentralized energy networks. It aims to transform smart meters—the kind you find in homes, businesses, and microgrids—into first-class citizens of the blockchain, where they can be on-chain actors, represented as NFTs, each it's cryptographic key, each capable of signing transactions to publish it's consumption data. These data points arrive fast and frequently, typically every minute. Each record represents a quantum of energy consumption information that can be used in a wide variety of on-chain applications: onchain power purchase agreements, bilateral energy service contracts, tokenized energy attribute credits (RECs, CO2 offsets, Negawatts), or even yield-bearing collateral for DeFi and ReFi protocols.

But herein lies the problem: sending all of these transactions to Ethereum would be impractical. Every single meter reading would need its own transaction, and with tens or hundreds of thousands of meters updating every minute, we would drown the blockchain in noise and cost.

So we did what many in the DePIN space have been forced to do: we kept the data off-chain.

But when you move computation and data off-chain to save on costs, you also forfeit transparency and verifiability. The moment you aggregate meter data off-chain, you introduce a trust boundary: who aggregated it? Can we trust them? Can we recompute it? Can we verify it?

Some projects resolve this by introducing consensus. After all, if multiple nodes can agree on the state of these off-chain components, then that state becomes authoritative. But this quickly starts to look like building your own blockchain—you need validators, consensus algorithms, incentive structures, and all the overhead that comes with it. And we didn't want to build yet another blockchain.

Instead, we asked: can we have verifiability without consensus?

Our system aggregates smart meter data off-chain but proves the correctness of this aggregation using a Groth16 zk-SNARK. The data comes in as signed transactions from meters, each tagged with a nonce and energy reading. Initially, I imagined using a simple zk circuit for aggregation—something like a zk-adder. After all, if you can just prove that each nonce increments and that energy values are summed correctly, wouldn’t that be enough?

Not quite, without verifying the signature on each transactions, the proof could be gamed. Anyone could fabricate input values. Long story short, rather than developing a custom ZK circuit, we turned to the SP1 zkVM. This allowed us to write Rust code for parsing transactions, verifying signatures, and computing the updated account all meters—and then prove that computation in Groth16 SNARKs. This was a huge unlock. We could now build a fully general-purpose prover for our offchain aggregation logic, while keeping the onchain interface minimal and cheap. The result of the computation is a Groth16 proof and the new state blob.

But before any aggregation can occur, it must first establish a trusted foundation—a snapshot of Ethereum’s state from which the rest of the computation derives legitimacy.

To begin, the prover selects the latest Ethereum block (or of the recent 256 blocks), using its blockhash as an anchor. This hash is not only committed to in the final proof—it is also critical for producing Merkle Patricia Trie (MPT) proofs that allow the prover to query and verify onchain storage in a stateless manner. Specifically, the prover uses this blockhash to retrieve the Ethereum state root for that block, and then constructs MPT proofs to verify the public keys of the meters, stored on-chain in a smart contract (ie a keystore). To validate a meter’s public key, the prover traces a proof path from the block’s stateroot, into the account root of the keystore contract, down to the storage root, and finally to the exact storage slot holding the public key. This ensures that the public key used to verify a meter’s signature is the same one registered on-chain at that block.

The prover then loads the most recent nonce and energy state for each meter from the previously published blobs. These blobs are also stored on-chain, typically embedded into contract bytecode using SSTORE2. The prover computes and commits to the keccak256 hash of these previous blobs—one for nonces, one for energy values. These hashes serve as public inputs to the zk-SNARK circuit, enforcing that the new state logically evolves from the last known state. Now, the prover begins processing the incoming transaction data.

Each one is verified by checking its ED25519 signature against the public key retrieved onchain. The nonce is checked to ensure it increments exactly by one relative to the previous recorded nonce. If valid, the energy value is added to the previous cumulative energy total. This process is repeated for every transaction of every meter, producing two updated blobs: one containing new nonces, and one with updated energy totals.

Once the aggregation is complete, the prover computes the keccak256 hashes of the new nonce and energy blobs. These, along with the hash of the previous blobs and the chosen Ethereum blockhash, are committed as public outputs of the proof. The new blobs are published to Ethereum using SSTORE2 contracts, which embed the raw byte data directly into contract bytecode—an efficient hack that bypasses the traditional storage cost model. Alongside these blobs, the zk-SNARK proof is submitted to the registry contract. On-chain verification ensures that what gets published isn’t just plausible, but provably correct. While it's not strictly necessary, the raw meter transactions that fed into this proof are also published to Ethereum's data-availability blobs or mirrored onto long-term decentralized storage backends like Arweave, IPFS, Filecoin etc for analytics and UX purposes.

This design allows any smart contract to read the latest state directly on-chain and for client nodes to be stateless. Nodes can share pending meter transactions using Waku, Streamr, or similar gossip protocols. If a new state proof is published to Ethereum, nodes can discard outdated data from their pending transaction list. No consensus is required, and yet, correctness is assured.

Is it a zk rollup? There is no sequencer, no fee market, no virtual machine for arbitrary logic. There are no users, just smart meters. There is no native asset, no chain ID, no need for bridging. But there is a kind of chain: each state blob builds on the one before it. There is a notion of chain length—the number of aggregation epochs since genesis. It behaves like a rollup, but only for one very specific application: proving the cumulative energy consumption of a global fleet of smart meters.

Is it a validium? We keep raw data off-chain. We post only proofs and final states to Ethereum. And yet, we go further than most validiums: our full state is readable and consumable by any contract on Ethereum.

Is it an oracle? We certainly deliver external data on-chain. But oracles typically deliver scalar values: prices, weather, timestamps. We deliver entire state blobs attested by cryptographic proof. We are not just an oracle; we are an attestation mechanism for an evolving global dataset.

Is it a zk coprocessor? It certainly shares that DNA. We offload heavy computation, we prove it off-chain, and we return the proof to Ethereum. But unlike typical coprocessors, we don’t respond to one-off queries.

Reading Krane and Emperor’s essay on verifiable offchain compute, I started to see believe that maybe zk rollups are themselves just a particular configuration of zk coprocessors. So perhaps what we are building is a zk-validium coprocessor oracle, but that’s a mouthful, and I’m not sure it helps. What I do know is this: we are building an essential missing link in the infrastructure stack of many DePIN and ReFi protocols (I've talked about this on Farcaster here). We are making energy data provable. And we are doing it in a way that makes it programmable.

Once smart contracts can rely on verifiable energy data, the design space opens up. Prepaid power agreements can be enforced on-chain. Energy attribute credits can be minted from actual usage. Carbon offsets can be more than just paper claims. You can build bilateral contracts, DAO-managed utilities, even integrate energy consumption into DeFi lending markets. A kilowatt-hour can become a primitive.

So maybe the classification doesn’t matter as much as the capability. Maybe this system doesn’t need to be boxed into a term we already know. Maybe it’s time we build new mental models for what zk infrastructure can be. But I’ll offer my classification anyway:

To me, this is a rollup. It lacks an Ethereum bridge, yes. It even lacks blocks (kinda), but it rolls up meter data into a verifiable, succinct commitment, and posts it on Ethereum and that's the most important thing.

I invite you to classify it however you like. Just don’t underestimate it.

This is the rollup for energy.

And it's just getting started.