Chain Resolver — Reference Hub
This app demos a unified resolver that maps a short label (like base) to an ERC-7930 chain identifier and back again via ENSIP-10
Looking for a deeper dive? Read the contracts README on GitHub.
Unified Resolver (ChainResolver.sol)
The unified resolver stores chain identifiers and label mappings (see 7930 chain identifier).
It implements ENSIP-10, meaning read operations use the extended resolver entrypoint resolve(bytes name, bytes data).
Mappings are keyed by labelhash, computed as labelhash = keccak256(bytes(label)) for the left‑most label (e.g., label = "optimism").
Enumerate registered chains via chainCount() and getChainAtIndex(uint256), which return each stored label and its associated chain name without relying on an off-chain index.

The ENS field text(..., "chain-id") (see ENSIP-5) returns the chain’s 7930 ID as a hex string. The data field data(..., "chain-id") (see ENSIP-24) returns the raw bytes. These values are written at registration by the contract owner (e.g., a multisig) and the resolver ignores user-set overrides. To resolve a chain ID:
- DNS-encode the ENS name (e.g.,
optimism.cid.eth). - Compute
labelhash = keccak256(bytes(label))(e.g.,label = "optimism"). - Calls
resolve(name, encode(text(labelhash,"chain-id")))resolve(name, encode(data(labelhash,"chain-id")))
You can also read the canonical human‑readable chain name for a label using the forward chain-name text key:
resolve(name, encode(text(labelhash, "chain-name")))→ returns the chain name (e.g.,"Optimism").
Reverse lookups use ENS text records. Build a key prefixed with"chain-name:" and suffixed with the 7930 hex (without a leading 0x), then call text(bytes32,string) via the Extended Resolver. This follows service key parameters per ENSIP‑TBD‑17. For example:
- textKey (string):
"chain-name:" + <7930-hex>(for example,"chain-name:00010001010a00") - Calls:•
resolve(name, encode(text(labelhash, serviceKey)))
7930 Chain Identifier
We use the chain identifier with a zero address from ERC-7930. It’s a compact blob that includes a chain type and a short reference.
- EVM chains: the reference is the CAIP-2
eip155:<id>chain number, written as bytes. We treat that number as ≤ 32 bytes, so the total identifier is ≤ 40 bytes (8 bytes overhead + up to 32 for the ID). - Most non-EVM chains: their CAIP-2 references are also short in practice, so identifiers are typically ≤ 40 bytes too.
- Full spec limit: the generic ERC-7930 format allows up to 263 bytes in total.
More details and examples: chain-resolver README
Deployments (Sepolia)
Canonical deployment addresses used across this app.
References
Standards that underpin the registry and resolvers.
- Chain Resolver — GitHub repo
- ERC‑7930 — Chain‑aware addresses (used here for chain identifiers)
- CAIP‑2 — Blockchain ID mapping
- ENSIP‑5 — Text record conventions
- ENSIP‑7 — Contenthash records
- ENSIP‑9 — Multi‑coin addresses
- ENSIP‑10 — Extended resolver
- ENSIP‑TBD‑17 — Service Key Parameters (e.g.,
chain-name:) - ENSIP‑TBD‑18 — Global
chain-idtext record - ENSIP‑24 —
data()records - ENSIP‑11 — Coin types and formats