This document provides context on the ongoing efforts. Your feedback is crucial as we move towards finalizing these standards.

How Much Time to Get Up to Speed?

☕ ~15 min: Understand the core problem & goals by reading this summary document. 📖 ~1 hour: Grasp the main proposals & key discussion points by reading the summary & skimming the linked Forum threads. (Good for general feedback) ⚙️ ~2.5 hours: Dive deep into the technical details & specifications by reviewing the summary, forum discussions, and linked PRs. (Ideal for specific technical feedback)

⏳ Background

Users and apps need ways to unambiguously refer to an address on a specific chain. Currently, there's no universally adopted standard for this, leading to fragmented user experiences and integration challenges for developers.

Past Efforts & Challenges:

1. Previous Versions of ERC-7828: Early drafts attempted to define chain-specific addresses using ENS. However, they faced challenges:
   • Lacked a fully defined, normative specification.
   • Relied heavily on ERC-7785 (ENS Chain Objects) for chain naming, which is not yet finalized nor ready to use as of now.
   • Were not easily extensible to non-EVM chains (e.g. Starknet, Aztec) or naming systems beyond ENS.
2. ENSIP-11 & ENSIP-19:
   • These ENS Improvement Proposals focused on storing and resolving addresses for other chains within ENS records (addr field with coin type, and universal resolution profile respectively).
   • Primarily address resolving a name to an address on potentially different chains but don't standardize chain naming itself.
   • ENSIP-19 enabling reverse resolution (address -> name) for non-L1 addresses is not production-ready, having only very recent testnet deployments.
3. CAIP-10: Introduced a text-based standard (<blockchain_id>:<address>) for identifying accounts across chains. While a step forward, it has limitations:
   • It lacks guarantees of canonicity (multiple string representations might exist).
   • It doesn't incorporate human-readable naming systems like ENS.

None of the approaches above serve the needs of on-chain actors, who need a canonical & compact binary representation of (chain, address) pairs. This is evident in ERC-7786, which takes on the overhead of parsing CAIP-10 strings on-chain due to no better standardized alternative being available.

These challenges highlight the need for a layered approach: a foundational, canonical binary format for machines, and a distinct, user-friendly text format built upon it. A direction that had been a frequent request from the Interop contributors working on this vertical. This led to splitting the effort into ERC-7930 and refining ERC-7828.

🌐 General

The overall goal is to create a standardized, robust, and extensible system for representing (chain, address) pairs across the blockchain ecosystem. This system consists of two complementary standards:

1. ERC-7930 - Interoperable Addresses**:** Defines a canonical binary format for representing a (chain, address) pair. It's designed for efficiency, extensibility, and machine-to-machine communication (e.g., smart contracts and off-chain agents as core components of cross-chain messaging protocols, intents, etc.). It also specifies a basic, canonical text representation primarily for debugging or fallback scenarios.
2. ERC-7828 - Human readable names for Interoperable Addresses**:** Defines a human-friendly text format built upon ERC-7930. It leverages decentralized naming registries (like ENS) and potentially curated lists (like shortname registries) to allow users to interact with human-readable names for both addresses and chains (e.g., [email protected] or [email protected]).

Together, these standards aim to:

• Provide a uniform way for wallets, explorers, dApps, and protocols to handle addresses from any chain.
• Improve user experience by allowing the use of familiar naming systems (like ENS) in a multi-chain context.