Asset Anchor Registry Interface - candidate ERC

ERCs
1

We would like feedback on a candidate ERC for binding token contracts or individual token IDs to registry records representing claims about off-chain assets.

The interoperability problem is narrower than proving legal ownership or the existence of a real-world asset. A token can claim through metadata that it represents an asset, but another contract currently lacks a common way to determine:

  • which registry record the token claims;

  • whether the registry records the same token-to-anchor relationship;

  • whether the binding applies to the whole contract or one token ID;

  • whether the binding is exclusive within that registry; and

  • whether the anchor remains active and the binding remains valid.

The proposed registry stores separate legalHash and evidenceHash commitments and derives a deterministic anchor identifier:


anchorId = keccak256(abi.encode(legalHash, evidenceHash));

It defines explicit domain-separated scopes for whole-contract and token-ID bindings, including an unambiguous representation for token ID zero. The registry enforces one valid binding per anchor and prevents reuse of an active binding tuple within that registry.

Separate token-side interfaces allow a token to declare the registry and anchor it recognizes. A consumer that requires mutual declaration can compare the registry record with the token’s own response. Tokens that do not expose the token-side interface can still be registered, but consumers must then treat the relationship as registry-declared rather than mutually declared.

Registrars may register and bind atomically via registerAndBind to avoid a window between registration and binding; otherwise binding authorization and timing matter for deployments that split those steps.

The lifecycle interface covers structured registration metadata, expiry, monotonic re-attestation, and permanent deactivation. Activity and binding are deliberately separate: an expired or deactivated anchor remains historically bound. An optional recovery interface can invalidate a disputed binding while preserving the record and may allow the tuple to be released for a replacement binding.

Scope boundaries

This proposal standardizes a registry-scoped structural relationship. It does not establish:

  • the existence, ownership, custody, legal validity, or value of an asset;

  • the truth or availability of committed documents;

  • global uniqueness across independent registries;

  • token supply, fractional-allocation, or entitlement integrity; or

  • that every registry deserves equal trust.

Registry selection and governance remain explicit trust decisions for each consumer.

Questions for review

  1. Is registry-scoped exclusivity the appropriate interoperability guarantee, or should the interface attempt any stronger cross-registry coordination?

  2. Is the distinction between whole-contract and token-ID scope sufficiently explicit for ERC-20, ERC-721, ERC-1155, permissioned, and future token designs?

  3. Should mutual token-side declaration remain optional, with consumers able to distinguish it from a registry-only assertion?

  4. Is separating lifecycle activity from binding validity clear and useful, or would consumers benefit from an additional consolidated query?

  5. Is administrative invalidation best kept as an optional recovery interface, given the trust it introduces?

Implementation status

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

This interface is independently deployable. It was introduced alongside five other standalone interfaces in an earlier architecture discussion, but adoption of those other interfaces is not required.

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:

2 Likes