ERC Proposal: RWA Disclosure Interfaces

parasev · June 2, 2026, 11:18am

Hi everyone,

I would like to propose a new ERC for Real World Asset (RWA) disclosure interfaces.

Summary

RWA tokens depend on off-chain facts that normal token interfaces do not expose: reserve reports, NAV statements, audit reports, backing status, global supply statements, and legal documents. Today, every issuer can publish those facts differently: website, API, dashboard, PDF, IPFS, custom contract, oracle, or legal portal.

That creates a composability problem. Wallets, explorers, vaults, lending protocols, auditors, and risk engines need custom integrations for each issuer if they want to answer basic questions such as:

Does this RWA token have a current reserve or NAV attestation?
Who attested it?
When was it published?
When does it expire?
What unit and value were reported?
Where is the source report?
What hash should the retrieved report or document match?
Which legal document governs the asset or holder rights?

This ERC proposes a small disclosure plane for RWAs. It does not prove that an asset is truly backed. It standardizes how disclosures are made machine-readable, timestamped, expired, hash-bound, attributed, and discoverable.

Proposed Interfaces

The proposal defines three optional ERC-165-discoverable interfaces:

IERCRwaDisclosureResolver

Optional discovery interface for finding a disclosure contract for an assetKey.

IERCRwaAttestation

Read interface for latest RWA attestations, attestation validity, authorized attesters, and backing status.

IERCRwaDocuments

Read interface for content-addressed legal documents, document hashes, hash algorithms, effective periods, and versioning.

The current ERC-165 interface IDs are:

	Interface	Interface ID
	IERCRwaDisclosureResolver	0xad59352f
	IERCRwaAttestation	0xd926a9ab
	IERCRwaDocuments	0xa6d47605

What This ERC Does Not Do

This ERC does not:

prove reserves trustlessly;
define transfer restrictions;
define identity or compliance registries;
define oracle construction;
define lifecycle/corporate-action taxonomies;
define distribution claims or settlement flows;
decide whether a disclosure is legally sufficient.

It only standardizes the minimum read surface for RWA disclosures and document anchors.

Relationship to Existing ERCs

This proposal is intended to complement, not replace:

ERC-7943, which focuses on RWA transfer controls;
ERC-3643, which focuses on identity and compliance architecture;
ERC-7726, which focuses on quote-oracle reads;
ERC-1643-style document-management ideas from the security-token ecosystem;
asset-specific standards such as ERC-7578, ERC-6956, ERC-7092, ERC-3475, and ERC-3525.

The intended gap is the disclosure layer: a common way for integrators to read and verify metadata around RWA reserve, NAV, audit, backing, supply, and legal-document disclosures.

Use Cases

A lending protocol could check whether an RWA collateral token has a fresh NAV or reserve attestation from an expected attester before accepting it as collateral.

A wallet or explorer could warn users when an RWA token’s reserve attestation is expired, backing status is missing, or terms document hash does not match the retrieved document bytes.

An auditor or risk engine could monitor many RWA tokens through one interface instead of integrating issuer-specific APIs and dashboards.

An issuer could expose disclosures once through a standard interface instead of building custom integrations for every exchange, vault, wallet, auditor, and data provider.

Feedback Requested

I would especially appreciate feedback on:

whether the scope is narrow enough for an ERC;
whether the resolver interface is useful or should be left to registries/linked-service standards;
whether the assetKey rules are sufficiently clear for direct token contracts and separate disclosure contracts;
whether backing status should remain in the attestation interface or be separated further;
whether the document-anchor interface is sufficiently different from prior ERC-1643-style document-management work;
whether the recommended topics (RWA_RESERVE, RWA_NAV, RWA_AUDIT, etc.) are useful or should be reduced.

Full draft:

title: RWA Disclosure Interfaces

description: Defines interfaces for RWA backing attestations and legal document anchors.

author: Parsa Bahmani (@parsabahmani)

discussions-to: https://ethereum-magicians.org/t/TODO

status: Draft

