Feat: add chain-specific addresses properties

PROPERTIES.md

@@ -1,3 +1,101 @@
 # Properties
-[WIP]
 
+This document outlines the required properties for existing interoperability tracks. For each one, properties are categorized as:
+
+- **Must-have**: Core requirements that any solution MUST implement
+- **Should-have**: Important features that solutions SHOULD implement
+- **Nice to have**: Optional features that improves the solution
+- **Non-Goals**: Explicitly out of scope
+
+# Chain-Specific Addresses
+
+L2s and interconnected chains complicate how we identify accounts and targets for transactions. This becomes clear when looking at common scenarios:
+* Same address on different chains representing completely different entities (or some of them do not "exist").
+* Different addresses across chains representing the same logical entity.
+
+From the integration perspective, we can separate cross-chain identification into two distinct concerns:
+
+- **Cross-Chain Naming**: Human-readable names or identifiers that can be resolved to cross-chain addresses (e.g., [email protected]).
+- **Cross-Chain Addressing**: Machine-readable addresses for uniquely identifying addresses across chains (e.g., eth:rollup:0x123...abc).
+
+_For a comparison of current efforts, see [here](./docs/addresses-current-efforts.md)._
+
+The following properties outline the requirements for solutions in both spaces.
+
+## Cross-Chain Addressing
+
+### Must-have
+
+1. **Address Uniqueness**
+- Unique (and thus, canonical) identification of addresses per chain
+- Prevention of cross-chain ambiguity
+
+2. **Format Compatibility**
+- Support for arbitrary "blockchain" address formats (not constrained to EVM)
+- Consistent encoding/decoding of its format
+
+3. **Implementation Requirements**
+- Deterministic resolution from chain identifier + address
+- Clear error handling for invalid identifiers
+- Support for checksums and pre-validations
+
+### Should-have
+
+1. **Extensibility**
+- Support for chain hierarchies (L1/L2/L3)
+- Support for future chain types and formats
+- Flexibility in implementation details
+
+2. **Integration Support**
+- Alignment with existing standards (DIDs, CAIP-10)
+
+### Nice to Have
+
+- Resolution path using on-chain config registries
+
+### Non-Goals
+
+- Human readability as primary concern
+- Enforcing specific name resolution services
+- Standardizing chain identifiers (covered by other standards)
+
+## Cross-Chain Naming
+
+### Must-have
+
+1. **Name Resolution**
+- Deterministic resolution to cross-chain addresses
+- Support for hierarchical naming patterns
+- Clear chain identification within names
+
+2. **User Interface**
+- _Human_-readable format
+- Reasonable length for manual validation
+- Clear syntax for separating name and chain components
+
+3. **Wallet Implementation Requirements**
+- Trusted verification method (e.g. on-chain registry)
+- Safe handling of malformed or invalid names
+
+### Should-have
+
+1. **Integration Support**
+- Compatibility with name service resolution (ENS, etc.)
+- Alignment with identity standards (DIDs)
+
+2. **Error Prevention**
+- Support for checksums at the name level
+
+### Nice to have
+- Reliance path in on-chain config registries
+
+### Non-Goals
+- Enforcing specific name resolution services
+
+## Message Passing
+
+[To be added]
+
+## Cross-Chain Intents
+
+[To be added]

docs/addresses-current-efforts.md

