# What is the M3tering Protocol?
What is it and why?
Conventional energy infrastructure is usually built from the center outward. A large institution finances generation, extends transmission and distribution, installs meters, and enrolls people as customers. This model has built reliable systems in many places. But in several others, the cost of sustaining centralized infrastructure has exceeded the capacity of institutions and customers expansion is too slow, communities face chronic outages, and weak accountability. People may wait decades for dependable service. Distributed energy makes another direction possible
### Reimagining The Grid
Every part (or participant) in an energy network can be understood as a system with a boundary. Energy crosses that boundary as an input or an output. The participating equipment may be radically different, and may play several roles over the course of a day. But it all boils down to a simpler fact: ***An identified system exchanged a measured quantity of energy with the infrastructure around it.***
{% hint style="info" icon="thought-bubble" %}
A home imports electricity from a network and exports electricity from its solar panels. A battery receives energy when it charges and supplies energy when it discharges. A transmission line accepts energy at one point and delivers it at another. An electric vehicle, generator, factory, appliance, microgrid, or entire city can be viewed through the same basic model.
{% endhint %}
The M3tering protocol provides a common way to count these exchanges, authenticate their source, and incorporate them into a shared record. From that simple foundation, much more complex energy systems can be built. It gives various participants in the energy supply chain a common way to establish identity, report activity, and participate in programmable agreements. It turns measurements from real-world energy resources into shared, verifiable records that software can act on. This allows people, devices, applications, and organizations to coordinate around energy and build their own energy networks
A participant may be compensated by their connected peers for producing or transmitting electricity with their assets. Other participants compensate their peers for electricity they've consumed or stored. Across the entire energy supply chain, each participant's meter operates a bilateral contract with each of it's connected peers.
Functioning energy networks can begin with a few connected participants, meters, and their contracts. A solar installation supplies several homes. A shop adds a generator. A clinic adds storage that receives priority during an outage. New participants connect. Additional owners finance new capacity. Eventually, one local network coordinates with another or with the wider grid. At every stage, the shared ledger answers the questions: who contributed energy, who received it, how the network's state changed, and which agreements should respond.
This is especially powerful in places that have never had reliable energy infrastructure. They can bypass legacy centralized institutions, begin locally, expand incrementally with more participant, and connect outward.
> The M3tering Protocol is an open state and communication protocol for energy systems: it turns authenticated energy inputs and outputs into shared state that smart contracts can interpret and participating systems can act upon
One measurement would only describe an event. A sequence of measurements describes how a resource's energy position changes over time. Measurements from many resources describe the evolving state of a network. The protocol is how we maintain a stateful ledger of those counted energy flows. It is state that programs can use. A smart contract can read an authenticated change in energy state and apply rules agreed beforehand. Depending on the application, it might:
* compensate a resource for energy supplied; or establish that an energy-service obligation was met;
* release revenue after an asset demonstrates performance; or the divide revenue among the owners of an asset;
* deduct consumed electricity from a prepaid balance; or reward a participant for reducing demand at a critical time;
The ambition is to provide a minimal, open primitive from which different energy infrastructures can be assembled: locally, incrementally, and according to the needs of the people who depend on them.
{% content-ref url="/pages/bxpA45c7suWsoz2sTLl5" %}
[V2.0 (Current)](/developer-docs/v2.0)
{% endcontent-ref %}
# M3ters
registered protocol identity associated with a physical metering endpoint.
A M3ter is the persistent onchain identity of a smart meter in the M3tering Protocol. It is the protocol object through which a particular physical interface becomes identifiable, ownable, addressable, and usable by smart contracts.
### ERC-721 Non-Fungible Tokens
Every meter participating in the protocol must be distinguishable from every other meter. Its measurements contribute to a particular energy account, its cryptographic key must be discoverable, and applications need a durable identifier through which to reference it.
An ERC-721 non-fungible token (NFT) provides these properties in a standard form.
{% hint style="info" %}
NFTs are unique digital assets that cannot be exchanged on a one-to-one basis unlike fungible tokens. Instead, each NFT has a distinct and indivisible identity, making it unique and valuable in its own right. Learn more [here](https://www.investopedia.com/non-fungible-tokens-nft-5115211)
{% endhint %}
Unlike a fungible token, each NFT has a unique `tokenId`. That identity can persist even when the physical asset changes operator, joins a different application, rotates its signing key, or accumulates a longer operating history. In the protocol, non-fungibility reflects a physical reality. Two devices of the same model are not interchangeable in protocol state because each measures a different system boundary and signs with a different key.
The M3ter NFT therefore provides:
* **unique identity** — one stable token ID for one registered meter identity;
* **key discovery** — a canonical onchain location for the device's public key;
* **ownership and administration** — a standard account with authority over defined identity operations;
* **contract composability** — a reference that application contracts can use in agreements and accounting;
* **provenance** — an onchain history of minting, ownership transfers, and key updates; and
* **extensibility** — a link to descriptive metadata and independently issued attestations.
### Technical functions
The protocol separates these responsibilities: a Nouns-derived ERC-721 system handles issuance, ownership, metadata, and governance, while a separate keystore maps the same token IDs to meter public keys. The **M3ter NFT contract** handles issuance, ERC-721 ownership and transfers. The **keystore contract** associates the same token IDs with Ed25519 device public keys.
```
NFT tokenId 42 ↔ keystore slot 42 ↔ account state index 42
```
The keystore does not issue another token. Entry 42 identifies M3ter NFT #42 because authorization is resolved against the NFT contract and the key is stored at the slot derived from that same ID.
> Separating these responsibilities keeps the cryptographic registry small, stable and most importantly lets the signature authentication (during state evaluation) depend on a predictable key layout used to verify Merkel trie proofs, that include the keys in the Ethereum state root.
#### Minting a M3ter
The Nouns-derived issuance system mints M3ters through recurring auctions rather than an unrestricted public mint. Auction settlement assigns the next token ID, transfers the new NFT to the winner, establishes its governance power, and starts the next auction according to the configured rules.
The exact cadence, reserve price, auction duration, founder allocation, renderer, and proceeds recipient are deployment parameters and should be documented from the deployed Nouns Builder contracts.
#### Registering or rotating the device key
The token owner calls:
```solidity
setPublicKey(uint256 tokenId, bytes32 newKey)
```
The contract binds a 32-byte Ed25519 public key to the token ID and emits:
```solidity
event NewKey(
uint256 indexed tokenId,
bytes32 indexed publicKey,
address from,
uint256 timestamp
);
```
The corresponding private key remains in the meter's secure environment and must never be published onchain. The meter uses it to sign energy payloads. Verifiers retrieve the registered public key and use it to check that a payload was signed by the device identity associated with the token.
Allowing the owner to change the public key supports commissioning, hardware replacement, recovery, and key rotation without discarding the token's stable identity. Applications that depend on key history should follow `NewKey` events and define how they treat measurements around a rotation. The keystore should also enforce unique keys and invalidate stale reverse mappings during rotation. Otherwise an old key may continue to resolve to a token even after `publicKey(tokenId)` has changed. Zero keys and the ambiguity between an absent entry and token ID `0` should be handled explicitly.
#### Looking up identity
The contract exposes both directions of the identity relationship:
```solidity
publicKey(uint256 tokenId) → bytes32
tokenID(bytes32 publicKey) → uint256
```
The first resolves a known M3ter to its current key. The second resolves a public key to its token ID. This allows gateways, provers, explorers, and applications to begin with either identifier.
#### Ownership and discovery
As an ERC-721, the contract supports the standard ownership, approval, and transfer interface. It additionally exposes enumeration functions for discovering the total token supply, tokens by global index, and tokens owned by an account.
Ownership determines who may perform owner-authorized NFT operations such as changing the registered key. Application-specific authority should be checked separately. A controller should not treat every NFT transfer as an unconditional physical operating command unless the application and installation explicitly define that behavior.
#### Metadata lookup
The contract exposes:
```solidity
tokenURI(uint256 tokenId) → string
```
The returned URI points to descriptive metadata for the M3ter. In the current contract, this URI is supplied during minting and there is no public function for changing it later.
### What does a M3ter NFT represent?
Token ownership and physical ownership may coincide, but they are not automatically the same legal fact. Holding a token proves control of the ERC-721 identity under the contract's rules. Whether it also conveys title to hardware, revenue rights, operating authority, a lease, or another legal interest depends on the agreement and law surrounding a particular deployment.
Applications may deliberately attach such rights to the NFT. For example, a project contract could direct revenue associated with a meter to the current token owner, or require the owner to authorize a key rotation. But those effects arise from the application contract and its real-world agreement; they should not be assumed merely from ERC-721 ownership.
The common element is not the type of equipment. It is that the meter observes energy crossing a defined boundary and can authenticate its reports.
In one sentence
> **A M3ter NFT is the persistent onchain identity and cryptographic key registry for a physical metering endpoint, linking its ownership, descriptive context, verified energy state, and application agreements through one stable token ID.**
The NFT makes the meter addressable. The device signature makes its reports authentic. Together, these functions allow a physical energy resource to participate as a first-class actor in the energy internet.
{% content-ref url="/pages/bxpA45c7suWsoz2sTLl5" %}
[V2.0 (Current)](/developer-docs/v2.0)
{% endcontent-ref %}
# V1.0 (Genesis)
The M3tering Protocol specifies a framework for secure and transparent metering of electricity consumption and tracking of the associated transactions, using a combination of secure smart meter hardware and an Arweave-based smart contracts known as SmartWeave contracts.
Each smart meter cryptographically signs its data payload locally before it is broadcasted to node operators for contract execution and to the larger Arweave network for permanent storage. This provides the relevant stakeholders with a way to trustlessly verify the integrity and authenticity of activity on the M3tering protocol. The protocol ensures secure and decentralized interactions with metering data. Each function within the protocol serves a distinct purpose, contributing to a secure, transparent, and decentralized energy metering system.\
\
This following document ion sections outlines the protocol’s core specification, including the format of energy payloads, signature verification, and the interaction between M3ter data and SmartWeave contracts. This specification lays out the technical aspects of the M3tering Protocol to guide developers and integrators in implementing and interacting with this decentralized energy metering solution.
# Data Payload Format
Defining: Smartweave interaction data
***
The core data unit in the protocol is a JSON payload sent from the smart meter, which includes energy consumption data along with cryptographic elements to ensure authenticity. This payload is carefully structured in the following order:
1. **Data**: A stringified array that contains:
1. **Nonce**: A sequential integer that serves as a unique identifier for each message, helping to prevent replay attacks.
2. **Voltage**: The average voltage measurement, recorded in volts (V), with a precision of two decimal places. This value is typically averaged over a one-minute interval.
3. **Current**: The average current reading, in amps (A), also recorded over a one-minute interval and to two decimal places.
4. **Energy**: The computed energy usage, in kilowatt-hours (kWh), calculated based on the voltage and current readings over the same interval. This value is highly precise, recorded to seven decimal places.
2. **Signature**: A Base64-encoded cryptographic signature of the data above, generated by the smart meter’s hardware. This signature verifies that the data originates from an authenticated meter and has not been tampered with.
3. **Public Key**: The Base64-encoded public key of the meter hardware that signed the data. This key uniquely associates the payload with a specific meter and allows external systems to validate its authenticity.
{% hint style="info" %}
The signature and public key within the payload are encoded using Base64. This encoding allows binary data to be easily represented as ASCII text, simplifying transmission across systems that may be resource constrained such as microprocessors in the smart metering hardware, and communication networks such as LoRaWAN.
{% endhint %}
{% hint style="warning" %}
Paying close attention to the exact structure and order of each meter payload is essential, as any change could result in misinterpreted data, incorrect energy balance calculations, or even invalidation of the cryptographic signatures. \
Each payload array is organized in a specific sequence: it begins with a nonce, followed by voltage, **current**, and the computed energy reading. This sequence of values is then converted into a single string and placed in an outer array alongside two additional components: the signature string (which is the cryptographic signature of the data string) and the meter’s public key. Maintaining this structure precisely as shown ensures the protocol’s reliability and integrity.
```
========================================================================
PAYLOAD: ["[nonce, voltage, current, energy]", "signature", "publicKey"]
========================================================================
```
{% endhint %}
#### **Example Payload**
```json
{
"msg.fmt": [
"[2, 213.7, 0.38, 0.007420]",
"9C7lPdznR9pymAIvjDPmm/mVX/uUTemapJRb8yzGKvG8or43u6V97oDPcW7ZP9HeHRZrGEf1iIkyLixAVdWsDg==",
"JR2VNczJacY86eyyCBr1iTTT7vxKtYbfqegeTkXJD88="
]
}
```
In this example:
* The signed data string is `"[2, 213.7, 0.38, 0.007420]"`, where 2 is the nonce, 213.7 is the voltage, 0.38 is the current, and 0.007420 is the computed energy.
* The signature and public key fields are Base64-encoded strings representing signature and public key, respectively.
## Signature Scheme
To ensure data integrity and authenticity, the M3tering Protocol employs the Ed25519 digital signature scheme. This scheme is a well-regarded cryptographic method known for its high performance and strong security guarantees. Each payload is signed by the meter’s private key, which, in conjunction with the associated public key, ensures that data can be verified and trusted by external systems or entities receiving it.
* **Simplicity**: Ed25519 is simpler and easier to implement than ECDSA, which is a considerable benefit for IoT devices with limited resources.
* **Performance**: Ed25519 provides faster signature generation and verification, which is crucial for IoT devices operating in real-time environments. The reduced computational load can lead to significant power savings and memory efficiency, which can significantly improve the overall performance of our devices and the M3tering Protocol as a whole.
* **Compatibility**: While secp256k1 is widely used in the blockchain space, curve25519 is gaining traction due to its compatibility with various platforms and libraries. This compatibility simplifies integration efforts and ensures a seamless experience for developers working with our devices.
* **Compact Signatures**: Ed25519 generates smaller signature sizes, which is crucial for IoT devices with constrained data transmission capabilities. The efficiency gains could lead to reduced transmission times and enhanced device responsiveness.
* **Long-term Viability**: It's designed with long-term security in mind, making it a reliable choice for the future.
{% hint style="info" %}
you can learn more about ED25519 and other comparable schemes [here](https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/)\
The blog also provides a rational for our adoption of the ED25519 signature scheme.
{% endhint %}
## Verification
The M3ter NFT contract on the EVM also serve as a key registry for each hardware smart meter. During the initial setup, each hardware meter generates its own ED25519 key pair and it posts the public key to this M3ter contract in a registration event, binding it to a specific tokenId that represents this particular hardware device. To authenticate any subsistent data from the smart meter, the public key stored in the M3ter contract can be used to verify the digital signature attached to the payload.
This setup provides a secure and tamper-resistant method for linking each data point to its specific device, ensuring the integrity and traceability of the data stream from the physical meter to its digital representation as an NFT on-chain.
# State Evaluation (Smartweave)
The M3tering protocol uses the Arweave network to permanently log and archive all interaction data on the protocol, ensuring that a record of energy consumption and associated payments remain available and immutable for the foreseeable future. A novel smart contract standard know as SmartWeave, is used to compute the state of PPA contracts on the protocol.
{% hint style="info" %}
SmartWeave contracts on Arweave are a type of smart contract specifically designed for use on the Arweave blockchain. Rather than executing code in real time (like on Ethereum), SmartWeave contracts rely on nodes to read the entire history of a contract’s interactions to compute its current state, an idea know as "Lazy Evaluation". This approach makes SmartWeave contracts scalable and ideal for decentralized, permanent storage applications, as it reduces computational demand on the network while prioritizing data availability and integrity. See more [here](https://dev.to/fllstck/smart-contracts-on-arweave-46l8)
{% endhint %}
While payments still happen on a secure, deterministic EVM contract using DAI, SmartWeave contracts are be used to process metering data and manage interactions between users and the smart metering infrastructure.
## Smartweave Contract Functions
The protocol defines three core functions within its Smartweave contracts to handle different types of interactions: `register`, `topup`, and `meter`.
### **The Register Function**
The `register` function is used for retrieving a smart meter's public key information. This public key is essential for authenticating any data that the meter sends. To do this, it requires a JSON object that includes an EVM transaction hash.
Example input:
```json
{
"input": {
"function": "register",
"txHash": "0x5cfeb3b6e68c9cbdd96e6f7db033900514009db660adc3c81d98495e6600506b"
}
}
```
During registration, the transaction emits a smart contract event that contains the token ID, public key, and address of the sender, along with a timestamp, following the ABI below:
### **The Topup Function**
The `topup` function enables offtakers to add balance or credits to their accounts. Similar to the `register` function, it requires an Ethereum transaction hash to validate the top-up transaction. This transaction hash is used to retrieve the payment amount and the current electricity tariff from the Ethereum smart contract. The participant’s electricity balance is then updated accordingly.
Example input:
```json
{
"input": {
"function": "topup",
"txHash": "0x5cfeb3b6e68c9cbdd96e6f7db033900514009db660adc3c81d98495e6600506b"
}
}
```
For the `topup` to be processed correctly, the transaction is expected to emit a smart contract event that provides details on the top-up, including the amount paid, the tariff rate, the source address, and the timestamp, with the following ABI:
```solidity
event Revenue(uint256 indexed tokenId, uint256 indexed amount, uint256 indexed tariff, address from, uint256 timestamp)
```
### **The Meter Function**
The `meter` function is the primary function that processes data collected from smart metering hardware. It expects the payload from the meter, containing the signed data, signature, and public key. This function would compute the offtaker electricity balances and deduct usage based on real-time electricity consumption data payload posted to Arweave. For more information about this payload see [Data Payload Format](/developer-docs/v1.0/data-payload-format) documentation
Example input:
```json
{
"input": {
"function": "meter",
"payload": [
"[2,213.7,0.38,0.007420]",
"9C7lPdznR9pymAIvjDPmm/mVX/uUTemapJRb8yzGKvG8or43u6V97oDPcW7ZP9HeHRZrGEf1iIkyLixAVdWsDg==",
"JR2VNczJacY86eyyCBr1iTTT7vxKtYbfqegeTkXJD88="
]
}
}
```
# Core Contracts
Overview of the 4 main source codes repositories implemented under the M3tering Protocol
{% embed url="" %}
## 🤖 M3ter: ERC-721 contract
#### Deployment Address: [0x39fb420Bd583cCC8Afd1A1eAce2907fe300ABD02](https://gnosis.blockscout.com/token/0x39fb420Bd583cCC8Afd1A1eAce2907fe300ABD02)
M3ter is an ERC-721 (NFT) contract where each NTF represent a smart metering device registerd on-chain by it's manufacturer. Similar to Helium device NFTs on Solana, or Wicrypt device NFTs on polygon. These devices contain cryptographic secure elements used to sign energy consumption data they measure. the purpose of `keyByTokenId` is to map an NFT's `tokenId` to the cryptographic `PublicKey` for a device (bytes 32 key for ED25519 digital signature scheme), while the `tokenIdByKey` is used to reverse map the above mentioned `PublicKey` to the NTF's `tokenId`
{% embed url="" %}
## 🪙 Solaxy: ERC-20 as ERC-4626 contract
#### Deployment Address: [0xF4F3c1666E750E014DE65c50d0e98B1263E678B8](https://gnosis.blockscout.com/token/0xF4F3c1666E750E014DE65c50d0e98B1263E678B8?tab=holders)
Solaxy is an ERC-20 token contract that implements a linear bonding curve with sDAI as the reserve currency. The bonding curve allows users to buy and sell Solaxy tokens directly from/to the contract at a dynamic price determined by the curve's slope.
Solaxy extends its functionality by providing support for [`ERC-4626`](https://eips.ethereum.org/EIPS/eip-4626); a tokenized vault interface. This interface allows the Solaxy contract to interact with other DeFi protocols and platforms seamlessly. `ERC-4626` integration enhances the capabilities of Solaxy in the context of token bonding curves.
{% embed url="" %}
## ⚙️ Protocol: PPA pre-payment contract
#### Deployment Address: [0x2b3997D82C836bd33C89e20fBaEF96CA99F1B24A](https://gnosis.blockscout.com/address/0x2b3997D82C836bd33C89e20fBaEF96CA99F1B24A?tab=contact_code)
Represents the onchain components of the Power Purchase Agreements (PPAs) between the Providers and Off-takers. The `pay` function is executed by the end users to pay xDAI tokens to the owner of their assigned M3ter at the time of payment.
{% embed url="" %}
### 📃 Listings: M3ter ERC-721 marketplace
#### Deployment Address: [0x1f15510D538bEC23E0ea81600EEe826514866204](https://gnosis.blockscout.com/address/0x1f15510D538bEC23E0ea81600EEe826514866204)
Simple NFT marketplace contract for the sale of M3ter NFTs. Allows users to list M3ters for free and to purchase other M3ters with xDAI .
{% embed url="" %}
# Audits
Code audits on the M3tering protocol code base
# Secure3 Audit Contest
The current codebase for the M3tering protocol has been audited by Secure3,
## Contest Details
Secure3’s audit contest organizes decentralized certified auditors in the form of an audit competition. View details of the M3tering contest using the link below.
{% embed url="" %}
## Secure3 Audit Report
This report is prepared for the Metering Protocol to identify vulnerabilities and issues in the smart contract source code.
{% file src="/files/UZ07lPe2OHky7qJ8mdz0" %}
> source:
# V2.0 (Current)
The M3tering 2.0 (V2) represents the next evolution of decentralized energy metering and market infrastructure. Building on the learnings of the genesis version and the foundational principles of secure, verifiable metering for peer-to-peer energy service markets, V2 introduces a suite of enhancements designed to meet the demands of broader protocol adoption and cross-chain deployments. It introduces a redesigned meter payload format, a trustless state evaluation engine powered by zk-rollup, and enhanced cross‑chain interoperability.
This documentation is intended for protocol integrators, application developers, infrastructure operators, and energy service providers. It outlines the core architectural changes in V2, details new on‑chain and off‑chain components, and provides guidance for deploying and interacting with the M3tering protocol.
By integrating seamlessly with Ethereum Mainnet and a broad spectrum of Layer 2 environments—such as Base, Arbitrum, Optimism, Celo, and UniChain—M3tering 2.0 delivers a unified framework for decentralized energy applications.
## **Key Features**
**M3ter Rollup, Ethereum Mainnet and L2 Integration** \
In V2, all meter state is now committed to Ethereum using succinct zero knowledge proofs, which ensures that applications and smart contracts across Ethereum L1 and L2s can access a single, canonical source of truth. Through trustless interoperability primitives like [CCIP Read (ERC-3668)](https://eip.tools/eip/3668), [L1SLOAD (RIP-7728)](https://eip.tools/rip/7728), and [Crosschain Tokens (ERC-7802)](https://eip.tools/eip/7802), developers can build cross-chain more powerful apps that interoperate across layer-1 and layer-2 environments—unlocking use cases that were previously infeasible onchain. By coming home to Ethereum Mainnet for ultimate security, and integrating and a broad spectrum of Layer 2 environments—such as Base, Arbitrum, Optimism, Celo, and UniChain—V2 delivers a unified framework for decentralized energy applications.
**Compact and Extensible Meter Payloads**\
A redesigned payload format uses tightly packed byte arrays—4 bytes for nonce, 4 bytes for energy reading, and 64 bytes for signature—with optional extension slots (voltage, device ID, geolocation) to future-proof data capture without bloating transaction size.
**Modular Client Node: P2P Gossip Networking and Data Publishing**\
The M3tering client node "Console" is designed as a modular and extensible component, enabling direct participation in the network without relying on intermediaries. Each participant can run a lightweight client node—no centralized relayer needed. By enabling p2p operation and diversity of implementation, V2 strengthens the protocol’s neutrality, reliability, and developer adoption across ecosystems. The modularity of the node software also supports optional plug-ins for
* data propagation via gossip and pub/sub protocols (eg Libp2p, Waku or Streamr)
* custom archiving strategies (e.g. Ethstorage, Ethswarm, Filcoin/IPFS, Arweave or Cloud providers).
Together, these improvements make M3tering Protocol the most versatile, and developer-friendly stack for decentralized energy metering, energy asset tokenization, and P2P energy markets. In the pages that follow, you will find detailed specifications and reference implementations to help you integrate, extend, and contribute to the M3tering ecosystem.
# Data Payload Format
Defining: Rollup transaction data
## Overview
At the heart of the protocol is the meter payload, a tightly packed binary data structure that carries essential information about energy consumption. By packing fields into fixed‑length byte‑segments, we minimize bandwidth requirement and storage costs. Beyond the core data, the payload format is also designed to be **extendable**: future fields (e.g. voltage, geolocation, device identifiers) can be tacked on without breaking the primary payload parser.
### Payload Structure
At its core, the meter payload is a tightly packed sequence of bytes designed for minimal overhead and efficient transmission. The base payload consists of a nonce, an energy value, and a digital signature. This structure is visualized below:
```
Byte Offset Length Field Description
––––––––––– –––––– ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
0 4 B Nonce Big‑endian uint32, strictly increasing counter
4 4 B Energy Big‑endian uint32, kWh × 10⁶
8 64 B Signature Ed25519 signature over bytes 0–7
[72] … Extension Optional extra fields (see below)
```
***
### Core Payload Fields
```python
4 bytes ‖ 4 bytes ‖ 64 bytes
└─ Nonce ─┴─ Energy int ──┴─ Ed25519 signature ──┘
```
The two most critical components of the core payload are the nonce and the energy value.
* **Nonce (4 bytes)**: The **nonce** is a strictly increasing 32‑bit unsigned integer (number used once). It ensures that each payload is unique, preventing replay attacks where an attacker could resend a previously captured payload: every new reading increments this counter. Encoded as big‑endian, it occupies bytes 0–3 of the payload.
* **Energy (4 bytes)**: The **energy** field records the cumulative kilowatt‑hours (kWh) measured, with **six decimal places** of precision. However, for the purpose of data transmission and signing, this decimal value is converted into an integer. This is achieved by multiplying the kWh value by 106 to shift six decimals and converted to a 32‑bit big‑endian integer. Those 4 bytes occupy offsets 4–7 of the payload.
#### Signing and Verification
To ensure the integrity and authenticity of the meter data, each payload is digitally signed. The process ensures that the data originates from a trusted meter and has not been tampered with in transit. The signature is generated using the **Ed25519 digital signature algorithm**, known for its high performance and strong security guarantees.
{% hint style="info" %}
you can learn more about ED25519 and other comparable schemes [here](https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/)\
The blog also provides a rational for our adoption of the ED25519 signature scheme.
{% endhint %}
Once the first 8 bytes (nonce‖energy) are assembled, the meter uses its private key to compute a 64‑byte signature over exactly those 8 bytes. The resulting 64-byte signature is appended to the nonce and energy values, forming the complete 72-byte core payload.
```
message = nonce_bytes || energy_bytes (8 bytes total)
signature = Ed25519.sign(privateKey, message) (64 bytes)
payload = message || signature
```
To verify the payload, a verifier first unpacks the first 8 bytes message of the payload (containing the nonce and energy), followed by 64 bytes that contains the corresponding signature to the message. Using the meter's public key, the verifier checks if the signature is valid for the extracted 8-byte message. Once verified, the nonce and raw energy integer are unpacked from the first 8 bytes of the payload and then the energy value is re‑scaled by 10-6 to recover the original kWh reading.
```
received_nonce_energy = payload[0..7]
received_sig = payload[8..71]
valid = Ed25519.verify(publicKey, received_nonce_energy, received_sig)
if valid:
decode_nonce(received_nonce_energy[0..3])
decode_energy(received_nonce_energy[4..7])
else:
reject("Invalid signature")
```
***
### Payload Extension
To support richer logic and analytics, the payload can be extended to include additional data points beyond the core nonce and energy values. When extended, the additional fields are appended after the core payload's signature. The extension provides supplementary information such as voltage measurement, the meter's identity and location information. Parsers that don’t recognize it can simply ignore any trailing bytes beyond offset 72.
{% hint style="info" %}
It is important to note that the extension data is **not** covered by the core signature. The primary signature only guarantees the integrity of the nonce and energy.
{% endhint %}
#### Common Extension Data
1. **Voltage** (2 bytes): The current voltage reading.
2. **Identifier** (32 bytes): A unique identifier for the meter, which can be either its public key or a specific Token ID.
3. **Longitude** (3 bytes): The geographic longitude of the meter.
4. **Latitude** (3 bytes): The geographic latitude of the meter.
```python
… ‖ 2 bytes voltage ‖ 32 bytes device ID ‖ 3 bytes longitude ‖ 3 bytes latitude
```
#### Extension Data Encoding
The data within the extension block follows a similar integer-encoding scheme to maintain efficiency.
* **Voltage:** The voltage has a precision of one decimal place. It is multiplied by 10 to be encoded as a 2-byte integer. **Example:** A voltage of `230.5 V` is encoded as `2305`.
* **Longitude & Latitude:** Geographic coordinates have a precision of five decimal places. They are multiplied by 105 to be encoded as 3-byte integers. **Example:** A latitude of `-4.81667` is encoded as `-481667`.
# State Evaluation (Rollup)
A Verifiable Computation Layer for Meter Data
The M3tering Protocol introduces a specialized, high-throughput system for aggregating vast amounts of time-series data from smart meters and making it verifiably available to on-chain applications. At its core, the system functions as an **Application-Specific** [**Rollup**](https://ethereum.org/en/developers/docs/scaling/zk-rollups/), leveraging the power of zero-knowledge proofs to execute complex computations off-chain while inheriting the full security and data availability guarantees of the Ethereum mainnet.
The primary challenge this system addresses is the impracticality of processing high-frequency Internet of Things (IoT) data directly on a Layer 1 blockchain. A smart meter might report energy consumption every minute, and a network of thousands of such meters would generate an overwhelming volume of transactions, leading to prohibitive gas costs and network congestion. Our solution is to aggregate this data off-chain and then periodically commit a succinct, cryptographically secured proof of the new global state to Ethereum. This allows smart contracts—for applications like prepaid energy billing, tokenized carbon credits, or renewable energy certificates—to access trustworthy, up-to-date energy consumption data without bearing the cost of processing every individual data point.
## Aggregation and Proving (off-chain)
An integral part of our rollup’s trust model is a formally verified cryptographic pipeline built using [**SP1** (Succinct Prover 1)](https://docs.succinct.xyz/docs/sp1/introduction), a high-performance zero-knowledge virtual machine (ZKVM) developed by Succinct Labs. SP1 enables arbitrary Rust programs to be executed in a provable environment and verified succinctly on-chain using a zk-SNARK proof system. This approach allows the M3tering Protocol to compress high-volume smart meter computations into compact proofs that can be validated on Ethereum at low cost. The meter aggregation logic is written in such a Rust program and compiled down to SP1 bytecode that targets [**SP1 Groth16 proofs**](https://docs.succinct.xyz/docs/sp1/generating-proofs/proof-types#groth16-recommended). Provers are stateless and ephemeral: they reconstruct all necessary state from Ethereum (via state blobs and MPT proofs) and does not need to maintain any historical data. This architecture makes proving accessible to any participant without requiring persistent infrastructure or privileged roles.
Shows how the state transition lifecycle and how the prover can operate statelessly, relying entirely on the Ethereum world state
A prover begins its work by gathering a set of inputs. These inputs are the foundation upon which the new state will be verifiably built. They include the last known state bobs for both nonces and energy, a recent Ethereum blockhash to act as a trust anchor, a collection of unprocessed meter data transactions, and cryptographic proofs of the meters' public keys.
The prover fetches the bytecode of the latest nonce and energy `SSTORE2` contracts directly from Ethereum. These blobs represent the starting point for the new computation. The prover then selects a recent block from the Ethereum chain, typically one within the last 256 blocks, and retrieves its blockhash. This blockhash is critical, as it corresponds to a specific, immutable state of the Ethereum world computer. It is against this state that all public key validations will be performed.
With the state anchor established, the prover uses the `eth_getProof` JSON-RPC method. This powerful function allows the prover to request a [Merkle-Patricia Trie (MPT)](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) proof for a specific piece of data within Ethereum's state. For each meter with pending transaction it intends to process, the prover fetches an MPT proof that demonstrates the value of the meter's public key as stored in the m3ter NFT contract at the checkpoint block. This mechanism ensures the prover is using the authentic, on-chain registered public keys for signature verification.
Illustrates how eth_getProof provides a verifiable link from a known blockhash down to a specific storage slot containing a meter's public key
Once all inputs are gathered, the SP1 program executes its core logic. It iterates through the list of unseen data transactions. For each transaction, it performs two critical checks. First, it verifies the [ED25519](https://www.google.com/search?q=https://en.wikipedia.org/wiki/EdDSA%23Ed25519) signature of the transaction using the public key whose authenticity was just confirmed via the MPT proof. Second, it checks the transaction's nonce, ensuring it is exactly one greater than the last known nonce for that meter from the input blob. This sequential nonce prevents replay attacks and guarantees that each transaction is processed exactly once.
If a transaction passes both validations, its energy consumption value is added to the meter's cumulative total, and its nonce is incremented. After processing all valid transactions in the batch, the prover constructs the `new_nonce_blob` and `new_energy_blob`. These are formed by concatenating the updated 6-byte values for each meter, indexed by their `tokenId`.
Finally, the SP1 program generates a Groth16 zk-SNARK proof of this entire computation. The proof cryptographically attests that the new state blobs were correctly derived from the initial state blobs according to the rules of the protocol. The program's output consists of the proof itself and a set of public outputs that the proof commits to. These public outputs are the keccak256 hashes of the initial and new state blobs, along with the checkpoint blockhash, which are essential for on-chain verification.
{% embed url="" %}
## Verification and State Update (on-chain)
With the proof and new state blobs in hand, the prover submits a transaction to the M3tering rollup contract on Ethereum. This transaction includes the proof, committed state blobs, and the anchor block number. The rollup contract first uses the `BLOCKHASH` opcode to retrieve the blockhash for the specified anchor block number. It then passes this retrieved blockhash, along with the other public outputs and the proof, to the SP1 Groth16 verifier. If the verifier confirms the proof's validity, the rollup contract proceeds to deploy the new nonce and energy blobs.
These blobs are simple, contiguous blocks of data. Each meter is allocated a 6-byte slice within the blob, indexed by its `tokenId`. For a meter with `tokenId = i`, its nonce can be read from `bytes 6*i` to `6*(i+1)-1` of the nonce blob. The aggregated state of all meters is stored on-chain using the [SSTORE2](https://www.google.com/search?q=https://github.com/solidstate-network/solidstate-solidity/blob/master/contracts/utils/SSTORE2.sol) pattern. This technique stores data in the bytecode of a deployed contract, offering significant gas savings for writing and reading large, static data blobs compared to traditional `SSTORE` operations. This structure is highly efficient for on-chain parsing but imposes a hard limit on the system's capacity. Due to the Ethereum contract code size limit of 24kb ([EIP-170](https://eip.tools/170)), the maximum indexable byte is `0x6000`. This translates to a maximum `tokenId` of `0x1000`, limiting the system to 4096 meters per rollup instance. Two separate contracts are maintained for each state update: one for meter **nonces** (to prevent replay attacks) and one for their **cumulative energy sums**.
The deployment uses `CREATE2` for deterministic addressing. The unique salt for the deployment is the `chain length`—the sequential number of this state update since the genesis. This elegant mechanism ensures that the address of each historical state blob can be easily recomputed, allowing applications to "time-travel" and query the system's state at any point in its history simply by knowing the update number.
The raw transaction data processed in the batch is also posted to Ethereum's Proto-Danksharding blob sidecar for cost-effective, short-term data availability, and simultaneously archived to long-term storage solutions like Arweave or Filecoin for permanent verifiability.
{% embed url="" %}
## Other Components
**M3ter Tokens (ERC721)**
Introduced on page [M3ter NFTs](/developer-docs/m3ters), The M3ter contract serves as both a digital registry of asset ownership and a keystore for smart meter identities. Specifically, each token maintains a 32-byte Ed25519 public key, mapped in contract storage to it's tokenId, which is used to verify the authenticity of data transmissions sent by the corresponding physical meter. Beyond identity binding, the NFT's metadata can also link to external attributes describing the physical asset—such as location, capacity, certification, or grid integration—via attestations published using the Ethereum Attestation Service (EAS). These attestations provide a decentralized way to associate rich contextual data with the M3ter NFT while maintaining compatibility with Ethereum's trust mode
{% embed url="" %}
#### **Peer-to-Peer Network**
Nodes running the off-chain client software form a p2p network using protocols like [Waku](https://waku.org/) or [Streamr](https://streamr.network/). This network is used to gossip and share pending meter data transactions before they are aggregated into a proof.
{% embed url="" %}
### Fork Mechanism
Forking manifests as a deliberate migration to a new smart contract verifier, preserving historical integrity while enabling protocol evolution. This mechanism allows possibly contentious upgrades like modifications to data formats, proof systems, or validation rules to be implemented without centralized upgrade controls, but instead relying on social consensus among participants to adopt changes. At its core, a fork begins with the deployment of a fresh rollup verifier contract on Ethereum. This new contract is initialized not from scratch but by inheriting a genesis state derived from a specific checkpoint in the prior contract's history. This provides a verifiable chain of zk proofs that attest to the correct computation of all state transitions up to the fork point while ensuring that the new contract can provably continue from a validated snapshot without rewriting history. Once deployed, the new verifier operates independently, accepting submissions of fresh zk-proofs for ongoing data batches.
New proofs extend the chain, but does not force a ecosystem-wide transition like upgradable smart contracts would. It instead, would allows for multiple parallel verifier contracts to exist and applications, such as DeFi integrations, payment processors, or user interfaces, then decide autonomously which contract to recognize as their source of truth. This choice could be guided by community governance, economic incentives, or rough consensus within the M3tering ecosystem. For instance, if a bug is discovered in the verifier logic or a scaling enhancement is proposed, developers can launch the updated contract, and rally support for adoption. Over time, network effects typically consolidate around a single canonical chain, but the design accommodates experimentation and recovery from disputes.
Developers using or integrating with the M3tering protocol V2 should have this in mide and make provision for some fork choice mechanism in their applications. Likewise app users should also monitor community channels for any proposed forks, as adoption decisions directly influence application behavior and data trustworthiness.