type: Standards Track

category: ERC

created: 2026-05-29

requires: 165

Abstract

This ERC defines optional interfaces for Real World Asset (RWA) disclosure. The interfaces expose machine-readable backing, valuation, supply, audit, and other issuer-defined attestations, plus content-addressed legal document anchors.

Each interface is independently discoverable through [ERC-165](./eip-165.md). Implementations may expose the interfaces directly on a token contract or through a separate disclosure contract discoverable by an optional resolver interface.

This ERC does not make off-chain facts trustless. It standardizes how RWA disclosures are attributed, timestamped, expired, hashed, linked, and discovered so wallets, vaults, auditors, explorers, risk engines, and other integrators can apply their own policies without building one-off issuer adapters.

This ERC is compatible with RWA control-plane standards such as [ERC-7943](./eip-7943.md), identity and compliance standards such as [ERC-3643](./eip-3643.md), and base token standards such as [ERC-20](./eip-20.md), [ERC-721](./eip-721.md), [ERC-1155](./eip-1155.md), and [ERC-6909](./eip-6909.md). It does not require any of them.

Motivation

RWA tokens frequently depend on disclosures that ordinary token interfaces do not expose. A lending market, vault, wallet, exchange, auditor, explorer, or risk engine may need to know whether an asset has a current reserve attestation, what its latest net asset value (NAV) is, whether an audit report is current, what the global supply statement says, or which legal document governs the holder’s rights. Without a common query surface, every issuer exposes this data differently, forcing bespoke integrations and weakening composability.

Off-chain publication alone is not enough for many on-chain and wallet-facing integrations. A protocol that accepts RWA collateral, for example, needs a predictable way to ask the same questions across issuers: who attested this value, when was it produced, when does it expire, what unit is it in, what payload hash should be verified, and where can the underlying report be found. A wallet or explorer similarly needs a standard way to surface documents and stale disclosures without integrating each issuer’s API.

ERC-7943 standardizes a minimal control plane for RWAs, including transfer eligibility, freezing, and enforcement transfers. ERC-3643 standardizes a richer regulated-token architecture with identity and compliance modules. These standards do not provide a general disclosure plane for attestations and document anchors.

This ERC focuses on the disclosure plane only. Transfer controls, identity, compliance registries, lifecycle settlement, distribution claims, custodial mechanics, and oracle construction are out of scope.

Use Cases

Collateral Risk Checks

A lending protocol or vault that accepts an RWA token as collateral can query the same interface across issuers to check whether the asset has a fresh NAV, reserve, audit, or backing attestation. The protocol can verify the attester, timestamp, expiry, unit, value, report hash, and URI before deciding whether the token is acceptable collateral.

Wallet and Explorer Disclosure Warnings

A wallet or block explorer can show users whether an RWA token has current disclosures. For example, it can warn that a reserve attestation is expired, a backing status is missing, or the current terms document hash does not match the retrieved document bytes.

Auditor and Risk-Engine Monitoring

Auditors, risk engines, and monitoring services can track many RWA tokens through one read interface instead of integrating issuer-specific APIs, dashboards, or contract layouts. They can index update events, detect stale attestations, and compare published backing status across assets.

Issuer Integration Surface

Issuers can expose disclosures once through a standard contract interface instead of building bespoke integrations for every exchange, vault, wallet, auditor, and data provider. The issuer still controls its disclosure process, attesters, schemas, documents, and URIs; this ERC only standardizes the read surface.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Contracts implementing any interface in this ERC MUST implement ERC-165. A contract MUST return `true` from `supportsInterface` for every interface in this ERC that it implements.

The interface identifiers in this ERC are calculated as the XOR of the function selectors in each interface, excluding inherited ERC-165 functions.

Exposure and Discovery

An implementation MAY expose the attestation and document interfaces directly on a token contract.

An implementation MAY expose the attestation and document interfaces on a separate disclosure contract. A separate disclosure contract MUST implement ERC-165 for the interfaces it exposes.

