{"id":"ERC-5564","name":"Stealth Addresses","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-5564 standardizes one-time stealth-address generation and announcements that compatible recipients scan to discover payments. It can reduce public links to a recipient's main wallet, but funding, onward transfers, and other disclosed metadata can reveal those links.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-5564","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-5564","sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-5564","type":"official-spec"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","summary":"ERC-5564 standardizes one-time stealth-address generation and announcements that compatible recipients scan to discover payments. It can reduce public links to a recipient's main wallet, but funding, onward transfers, and other disclosed metadata can reveal those links.","partialDeployment":{"body":"Availability varies by wallet and integration. Verify the selected wallet's first-party support for private sending, announcement scanning, and claim flows. Label unsupported or pending states, and never imply funds are lost when a payment has not appeared."},"designerTakeaways":["Offer Send privately alongside normal send with plain-language privacy copy.","Keep the stealth meta-address separate from the public wallet address and explain what each reveals.","Build scanning and recovery into a stealth receive flow; inbox, notification, claim destination, and freshness defaults remain product decisions."],"applicability":{"whenToUse":["Privacy is a core product value and the target wallet can generate and scan stealth addresses.","Users receive donations, salary, or payments while reducing public links to their main wallet.","The product can explain recipient scanning, funding, and claim costs before the user opts in."],"whenToAvoid":["Compliance or product policy requires transparent recipient identity on every transfer.","The wallet lacks scanning and recovery infrastructure for stealth announcements.","A simple public-address send meets the need with less privacy and operational complexity."]},"prototypeFirst":[{"screen":"Send privately composer","why":"Senders need privacy without learning stealth jargon.","covers":["Stealth recipient","Amount","Confirmation"],"include":["Send privately toggle","Recipient stealth meta-address field","Privacy explainer one-liner"]},{"screen":"Stealth receive setup","why":"In a registry-based product, recipients publish and share the correct meta-address; direct sharing does not require registration.","covers":["Unregistered","Registered","Share sheet"],"include":["Register for private payments CTA","Meta-address copy","QR for stealth receiving"]},{"screen":"Stealth payment inbox","why":"The wallet scans announcements to discover incoming payments; the transfers themselves remain public.","covers":["Scanning","New payment found","Empty"],"include":["Scan state","Incoming payment rows","Funding and claim explanation","Review action"]},{"screen":"Privacy onboarding","why":"First-time users need metaphor before math.","covers":["Opt-in education","Skip"],"include":["One-time address explanation","Public versus private choice","Key handling guidance","Opt-in consent"]}],"mentalModel":[{"label":"Public wallet","description":"Your normal address — full history visible on explorers."},{"label":"Stealth meta-address","description":"A receiving profile from which one-time addresses are derived — not where funds sit."},{"label":"Ephemeral deposit address","description":"The sender derives a one-time address from the recipient's meta-address. The sender knows the link; the recipient controls the derived spending key."},{"label":"Scanning","description":"A client uses the viewing private key and spending public key to recognize incoming announcements. Viewing-key access reveals those payment links. It is read-only only when the scheme uses separate viewing and spending keys; sharing a combined key also exposes spending authority."},{"label":"Spending","description":"Received funds are already held at the derived address. The recipient can spend with the derived private key; sweeping to another wallet is an optional product flow with funding and privacy consequences."}],"statesToDesign":[{"state":"Stealth not set up","trigger":"User has no stealth keys.","userNeed":"Start receiving private payments.","designResponse":"Set up and back up the required keys, then offer direct meta-address sharing. Offer registry publication only when the integration uses a registry, and explain what becomes public."},{"state":"Scanning for payments","trigger":"User opens inbox or background scan runs.","userNeed":"Know scan is working.","designResponse":"Scanning indicator with last checked time."},{"state":"New stealth payment detected","trigger":"Scan finds incoming deposit.","userNeed":"See amount and sender hint if available.","designResponse":"Show a Review action and the verified asset transfer. An announcement alone is not proof that funds arrived, and reviewing it does not accept or unlock the funds."},{"state":"Send privately confirmation","trigger":"Sender submits stealth payment.","userNeed":"Confirm sent without exposing recipient main wallet.","designResponse":"Sent privately confirmation; no link to recipient public address."},{"state":"Scan failed or missed payment","trigger":"Indexer lag or user on new device.","userNeed":"Recover without panic.","designResponse":"Rescan CTA and support path; never imply funds are lost."}],"designDecisions":[{"question":"Default to private or opt-in?","recommendation":"Opt-in with clear Send privately toggle; keep public send default for familiarity.","rationale":"Failed scanning can hide received payments from the app until rescanning or recovery. Explain that dependency before opting in."},{"question":"How much cryptography to show?","recommendation":"Meta-address copy button only; hide derivation details.","rationale":"Keys and schemes overwhelm; outcomes matter."},{"question":"Automatic background scan?","recommendation":"Yes with manual Rescan and notification on new payment.","rationale":"Users will not manually scan every session."}],"problemsSolved":[{"problem":"All wallet activity is public","oldWay":"Single address reveals full financial history","newWay":"One-time receiving addresses reduce direct public links to a main wallet when funding and spending avoid linkage.","impact":"critical"},{"problem":"Sharing address reveals entire history","oldWay":"Give address to receive payment, they see all your transactions","newWay":"A compatible sender derives a fresh receiving address for each payment.","impact":"critical"},{"problem":"Donation and salary privacy","oldWay":"Recipients expose net worth on chain","newWay":"Stealth receiving can obscure the recipient's identity, while transfers and announcements remain public.","impact":"high"},{"problem":"Sender links to recipient forever","oldWay":"Permanent address ties parties in explorer graph","newWay":"A one-time address avoids publishing the recipient's main address; funding and onward transfers can still reveal links.","impact":"high"},{"problem":"Reusing addresses destroys privacy","oldWay":"Manual new address per payment = terrible UX","newWay":"Automatic stealth address generation","impact":"high"}],"uxPatterns":[{"name":"Share Stealth Meta-Address","description":"Give out a receiving profile that enables private payments.","mockup":"concept/stealth-receive","components":["StealthMetaAddressDisplay"],"userFlow":["User wants to receive payment privately","Opens private receiving setup","Copies or shows QR of meta-address","Shares with sender"]},{"name":"Send Privately Toggle","description":"Optional stealth send in transfer composer.","mockup":"concept/stealth-address","components":["PrivacyToggle","StealthAddressInput","SendButton"],"userFlow":["User composes send","Enables Send privately","Enters meta-address","Confirms","Payment sent to ephemeral address"]},{"name":"Send to Stealth Address","description":"Derive a one-time destination from a recipient's compatible meta-address and send through a supported integration.","components":["StealthSendForm","PrivacyIndicator"],"userFlow":["Sender obtains a compatible stealth meta-address","Generate a fresh stealth address and ephemeral public key","Review asset, amount, network, and funding implications","Transfer the asset and publish the required announcement through the supported integration","Show submission, execution outcome, and commitment separately"]},{"name":"Stealth Payment Inbox","description":"Scan and list incoming private payments.","mockup":"concept/stealth-inbox","components":["ScanButton","PaymentList","ReviewAction"],"userFlow":["User opens the inbox","Client scans announcements with the required keys","Shows incoming candidates and scan timestamp","User reviews the payment and its available evidence","After verifying the received balance, offer supported spending or an optional sweep with its destination and fees"]},{"name":"Claim Stealth Payment","description":"Optionally sweep funds from a stealth address to another wallet. The funds are already controlled by the derived key; the standard does not require a separate claim to unlock them.","components":["ClaimDestinationPicker","PrivacyIndicator"],"userFlow":["User selects a verified payment to spend or sweep","Review the asset, balance, and fee-funding method","For a sweep, choose a supported destination","Explain how funding or the destination can reveal the recipient link","Sign and submit with the derived key, then show the observed transfer outcome"]}],"uiComponents":[{"name":"StealthMetaAddressDisplay","description":"Show and share private receiving profile","states":["generating","ready","copied"],"props":["metaAddress","onCopy","showQR"]},{"name":"StealthInbox","description":"Scan and list stealth payments","states":["scanning","found-payments","no-payments","error"],"props":["payments[]","onClaim","scanProgress"]},{"name":"StealthSendForm","description":"Form for sending to a stealth meta-address","states":["entering","generating","confirming","sent"],"props":["recipientMetaAddress","amount","generatedAddress","onSend"]},{"name":"ClaimDestinationPicker","description":"Choose where to claim a stealth payment","states":["selecting","warning","confirmed"],"props":["mainWallet","freshAddressOption","onSelect"]},{"name":"PrivacyIndicator","description":"Show privacy level of an action","states":["private","partially-private","public"],"props":["privacyLevel","explanation"]}],"antiPatterns":[{"pattern":"Shipping stealth receive without a scanner","why":"Recipients need a way to detect announcements and identify deposits.","instead":"Provide scanning with a last-checked state, or clearly label receive as unsupported.","severity":"critical"},{"pattern":"Claiming to the main wallet without a privacy choice","why":"The destination can link a private payment to the recipient's public identity.","instead":"Explain the tradeoff and let the user choose a supported destination.","severity":"high"},{"pattern":"Showing stealth and public addresses interchangeably","why":"Senders may pay the wrong target or misunderstand linkability.","instead":"Use distinct labels and copyable values for public address and private receiving profile.","severity":"high"},{"pattern":"Auto-claiming without consent","why":"Claim transactions and destination choice can expose the user's privacy preference.","instead":"Ask before claiming and disclose destination, funding, and transaction effects.","severity":"high"},{"pattern":"No scanning progress or recovery state","why":"Indexers, devices, and recipient scanning can lag without implying funds are lost.","instead":"Show last scan, retry/rescan, and support states with honest unknown/pending copy.","severity":"medium"},{"pattern":"Privacy jargon in the primary CTA","why":"Users may skip a useful option because the protocol name is unfamiliar.","instead":"Use Send privately with one-line benefit and expandable technical details.","severity":"medium"}],"vocabulary":[{"use":"Send privately","avoid":"Generate stealth address","why":"Outcome language over cryptography."},{"use":"Private receiving profile","avoid":"Stealth meta-address","why":"Metaphor before protocol terms."},{"use":"Check for incoming payments","avoid":"Scan stealth tags","why":"Action users understand."}],"specConstraints":[{"id":"stealth-recipient-discovery","constraint":"Recipients must be able to check ownership of a stealth address and compute its private key through the scheme interface.","appliesTo":"wallet","normativity":"normative","specQuote":"A recipient MUST be able to check if a stealth address belongs to them by calling a method with the following signature:","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-5564#specification","designImplication":"A stealth wallet flow needs an explicit scanning/ownership-check state and a secure key-derivation path before showing a discovered balance as spendable."},{"id":"announcement-view-tag","constraint":"The announcement includes the recipient address and view tag so recipients can quickly filter ownership checks.","appliesTo":"wallet","normativity":"normative","specQuote":"- `viewTags` MUST be included in the announcement event and is used to reduce the parsing time for the recipients.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-5564#specification","designImplication":"Show fast-scan progress and distinguish a view-tag match from final ownership proof; do not expose the view tag as a recipient identity."},{"id":"announcement-dos","constraint":"Announcement spam can impose uncompensated parsing work on recipients and may require provider anti-DoS controls.","appliesTo":"infrastructure","normativity":"security-considerations","specQuote":"### DoS Countermeasures\n\nThere are potential denial of service (DoS) attack vectors that are not mitigated by network transaction fees. Stealth transfer senders cause an externality for recipients, as parsing announcement events consumes computational resources that are not compensated with gas. Therefore, spamming announcement events _can_ be a detriment to the user experience, as it _can_ lead to longer parsing times.\nWe consider the incentives to carry out such an attack to be low because **no monetary benefit can be obtained**\nHowever, to tackle potential spam, parsing providers may adopt their own anti-DoS attack methods. These may include ignoring the spamming users when serving announcements to users or, less harsh, de-prioritizing them when ordering the announcements. The indexed `caller` keyword may help parsing providers to effectively filter known spammers.\n\nFurthermore, parsing providers have a few options to counter spam, such as introducing staking mechanisms or requiring senders to pay a `toll` before including their `Announcement`. Moreover, a Staking mechanism may allow users to stake an unslashable amount of ETH (similarly to [ERC-4337](./eip-4337)), to help mitigate potential spam through _sybil attacks_ and enable parsing providers filtering spam more effectively.\nIntroducing a `toll`, paid by sending users, would simply put a cost on each stealth address transaction, making spamming economically unattractive.","specSection":"Security Considerations > DoS Countermeasures","specUrl":"https://ercs.ethereum.org/ERCS/erc-5564#dos-countermeasures","designImplication":"Give scanning systems filtering, throttling, or provider-selection states and communicate when a scan is incomplete because of spam controls."},{"id":"funding-privacy","constraint":"The wallet funding a stealth address must not have a physical connection to the stealth-address owner for full privacy benefits.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"### Recipients' transaction costs\n\nThe funding of the stealth address wallet represents a known issue that might breach privacy. The wallet that funds the stealth address MUST NOT have any physical connection to the stealth address owner in order to fully leverage the privacy improvements.\n\nThus, the sender may attach a small amount of ETH to each stealth address transaction, thereby sponsoring subsequent transactions of the recipient.","specSection":"Security Considerations > Recipients' transaction costs","specUrl":"https://ercs.ethereum.org/ERCS/erc-5564#recipients-transaction-costs","designImplication":"Warn users that funding patterns can link a stealth wallet to its owner and provide privacy-preserving funding guidance."},{"id":"announcement-asset-metadata","constraint":"Announcement metadata MUST include the view tag and is RECOMMENDED to use structured layouts for native and token assets.","appliesTo":"wallet","normativity":"normative","specQuote":"/// but the below guidelines are recommended:","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-5564#specification","designImplication":"Decode and label the asset context in stealth-transfer review when possible, while keeping an opaque-metadata fallback for unsupported schemes."},{"id":"stealth-meta-address-registry","constraint":"Stealth meta-addresses MAY be managed by the user or registered in a public Registry contract.","appliesTo":"wallet","normativity":"normative","specQuote":"Stealth meta-addresses may be managed by the user and/or registered within a publicly available `Registry` contract, as delineated in [ERC-6538](./eip-6538.md). This provides users with a centralized location for identifying stealth meta-addresses associated with other individuals while simultaneously enabling recipients to express their openness to engage via stealth addresses.","specSection":"Specification > Stealth meta-address format","specUrl":"https://ercs.ethereum.org/ERCS/erc-5564#stealth-meta-address-format","designImplication":"Offer registry lookup as an optional discovery path and show whether a recipient address came from a public registry or direct user input."}],"keyTakeaways":["ERC-5564 derives one-time stealth deposit addresses for private receiving.","A usable client needs recipient scanning and a recovery path.","The sender knows the recipient link. Viewing-key access reveals incoming payments and is read-only only when viewing and spending keys are separate.","Claim destination, notification cadence, and fresh-address defaults are product choices with privacy and cost tradeoffs.","Separate public address, stealth meta-address, and derived deposit address in the UI.","Never infer that scanning or a claim proves sender identity."],"technicalNotes":"ERC-5564 defines stealth-address generation, announcements, and recipient scanning; clients must account for recipient transaction costs, announcement indexing, and funding the derived address for a claim. The ERC does not define inbox information architecture, notification cadence, claim destination defaults, or an automatic fresh-address policy. Label those as product decisions and keep pending/unknown states when provider data is incomplete.","relatedStandards":[{"id":"ERC-6538","relationship":"Registry for discovering stealth meta-addresses"},{"id":"ERC-721","relationship":"Optional NFT privacy extensions"}]},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-5564","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-5564","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-5564","markdown":"https://www.eipsfordesigners.com/standards/ERC-5564/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-5564/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-5564","official":"https://ercs.ethereum.org/ERCS/erc-5564","discussion":"https://ethereum-magicians.org/search?q=ERC-5564"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}