Subject-Linked Compliance Event Log - candidate ERC

ERCs
1

We would like feedback on a candidate ERC for append-only, subject-linked compliance-event records with attribution, evidence commitments, typed parties, versioned payloads, indexing, and correction provenance.

Existing token and compliance standards primarily define behavior: transfer eligibility, holder identity, freezes, forced transfers, and other lifecycle operations. Applications still represent the resulting records through custom events, token-local state, generic attestations, or off-chain databases. That makes it difficult for contracts, indexers, auditors, and reporting systems to query comparable subject-level histories across implementations.

Each record contains:

  • an application-defined subject and subject type;

  • event type and outcome;

  • msg.sender as the technical recorder;

  • a separately declared authority or mandate;

  • parties with explicit roles;

  • a nonzero evidence commitment and optional evidence URI;

  • a versioned payload profile and payload;

  • an operation reference; and

  • occurrence, recording, and correction data.

Events are stored per subject and indexed by exact event type. The proposal defines base identifiers for common lifecycle actions, outcomes, authorities, party roles, and ABI-encoded payload profiles while allowing namespaced custom extensions.

Corrections are additive. A correction is a new event linked to an earlier record, and the corrected record receives a forward pointer to its successor. Each event can have at most one successor, preventing correction forks while preserving the complete history. Helpers resolve the terminal event in a correction chain.

The actor and authority fields are intentionally distinct. The actor proves which authorized address submitted the bytes. The authority field records the basis that actor claims; the log does not authenticate the legal or regulatory authority itself.

Scope boundaries

This is a reporting interface, not a compliance engine. It does not define or prove:

  • holder identity or eligibility;

  • transfer restrictions or token enforcement;

  • truth of an event or occurrence of the underlying action;

  • legal authority or regulatory compliance;

  • evidence authenticity or availability; or

  • semantic validity of every event-type, outcome, and payload combination.

Applications remain responsible for authorization, policy validation, privacy, and linkage to the underlying operation.

Questions for review

  1. Is an opaque subject identifier broad enough for tokens, addresses, assets, cases, and policies without sacrificing interoperability?

  2. Is separating the technical actor from the claimed authority useful and sufficiently clear?

  3. Should the base ERC define common payload profiles, or only a generic versioned payload envelope?

  4. Is a single-successor correction chain preferable to allowing competing correction branches?

  5. Should the party-count and payload-size limits be normative interoperability requirements or reference-implementation choices?

  6. Are the stored query surfaces worth the on-chain cost compared with an event-only design?

Implementation status

A Solidity reference implementation, constants library, and test suite is available at audited commit caa9b05, including unit tests and Medusa property tests. The implementation has also been reviewed in an independent Verichains audit.

This interface is independently deployable and does not require a particular token or identity standard. It was introduced alongside five other standalone interfaces in an earlier architecture discussion, but those interfaces are not 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.

The formal ERC submission is available here:

1 Like