A token contract, registry, or other discovery contract MAY implement `IERCRwaDisclosureResolver` to identify the disclosure contract for an `assetKey`. If a token contract exposes the attestation or document interfaces directly and also implements `IERCRwaDisclosureResolver`, `rwaDisclosureContract(assetKey)` SHOULD return `address(this)`.

Consumers SHOULD first check whether the token contract supports the needed disclosure interface directly. If it does not, consumers MAY query an issuer-accepted resolver, registry, linked-service mechanism, or other trusted discovery source. Consumers MUST NOT assume that an arbitrary resolver or disclosure contract is authoritative for a token.

For interfaces exposed directly on a token contract, `assetKey` is interpreted in the context of that token contract. For interfaces exposed by a separate disclosure contract, the exposing contract MUST define and document the `assetKey` namespace.

Asset Keys

An `assetKey` identifies the asset or asset series to which a disclosure applies.

For a single-asset fungible token exposing this ERC directly, `assetKey` MUST be `bytes32(0)`.

For an ERC-721 token, an ERC-1155 token id, an ERC-6909 token id, or another multi-asset representation exposing this ERC directly, `assetKey` SHOULD be `bytes32(uint256(tokenId))`, where `tokenId` is left-padded to 32 bytes.

For a separate disclosure contract representing more than one token contract or more than one chain, `assetKey` SHOULD be:

keccak256(abi.encode(uint256(chainId), address(tokenContract), uint256(assetId)))

`chainId` SHOULD be the [EIP-155](./eip-155.md) chain id for the chain where `tokenContract` is deployed. `assetId` SHOULD be the token id, series id, tranche id, or `0` for a single-asset fungible token.

Implementations MAY use another deterministic encoding if the encoding is documented in a legal document, attestation payload, resolver metadata, or disclosure-contract documentation exposed through this ERC.

Canonical Topics, Document Names, and Hash Algorithms

The following values are RECOMMENDED:

bytes32 constant RWA_RESERVE = keccak256(“RWA_RESERVE”);

bytes32 constant RWA_NAV = keccak256(“RWA_NAV”);

bytes32 constant RWA_PRICE = keccak256(“RWA_PRICE”);

bytes32 constant RWA_AUDIT = keccak256(“RWA_AUDIT”);

bytes32 constant RWA_GLOBAL_SUPPLY = keccak256(“RWA_GLOBAL_SUPPLY”);

bytes32 constant DOC_TERMS = keccak256(“DOC_TERMS”);

bytes32 constant DOC_PROSPECTUS = keccak256(“DOC_PROSPECTUS”);

bytes32 constant DOC_LEGAL_WRAPPER = keccak256(“DOC_LEGAL_WRAPPER”);

bytes32 constant DOC_GOVERNING_LAW = keccak256(“DOC_GOVERNING_LAW”);

bytes32 constant HASH_KECCAK256 = keccak256(“HASH_KECCAK256”);

bytes32 constant HASH_SHA256 = keccak256(“HASH_SHA256”);

Implementations MAY define additional topics, document names, and hash algorithms. Consumers MUST NOT assume that the recommended topics are exhaustive or legally sufficient for every RWA type.

Lifecycle events, corporate actions, distributions, and other issuer-specific notices MAY be published as attestations using implementation-defined topics and schemas. This ERC does not standardize lifecycle taxonomies, claim entitlements, or settlement behavior.

Units

The `unit` field in this ERC is a machine-readable identifier for the unit in which a value is expressed.

For an on-chain token on the same chain as the exposing contract, `unit` SHOULD be `bytes32(uint256(uint160(tokenAddress)))`.

For a national currency, `unit` SHOULD be `keccak256(abi.encodePacked(“ISO4217:”, code))`, where `code` is the three-letter ISO 4217 currency code in uppercase ASCII, such as `USD`.

For a cross-chain, non-fungible, or off-chain unit, `unit` SHOULD be a collision-resistant hash of a documented unit string. The documented unit string SHOULD be globally unambiguous, for example by including a chain identifier, registry identifier, or asset identifier.

