Registry Resolution

Registry resolution operates without a central authority. A decentralized registry (like a smart contract on Ethereum) acts as the single source of truth. When a user queries a name, their wallet or application interacts directly with this on-chain registry to resolve it to the correct resource record, such as a cryptocurrency address or IPFS hash. This eliminates reliance on traditional DNS servers.

The mapping between a name and its data is stored as a resource record on the blockchain. The registry's smart contract allows the name's owner (controller) to update these records, which can include:

• Address records: For cryptocurrencies (ETH, BTC).
• Content hashes: For decentralized storage (IPFS, Arweave).
• Text records: For metadata like email, website URLs, or social profiles. All updates are on-chain transactions, providing a transparent and immutable history.

Names are organized in a hierarchical, tree-like structure similar to DNS. A top-level domain (TLD) like .eth is controlled by a registry contract. Under it, subdomains (e.g., wallet.chainscore.eth) can be created and managed by the owner of the parent domain (chainscore.eth). This allows for flexible organizational structures and delegated management, enabling projects to issue branded subdomains to users.

A resolver is a critical smart contract specified in the registry that performs the actual resolution logic. When the registry is queried for a name, it returns the address of its configured resolver. The querier then calls a standard function (like addr() or text()) on that resolver to get the final data. This separation of concerns allows for upgraded resolution logic without changing the core registry.

For advanced use cases, resolution can fetch data stored off-chain using CCIP-Read (EIP-3668). If a resolver doesn't have the requested data, it can revert with an error containing a URL to an off-chain gateway. The client then fetches the data (with a cryptographic proof) from that gateway, enabling gas-efficient storage of large or dynamic data like profile pictures while maintaining verifiability.

A single human-readable name can resolve to different addresses across multiple blockchains. For example, vitalik.eth can map to an Ethereum address, a Bitcoin address, and a Dogecoin address simultaneously. The resolver contract stores these mappings using chain-specific coin types (defined in SLIP-44). Wallets use this to send assets to the correct chain based on the user's selection.

A critical use case for interoperability protocols. Services like ENS and Space ID allow a single human-readable name to resolve to different addresses on different blockchains.

• name.eth → Ethereum: 0x123..., Polygon: 0x456..., Arbitrum: 0x789... This is managed through multicoin address records in the registry, simplifying user experience for multi-chain activity.

Registry resolution enables accessing websites stored on decentralized networks. A domain name resolves to a content hash (like an IPFS CID or Arweave transaction ID).

• Process: Browser/Resolver fetches the hash from the registry → Retrieves content from the decentralized storage network. This creates censorship-resistant websites whose content is immutable and served directly from the distributed network.

Used by Decentralized Autonomous Organizations (DAOs) and dApps for upgradability and management. A persistent name (e.g., treasury.dao.eth) can be pointed to a proxy contract address. This allows the underlying implementation contract to be upgraded without changing the public-facing identifier users and integrators rely on, separating the persistent interface from the mutable logic.

Resolution is the act of querying a name registry to retrieve the associated resource records. The process involves:

• A client (e.g., a wallet) sending a query for a domain (e.g., example.eth).
• The query traverses the registry's smart contract logic to find the owner and resolver.
• The designated resolver contract is queried for the specific record type (e.g., addr(60) for an Ethereum address).
• The resolver returns the associated data, completing the lookup.

A Resolver is a smart contract that stores and serves the actual resource records for a name. It is separate from the registry that owns the name. Key functions include:

• setAddr(): Maps a name to a blockchain address.
• setText(): Stores arbitrary metadata (email, URL, description).
• setContentHash(): Points to decentralized storage (IPFS, Swarm). Different resolver implementations (like Public Resolver or CCIP-read resolvers) enable advanced functionality like off-chain data and multi-chain addresses.

CCIP-Read (Chainlink) allows resolvers to delegate lookup to an off-chain gateway via a signed response. This enables:

