Feat: add chain-specific addresses properties

PROPERTIES.md

@@ -1,3 +1,75 @@
 # 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, three layers of identification of accounts could be described as:
+
+- **Human-readable name**: A user-friendly identifier that can be resolved to a machine address (e.g., [email protected]).
+- **Machine-readable address**: The underlying technical representation that goes to an address (e.g., eth:rollup:0x123...abc).
+- **Raw address**: The address in its native format, readable by the underlying blockchain protocol (e.g., 0x123...abc).
+
+The ecosystem needs a standardized way to specify both an address and its associated chain. The following properties outline the requirements for solutions in this space.
+
+### Must-have
+
+1. **Address Resolution**
+- Unique identification of accounts per chain
+- Resolution from chain identifier
+- Prevention of cross-chain ambiguity
+
+2. **Format Compatibility**
+- Support for arbitrary "blockchain" address formats (not constrained to EVM)
+- Support for chain hierarchies (L1/L2/L3)
+- Consistent parsing mechanism
+
+3. **User Interface**
+- Clear chain identification
+- Separation of concerns between human readability and machine addresses
+- Error prevention (e.g. reasonable length for manual validation)
+
+4. **Wallet Implementation Requirements**
+- Deterministic resolution from human-readable name to machine address
+- Safe handling of malformed or invalid identifiers
+- Support for checksums and pre-validations
+
+### Should-have
+
+1. **Extensibility**
+- Support for future chain types and formats
+- Flexibility in implementation details
+
+2. **Integration Support**
+- Compatibility with name service resolution (ENS, etc)
+- Alignment with existing standards (DIDs, CAIP-10)
+
+### Nice to Have
+
+- Name resolution services standard
+- On-chain config registries
+- Deterministic resolution from machine address to human-readable name
+
+### Non-Goals
+
+- Enforcing specific name resolution services
+- Standardizing chain identifiers (covered by other standards)
+
+For a comparison of current efforts, see [here](./docs/addresses-current-efforts.md).
+
+## 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).