Draft Proposal: Stealth Name Resolution (stealth meta-address names across asynchronous chains)

ERCs
,
1

Summary

I am sharing a draft proposal for discussion. It defines a name-resolution layer for stealth meta-addresses. A canonical Ethereum registry acts as both registrar and ENSIP-10 wildcard resolver for a parent ENS name, serving a com.opaque.meta text record. The registry can store explicit keys or source them live from the ERC-6538 registry. The proposal also defines a transport-agnostic mirror payload so a second chain can maintain read-only name records without querying an Ethereum RPC endpoint.

I intend to submit this for the Standards Track once it has had discussion; it is not submitted yet and has no assigned number. It requires ERC-5564 and ERC-6538.

Problem

ERC-5564 and ERC-6538 let a sender pay a stealth meta-address, but a 66-byte meta-address is not a practical user-facing identifier. ENS solves this on Ethereum. Users who receive on more than one chain need one human-readable name that resolves to the same meta-address from wallet environments that may not have an Ethereum RPC available, for example a Solana-native wallet.

Relationship to existing work

I want to be clear about what is new here and what is not.

  • Publishing a stealth meta-address under a name is not new. It was described in the 2023 stealth-address writeup and is standardized for Ethereum by ERC-6538. Production wallets already pair ENS subnames with stealth addresses.

  • Cross-chain name resolution is an active area. CCIP-Read (ERC-3668) with ENSIP-10 is the established Ethereum-native path, and ERC-7265 addresses cross-chain name bridging with a canonical-chain-wins model and proof-of-origin metadata.

The part this draft tries to add is narrower:

  1. A read-only mirror format for non-EVM chains that does not depend on an Ethereum RPC or a CCIP-Read gateway. CCIP-Read assumes a verifiable path back to Ethereum; this proposal targets environments where that is awkward, and accepts bridge latency under an explicit canonical-chain-wins rule.

  2. Live ERC-6538 sourcing inside a wildcard resolver, so a user can rotate stealth keys once in ERC-6538 and have the name follow, with explicit keys as an override.

  3. Specified semantics for asynchronous remote claims: a consume-once claim message, a canonical-chain-wins race rule for contested labels, and a pending, confirmed, lost, or expired state machine that wallets surface to users.

Design overview

  • Names: depth-1 subnames of a configured parent (for example alice.opq.eth), LDH labels only, with Unicode normalization out of scope.

  • Canonical registry: holds one record per name (registrant, optional remote authority, optional explicit keys, timestamp). Implements ENSIP-10 resolve for text(node, "com.opaque.meta") and addr(node).

  • Key sourcing: explicit keys win; if they are empty, the resolver reads stealthMetaAddressOf(registrant, 1) from ERC-6538.

  • Mirror payload: a fixed 164-byte version-1 layout (version, action, name hash, spend key, view key, owner, remote authority). A bridge envelope may wrap it; receivers authenticate the envelope, enforce an approved-emitter list, and reject stale or replayed sequence numbers.

  • Remote claims: an optional provisional-claim payload from a remote chain, consumed at most once by the canonical registry, with canonical registrations winning contested labels.

Key-ordering note

ERC-5564 and ERC-6538 serialize a meta-address as spend key then view key. The com.opaque.meta text record uses view key then spend key. The mirror payload uses spend key then view key. A resolver or mirror that emits the text record reorders the halves. The spec states this in every direction, because it is an easy interop mistake to make.

Open questions for reviewers

  1. Is canonical-chain-wins with an explicit read-only mirror the right trade-off for non-EVM environments, or should the proposal defer to CCIP-Read where a gateway is feasible and only specify the mirror for the non-EVM case?

  2. Should the surrogate-address derivation for remote-originated registrants be specified here, or left to deployments?

  3. Is a 24-hour default pending window reasonable, and should it be a protocol constant or a per-deployment value?

  4. Does the overlap with ERC-7265 warrant aligning the mirror payload with its proof-of-origin metadata rather than defining a separate layout?

  5. Is the ERC-6538 live-sourcing override behavior specified clearly enough to implement without ambiguity?

Feedback on scope, security, and any overlap I have missed is welcome.