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.
Overview
We are proposing a family of six draft 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 proposals 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.
- Proposal 1 — Asset Anchor Registry — asset-to-token binding
- Proposal 2 — Canonical Document Bundle Anchor — deterministic document anchoring
- Proposal 3 — Directional Transfer Domain Registry — directional transfer domains
- Proposal 4 — Subject-Linked Compliance Event Log — on-chain compliance event recording
- Proposal 5 — Subject-Linked Impact Snapshot Log — impact snapshot logging
- Proposal 6 — Subject-Linked NAV Snapshot Oracle — standardised NAV reporting
No required stack. These are separate interfaces, not a monolithic protocol. A project may deploy any one of them alone. A fund can adopt Proposal 6 for subject-keyed NAV reporting without Proposal 1, 2, or any other layer. Proposal 1 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 draft specifications and package READMEs. This thread is for the architecture: prior art, scope, naming, and whether the family should be split differently before ERC PRs.
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 draft 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
- Formal ERCs — individual Magicians threads and ethereum/ercs PRs to follow after incorporating feedback from this discussion. We will update this post as those links are available.
Interface numbers and ERC-XXXX constants are provisional until assignment; specs may change based on 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 proposals 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 proposals, we would like to find it before submitting formal ERCs.
The Six Candidate Interfaces
Working titles only. Numbers will be assigned at submission.
Proposal 1 — 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.
Proposal 2 — 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.
The proposal 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. This proposal stands alone and does not depend on the asset registry.
Proposal 3 — 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.
Proposal 4 — 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.
Proposal 5 — 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 want feedback from those communities before formal submission.
Proposal 6 — 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. This proposal 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 Proposal 6 without deploying Proposal 1 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 | Proposal 6 | Proposals 1–5 |
| Portable compliance history only | Proposal 4 | Proposals 1–3, 5–6 |
| Deterministic document commitments only | Proposal 2 | Proposal 1 (uses any bytes32 subject) |
| Asset–token binding only | Proposal 1 | Proposals 2–6 |
| Directional corridor rules only | Proposal 3 | Proposals 1–2, 4–6 |
| Impact snapshots only | Proposal 5 | Proposals 1–4, 6 |
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, Proposal 1’s anchorId can act as subjectId for Proposals 2, 4, 5, and 6. 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. Proposal 2 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. Proposal 3 is a token-agnostic corridor registry above holder-level checks.
ERC-8106 — emits advisory compliance events and entity classification. Proposal 4 is an evidentiary append-only log with correction semantics, evidence commitments, and authority attribution. Different use case.
Toucan / Regen — carbon and ecological asset methodology tracking. Proposal 5 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. Proposal 1 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. Proposal 1 is specifically about legal-asset binding, not general data storage.
ERC-7726 Common Quote Oracle / ERC-7540 / ERC-7575 — Common Quote Oracle APIs; async vaults; and multi-asset vaults. Proposal 6 addresses subject-keyed NAV for illiquid assets with publication and valuation staleness semantics.
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 before creating individual ERC threads:
- Where should boundaries move — merge, narrow, or drop?
- Prior art we missed that should absorb or replace a proposal?
Not asking in this thread
- ERC number assignment
- Reference-implementation admin recovery and trust-model detail (→ Proposal 1 thread)
- Normative PDF/image profiles (→ Proposal 2 thread)
- Audit finding summaries or remediation walkthroughs (→ individual ERC PRs)
Open Questions
- Proposal split (architecture) — are these six interfaces the right boundaries, or should the family be decomposed differently?
- Proposal 3 governance (token / compliance integrators) — what registrar/governance models make sense for directional domain registries on permissionless chains?
- Proposal 4 privacy (regulatory / privacy reviewers) — have commitment-only compliance event logs been validated under real GDPR or equivalent review?
- Proposal 5 overlap (impact / carbon communities) — where should impact methodology work stop and on-chain methodology-versioned logging begin?
- Proposal 1 vs ERC-6956/ERC-7929 (binding / oracle designers) — complementary layers, or a sign that Proposal 1 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 submission grouping (architecture / ERC editors) — which proposals, if any, should merge first before PRs to ethereum/ercs?
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.
Individual Magicians threads and ERC PRs will follow after incorporating feedback from this discussion.