RWA Disclosure Resolver

The resolver interface provides an optional discovery surface for implementations that expose disclosures through separate contracts.

// SPDX-License-Identifier: CC0-1.0

pragma solidity ^0.8.20;

interface IERC165 {

function supportsInterface(bytes4 interfaceId) external view returns (bool);

}

interface IERCRwaDisclosureResolver is IERC165 {

function rwaDisclosureContract(bytes32 assetKey)

external

view

returns (address disclosureContract);

}

`rwaDisclosureContract` MUST be a `view` function and MUST NOT modify state.

`rwaDisclosureContract(assetKey)` MUST return `address(0)` if no disclosure contract is known for `assetKey`.

If `rwaDisclosureContract(assetKey)` returns a nonzero address, that address SHOULD implement ERC-165 and SHOULD return `true` for at least one of `IERCRwaAttestation` or `IERCRwaDocuments`.

The resolver interface does not prove that a disclosure contract is authoritative. Consumers SHOULD verify resolver authority through issuer documentation, a trusted registry, governance, legal documents, or another accepted trust source.

RWA Attestations

The attestation interface exposes the latest machine-readable statement for an asset and topic. Attestations are not proof by themselves. They identify what was attested, who attested it, when it was produced, when it expires, and where the underlying payload can be verified.

struct RwaAttestation {

bytes32 assetKey;

bytes32 topic;

uint256 value;

uint8 decimals;

bytes32 unit;

uint64 timestamp;

uint64 validUntil;

address attester;

bytes32 schema;

bytes32 dataHash;

string uri;

}

struct RwaBackingStatus {

bytes32 assetKey;

uint256 reserveValue;

uint8 reserveDecimals;

bytes32 reserveUnit;

uint256 liabilityValue;

uint8 liabilityDecimals;

bytes32 liabilityUnit;

uint64 timestamp;

uint64 validUntil;

address attester;

bytes32 schema;

bytes32 dataHash;

string uri;

bool sufficient;

}

interface IERCRwaAttestation is IERC165 {

event RwaAttestationUpdated(

bytes32 indexed assetKey,

bytes32 indexed topic,

address indexed attester,

uint256 value,

uint64 timestamp,

uint64 validUntil,

bytes32 dataHash

);

event RwaBackingStatusUpdated(

bytes32 indexed assetKey,

address indexed attester,

uint64 timestamp,

uint64 validUntil,

bytes32 dataHash,

bool sufficient

);

function latestRwaAttestation(bytes32 assetKey, bytes32 topic)

external

view

returns (RwaAttestation memory attestation);

function isRwaAttestationValid(bytes32 assetKey, bytes32 topic)

external

view

returns (bool valid);

function rwaAttester(bytes32 assetKey, bytes32 topic)

external

view

returns (address attester);

function latestRwaBackingStatus(bytes32 assetKey)

external

view

returns (RwaBackingStatus memory status);

}

`latestRwaAttestation`, `isRwaAttestationValid`, `rwaAttester`, and `latestRwaBackingStatus` MUST be `view` functions and MUST NOT modify state.

`latestRwaAttestation` MUST NOT revert because no attestation exists. If no attestation exists, it MUST return an attestation with `timestamp == 0`.

`isRwaAttestationValid` MUST return `false` if no attestation exists. It MUST return `false` if `timestamp == 0`. It MUST return `false` if `timestamp > block.timestamp`. If `validUntil != 0`, it MUST return `false` when `block.timestamp > validUntil`.

`rwaAttester` MUST return the authorized attester for the `assetKey` and `topic`, or `address(0)` if no attester is specified by the implementation. If `rwaAttester(assetKey, topic) != address(0)`, `isRwaAttestationValid(assetKey, topic)` MUST return `false` unless `latestRwaAttestation(assetKey, topic).attester == rwaAttester(assetKey, topic)`.

`schema` SHOULD identify the attestation payload schema, report type, or off-chain data format used to interpret `dataHash` and `uri`.

