ERC-7828: Chain-specific addresses using ENS

ERCs
18

Hi everyone!

We wanted to share an update on ERC-7828: Interoperable Names. After several discussions with Unruggable and other community members, we made some important changes that we believe improve the standard.

What changed?

Restructuring: Interoperable Names now lives in ERC-7828

An important change worth clarifying: the Interoperable Names definition now lives entirely in ERC-7828, rather than inheriting from ERC-7930.

The separation is now:

  • ERC-7930: Defines the binary format to reference an address on a specific chain (machine-oriented)
  • ERC-7828: Defines human-friendly name resolution to Interoperable Addresses, using ENS

This makes each standard more specific and easier to implement.

Optional checksums

One of the longest debates was whether the checksum should be mandatory or not. In the end, we decided to make it optional but recommended for raw addresses, and not necessary for ENS names.

The reason is simple: if you’re using ENS, you’re already trusting its validation mechanisms. Also, ENS names can resolve to different addresses over time (for example, if the owner updates the resolver), which would make an old checksum stop working. Forcing checksums in these cases only adds friction without real benefit.

For raw addresses, the checksum remains useful to avoid typos and spoofing attacks. An important detail: the checksum is calculated on the resolved ERC-7930 address, not on the name or textual representation. This approach guarantees canonicity, but adds complexity for implementers. We’re open to feedback on this design decision.

Versioning

We added a versioning section so that Interoperable Names keep working even if ERC-7930 gets updated in the future. The trick is to exclude the Version field from the checksum calculation.

Chain registry with on.eth

We updated the spec to align with the latest chain resolver implementation, which will be at on.eth. This resolver contract:

  • Maps human labels (like optimism) to their canonical ERC-7930 identifiers
  • Exposes additional metadata for each chain
  • Supports aliases (for example, op.on.eth and optimism.on.eth resolving to the same data)

This way, optimism.on.eth would resolve to Optimism’s Interoperable Address.

This proposal is currently under discussion at ENS DAO, so it’s not finalized yet.

Clearer specification

We restructured the ERC to make it easier to implement. It now has dedicated sections on how to resolve the <chain> component and how to resolve the <address> component, instead of mixing everything together.

Why does this matter?

The problem ERC-7828 solves is simple: with hundreds of L2s using the same address format as Ethereum mainnet, an address alone no longer tells you which chain it belongs to. This can result in funds being sent to unreachable addresses on the wrong chain.

With Interoperable Names like alice.eth@optimism or 0x123...@base, both the address and the destination chain are clear.

Next steps

The ERC is currently in Draft status. Our goal is to move it to Review and eventually to Final. For that, we need community feedback.

We’d love to hear your thoughts on:

  • The optional checksum approach, does it balance flexibility and security appropriately?
  • Any edge cases or implementation challenges you foresee?

Looking forward to your feedback!

1 Like