This is an early design discussion, not a finished ERC. The ABI, profile format, extension boundaries, reference implementation, and conformance suite are not finalized. I am seeking feedback before committing to those choices.
Summary and request for feedback
I am proposing a backend-neutral read interface for real-world asset disclosures.
Existing proposals already address important parts of this problem, including signed claims, document anchors, specialized asset records, and minimal disclosure discovery. This proposal addresses the remaining need for a common way to determine:
- what a disclosure concerns;
- who provided it and who published it;
- what period, event, methodology, and evidence it covers;
- how it has changed or been corrected; and
- whether a specified set of disclosure requirements can be evaluated from a pinned set of disclosure records.
The proposed ERC standardizes reads over attributable, append-only disclosure histories without requiring every source to adopt the same publication workflow. This interface does not judge whether a disclosure is accurate, complete, legally valid, compliant, or suitable for investment.
Disclosure: I am the co-founder and CTO of Remora, which builds infrastructure for tokenization and management of private-market assets, initially focused on real estate. Remora plans to implement and test the smallest useful version of this proposal. Community feedback will inform its exact boundary before implementation choices are fixed.
Before freezing an ABI, I would particularly value feedback on what belongs in the minimum useful interface, where existing work already provides the needed semantics, and whether profiles and relationships should be part of the same ERC or separate extensions or companion specifications.
Practical motivation
In our work at Remora, we encountered a practical problem: prospective distributors and other disclosure consumers need asset information before they can decide whether deeper diligence or a commercial relationship is warranted. Today, they may need to request that information directly from the issuer or platform, learn a proprietary data model, and repeat much of the same preliminary work for each asset.
A common read interface allows those consumers to discover structured disclosures, check content against its recorded commitments, identify who provided and published it, inspect supporting evidence and history, and evaluate coverage against their own requirements before contacting the issuer or platform. It also reduces the need for issuers, auditors, and other service providers to recreate overlapping diligence packages for each potential consumer.
Putting ownership records on-chain makes ledger state easier to access, inspect, and integrate. We do not think those benefits should stop at the ownership ledger. Information about what an asset represents, which rights it carries, what supports its value, how it is performing, and what evidence supports those statements should also be easier for applications to discover and compare.
Today, that information may be machine-readable and still not be interoperable. Equivalent disclosures can use different contracts, schemas, identifiers, document structures, and publication workflows. A distributor, lender, exchange, protocol, wallet, auditor, or risk application may therefore need a bespoke integration for each issuer or platform.
The proposed standard does not make every asset comparable in an economic or investment sense. It makes the inputs used in those comparisons easier to find, attribute, interpret, and reuse. Each consumer continues to decide which providers, methodologies, evidence, and exceptions it accepts.
The smallest useful case
Consider a private loan represented by one disclosure subject. A consumer may need to find its governing terms, collateral information, and payment-status history. For each item, the consumer should be able to determine who provided the information, when it applies, whether it has been corrected, and what evidence supports it.
The conceptual read flow is:
Find the disclosure subject
-> find disclosure streams by topic
-> read the relevant observations and disclosure records
-> inspect disclosure-record history and supporting evidence
-> optionally evaluate those disclosure records against a named profile
-> apply the consumer's own trust, legal, credit, and investment policy
This simple case should not require a relationship graph or a large set of optional interfaces. Keeping it lightweight is a design goal that still needs to be demonstrated through implementation and gas measurement.
Proposed core model
On EVM chains, a disclosure endpoint is a contract operated by an accountable publisher. It exposes one or more subjects, such as an issuer, asset, agreement, investment interest, loan, property, or token representation.
For token-integrated deployments, an optional token-side locator can identify the disclosure endpoint and exact subject. Legacy tokens and non-token disclosures may instead rely on registries or indexers. Discovery alone proves neither rights nor completeness.
A subject identifier says what a disclosure concerns. It is not proof of ownership, identity, or authority.
Disclosures use the following model:
Subject
`-- Stream
`-- Observation
`-- Disclosure record(s)
- A stream groups comparable reporting about one topic, provider, scope, and methodology, such as loan payment status reported by an administrator.
- An observation identifies one period, event, or measurement within that stream, such as the payment due for June 2026.
- A disclosure record is the immutable registered assertion for that observation. It contains or commits to the structured disclosure, its provider, effective period, methodology, evidence set, provider approval, and registration provenance. A correction creates another disclosure record for the same observation; it does not overwrite the earlier record.
“Disclosure record” in this proposal always refers to that immutable registered assertion. It does not mean the stream, observation, payload file, evidence object, profile, review, or evaluation result.
For example:
Property
`-- Occupancy stream, supplied by the property manager
`-- 2026 Q2 observation
|-- Original disclosure record: 94%
`-- Correcting disclosure record: 92%
A second appraiser’s valuation under a different methodology belongs in a separate stream. Both remain discoverable without the standard deciding which one is correct.
Each disclosure record may reference multiple role-labeled evidence objects. Evidence commits to exact content and may have more than one retrieval location. Moving identical bytes to another location should not create new evidence; changing the bytes should.
The model also distinguishes the provider from the publisher. The provider is the party attributed as author of and consenting to the structured disclosure record. The publisher operates the endpoint and registers or relays the record. A platform can therefore publish a provider-approved record without presenting itself as the source of the underlying information.
Naming a provider or attaching its document is not sufficient provider consent. The provider’s proof must commit to the exact structured disclosure record and evidence set; otherwise, the attribution remains an assertion by the publisher.
A signature proves control of a signing method, not by itself the signer’s legal identity, organizational role, or authority. Those connections require separate identity and authority evidence, interpreted under consumer policy.
The exact function selectors, return structures, identifier rules, and event surface remain open. At minimum, a consumer should be able to discover subjects and the publisher, enumerate disclosure streams and immutable disclosure-record history, retrieve baseline evidence references, and inspect subject-scoped profile declarations.
Optional relationships for complex assets
Some investments contain several related subjects:
Investment interest -- ISSUED_BY ------------> Issuer
Token ---------------- REPRESENTS -----------> Investment interest
Investment interest -- ECONOMIC_EXPOSURE_TO -> Investment position
Investment position -- OBLIGATION_OF --------> Borrower
Investment position -- SECURED_BY -----------> Property
Relationships can make this structure traversable, but they should not make a simple disclosure expensive to implement. They establish attributable connections; they do not by themselves establish balances, seniority, waterfalls, legal rights, or completeness. Those matters remain disclosure records with supporting evidence.
This optional capability would allow a consumer to start from an investment interest, follow its disclosed position and collateral, and find relevant disclosure records at a specified checkpoint. Whether relationship semantics belong in the initial ERC is one of the questions this discussion is intended to test.
Profiles as reusable disclosure requirements
A profile is a versioned, content-addressed set of machine-readable disclosure requirements for a named asset type or evaluation process. It can specify required topics, schemas, methodologies, evidence roles, freshness, and traversal rules.
For example, a private-credit profile can require loan terms, payment status, collateral disclosure records, provider attribution, specified evidence, and freshness rules. An evaluator applies the profile to a pinned set of subjects and disclosure records and reports which requirements have qualifying inputs.
A profile declaration does not prove that the profile is satisfied. A successful evaluation does not prove that the disclosures are true or that the asset is acceptable. It reports whether the specified inputs were found and how they were resolved. Consumer policy makes the final trust, legal, credit, and investment decisions.
The minimum interface includes subject-scoped profile-declaration reads, but a subject is not required to declare or use a profile. Zero profile declarations is valid. This discussion will help determine whether the declaration reads and a normative Profile Format v1 ultimately belong in the same ERC, an optional interface, or a companion specification.
Scope and non-goals
The candidate minimum interface covers:
- subject and publisher discovery;
- attributable disclosure records and immutable correction history;
- baseline evidence references;
- subject-scoped profile-declaration reads, with zero declarations permitted; and
- registration provenance and structural events.
Possible optional capabilities include relationships, token-to-disclosure bindings, richer evidence and review records, and provenance for disclosure records adapted from other systems.
Backend neutrality is a design objective that implementation and adapter tests must demonstrate. A conforming adapter exposes the normalized reads while preserving the source record, source lifecycle, mapping version, and any information the source cannot supply. Here, “source record” means the native record in the system being adapted, not a normalized disclosure record. Missing information remains explicitly unknown or unsupported; an adapter must not infer it.
The proposal does not:
- establish that a disclosure is factually or legally true;
- guarantee that all relevant facts or liabilities were disclosed;
- approve, value, finance, or recommend an asset;
- define an underwriting methodology or risk score;
- enforce transfer restrictions or holder eligibility;
- make cross-chain information automatically verified; or
- require consumers to trust a publisher, provider, reviewer, or evaluator.
Encryption, data-room access, provider credentialing, legal-identity resolution, cross-chain proofs, and consumer trust policy remain outside the base interface.
Prior and adjacent work
This proposal does not claim that machine-readable RWA disclosures, signed claims, document anchors, graphs, or external evaluation are new.
ERC-8320 defines signed, schema-bound, versioned regulated-asset claims with multiple active claims and an author/validator/activator publication lifecycle. Its canonical schemas could encode many concepts described here. The question is whether common disclosure reads should depend on that governed write lifecycle or also be exposable by other backends.
KULA’s family of titled-asset interfaces defines composable, specialized primitives for asset anchors, document bundles, transfer domains, compliance events, impact snapshots, and NAV. In particular, ERC-8329 and ERC-8330 already define subject-linked reporting streams, provider attribution, methodology references, reporting periods, and correction histories for impact and NAV. This proposal asks whether a common subset of these reporting and history semantics should be generalized across disclosure topics and backend systems, without requiring them to use the same storage or publication workflow.
The unnumbered RWA Disclosure Interfaces proposal defines optional token-level interfaces for disclosure resolution, attestations, backing status, and legal-document anchors. It provides a deliberately narrow asset-keyed disclosure surface; this proposal asks whether consumers also need comparable record histories and evaluation requirements across more complex disclosure systems.
ERC-8104 explores minimal disclosure discovery through a URI. ERC-8241 is adjacent prior art for structural declarations whose verification and risk interpretation remain external. ERC-8241 focuses on protocol-control topology and dependency disclosure; this proposal focuses on attributable RWA disclosure histories, including provider/publisher separation, reporting periods, corrections, evidence sets, and reusable diligence requirements.
The proposed distinction is a backend-neutral read model combining multi-subject discovery, comparable disclosure streams, immutable corrections, multi-item evidence, and optional profile-based evaluation. Its adoption test is whether it reduces integration work for independent issuers and consumers more effectively than existing standards, specialized interfaces, or one-off adapters.
Feedback requested
I would especially value feedback on three questions:
-
Where does existing work already provide the required semantics? Which necessary common reads can ERC-8320, KULA, the RWA Disclosure Interfaces proposal, or another existing standard already provide, and which remain unaddressed?
-
What is the smallest useful core? Which consumer query and corresponding fields are necessary for interoperability, which fields require direct on-chain reads, which can safely use content-addressed payloads, and which parts of the proposed model are unnecessary?
-
How should the proposal be divided? Should profiles and relationships be part of one ERC, optional interfaces, or companion specifications?
References to overlapping work and examples from issuers, DeFi protocols, distributors, auditors, indexers, and other disclosure consumers would be particularly helpful.
Current maturity and next steps
This proposal remains at the design stage. No ABI or Profile Format v1 serialization should be treated as final.
Following this discussion, the planned next steps are to:
- reduce the proposal to the smallest defensible core;
- publish illustrative interfaces and examples;
- test the same consumer queries against a native implementation, ERC-8320, and at least one other backend, reporting unsupported or missing semantics;
- build a reference implementation, evaluator, and conformance fixtures; and
- evaluate gas, enumeration, privacy, and security before submitting a formal ERC.
I am posting now because unnecessary complexity and duplication are cheaper to identify before those implementation choices are fixed.