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) andclaimId(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,000Carbon Retired (tCO₂e):
sum of reduction_tco2e where retired = trueTime-to-Cash (T2C):
median of settlement_ts − end_ts for settled items (seconds → hours)PoV Health:
percent of items with flagged = false in the periodEDM Burn:
sum of burn_edmEDUSD 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)
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.
Bottom line: the dashboard is not a marketing slide. It’s a thin, honest view over proofs you can click into. If a number is on the page, it can be traced to a claimId and a evidenceHash—and that’s why people will trust it.
Last updated
