We would like feedback on ERC-8325 — Asset Anchor Registry, a draft ERC for binding token contracts or individual token IDs to registry records representing claims about off-chain assets.
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#1853
Spec file: ERCS/erc-8325.md
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.
ERC-8325 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
ERC-8325 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
-
Is registry-scoped exclusivity the appropriate interoperability guarantee, or should ERC-8325 attempt any stronger cross-registry coordination?
-
Is the distinction between whole-contract and token-ID scope sufficiently explicit for ERC-20, ERC-721, ERC-1155, permissioned, and future token designs?
-
Should mutual token-side declaration remain optional, with consumers able to distinguish it from a registry-only assertion?
-
Is separating lifecycle activity from binding validity clear and useful, or would consumers benefit from an additional consolidated query?
-
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 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, fuzz, invariant, and Medusa property tests. The implementation has also been reviewed in an independent Verichains audit.
ERC-8325 is independently deployable. It was introduced alongside five other standalone draft ERCs in the 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.