`latestRwaBackingStatus` MUST NOT revert because no backing status exists. If no backing status exists, it MUST return a status with `timestamp == 0` and `sufficient == false`.

If `latestRwaBackingStatus(assetKey).sufficient == true`, the implementation MUST expose reserve and liability values, units, timestamp, attester, schema, data hash, and URI sufficient for consumers to evaluate the published sufficiency conclusion. If reserve and liability units differ, the normalization or valuation methodology MUST be identified by `schema`, `dataHash`, or `uri`. Consumers MUST NOT treat `sufficient == true` as trustless proof of backing.

Implementations SHOULD set `sufficient == false` when the relevant reserve or liability attestation is expired.

Recording or updating an attestation MUST emit `RwaAttestationUpdated`. Recording or updating a backing status MUST emit `RwaBackingStatusUpdated`.

RWA Legal Documents

The document interface exposes content-addressed legal documents and related disclosures for an RWA.

struct RwaDocument {

bytes32 assetKey;

bytes32 name;

string uri;

bytes32 documentHash;

bytes32 hashAlgorithm;

uint64 effectiveFrom;

uint64 effectiveUntil;

uint64 lastModified;

uint256 version;

}

interface IERCRwaDocuments is IERC165 {

event RwaDocumentUpdated(

bytes32 indexed assetKey,

bytes32 indexed name,

uint256 indexed version,

string uri,

bytes32 documentHash

);

function rwaDocument(bytes32 assetKey, bytes32 name)

external

view

returns (RwaDocument memory document);

function rwaDocumentCount(bytes32 assetKey)

external

view

returns (uint256 count);

function rwaDocumentNameAt(bytes32 assetKey, uint256 index)

external

view

returns (bytes32 name);

}

`rwaDocument`, `rwaDocumentCount`, and `rwaDocumentNameAt` MUST be `view` functions and MUST NOT modify state.

`rwaDocument` MUST NOT revert because a document is unset. If no document exists, it MUST return a document with `lastModified == 0`.

`rwaDocumentCount` and `rwaDocumentNameAt` are used instead of returning an unbounded array. `rwaDocumentNameAt` MUST revert when `index >= rwaDocumentCount(assetKey)`.

`documentHash` MUST be the hash of the exact document bytes available at `uri` using `hashAlgorithm`.

`uri` MAY point to public, permissioned, encrypted, or access-controlled content. Regardless of access model, `documentHash` MUST bind the exact bytes identified by `uri`. If the legally operative commitment is to decrypted plaintext rather than encrypted bytes, the decryption and plaintext-hash convention MUST be specified in the document payload, schema, or issuer documentation.

If `hashAlgorithm == HASH_KECCAK256`, `documentHash` MUST equal `keccak256(documentBytes)`. If `hashAlgorithm == HASH_SHA256`, `documentHash` MUST equal `sha256(documentBytes)`.

Updating a document MUST increment `version` for that `(assetKey, name)` pair and MUST emit `RwaDocumentUpdated`. The first version for a document name SHOULD be `1`.

`effectiveUntil == 0` means the document has no specified expiry. `effectiveFrom` and `effectiveUntil` describe the legal or disclosure validity period of the document, not the availability period of the URI.

ERC-165 Interface Identifiers

The ERC-165 interface identifier is the XOR of all function selectors in the interface, excluding inherited ERC-165 functions.

	Interface	Interface ID
	IERCRwaDisclosureResolver	0xad59352f
	IERCRwaAttestation	0xd926a9ab
	IERCRwaDocuments	0xa6d47605

These values are derived from the function selectors listed in the interfaces above.

Rationale

Narrow Disclosure Scope

This ERC deliberately standardizes a small disclosure surface: attestations, backing status, document anchors, and optional discovery of a disclosure contract. Earlier versions of this proposal considered lifecycle actions, distributions, and on-chain claim settlement. Those concerns introduce custody, entitlement, authorization, reentrancy, payout-token, tax, and legal-settlement questions that are better handled by separate standards or issuer-specific systems.

