4. ESG Reporting & Dashboards

Summary: ESG reports in EDMA are generated from the same immutable lineage that drives settlement: evidenceHash → claimId → proof mint → asset move/retirement. Reports are machine-readable, auditable, and simple to understand. Energy outputs are in Wh; carbon in tCO₂e. Every figure links back to on-chain proofs.

What the report shows

For a chosen period and scope (for example, a company, site, or project), the dashboard summarizes: how much energy was generated and retired, how many carbon credits were retired, how fast items moved from verification to cash, and whether anything is currently flagged. Each number is backed by a precise list of windows or tokens and their proofs.

Core fields the report relies on (always present)

  • device_id, start_ts, end_ts, quantity_wh (energy windows)

  • evidenceHash (SHA-256 of canonical JSON) and claimId (route-agnostic uniqueness)

  • method_hash, baseline_wh, delta_wh (when methods apply)

  • reduction_tco2e (carbon), token_id (Energy NFT or Carbon Credit NFT), retired (boolean, carbon)

  • settled_edusd (cash leg), fee_edm, burn_edm (protocol fee/burn)

  • flagged / frozen (current PoV state, if any)

These are enough for anyone to double-check totals.

Aggregations the dashboard computes

Energy generation is the sum of quantity_wh for windows that passed PoV in the period, shown as Wh and converted to MWh for readability. Carbon impact is the sum of reduction_tco2e for tokens retired in the period. EDM economics show total fee_edm and burn_edm tied to those settlements. Nothing is guessed; everything is an add-up of verified rows.

Key widgets (simple and auditable)

  • Total Energy (MWh): sum of quantity_wh ÷ 1,000

  • Carbon Retired (tCO₂e): sum of reduction_tco2e where retired = true

  • Time-to-Cash (T2C): median of settlement_ts − end_ts for settled items (seconds → hours)

  • PoV Health: percent of items with flagged = false in the period

  • EDM Burn: sum of burn_edm

  • EDUSD Settled: sum of settled_edusd

These few widgets cover the questions most teams ask: “how much, how clean, how fast, and what did it cost.”

Output structure (one simple JSON you can export)

Important: the hash is the SHA-256 of the exact UTF-8 bytes of this report JSON. Pin it alongside the raw lists so auditors can lock the view.

How numbers are produced

Energy total in MWh:

Carbon retired:

EDM burn:

Median Time-to-Cash:

These are easy to check by hand if needed.

API patterns

Fetch a summary:

Fetch the rows behind it:

Each row includes evidenceHash, claimId, window fields, token ids, settlement figures, and flags. That’s enough to re-aggregate and match the dashboard.

What the dashboard highlights

It calls out the totals, then shows a small table of the top sites and any flagged items. A flagged row explains why in a short reason like SPIKE_RATE or REPLAY_NONCE, with a link to the on-chain event. If there are no flags, the report says so explicitly.

Privacy and access

No PII is placed on-chain. The dashboard links to URIs that may require short-lived signed URLs to download the canonical JSON or raw exports. Access attempts are logged. If you need to show a regulator everything, you can issue a time-limited “viewer” token for the report.

Versioning and governance

The schema name is in schema (for example, esg_report.v1). If a field changes meaning, bump the version. The method_hash for any baseline math and the inputs_hash for external series are included in the lineage so reviewers can reproduce values.

Conformance checklist

Produce totals from verified rows only; use quantity_wh (Wh) and UTC seconds; display PoV states clearly; include evidenceHash and claimId in the downloadable rows; compute and store the report hash; keep labels readable.

Drawing

Last updated