Exchange and Custody Integration Checklist

The core integration risk is resolving an ENS name to an incorrect or malicious address. Implementations must use a trusted Ethereum execution client and verify that the resolver contract is the canonical Public Resolver, not a malicious proxy. Always fetch the address record via the addr(nameHash) call on the resolver, not from offchain caches. For multi-chain deposits, validate that the resolved address matches the user's intended network and asset type. A mismatch between the resolved address format and the withdrawal network can cause irreversible fund loss.

Offchain name resolution via EIP-3668 introduces a dependency on gateway operators. Exchanges must decide whether to trust third-party gateways or operate their own. A compromised gateway can return a malicious address, leading to fund loss. The integration must verify that gateway responses include a valid signature from an authorized signer for the domain. Implement a strict timeout policy and a circuit breaker that halts resolution if a gateway becomes unresponsive or returns malformed data. Never silently fall back to an untrusted gateway.

A deposited ENS name that expires before the transaction is confirmed can resolve to a different address controlled by a new registrant. Exchanges must check the name's expiration timestamp on the Registrar contract immediately before broadcasting the withdrawal transaction. If the name expires within the expected confirmation window, the transaction must be blocked. Implement a grace-period buffer that accounts for network congestion and reorg risk. For automated renewal systems, ensure the renewal transaction is confirmed before the withdrawal is authorized.

ENS names can store addresses for dozens of different blockchains via the addr(nameHash, coinType) interface. An exchange must never assume that the resolved address is for the same network as the deposit. Always explicitly query the coin type matching the withdrawal network's SLIP-44 identifier. If the name does not have a record for that coin type, the transaction must be rejected with a clear user-facing error. Silent fallback to the Ethereum address record is a common and dangerous anti-pattern that leads to cross-chain fund loss.

ENS names must be normalized using the ENSIP-15 algorithm before hashing to prevent homoglyph attacks where visually identical names resolve to different namehashes. An exchange that hashes a non-normalized name will look up a different name than the user intended, potentially sending funds to an attacker-controlled address. The integration must apply UTS-46 normalization with the ENS-specific deviation rules. Reject names that contain disallowed characters or fail normalization entirely. Test against known homoglyph vectors regularly.

Wrapped .eth names (ERC-1155) and emancipated subnames introduce new custody risks. An exchange holding a wrapped name must track fuse status, particularly the PARENT_CANNOT_CONTROL fuse. If this fuse is burned, the parent owner cannot reclaim the name, which is critical for custody models. When supporting deposits of wrapped names, verify that the exchange's custody contract can safely hold and transfer ERC-1155 tokens. For subname withdrawals, confirm that the recipient address can manage the name without accidentally burning fuses that lock control permanently.

Start with the official ENS documentation to confirm the expected resolution flow: normalize the name, compute the namehash, read the registry owner and resolver, then query the resolver for the relevant record. Exchange and custody teams should treat this as the baseline for deposit and withdrawal policy, but should not rely on documentation alone for production safety. Validate behavior against live contracts, test expired names, unset resolvers, unsupported coin types, resolver reverts, and reverse-record mismatches before enabling automated transfers.

EIP-2304 defines the ENS resolver interface for coin-specific address records. Custodians and exchanges should use this resource when supporting non-ETH withdrawals through ENS names, because the correct record depends on the registered coin type rather than a generic text field or Ethereum address lookup. Operational controls should include allowlisting supported coin types, rejecting empty or malformed records, verifying address encoding for the target chain, and logging the exact resolver response used to authorize a withdrawal.

EIP-3668 specifies CCIP-Read, the mechanism used by offchain resolvers to return data through gateway requests and callback verification. Exchange and custody integrations need explicit policy for whether CCIP-Read is allowed in deposit and withdrawal flows. If supported, gateways should be treated as availability and trust-boundary dependencies: enforce timeouts, require callback verification, record gateway URLs used, and fail closed when responses are malformed or unverifiable. If unsupported, surface a clear rejection path instead of silently falling back to stale records.

Name normalization is a custody-critical control, not a UI detail. Integrations should normalize ENS names before namehashing, searching, storing aliases, or displaying withdrawal confirmations. Inconsistent normalization can create mismatches between the name shown to a user and the name actually resolved by the backend, increasing phishing and misrouting risk. Use a maintained ENS normalization implementation in all services that accept user-entered names, and add regression tests for mixed-script, emoji, invisible-character, and case-related edge cases.

The ENS contracts repository is the primary source for contract interfaces and implementation context. Custody engineering teams should use it to verify resolver interfaces, registry assumptions, registrar behavior, and Name Wrapper interactions used by internal tooling. Do not hard-code resolver behavior based only on a single deployment observed in production; resolvers are pluggable, and names can move between resolver contracts. Maintain a deployment verification step for any contract address your system calls directly, especially for renewal automation, ownership checks, and wrapped-name custody support.

ENS governance can affect registrar parameters, treasury-funded infrastructure, root-related authority, and ecosystem standards that downstream operators depend on. Exchanges and custodians should monitor ENS DAO governance before and after integration releases, especially when relying on registrar pricing, renewal assumptions, official app behavior, public resolver migrations, or operational services funded by the DAO. Governance monitoring should feed a change-management queue so policy, legal, risk, and engineering teams can review proposals before they become production-impacting changes.