• Gasless resolution for frequently updated data.
• Cross-chain name resolution without bridging assets.
• Privacy-preserving lookups (e.g., email in an ENS record). The resolver contract acts as a verifier, checking the signature of the off-chain data provider before returning the result to the client.

The core security model is defined by where the mapping logic resides.

• Centralized Registries: A single entity (e.g., a company) controls the database. This offers simplicity but creates a single point of failure and censorship risk.
• Decentralized Registries: The mapping logic is enforced by a smart contract on a blockchain like Ethereum. Control is distributed, making it tamper-resistant and permissionless, but subject to the underlying chain's governance and finality.

Every resolution system has implicit trust assumptions that define its threat model.

• Registry Operator Trust: In centralized systems, you must trust the operator not to censor or maliciously alter records.
• Smart Contract Trust: In decentralized systems, you trust the code is bug-free (no vulnerabilities) and that the contract's owner (if any) will not upgrade it maliciously.
• Underlying Blockchain Trust: You ultimately trust the consensus mechanism (e.g., Proof-of-Stake) of the host chain to correctly order and finalize transactions that update the registry.

A robust registry resolution system aims to guarantee several critical properties:

• Censorship Resistance: No single party can prevent a user from resolving a valid name or registering a new one.
• Data Integrity & Non-Repudiation: Once a record (e.g., an ETH address) is set for a name, it cannot be altered fraudulently. All changes are cryptographically verifiable.
• Liveness: The resolution service should be highly available, with no central server that can be taken offline.
• Finality: After a update transaction is confirmed, the new mapping is guaranteed to be permanent under normal network conditions.

Understanding potential vulnerabilities is crucial for secure integration.

• Front-Running: In decentralized systems, an attacker can see a pending registration transaction and submit their own with a higher gas fee to steal a desired name.
• Registry Logic Exploits: Bugs in a smart contract's resolution or renewal logic could allow unauthorized changes or permanent locking of names.
• DNS/HTTP Hijacking (for Centralized Services): Attackers can compromise the traditional DNS or the API server to return incorrect resolution data, leading to funds being sent to the wrong address.
• Governance Attacks: For decentralized registries with on-chain governance, a malicious majority could vote to change resolution rules.

Security is enhanced by shifting trust from the resolution provider to cryptographic proof.

• Light Client Proofs: Clients can use Merkle proofs or similar to verify that a resolution response is consistent with the canonical state of a decentralized registry, without running a full node.
• Signature Verification: Records can be signed by the name owner. A resolver can provide this signature, allowing the client to cryptographically verify the authenticity of the returned data independently of the resolver's trustworthiness.
• CCIP Read / Offchain Data: Protocols like ENS use CCIP Read to fetch data from an offchain source, but the request includes a signature from the on-chain record, ensuring the returned data is authorized.

The on-chain programs that govern the logic of a decentralized naming system. They handle:

• Registration & Renewal: Rules for claiming and maintaining a name.
• Resolution Logic: The function that maps a name (e.g., alice.eth) to its associated data (e.g., an Ethereum address).
• Ownership Transfer: Secure processes for selling or gifting names.

These contracts are the immutable source of truth for the registry's state.

Specialized smart contracts that perform the actual resolution lookup. They are separate from the registry contract that stores ownership.

• Function: When queried with a name, a resolver returns the associated resource, such as a cryptocurrency address, IPFS content hash, or off-chain metadata URL.
• Flexibility: Users can point their name to different resolvers, enabling one name to manage multiple records (e.g., ETH address, BTC address, avatar).

The capability for a name registered on one blockchain to resolve to addresses or resources on different, independent blockchains.

• Challenge: Blockchains are isolated; a name on Ethereum cannot natively read data on Solana.
• Solutions: Use bridges, oracles, or general-purpose resolvers that maintain a cross-chain record set. This enables a single name like bob.crypto to point to an Ethereum, Solana, and Bitcoin address simultaneously.