{"id":"ERC-6538","name":"Stealth Meta-Address Registry","status":"Final","chain":"both","category":{"id":"identity","name":"Identity & Privacy","description":"Who you are on-chain, and what you choose to reveal"},"journeyStages":[{"id":"authentication","name":"Authentication & Identity","description":"Proving who you are and logging in"},{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"}],"uxImpact":"ERC-6538 defines a registry that maps a registrant address and schemeId to stealth meta-address bytes. It helps an ERC-5564 client discover a private-receive key; it does not define name resolution, profile verification, unregister/privacy erasure, or payment settlement.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-6538","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-6538","sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-6538","type":"official-spec"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","summary":"ERC-6538 defines a registry that maps a registrant address and schemeId to stealth meta-address bytes. It helps an ERC-5564 client discover a private-receive key; it does not define name resolution, profile verification, unregister/privacy erasure, or payment settlement.","designerTakeaways":["Show registration and overwrite as address + schemeId state; label any empty overwrite or removal behavior as implementation-specific.","Resolve ENS or another naming system separately, then query the registry; a result is a registered key, not identity verification.","Keep manual meta-address sharing available and display the scheme, source, and historical on-chain state."],"applicability":{"whenToUse":["The target chain has a verified ERC-6538 registry and the product already supports ERC-5564 stealth derivation.","Users opt into discoverable private receive and understand that registration is public on-chain state.","The product can resolve names separately and display address, schemeId, and meta-address context."],"whenToAvoid":["Users need private receive without a discoverability signal or public registration history.","The product promises deletion or privacy erasure of registrations, events, or derived stealth addresses.","There is no verified registry deployment or compatible end-to-end ERC-5564 key and scanning flow."]},"prototypeFirst":[{"screen":"Private payments registration","why":"Users opt in with an informed discoverability tradeoff.","covers":["No entry","Registering","Registered"],"include":["Address and schemeId","Meta-address bytes","Public-state disclosure","Confirm registration"]},{"screen":"Registry lookup send","why":"A sender needs a registered key without confusing it with identity verification.","covers":["Name resolved","Entry found","No entry"],"include":["Separate name resolution","Address and schemeId","Meta-address source","Recipient confirmation"]},{"screen":"Registration overwrite policy","why":"The registry supports writing a key for a scheme, while empty overwrite and removal treatment depend on the implementation.","covers":["Existing entry","Overwrite pending","Historical entry"],"include":["Current value","Transaction state","Historical event context","Implementation-specific policy"]},{"screen":"Recipient not in registry fallback","why":"Manual meta-address sharing remains necessary for unlisted recipients.","covers":["Paste meta-address","Invalid format"],"include":["Advanced paste field","Scheme selector","Validation feedback"]}],"mentalModel":[{"label":"Registry entry","description":"ERC-6538 maps a registrant address and schemeId to stealth meta-address bytes; resolve a name separately before querying."},{"label":"Discoverability tradeoff","description":"Registration helps senders find a key but creates public registration state and history."},{"label":"Lookup before send","description":"The sender queries the registry, then an ERC-5564-compatible flow derives a destination address."},{"label":"Registered key is not identity","description":"A registry result is key material for a scheme, not a verified profile, avatar, or proof of control by a named person."},{"label":"Overwrite and history","description":"A later write may replace the current mapping; prior events and previously derived addresses are not erased by that write."}],"statesToDesign":[{"state":"Not registered","trigger":"The address has no entry for the selected schemeId.","userNeed":"Choose whether to be discoverable.","designResponse":"Show the register action, scheme, and public-state disclosure."},{"state":"Registered — discoverable","trigger":"The registry returns meta-address bytes for the address and schemeId.","userNeed":"Know what senders can discover.","designResponse":"Show address, schemeId, current value, and event/history context."},{"state":"Lookup success","trigger":"Separate name resolution yields an address and the registry has a matching scheme entry.","userNeed":"Confirm the intended recipient and key source.","designResponse":"Show the resolved address and scheme; label any name, avatar, or identity evidence as external."},{"state":"Lookup miss","trigger":"Name resolution succeeds but no matching registry entry exists.","userNeed":"Use a safe alternative.","designResponse":"Explain that no entry was found and offer manual meta-address entry."},{"state":"Overwrite pending","trigger":"The user submits a new registry write or implementation-specific empty overwrite.","userNeed":"Know which value is current and what history remains.","designResponse":"Show transaction state and retain prior event context; do not promise deletion or erasure."}],"designDecisions":[{"question":"Surface registry in global search?","recommendation":"Show Private payments available badge on resolved profiles.","rationale":"Senders discover capability at moment of payment."},{"question":"Explain discoverability paradox?","recommendation":"One sentence: Helps friends pay you privately; shows you use privacy features.","rationale":"Informed consent prevents backlash from privacy purists."},{"question":"Require registration for stealth receive?","recommendation":"No — allow manual meta-address share without registry.","rationale":"Registry is convenience, not gate."}],"problemsSolved":[{"problem":"Stealth keys shared through insecure DMs","oldWay":"Copy-paste meta-address in a private message","newWay":"Resolve a name separately, then query the registry by address and schemeId.","impact":"high"},{"problem":"Senders cannot find registered stealth-capable recipients","oldWay":"Assume everyone uses a public address or rely on ad hoc sharing","newWay":"A public registry entry can expose a selected private-receive key for a scheme.","impact":"medium"},{"problem":"Wrong meta-address or scheme selected","oldWay":"Manual entry hides the scheme and source","newWay":"Show the returned meta-address, address, and schemeId together, while keeping manual entry and explicit recipient confirmation.","impact":"high"}],"uxPatterns":[{"name":"Private payments registration","description":"Opt-in registry onboarding with explicit address, scheme, and public-history disclosure.","components":["RegisterCTA","DiscoverabilityNote","StatusBadge"],"userFlow":["User selects an address and schemeId","App submits registerKeys or the verified implementation's supported write","App reads the current registry value","UI shows the value and event/history context"]},{"name":"Registry lookup send","description":"Resolve a name separately, then find a registered stealth meta-address for the resulting address and scheme.","components":["SearchInput","RegistryResult","PrivateSendCTA"],"userFlow":["Sender enters a name or address","App resolves a name using the selected external naming system","App queries stealthMetaAddressOf(address, schemeId)","UI shows the address, scheme, and key source","User confirms the recipient before continuing to the ERC-5564 flow"]}],"antiPatterns":[{"pattern":"Auto-register without consent","why":"Registration exposes a public discoverability signal and event history.","instead":"Use an explicit opt-in with scheme and public-state disclosure.","severity":"critical"},{"pattern":"Treating a registry result as identity verification","why":"The registry returns key bytes for an address and scheme, not proof that a named person controls the address.","instead":"Show address and scheme; label external name, avatar, or identity evidence separately.","severity":"critical"},{"pattern":"Promising unregister erases discovery or history","why":"The interface defines registration/overwrite, and prior events and derived addresses remain public.","instead":"Show the implementation-specific overwrite policy and retain historical-state context.","severity":"high"},{"pattern":"Hiding manual meta-address entry","why":"An unregistered recipient may still share a key through another channel.","instead":"Keep an advanced manual path with scheme and recipient confirmation.","severity":"high"}],"vocabulary":[{"use":"Registered private-receive key","avoid":"Verified private profile","why":"Describes the registry value without implying identity proof."},{"use":"Address + scheme","avoid":"Find by name","why":"The standard lookup key is an address and schemeId; name resolution is separate."},{"use":"Registration history","avoid":"Deleted entry","why":"Overwrites do not erase prior events or derived addresses."}],"specConstraints":[{"id":"erc-6538-singleton-registry","constraint":"The ERC6538Registry is a singleton with one instance per chain.","appliesTo":"infrastructure","normativity":"normative","specQuote":"This contract defines an `ERC6538Registry` that stores the stealth meta-address for entities. These entities may be identified by an address, ENS name, or other identifier. This MUST be a singleton contract, with one instance per chain.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-6538#specification","designImplication":"Resolve the verified per-chain registry before lookup or registration, and show chain context so a result is not mistaken for a cross-chain universal record."},{"id":"erc-6538-compromised-key","constraint":"A registrant with a compromised private key should promptly unregister from the stealth key registry to reduce future-fund loss.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"In the event of a compromised private key, the registrant should promptly un-register from the stealth key registry to prevent loss of future funds sent to the compromised account.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-6538#security-considerations","designImplication":"Keep a clearly labeled recovery path for the implementation's supported overwrite or unregister behavior, and warn that already public history or previously derived destinations cannot be erased by the UI."}],"technicalNotes":"ERC-6538 stores stealthMetaAddressOf[registrant][schemeId] and nonceOf[registrant]. registerKeys writes the caller's bytes for a scheme; registerKeysOnBehalf accepts an EIP-712/EIP-1271 authorization. The interface has no named unregister, delete, or privacy-erasure operation. An implementation may define an empty overwrite policy, but prior StealthMetaAddressSet events and previously derived addresses remain. Resolve ENS or another naming system separately before querying the address/scheme mapping.","relatedStandards":[{"id":"ERC-5564","relationship":"Stealth addresses registered for discovery"},{"id":"ERC-137","relationship":"ENS or another naming system can resolve a human-readable identifier to the address that ERC-6538 uses as registrant; the registry lookup itself is address plus schemeId."}]},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-6538","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-6538","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-6538","markdown":"https://www.eipsfordesigners.com/standards/ERC-6538/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-6538/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-6538","official":"https://ercs.ethereum.org/ERCS/erc-6538","discussion":"https://ethereum-magicians.org/search?q=ERC-6538"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}