@thamerdridi Interesting proposal, and great to see another team contributing to this part of the standards landscape. There is meaningful but partial overlap with our existing candidate ERC family, particularly around asset identity and backing, compliance records, and valuation. That convergence reinforces that machine-readable trust, asset claims, and lifecycle data are becoming shared infrastructure problems rather than project-specific concerns.
On July 2nd, we shared a related discussion covering six specialized candidate ERC interfaces for asset binding, canonical document-bundle commitments, directional transfer domains, compliance events, impact snapshots, and NAV reporting.
The repository includes Foundry reference implementations, unit/fuzz/invariant testing, and an independent Verichains audit.
Our individual ERC drafts and PR branches are implementation-ready, but we are intentionally waiting to open them until the community discussion has tested the proposed decomposition, prior art, and potential areas of overlap. We want community feedback to be able to reshape the boundaries before those interfaces enter the formal ERC process.
We see an important architectural distinction between the approaches. ERC-8320 provides a flexible, generic signed-claim envelope whose semantics live in external schemas. Our work instead defines specialized interfaces with typed on-chain fields and domain-specific query behavior.
That specialization is deliberate. Safety-critical semantics such as binding exclusivity, canonical bundle derivation, directional route permission, correction provenance, measurement periods, methodology changes, NAV basis, currency, staleness, and provider aggregation are directly available to consuming contracts without fetching and decoding schema-specific off-chain payloads. This reduces adapter ambiguity and gives integrations deterministic query behavior across implementations.
The tradeoff is flexibility versus typed composability: a generic claim registry can evolve through new schemas without changing its interface, while specialized interfaces make important values and invariants directly queryable and, where specified, enforceable on-chain. Because the approaches overlap somewhat, we believe the author teams should coordinate scope and explore partnership before the proposals progress independently.
A few questions:
-
Canonical schema representation: schemaHash authenticates particular schema bytes, but how are those bytes retrieved and canonicalized? Two semantically identical JSON schemas can hash differently. Does the proposal need a normative schema serialization rule or schema URI?
-
Multiple active claims: when multiple claims of the same (assetId, claimType) are active, how should an on-chain consumer deterministically select one? This seems particularly important for VALUATION, COMPLIANCE, and BACKING, where selecting a different author or schema may produce materially different results.
-
Typed on-chain consumption: because claim payloads remain off-chain, a consuming contract cannot directly query values such as NAV, currency, valuation timestamp, compliance outcome, or backing amount. Is ERC-8320 intended primarily as a discovery and attestation envelope that may reference specialized typed interfaces, or as a replacement for those interfaces?
-
Asset identifier derivation: should the assetId derivation specify domain separation and exact ABI encoding, for example:
keccak256(abi.encode("ERC-8320:ASSET", chainId, contractAddr, subAssetId))
How should namespaces work for off-chain assets where contractAddr == address(0)?
-
Maker-checker independence: requiring the validator address to differ from the author provides address-level separation, but does not establish organizational or beneficial independence. Would it be more precise to describe this as enforced role separation rather than enforced segregation of duties?
We will add ERC-8320 to the prior-art discussion for our candidate interfaces. Given the adjacent scope and partial overlap, would you and your co-authors be open to partnering with us on this standards work?
We would welcome a direct conversation about aligning the areas of shared scope, combining the teams’ expertise, and exploring shared authorship where the proposals address the same requirements.