Thesis: No composition of existing ERC standards appears to cover the full titled-asset layer: structural asset-to-token binding, deterministic document-bundle commitments, directional transfer-domain rules, compliance event recording, impact snapshots with optional attestation, and standardised NAV reporting. We have split that layer into six candidate ERC interfaces. Each is designed to deploy and add value on its own; composition is optional, and the split itself is part of what we want feedback on.
See Materials below. Prior-art corrections and co-authorship welcome.
Update — July 09, 2026: ERC numbers are now allocated for all six drafts and references updated. This parent thread remains the umbrella architecture discussion for draft ERC boundaries, prior art, overlap, composition, and whether any interfaces should merge, narrow, or be dropped.
Update — July 5, 2026: individual Magicians threads and ethereum/ERCs PRs were opened for each draft. This thread remains the umbrella architecture discussion: boundaries, prior art, overlap, and whether any interfaces should merge, narrow, or be dropped.
Overview
We are proposing a family of six ERC interfaces for titled asset infrastructure on EVM: real estate, concessions, natural resource rights, and other instruments where legal title exists independently of the ledger.
Existing standards such as ERC-3643, ERC-7943, ERC-4626, and ERC-7208 describe important parts of how tokens behave, how compliance checks are exposed, how vault shares work, or how on-chain data can be structured. They do not, as far as we can tell, standardise the layer that binds a fractional instrument to a specific legally anchored asset and makes the supporting assertions verifiable across platforms.
These ERCs occupy the space between contractual and title tokenisation. They do not create legal title on-chain; that requires statute and institutional recognition. The narrower technical goal is to make assertions about titled assets portable, verifiable, and difficult to revise silently.
Individual ERCs
Each ERC has its own discussion thread and published specification:
| ERC | Title | Discussion | Specification |
|---|---|---|---|
| ERC-8325 | Asset Anchor Registry | thread | ERC-8325 |
| ERC-8326 | Canonical Document Bundle Anchor | thread | ERC-8326 |
| ERC-8327 | Directional Transfer Domain Registry | thread | ERC-8327 |
| ERC-8328 | Subject-Linked Compliance Event Log | thread | ERC-8328 |
| ERC-8329 | Subject-Linked Impact Snapshot Log | thread | ERC-8329 |
| ERC-8330 | Subject-Linked NAV Snapshot Oracle | thread | ERC-8330 |
No required stack. These are separate interfaces, not a monolithic protocol. A project may deploy any one of them alone. A fund can adopt ERC-8330 for subject-keyed NAV reporting without ERC-8325, ERC-8326, or any other layer. ERC-8325 is an optional identity root when a deployment wants a shared subjectId across records — not a prerequisite for the others. Each package in the reference repo builds and tests independently.
Not in scope: on-chain legal title; replacing ERC-3643, ERC-7943, ERC-4626, ERC-7540, or ERC-7208; prescribing a single RWA protocol; proving that off-chain assertions are true. These interfaces make assertions easier to verify and audit. They do not replace registries, courts, custodians, auditors, valuation agents, compliance providers, or regulators.
Normative detail lives in the individual ERC specifications and package READMEs. This thread is for the architecture: prior art, scope, naming, cross-proposal boundaries, and whether any interfaces should merge, narrow, or be dropped.
Materials
- Reference implementations — Foundry monorepo (
erc-asset-registry,erc-document-bundle-anchor,erc-transfer-domain,erc-compliance-event-log,erc-impact-snapshot,erc-nav-oracle) - Example UI suite — interactive demos of the six ERC interfaces (non-normative Protocol Stack / Architecture views)
- Technical white paper — motivation, prior art, regulatory context, and composition of the six interfaces
- Where Authority Resides (SSRN) — completion-based taxonomy of tokenisation models; clarifies where legal, contractual, and ledger authority sit, and why a titled-asset layer is still mostly bespoke
- Security review — Verichains audit report
All six ERCs have assigned numbers and are now in Review. Specs may change based on review and discussion.
Why Now
Production deployments are no longer theoretical. Baillie Gifford has launched a fully native UK-regulated tokenised fund on Ethereum and Solana, and the Dubai Land Department has launched a limited real-estate tokenisation pilot in collaboration with VARA.
Meanwhile, token-side standards are consolidating. ERC-3643 and ERC-7518 (Review) cover permissioned transfer patterns. ERC-7943 is now Final as a minimal, vendor-neutral RWA compliance interface. ERC-4626, ERC-7540, and ERC-7575 cover vault mechanics. ERC-7208 provides on-chain data container infrastructure.
Those layers are useful, and these ERCs are meant to compose with them. What is still mostly bespoke per issuer is the titled-asset layer: binding a token to a specific legally anchored asset, deterministic document commitments, directional corridor rules, and portable compliance, impact, and NAV history across venues.
The cost of leaving that layer bespoke shows up quickly: buyers cannot verify binding to a specific parcel or concession; diligence teams cannot reproduce document commitments without reverse-engineering the issuer’s platform; regulators and auditors do not have a portable compliance history across venues; DeFi protocols cannot safely consume NAV without custom adapters and staleness semantics.
What Existing Standards Cover
ERC-3643, ERC-7518 (Review), ERC-7943, ERC-4626, ERC-7540, ERC-7575, and ERC-7208 are useful existing layers. We are not proposing alternatives to them.
Our read of the landscape is that they mostly describe token behaviour, compliance exposure, vault mechanics, or data containers. They do not define a common titled-asset layer for asset binding, deterministic legal document commitments, directional corridor rules, evidentiary compliance logs, impact records, or subject-keyed NAV.
That is the proposed gap. If there is prior art we have missed, especially active work that should absorb or replace one of these ERCs, we would like to identify it while the specifications are still early.
The Six ERCs
The six ERCs are now in Review. The short summaries below remain architecture-level; normative detail lives in the individual ERC specifications, and dedicated discussion threads.
ERC-8325 — Asset Anchor Registry
A registry-scoped binding links an anchor to a (token, bindingScope, tokenId) tuple, with separate commitments for the legal basis and supporting evidence. Each anchor can be bound once, and each tuple can have at most one valid binding within a registry; invalidated historical bindings remain queryable. Binding fields are immutable after binding. Lifecycle deactivation and admin-only binding invalidation are explicit state transitions: neither rewrites historical binding fields, while binding invalidation can release the token-binding slot for a replacement anchor. Allocation integrity, such as fractional claims not exceeding 100%, belongs in the token implementation and legal structure, not the registry.
The intended contribution is narrow: make asset binding queryable and structurally verifiable against both the registry-side record and the token-side declaration, rather than only asserted in issuer metadata or offering documents.
ERC-8326 — Canonical Document Bundle Anchor
Deterministic commitment of a manifest describing an off-chain document set. Given the same normalised document representations, canonical entry fields, ordering rules, and schema version, compatible implementations derive the same bundle hash.
ERC-8326 separates bundle structure from file normalisation. The specification defines JSON and XML normalisation profiles, but canonicalisation is performed off-chain. The Solidity reference package receives the resulting document-entry hashes, applies or verifies canonical ordering, and derives the bundle hash; it does not itself canonicalise JSON or XML. PDF and image profiles are deliberately deferred. Until robust profiles exist, binary documents should use raw-byte mode. ERC-8326 stands alone and does not depend on the asset registry.
ERC-8327 — Directional Transfer Domain Registry
Corridor-level rules: whether a transfer between two domains is permitted for an asset class, independent of whether either holder individually passes KYC. Routes are directional; reverse permission requires a separate registration.
This registry is advisory and does not enforce token transfers by itself. A consuming token or application that requires enforcement must call isRoutePermitted() atomically with the transfer. ERC-165 can signal support for the registry interface; it cannot prove that a token consults the registry or enforces its decisions. We want feedback on registry governance, registrar models, and revocation semantics.
ERC-8328 — Subject-Linked Compliance Event Log
Append-only, attributed compliance history across an asset or token lifecycle: issuance, verification, transfer checks, freeze, unfreeze, regulatory hold, enforcement, redemption, corrections, and custom events.
Corrections are appended as new entries. Existing event content remains unchanged except that the corrected event’s correctedByIndex forward pointer is set once, linking it to the correction; the correction entry’s correctsIndex points back to the original. The intended contribution is an evidentiary record that regulators, auditors, and counterparties can read without depending on a proprietary off-chain log format. Sensitive data should remain off-chain; the on-chain record should carry commitments, role-labelled parties where appropriate, payload profiles, and evidence hashes.
This is not RWA-specific. It may be the broadest adoption path because regulated tokens outside titled assets have the same audit-history problem.
ERC-8329 — Subject-Linked Impact Snapshot Log
Tamper-evident impact snapshots with required nonzero methodology commitments, correction provenance, and optional extension points for methodology versioning and positive or negative attestations. The core interface records measured indicators over defined periods and supports fork-free corrections.
This does not establish that reported measurements are true. It prevents silent revision and makes correction and methodology history visible when corresponding extensions are used. The goal is to complement, not duplicate, work from carbon and impact ecosystems such as Toucan and Regen. We welcome feedback from those communities as this specification progresses.
ERC-8330 — Subject-Linked NAV Snapshot Oracle
Subject-keyed NAV reporting with explicit basis, currency, provider attribution, correction chains, and two separate staleness checks:
- Publication staleness: has the provider published within the expected heartbeat?
- Valuation staleness: was the underlying valuation itself struck recently enough?
Both matter for illiquid-asset NAV. A provider can republish an old valuation on time; publication freshness alone does not make the valuation fresh. ERC-8330 complements ERC-4626/7540/7575 vault mechanics and ERC-7726 Common Quote Oracle APIs. It reports valuation; it does not create executable prices.
Deployable standalone: a fund or vault can publish subject-keyed NAV through ERC-8330 without deploying ERC-8325 or any other interface in this set.
Optional Composition
Independence first. None of these interfaces requires another. There is no mandatory deployment order and no required full stack.
| If you need… | You can deploy… | Without… |
|---|---|---|
| Subject-keyed NAV only | ERC-8330 | ERC-8325 through ERC-8329 |
| Portable compliance history only | ERC-8328 | ERC-8325, ERC-8326, ERC-8327, ERC-8329, ERC-8330 |
| Deterministic document commitments only | ERC-8326 | ERC-8325 (uses any bytes32 subject) |
| Asset–token binding only | ERC-8325 | ERC-8326 through ERC-8330 |
| Directional corridor rules only | ERC-8327 | ERC-8325, ERC-8326, ERC-8328, ERC-8329, ERC-8330 |
| Impact snapshots only | ERC-8329 | ERC-8325 through ERC-8328, ERC-8330 |
Example — NAV-only: an ERC-4626 fund publishes NAV snapshots keyed by its own subjectId (vault address, ISIN hash, or other opaque identifier). It never deploys an Asset Anchor Registry.
Example — full titled-asset stack: when a deployment wants a shared subject root, ERC-8325’s anchorId can act as subjectId for ERC-8326, ERC-8328, ERC-8329, and ERC-8330. That is a composition pattern, not a requirement.
Illustrative stack example:
An ERC-3643 concession token is associated with an Asset Anchor Registry. Its anchorId is then used to key a canonical legal-document bundle, a Compliance Event Log, an Impact Snapshot Log, and a NAV Snapshot Oracle used by collateral integrations. Each component remains independently deployable.
See the live UI suite for a non-normative Protocol Stack and Architecture view. The interfaces compose in layers when useful; several are useful alone.
Prior Art
ERC-3643 / ERC-7943 / ERC-7518 (Review) — compliant token behaviour and transfer controls. These are complementary. The asset-binding and lifecycle-data layer remains outside their core scope.
ERC-1643 / ERC-5289 — document registry and notary workflows. ERC-8326 differs by specifying deterministic, cross-platform bundle hashing rather than only document reference storage or notarisation.
ERC-1404 / ERC-1462 / ERC-1592 — token-local transfer restrictions and security-token transfer semantics. ERC-8327 is a token-agnostic directional corridor registry above holder-level checks.
ERC-8106 — emits advisory compliance events and entity classification. ERC-8328 is an evidentiary append-only log with correction semantics, evidence commitments, authority attribution, and subject/event-type indexing. Different use case.
Toucan / Regen — carbon and ecological asset methodology tracking. ERC-8329 generalises to arbitrary quantitative indicators and methodology versioning, but should not duplicate established domain-specific methodology work.
ERC-6956 / ERC-7929 — physical oracle binding and token-to-token hierarchy. ERC-8325 uses a different trust model: a standalone registry with legal/evidence commitments and mutual anchor–token verification. We believe these are complementary; tell us if you see a merge path.
ERC-7208 — on-chain data containers. Composable as a data layer. ERC-8325 is specifically about legal-asset binding, not general data storage.
ERC-7726 / ERC-7540 / ERC-7575 — canonical asset oracle interfaces, async vaults, and multi-asset vaults. ERC-8330 addresses subject-keyed NAV for illiquid assets with publication and valuation staleness semantics. It reports valuation; it does not create executable prices or vault mechanics.
ERC-8320 Regulated Asset Claim — a governance envelope for claims: who published a claim, who validated it, who made it active, and whether it remains trustworthy. We see ERC-8320 as complementary to these ERCs. For example, an ERC-8320 valuation claim could reference an ERC-8330 NAV stream or snapshot; a compliance claim could reference ERC-8328; a backing or terms claim could reference ERC-8326; and an identity claim could reference ERC-8325.
ERC-8318 uFund — standardised fund metadata and lifecycle interface. ERC-8330 sits at a different layer: provider-attributed NAV snapshots with valuation timestamps, staleness thresholds, correction chains, and aggregation semantics. A uFund implementation could use ERC-8330 as a NAV source.
Issuer NAV feeds / Vault Registrar / bespoke RWA stacks — production patterns exist, and in some cases work well. The question is whether common read/write interfaces would reduce adapter work and vendor dependency across the ecosystem.
ERC-6065 — real-estate-specific ERC-721 metadata. Partial overlap with titled assets, but narrower in asset class and not focused on fractional instrument binding.
What We’re Asking (and Not)
Asking
Architecture review across the family:
- Where should boundaries move — merge, narrow, or drop?
- Prior art we missed that should absorb or replace one of these ERCs?
- Which concerns belong in this umbrella architecture thread vs the individual ERC discussion threads?
Not asking in this thread
- Reference-implementation admin recovery and trust-model detail (→ ERC-8325 thread)
- Normative PDF/image profiles (→ ERC-8326 thread)
- Specification-specific editorial issues (→ a GitHub issue or future update PR)
Open Questions
- Interface split (architecture) — are these six interfaces the right boundaries, or should the family be decomposed differently?
- ERC-8327 governance (token / compliance integrators) — what registrar/governance models make sense for directional domain registries on permissionless chains?
- ERC-8328 privacy (regulatory / privacy reviewers) — have commitment-only compliance event logs been validated under real GDPR or equivalent review?
- ERC-8329 overlap (impact / carbon communities) — where should impact methodology work stop and on-chain methodology-versioned logging begin?
- ERC-8325 vs ERC-6956/ERC-7929 (binding / oracle designers) — complementary layers, or a sign that ERC-8325 should be re-scoped?
- Layer model (architecture) — does the stack of compliance, asset binding, lifecycle evidence, and vault mechanics miss or misplace any important layer?
- ERC family structure (architecture / ERC editors) — now that the individual ERCS are in Review, should any of them merge, split further, or explicitly reference one another?
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.