ERC-8329: Subject-Linked Impact Snapshot Log

ERCs
1

We would like feedback on ERC-8329 — Subject-Linked Impact Snapshot Log, a draft ERC for append-only quantitative impact snapshots linked to application-defined subjects, indicators, completed measurement periods, units, and methodologies.

Update — July 09, 2026: ERC number has been allocated. The ERC remains in Draft status and may change based on review.

Formal ERC PR: ethereum/ERCs#1857
Spec file: ERCS/erc-8329.md

Impact measurements are commonly published in reports or application-specific formats. A single mutable on-chain value cannot distinguish a new reporting period from a correction to an earlier period, and replacing the value erases the prior assertion. Generic attestations can represent individual claims but do not by themselves define period lookup, indicator time-series indexing, correction chains, or methodology transitions.

The core snapshot interface records:

  • subjectId and indicatorId;
  • a signed value with explicit decimals and unit;
  • a completed half-open measurement period [periodStart, periodEnd);
  • a required methodology hash and retrieval URI;
  • reporter attribution and recording time; and
  • correction provenance.

Only one original snapshot may occupy an exact (subjectId, indicatorId, periodStart, periodEnd) slot. Later revisions use a linear, fork-free correction chain. Different periods may overlap because monthly, quarterly, annual, rolling, and project-phase measurements can all be legitimate; consumers remain responsible for avoiding double counting.

Two optional interfaces add functionality without making it mandatory for the core log:

  1. An attestation interface stores immutable endorsements or disputes against a specific snapshot. It does not calculate consensus or carry attestations forward to corrections automatically.

  2. A methodology-versioning interface exposes the active methodology for future snapshots and supports immediate or ordinal-scheduled supersession.

The exact reporter address cannot attest its own snapshot, but this is only address-level separation. It does not prove organizational or financial independence.

Scope boundaries

ERC-8329 standardizes representation and lifecycle behavior. It does not:

  • verify measurements, source data, or methodology application;
  • credential reporters or attestors;
  • define a universal indicator taxonomy or scoring model;
  • decide whether overlapping periods are additive;
  • prevent the same underlying impact from being claimed elsewhere; or
  • convert snapshots into carbon credits or other transferable assets.

Questions for review

  1. Is one original per exact period, followed by correction provenance, the right way to provide a resolvable current value?

  2. Should ERC-8329 define a small base set of indicator and unit identifiers, or leave all semantics to external taxonomies?

  3. Should a nonempty methodology URI be mandatory alongside the methodology hash, despite private or access-controlled retrieval requirements?

  4. Are methodology governance and snapshot attestations appropriately separated into optional ERC-165-detectable interfaces?

  5. Should attestations remain append-only even when an attestor later changes its assessment?

  6. Are ordinal-scheduled methodology changes preferable to timestamp-based activation for an append-only reporting stream?

Implementation status

A Solidity reference implementation, optional extensions, and test suite is available in the reference repository.

An example UI suite is also available for non-normative exploration of the interface and its role in the broader titled-asset standards family.

The audited reference commit is caa9b05. It includes unit tests and Medusa property tests. The implementation has also been reviewed in an independent Verichains audit.

ERC-8329 is independently deployable and does not depend on a token, asset registry, or accounting standard. It was introduced alongside five other standalone draft ERCs in the architecture discussion, but those interfaces are optional context rather than dependencies.

Authorship

Chris Turner, David Hay (LinkedIn), Reagan Simpson, and Collins Musyimi.

Developed at Kula, which builds infrastructure for regulated virtual-asset and titled-asset use cases. Reference implementations are open-source; we are proposing ecosystem interfaces, not a Kula-only stack. We are open to additional co-authorship and community contribution beyond Kula.

4 Likes