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
2

Status update: ERC-8329 is now in Last Call through October 19, 2026. Focused technical feedback on the specification remains very welcome.

3

ERC-8329: clarifications for corrections, methodology, and consumers.

Thanks for the work on ERC-8329. An append-only log with exact-period lookup and explicit correction provenance provides a useful way to preserve reporting history without treating each new period as a replacement for the last. The scope boundary is also important: the interface records claims and their history; it does not verify the underlying measurement or establish that reporters and attestors are independent.

As ERC-8329 approaches Last Call on October 19, a few clarifications could make implementation and consumer behavior easier to reason about:

Corrections and methodology transitions. The specification allows corrections to change methodology, while the versioning extension applies active-methodology rules to snapshots. Please state explicitly which methodology a correction must use when the active methodology has changed since the original record. It would also help to clarify whether corrections count as new indicator ordinals for scheduled methodology changes, with a short example covering a correction after a transition.

Correction-chain lookup. A linear chain gives each period one resolvable current snapshot, but consumers may need to traverse that chain to find it. Guidance on expected lookup behavior and the cost of long chains would help implementers. An index or terminal pointer may be useful as an implementation option, without requiring every deployment to adopt one.

Methodology hash and URI. Please define precisely which bytes the methodology hash commits to. The URI should be described as a locator, not a guarantee that the material is public or will remain available. Consumers can verify retrieved material against the hash, but the hash alone does not provide access to it.

Events and indexers. The recording event includes several snapshot fields, while consumers can retrieve the complete record through getSnapshot. A brief statement of which fields require a getter call, and how indexers should distinguish recording order from measurement-period order, would reduce implementation ambiguity.

Attestations and independence. The same-address restriction prevents an address from attesting to its own snapshot, but does not establish organizational or financial independence between addresses. Attestations also remain attached to the specific snapshot, including when that snapshot is later corrected. Keeping these limits explicit will help prevent consumers from treating an endorsement as a transferable approval of the corrected record.

Periods, units, and aggregation. Permitting overlapping periods supports different reporting windows, but does not make their values additive. Consumers remain responsible for applying the relevant methodology when comparing or aggregating records. Documentation should also make clear that unit identifiers and decimal precision encode values; they do not, by themselves, establish semantic equivalence between indicators or units.

These points can be handled as clarifications and implementation guidance without expanding ERC-8329 into a measurement-verification or universal taxonomy standard.

The proposal’s value is a consistent record of what was reported, for which period and methodology, and how the report was later revised. That record should remain clearly distinct from proof that the reported impact is accurate.