ERC-8110: Domain Architecture for Diamonds

ERCs
4

Hey @Vagabond,

I’m happy someone picked up on the idea that I had here in the ERC-8042: Diamond Storage discussion.

I think formalizing this as an architectural pattern makes sense, and I like the direction! I have a few remarks:

  1. For clarity and tooling: identifiers MUST be valid ERC-8042 identifiers, and domains MUST declare them via the ERC-8042 NatSpec tag (@custom:storage-location erc8042:<id>) so tooling can reliably discover them. This avoids the need to restate validation rules.

  2. On “exactly one storage struct”: it may help to spell this as “one domain maps to one storage slot and one root storage struct.” The root struct MAY contain nested structs/enums/mappings. The key is that the storage entrypoint (slot) is singular per domain.

  3. Collisions: Maybe it’s worth emphasizing that collisions matter only when multiple logic modules share the same storage context (e.g., Diamonds/proxies via DELEGATECALL). This prevents newcomers from overgeneralizing collision risk.

  4. Naming: to align better with DDD-style organization, consider replacing domain_type with context (inspired by bounded contexts).

    • {org}.{project}.{context}.{domain_name}.{version}
    • e.g. org.project.access.pausable.v2

    This tends to yield a cleaner directory layout where folders represent contexts (e.g., contracts/access/, contracts/token/) rather than generic types.

What do you think?

1 Like