Lifecycle notices and corporate actions can still be disclosed as attestations using issuer-defined topics and schemas. This ERC only standardizes the common read surface needed to discover, timestamp, expire, hash, and attribute those statements.

Why an ERC

RWA disclosures are commonly published as web pages, PDFs, APIs, or issuer dashboards. Those channels are useful but do not give on-chain protocols or wallets a common interface. An ERC lets integrators write generic checks such as “does this asset have a fresh reserve attestation from the expected attester?” or “where is the current terms document and what hash should it match?” without hardcoding issuer-specific APIs.

The standard does not decide whether a disclosure is true, legally sufficient, or acceptable for a given protocol. It standardizes where the disclosure is found and the minimum metadata needed for consumers to make that decision.

Compatibility with ERC-7943

ERC-7943 standardizes whether an address may send, receive, or transfer an RWA token and how enforcement actions such as freezes and forced transfers are exposed. This ERC does not change those semantics. It adds optional disclosure interfaces that may be implemented by ERC-7943 tokens, ERC-3643 tokens, ordinary token contracts, vaults, or separate disclosure contracts.

Difference from Quote Oracles

[ERC-7726](./eip-7726.md) standardizes quote-oracle reads for relative asset values. This ERC does not replace quote oracles. It standardizes attested RWA disclosure, including attester provenance, timestamp, expiry, data hash, legal/report URI, backing status, and document anchors. An implementation may use an ERC-7726 oracle as an input to an `RWA_PRICE` or `RWA_NAV` attestation, but consumers still need this ERC’s provenance and validity fields to decide whether the quoted value is acceptable for regulated or collateral use.

Relationship to ERC-1643

ERC-1643 proposed document-management functions for security tokens. This ERC covers the same general need for document anchoring but differs in several ways: it supports multi-asset `assetKey` namespaces, explicit hash algorithms, validity periods, versioning, ERC-165 discovery, and use by disclosure contracts that are not necessarily the token contract. The document interface is therefore a generalized RWA document anchor rather than a direct replacement for any particular security-token suite.

Relationship to Physical-Asset and Bond Standards

Standards such as [ERC-7578](./eip-7578.md), [ERC-6956](./eip-6956.md), [ERC-7092](./eip-7092.md), [ERC-3475](./eip-3475.md), and [ERC-3525](./eip-3525.md) define token models or asset-specific behaviors. This ERC does not define how to represent ownership, redemption, privileges, bond terms, or semi-fungible positions. It defines a common disclosure surface that those token models may optionally expose or reference.

Business-Specific Terms

This ERC uses a small set of recommended RWA topics because reserve, NAV, price, audit, and supply disclosures are common integration needs. The interface itself remains generic: topics, schemas, units, document names, and payloads are all extensible `bytes32` identifiers. Implementations can use narrower legal, fund, credit, real-estate, commodity, invoice, bond, or private-credit schemas without changing the interface.

Asset Keys

`assetKey` allows the same interfaces to support single-asset ERC-20 style tokens, ERC-721 tokens, ERC-1155 token ids, ERC-6909 token ids, and separate disclosure contracts. Using `bytes32(0)` for directly exposed single-asset fungible tokens keeps the common case simple. The recommended sidecar encoding avoids collisions when one disclosure contract covers multiple token contracts or chains.

Backing Status Instead of `isBacked()`

A single `isBacked()` boolean is too ambiguous for RWAs. Backing depends on reserve unit, liability unit, valuation methodology, timestamp, expiry, attester, and source data. `RwaBackingStatus` exposes the values and source references used for the sufficiency conclusion so integrators can apply their own haircuts, freshness limits, and risk policies.

Disclosure Resolver

Direct token implementation is simple for new tokens, but many existing tokens are not upgradeable or may prefer to separate token logic from disclosure operations. The optional resolver interface provides a minimal discovery hook without forcing a universal registry or linked-service mechanism.

Bounded Enumeration