@@ -16,6 +16,30 @@ A core challenge in Ethereum's multichain landscape is disambiguating addresses
 
 [ERC-7828](https://ethereum-magicians.org/t/erc-7828-chain-specific-addresses-using-ens/21930) builds on top of [ERC-7785](https://ethereum-magicians.org/t/erc-7785-onchain-registration-of-chain-identifiers/21299), to integrate with ENS, enabling the storage of chain names within an existing chain ID mapping and moving registrations away from centralized registries. Address formats could take the form of `alice@rollup` or `alice.rollup.eth`, which can be resolved on-chain through wallets.
 
+## ENSIP-9: Multichain Address Resolution
+
+[ENSIP-9](https://github.com/ensdomains/ensips/blob/master/ensips/9.md) introduces a unified way for ENS resolvers to store and return addresses for different blockchains by overloading the `addr` function. Rather than proposing a textual format like `chain:address`, ENSIP-9 leverage from coin types (following [SLIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)). This allows resolvers to identify each blockchain by its unique coin type and store the address in its native binary form (such as 20-byte hex for Ethereum, base58-decoded bytes for Bitcoin, etc).
+
+### ENSIP-11: EVM compatible Chain Address Resolution
+
+[ENSIP-11](https://github.com/ensdomains/ensips/blob/master/ensips/11.md) extends ENSIP-9 by introducing a dedicated range of coin types for EVM chains. This range prevents collision with existing [SLIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) coin types.
+
+## Comparison
+
+The existing approaches to chain-specific addresses represent an evolution in thinking about cross-chain identification rather than competing solutions. Some standards builds upon lessons learned from previous implementations while other targets other aspects or they could built on top of.
+
+| **Feature** | ERC-3770 | CAIP-10 | ERC-7828 | ENSIP-9/ENSIP-11 |
+| --- | --- | --- | --- | --- |
+| **Scope** | Primarily a UI/UX layer standard for human-readable prefixes | A universal account identifier format (machine-readable) for all blockchains | On-chain naming integration with ENS (for chain names and addresses), EVM-focused | ENS resolver-level standards for storing/retrieving multi-chain addresses |
+| **Status** | Draft (Fully defined) | Final (Fully defined) | Draft (Incomplete) | Final/Draft |
+| **Format Example** | `chain:address` | `chain_namespace:chain_reference:address` | `address:chain.eth` or `[email protected]` | Still uses typical `.eth` format |
+| **Human Readability (_best-case scenario_)** | Medium | Medium | High | High (from typical ENS format) | 
+| **Technical Compatibility** | EVM only (but extensible) | All chains | EVM only (potential non-EVM support) | Blockchain that are part of [SLIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) or follows EVM `chainId` specs |
+| **ENS Integration** | Not Required | Not Required | Required | Required |
+| **DID Compatibility** |  |  |  |  |
+| **Checksum Support** | Incomplete (ERC-55 only) | No | Yes | Yes |
+| **Usage of lists** | Yes (referencing github.com/ethereum-lists/chains) | No | Yes (requires ERC-7785 aka onchain registry) | Base in [SLIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) |
+
 # Additional Considerations
 
 Unique chain identifiers rely on social consensus to avoid collisions that could break integrations. The transition from off-chain registries to on-chain methods in the Ethereum ecosystem has been widely discussed and documented [here](chain-registries.md).

docs/interoperable-address-explainer.md

@@ -0,0 +1,52 @@
+Introducing: Interoperable Addresses
+====
+
+Interoperable Addresses is a standard defining address formats for a multi-chain world.
+
+For a normal user, they look like this:
+
+<p>
+    <code>
+        <span style="color:grey">3::</span><span style="color: blue">vitalik.eth</span>@<span style="color: magenta">eth</span>#<span style="color:grey">5966be0f</span>
+    </code>
+</p>
+
+- <code><span style="color:grey">3::</span></code>: the Interoperable Address Resolver version, which your wallet may very well omit.
+- <code><span style="color: blue">vitalik.eth</span></code>: A human-readable name, specific to a chain. Supported by (anything looking like) ENS.
+- <code><span style="color: magenta">eth</span></code>: A human-readable chain name, defined by either https://github.com/ethereum-lists/chains if available (same registry for ERC-3770) or CAIP-2 in all other cases.
+- <code><span style="color:grey">5966be0f</span></code>: A checksum so you can at a glance validate what you see matches what you expect to be under the hood.
+
+---
+
+For nerds and computers, however, they look like this:
+
+<p>
+    <code>
+        <span style="color:grey">3:</span><span style="color:green">eip155:1</span>:<span style="color: red">0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e</span>::<span style="color:magenta">eip155:1</span>:<span style="color: blue">0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045</span>#<span style="color:grey">5966be0f</span>
+    </code>
+</p>
+
+- <code><span style="color:grey">3:</span></code>: Interoperable Address version.
+- <code><span style="color:green">eip155:1</span></code>: CAIP-2 id of chain where the naming registry is located
+- <code><span style="color: red">0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e</span></code>: Address where to find the naming registry
+- <code><span style="color:magenta">eip155:1</span></code>: CAIP-2 id of chain we are referring to
+- <code><span style="color: blue">0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045</span></code>: Chain-specific address we are targeting in that chain
+- <code><span style="color:grey">5966be0f</span></code>: Checksum of all previous fields, to make sure nothing got lost in transit
+
+---
+
+The Interoperable Address is a format for strings to:
+- Fully specify an address on a particular chain (using CAIP-10), supporting any EVM-ecosystem chain and any chain on SLIP-044.
+- Also include the information to display it to a human in a readable way, as displayed above.
+
+Some of its features are:
+- Uses mature technologies such as CAIP-10 and ENS.
+- Is extensible for future resolving mechanisms (eg: ERC-7785, when/if it reaches production).
+- Resolution of Interoperable Addresses to human readable names is fully deterministic.
+- Edge cases are securely abstractable to a library/SDK for wallets.
+- Does not enshrine a particular ENS contract, making it flexible for a future naming-only rollup, instances on other rollups or even an ENS fork.
+
+And, in all honesty, it has some drawbacks as well:
+- Exposes a version number to users (although that can be mitigated by wallet UX)
+- Supporting different name resolution contracts mean human-readable name -> machine address resolution can produce different results (which is mitigated by the checksum)
+- Wallets will have to maintain a set of name resolving contracts considered trustworthy, with a trust model similar to RPC urls (can be taken care of by a library/SDK, but user overrides should be supported).