ERC-7828 is an Ethereum Improvement Proposal that extends the Ethereum Name Service to support chain-specific address resolution, so a single ENS name like alice.eth@base can resolve to a different address on each blockchain network while the underlying name record remains stored on Ethereum mainnet. Before ERC-7828, ENS resolvers returned a single address per coin type (using ENSIP-11 multi-chain records), but there was no standardized syntax for resolvers or dapps to express "give me the address for this name on this specific chain" as part of a single human-readable string. ERC-7828 adds the @chainname suffix and the resolver extension that makes chain-specific lookups possible without additional metadata from the caller.
​

ENS registered over 3 million names as of early 2026, according to the ENS Dune analytics dashboard, and the majority of those names resolve to a single Ethereum mainnet address. As value spreads across Base ($4.3B TVL), Arbitrum ($1.7B TVL), and Solana ($5.4B TVL), the single-resolution model creates a growing mismatch between where users hold assets and where their human-readable identity resolves.
​

ERC-7828 is a standard that extends ENS resolver contracts and ENS client libraries to accept a chain identifier as part of the name resolution request, enabling a single ENS name to resolve to different addresses on different blockchain networks. The standard defines the @chainname suffix syntax for human-readable name strings and a corresponding resolver function signature that accepts a chain context parameter alongside the ENS name hash. It is designed to be backward-compatible with existing ENS resolvers and names.
​

The ERC-7828 specification defines two components: a name format extension and a resolver interface extension. The name format extension formalizes name.eth@chainname as the canonical string representation of a chain-specific ENS name, where chainname is a short string identifier registered in a chain alias registry (e.g., base, arbitrum, optimism, bnb). The resolver interface extension defines a new function addrWithContext(bytes32 node, uint256 chainId) that resolvers can implement to return chain-specific addresses alongside the existing addr(bytes32 node) function, which continues to return the mainnet address as the default.
​

ERC-7828 was developed alongside ERC-7930, which defines the binary encoding format for the addresses that ERC-7828 resolves. The two standards address adjacent layers of the same problem: ERC-7828 handles human-readable name resolution; ERC-7930 handles machine-readable address encoding. A fully compliant implementation uses ERC-7828 to resolve alice.eth@base and then encodes the result using ERC-7930 for downstream use in QR codes or payment payloads.
​

Chain-specific ENS resolution works by passing a chain identifier as an additional parameter to the resolver lookup, so the resolver can return an address stored in a chain-specific record rather than the default mainnet record. The name owner sets multiple address records in their ENS resolver, one per chain, and the resolver returns the matching record based on the chain ID provided by the caller. If no record exists for the requested chain, the resolver falls back to the default Ethereum address.
​

The resolution flow for alice.eth@base proceeds as follows. The client application parses the @base suffix to extract the chain identifier, maps it to chain ID 8453 using the chain alias registry, then calls addrWithContext(namehash("alice.eth"), 8453) on the ENS public resolver. The resolver looks up the address record stored for chain ID 8453 in alice's name record and returns it. If alice has not set a Base address, the resolver returns either zero or the default Ethereum address, depending on the fallback policy set in the resolver contract.
​

Name owners set chain-specific records through the ENS app or directly through the resolver contract's setAddr(bytes32 node, uint256 coinType, bytes memory addr) function using ENSIP-11 coin types. ERC-7828 does not introduce a new record format; it introduces a new lookup path that reads existing ENSIP-11 multi-chain records using the @chainname syntax. This means any name that has already set multi-chain records using ENSIP-11 is immediately compatible with ERC-7828 clients without any name owner action.
​

The chain alias registry that maps short names like base and arbitrum to numeric chain IDs is a critical dependency. ERC-7828 references the chainid.network registry, which lists chain IDs for all EVM-compatible networks, as the canonical source for chain alias resolution. Short names that are not in the registry require a disambiguation step to prevent name collisions between different chains that share similar identifiers.
​