The document interface uses `count` and indexed lookup functions rather than returning an unbounded array. This makes the interface safer for on-chain callers and easier to implement for contracts with many documents.

Deferred Compliance Portability

Identity and compliance portability are intentionally out of scope. ERC-7943 defines a common transfer-control interface, while ERC-3643 and other standards define richer identity and compliance systems. A separate ERC may define shared compliance-registry discovery without coupling it to RWA disclosure.

Deferred Cross-Chain Identity

Cross-chain RWA identity and aggregate supply are intentionally out of scope because bridge, mirror-token, and issuer-led multi-chain models differ. Implementations that need cross-chain supply disclosure may publish it as an `RWA_GLOBAL_SUPPLY` attestation. A future ERC can standardize canonical cross-chain asset identity and supply reconciliation.

Backwards Compatibility

This ERC defines additive interfaces only. It does not change ERC-20, ERC-721, ERC-1155, ERC-6909, ERC-7943, or ERC-3643 behavior. Existing wallets and applications that do not query these interfaces are unaffected.

Existing deployed tokens can adopt this ERC by exposing the interfaces directly if upgradeable, by implementing the resolver interface, or by using a separate disclosure contract referenced through issuer-accepted discovery.

Test Cases

The following ERC-165 interface identifiers must be returned by compliant implementations:

	Interface	Interface ID
	IERCRwaDisclosureResolver	0xad59352f
	IERCRwaAttestation	0xd926a9ab
	IERCRwaDocuments	0xa6d47605

Implementations should include tests proving that unset attestations return `timestamp == 0`, unset backing status returns `timestamp == 0` and `sufficient == false`, unset documents return `lastModified == 0`, expired attestations are invalid, unauthorized attesters are invalid when `rwaAttester` is nonzero, and unknown disclosure contracts resolve to `address(0)`.

Reference Implementation

A reference implementation should include:

- an ERC-165 implementation exposing each supported interface id;

- a minimal resolver returning disclosure contracts by `assetKey`;

- a minimal attestation store;

- a minimal document store with version increments;

- a mock RWA token using direct disclosure;

- a mock RWA token using a separate disclosure contract; and

- tests for the interface ids, required unset-value behavior, attestation validity, and document versioning.

Security Considerations

Attestations are only as reliable as their attesters, schemas, and source documents. Consumers must not treat an attestation as trustless proof. Consumers should verify attester reputation, `dataHash`, `uri`, `timestamp`, and `validUntil` before relying on an attestation.

Stale attestations can create incorrect collateral valuations or redemption assumptions. Consumers should reject expired attestations and should apply asset-specific freshness requirements even when `validUntil == 0`.

Backing sufficiency can be misleading if reserve units and liability units are not comparable. Implementations should make the methodology available through `schema`, `dataHash`, and `uri`. Consumers should independently validate the methodology before using `sufficient`.

Contracts can expose inaccurate or stale disclosure data. Consumers should verify the exposing contract, related token contract, attester identity, document hashes, and update cadence before relying on the data exposed by this ERC.

Document anchors do not guarantee that a legal document is enforceable, current, complete, readable by a court, or actually accepted by a holder. They only bind a URI, hash, algorithm, version, and effective period to an on-chain asset reference. Consumers should verify the document bytes, legal authority, governing law, and amendment history.

Mutable URIs can point to different bytes over time. Consumers should verify `documentHash` against the retrieved bytes and should reject documents whose bytes do not match the declared hash.

Separate disclosure contracts and resolvers can be spoofed. Consumers should verify that the disclosure contract and resolver are authorized by the token issuer, an accepted registry, governance, legal documents, or another trusted source before relying on them.

The recommended sidecar `assetKey` encoding depends on accurate `chainId`, `tokenContract`, and `assetId` values. Consumers should reject disclosures that use undocumented or inconsistent asset-key namespaces.

Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).

I am posting this here first to collect feedback before opening a PR to the ethereum/ERCs repository. After this topic is created, I will use this thread as the discussions-to URL in the formal ERC draft.