1. IoT-Enabled Smart Meters & Devices

Summary: Proof starts at the edge. EDMA accepts meter data only when a device is commissioned, its batches are signed at the source, the payload is canonicalized to a stable JSON, and the resulting evidenceHash can be verified by independent attestors. Unsigned, overlapping, or non-canonical data is not admissible to PoV.

Role in PoV

• Produce admissible evidence for energy generation in fixed windows

• Bind identity to data (device certificate → device_id)

• Prevent ambiguity (stable units, sorted/minified JSON)

• Enable One-Claim by making each window uniquely addressable (batch_id + window)

Commissioning & Device Identity

• Device identity: each meter is provisioned with a certificate or public key; on commissioning it is mapped to a device_id (bytes32) in the operator registry.

• Ownership and location: commissioning record includes owner account, site coordinates or grid node, and installation date.

• Calibration: upload calibration certificate and expiry; expired calibration MAY block new attestations by policy.

• Revocation: compromised devices can be disabled in the registry; new windows from a disabled device are rejected upstream.

Measurement Windows & Clocks

• Windowed reporting: meters aggregate generation into windows defined by start_ts and end_ts (UTC seconds).

• No overlaps: a device MUST NOT create overlapping windows; PoV equality checks will reject them.

• Units: report quantity_wh (watt-hours); avoid mixed units.

• Clock discipline: maintain NTP or GNSS sync; include clock_offset_ms if supported.

Secure Signing & Transport

• On-device signing: sign the canonical payload (or its digest) with the device key stored in a secure element/HSM.

• Transport: mTLS/TLS for HTTPS or MQTT; replay protection via nonces and window batch_id.

• Store-and-forward: buffer when offline; send with original timestamps; idempotency via batch_id.

Canonical JSON & evidenceHash

Why: the same reality must hash to the same bytes. Attestors will only PASS when the digest is reproducible.

Canonical rules: sorted keys (ASCII), UTF-8, minified (only , : as separators), numeric fields as integers unless explicitly decimal strings.

Minimal object (energy window):

{"batch_id":"0x<32-byte>","device_id":"0x<32-byte>","start_ts":1698796800,"end_ts":1698883200,"quantity_wh":10000,"nonce":"0x<32-byte>"}

Recommended fields: grid_node, firmware, method, samples, source_file_hash, clock_offset_ms.

Digest: evidenceHash = SHA-256(utf8(canonical_json))

Claim linkage (used by One-Claim): claimId = keccak256(device_id,start_ts,end_ts,quantity_wh,evidenceHash)

Local Validation & Rate Limits

• Sanity bounds: reject negative energy, impossible spikes, or window lengths outside policy.

• Duplicate guard: do not reuse batch_id; enforce monotonic windows per device.

• Throughput control: apply per-device rate limits to prevent floods.

Exceptions & Replacement

• Clock drift: if drift exceeds policy, mark window “needs audit”; attestors may still PASS with notes.

• Meter swap: link old and new device_id via a handover record; do not reuse identifiers.

• Gaps: report explicit missing windows; backfills must reference the original time span.

Privacy & Storage

• No PII on-chain: only hashes, IDs, and links.

• Artifacts off-chain: S3/IPFS/partner vaults with signed URLs; access is logged.

• Selective disclosure: when required, use viewer roles or ZK proofs to reveal attributes without raw data.

Developer Snippets

TypeScript: compute evidenceHash

import { createHash } from "crypto";

export function evidenceHash(canonicalJson: string): `0x${string}` {
  const h = createHash("sha256").update(Buffer.from(canonicalJson, "utf8")).digest("hex");
  return `0x${h}` as const;
}

TypeScript: compute claimId

import { solidityPackedKeccak256 } from "ethers";

export function claimId(deviceId: string, startTs: bigint, endTs: bigint, quantityWh: bigint, evidenceHash: string) {
  return solidityPackedKeccak256(["bytes32","uint64","uint64","uint128","bytes32"],
                                 [deviceId, startTs, endTs, quantityWh, evidenceHash]);
}

Conformance Checklist (meters & integrators)

• Commission device (identity, owner, grid node, calibration).

• Window correctly (UTC, no overlaps, fixed units).

• Canonicalize JSON and compute evidenceHash.

• Sign payload/digest and transmit over mTLS/TLS with nonce and batch_id.

• Publish attestations (MeterReadingBatch.v1 then Verification.v1 by roles incl. AUDITOR).

• Call PoV Gate in the same transaction that mints/settles; Gate reserves and finalizes One-Claim.

• Handle revocation flags from PoV Feed; support rectification if needed.

KPIs to track

• First-pass attestation rate (PASS without manual intervention)

• Verification latency (window close → PoVPassed)

• Overlap/duplicate rate per 1,000 windows

• Clock drift incidents and time to correction

• Flag/rectify cycle time when issues occur

Bottom line: smart meters are not “data sources”; they are the first link in a verifiable evidence chain. Get commissioning, windows, and canonicalization right, and PoV can admit your energy into on-chain settlement with confidence.