ENS already supports multi-chain addresses through ENSIP-11, which extended the resolver to store addresses for any blockchain using SLIP-44 and EVM chain ID coin types. ERC-7828 builds on ENSIP-11 rather than replacing it, adding the human-readable @chainname syntax and the standardized resolver function for chain-context lookups. The key additions are the string format and the client-facing API; the underlying record storage is unchanged.
​

The table below compares ERC-7828 with the two existing approaches to multi-chain ENS resolution across five dimensions.
​

CCIP-Read (EIP-3668) offchain resolvers are a complementary technology: they move ENS record storage offchain to reduce gas costs for name owners who update records frequently. ERC-7828's addrWithContext function can be implemented by both onchain and CCIP-Read resolvers, meaning the chain-specific syntax works regardless of the resolver architecture the name owner chooses. The ENS CCIP-Read documentation describes how offchain resolvers are structured.
​

ERC-7779 is a proposal for cross-chain permission delegation that allows a smart account on one chain to authorize actions on another chain without submitting a separate transaction on the destination chain. ERC-7828 and ERC-7779 interact because permission delegation flows that use human-readable identifiers need to resolve those identifiers to chain-specific addresses before the delegation can be constructed. ERC-7828 provides the resolution layer that ERC-7779-based flows depend on.
​

A concrete example: a governance system deploys a treasury on Ethereum mainnet and wants to delegate spending authority to an operator whose identity is expressed as an ENS name. Using ERC-7779, the treasury can issue a cross-chain permission that references the operator by ENS name. The ERC-7779 implementation resolves the name using ERC-7828 to obtain the operator's chain-specific address on the destination chain before encoding the permission. Without ERC-7828, the governance flow would need to accept raw addresses as inputs, reducing human-readability and increasing the risk of address-chain mismatches.
​

The interaction is one-directional: ERC-7828 does not require ERC-7779, and ERC-7779 does not require ERC-7828. They are designed to be used together in cross-chain identity and permission workflows, but each is independently useful. The ERC-7779 specification references ERC-7828 as the recommended name resolution mechanism for cross-chain permission targets.
​

For products built on Eco Routes, which orchestrates stablecoin flows using Hyperlane as the primary cross-chain messaging rail, ERC-7828 integration would allow payment destinations to be expressed as merchant.eth@base rather than bare addresses. The resolver outputs a Base-chain address that Eco Routes' settlement contracts can use directly in the USDC or USDT transfer instruction.
​

Chain-specific ENS names make blockchain interactions more readable and less error-prone in any context where a human-readable identifier needs to resolve to an address on a specific network. Four use cases are particularly well-matched to ERC-7828's design: multi-chain dapps that let users specify destination chains by name, cross-chain payment flows using human-readable recipient identifiers, multi-chain identity profiles for wallets, and developer tooling that reads deployment addresses from ENS.
​

A dapp that supports deposits to Base, Arbitrum, and Optimism can present users with a single ENS input field and resolve the destination address based on a chain selector, without requiring users to paste chain-specific addresses for each network. The dapp calls addrWithContext with the user-selected chain ID and gets the correct address. Uniswap's cross-chain interface and Jumper Exchange are examples of routing UIs that would benefit from ERC-7828-compliant name resolution, since both handle user-specified destinations across many EVM chains.
​

Payment flows that use human-readable names today typically resolve to a single Ethereum address, requiring the sender to manually switch networks or trust that the receiving wallet is monitoring the correct chain. With ERC-7828, a payment link like pay:invoice.company.eth@base?amount=100&currency=USDC encodes both the recipient name and the intended chain in the URI. The sending wallet resolves the name, obtains the Base address, and routes the USDC transfer to chain ID 8453, all without the user selecting a network. This is relevant to stablecoin payment protocols handling USDC ($77.3B circulating, CoinGecko Q2 2026) and USDT ($189.5B circulating) transfers across chains.
​

Wallets that display ENS names as user identifiers currently show a single address per name. With ERC-7828, a wallet can display the correct address for the active network automatically, so alice.eth shown in a Base context resolves to alice's Base address, not her Ethereum mainnet address. This reduces the class of errors where a user shares their ENS name as an address, the sender resolves it to the Ethereum mainnet address, and sends on the wrong chain. Wallets like MetaMask and Phantom have both explored multi-chain ENS resolution as part of their unified address UX.
​

Developers often use ENS names to store contract addresses rather than hardcoding them, enabling deployments to be updated by changing an ENS record. With ENSIP-11 and ERC-7828, a protocol can register v2.protocol.eth with different addresses per chain, and deployment scripts can resolve the correct address for each target chain using the @chainname syntax. This pattern is used by protocols like Aave and Uniswap to manage multi-chain deployment references.
​

Name owners do not need to take any action if they have already set multi-chain address records using ENSIP-11. ERC-7828 reads the same records that ENSIP-11 clients write. The only change required is on the client side: dapps and wallets need to support the addrWithContext resolver call and parse the @chainname suffix from user input. For name owners who want to add chain-specific addresses for the first time, the process is to open the ENS app, add address records for each chain using the "Edit Records" flow, and save. The @chainname syntax becomes immediately usable for any client that supports ERC-7828 once those records are set.
​

The ENS documentation describes the multi-chain address record format and the resolver ABI. Resolver contracts deployed before ERC-7828 need to be updated to implement the addrWithContext function if they do not already implement ENSIP-11's coin-type-based addr(bytes32, uint256) variant; many modern ENS resolvers already support this variant, making them compatible with ERC-7828 clients immediately. The ENS Public Resolver maintained by the ENS DAO supports ENSIP-11 and will require a minor update to expose the chain-context-specific function signature defined in ERC-7828.
​

As of Q2 2026, ERC-7828 is in the Review stage of the EIP process. Wallets and dapps are beginning test integrations, and the ENS DAO governance has acknowledged the proposal. Name owners should monitor the official EIP page for finalization updates.
​

No. ERC-7828 builds on ENSIP-11 without replacing it. ENSIP-11 defines how multi-chain address records are stored in ENS resolvers; ERC-7828 adds the @chainname human-readable syntax and the addrWithContext resolver function that lets clients request chain-specific records. Existing ENSIP-11 records are immediately compatible with ERC-7828 clients without any name owner action.
​

The resolver returns either a zero address or the mainnet default address, depending on the fallback policy configured in the resolver contract. ERC-7828 specifies that the fallback behavior must be explicitly documented by the resolver implementation. Client applications should check whether the returned address is zero and display an appropriate warning rather than proceeding with a transfer to a zero address.
​

CAIP-10 encodes a specific address alongside its chain identifier in a colon-delimited format (e.g., eip155:8453:0xAbc...). ERC-7828's @chainname suffix is applied to a human-readable name, not a raw address; the resolver handles the chain-specific lookup. The two formats operate at different layers: CAIP-10 is an address format, while @chainname is a name resolution hint that produces a chain-specific address.
​

ERC-7828 targets ENS, which is an Ethereum-native system, so the primary use case is EVM chains. However, because ENSIP-11 already supports non-EVM address types using SLIP-44 coin types, an ERC-7828 resolver that maps chain names to SLIP-44 coin types can return Solana, Bitcoin, or other non-EVM addresses for the appropriate @chainname suffix. This requires the chain alias registry to include non-EVM chain names, which is an area of active development in the ENS ecosystem.
​

ERC-7828 makes the recipient address layer of cross-chain stablecoin payments human-readable. Instead of requiring the sender to know the recipient's chain-specific address, the sender types recipient.eth@base and the wallet resolves the correct Base address automatically. This integrates with stablecoin payment flows using USDC on Base or USDT0 on Arbitrum, where the destination chain needs to be explicit for correct routing. See the cryptographic proof article for how resolution proofs secure cross-chain messages.
​

Sources and methodology. Stablecoin supplies from DeFiLlama and CoinGecko, April 29, 2026. Chain TVL from DeFiLlama, April 29, 2026. ENS name count from ENS Dune dashboard. ERC-7828 specification details verified against eips.ethereum.org/EIPS/eip-7828. Figures refresh as standards evolve.
​

By Eco research. Updated Apr 2026.
​