# ERC-5564: Stealth Addresses Source: https://www.eipsfordesigners.com/standards/ERC-5564 Agent brief: https://www.eipsfordesigners.com/standards/ERC-5564/agent.md Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-5564 Last reviewed: 2026-05-25 Last updated: 2026-05-25 | Field | Value | | --- | --- | | Status | Final | | Chain | both | | Category | Identity & Privacy | | Journey stages | Authentication & Identity | | Detailed guide | Yes | | Official specification | https://eips.ethereum.org/EIPS/erc-5564 | | Discussion search | https://ethereum-magicians.org/search?q=ERC-5564 | ## UX Impact Senders generate one-time stealth addresses for recipients — receive funds privately without revealing main wallet. Design implications: show 'Send Privately' option, explain stealth address concept simply, add stealth transaction scanner for recipients. Design decisions: how to onboard users to stealth — complexity vs privacy benefit, whether to default to private or make it opt-in, scanning UX for finding received funds. 77K addresses deployed via Umbra. Part of the On-Chain Activity Is Public by Default pain point (High severity, Research status). Users often don't realize their complete financial history is visible — stealth addresses are one of four leading privacy solutions. ## Summary Senders generate one-time stealth addresses for recipients — receive funds privately without revealing main wallet. ## What does not work everywhere yet Many wallets support sending to a private receiving profile, but inbox scanning and claim flows are not universal yet. Label what each wallet can do, offer Rescan, and never imply funds are lost when a payment has not appeared. ## For Designers - You can offer Send privately alongside normal send with plain-language privacy benefit. - Your receive flow can show a stealth receiving address separate from your public wallet. - You can build a stealth payment inbox that scans and surfaces incoming deposits. ## Applicability ### When to Use - Privacy is a core product value. - Users receive donations, salary, or payments without public linkage. - Wallet supports stealth key generation and scanning. ### When to Avoid - Compliance requires transparent recipient identity on every transfer. - Wallet lacks scanning infrastructure — users would miss funds. - Simple public address send meets the need with less risk. ## Problems It Solves ### All wallet activity is public Impact: critical Old way: Single address reveals full financial history New way: One-time deposit addresses unlink payments from main wallet ### Sharing address reveals entire history Impact: critical Old way: Give address to receive payment, they see all your transactions New way: Generate fresh address per sender ### Donation and salary privacy Impact: high Old way: Recipients expose net worth on chain New way: Stealth receive hides incoming payment graph ### Sender links to recipient forever Impact: high Old way: Permanent address ties parties in explorer graph New way: Ephemeral address breaks long-term linkability ### Reusing addresses destroys privacy Impact: high Old way: Manual new address per payment = terrible UX New way: Automatic stealth address generation ## Anti-Patterns ### Stealth receive with no scanner Severity: critical Users never see incoming funds Instead: Mandatory inbox with auto-scan and notifications ### Claiming to main wallet by default Severity: critical Links stealth payment to main identity and defeats privacy Instead: Default to fresh address; warn if main wallet selected ### Showing stealth and public address interchangeably Severity: critical Senders pay to wrong target Instead: Distinct labels: Public address vs Private receiving profile ### Auto-claiming to main wallet Severity: critical User loses privacy without knowing Instead: Always ask where to claim and explain implications ### No scanning progress indicator Severity: high Scanning can take time; users think the inbox is broken Instead: Show scanning progress and found count ### Privacy jargon in primary CTA Severity: high Users avoid feature they do not understand Instead: Send privately with one-line benefit copy ## Design Decisions ### Default to private or opt-in? Recommendation: Opt-in with clear Send privately toggle; keep public send default for familiarity. Rationale: Stealth misses funds if scanning fails — defaulting private is risky. ### How much cryptography to show? Recommendation: Meta-address copy button only; hide derivation details. Rationale: Keys and schemes overwhelm; outcomes matter. ### Automatic background scan? Recommendation: Yes with manual Rescan and notification on new payment. Rationale: Users will not manually scan every session. ## States to Design ### Stealth not set up Trigger: User has no stealth keys. User need: Start receiving private payments. Design response: Onboarding card with Register for private payments. ### Scanning for payments Trigger: User opens inbox or background scan runs. User need: Know scan is working. Design response: Scanning indicator with last checked time. ### New stealth payment detected Trigger: Scan finds incoming deposit. User need: See amount and sender hint if available. Design response: Inbox row with Accept or Review action. ### Send privately confirmation Trigger: Sender submits stealth payment. User need: Confirm sent without exposing recipient main wallet. Design response: Sent privately confirmation; no link to recipient public address. ### Scan failed or missed payment Trigger: Indexer lag or user on new device. User need: Recover without panic. Design response: Rescan CTA and support path; never imply funds are lost. ## Vocabulary - Use "Send privately" instead of "Generate stealth address": Outcome language over cryptography. - Use "Private receiving profile" instead of "Stealth meta-address": Metaphor before protocol terms. - Use "Check for incoming payments" instead of "Scan stealth tags": Action users understand. ## What to Prototype First ### Send privately composer Senders need privacy without learning stealth jargon. Covers: Stealth recipient, Amount, Confirmation - Send privately toggle - Recipient stealth address field - Privacy explainer one-liner ### Stealth receive setup Recipients must register and share the right meta-address. Covers: Unregistered, Registered, Share sheet - Register for private payments CTA - Meta-address copy - QR for stealth receiving ### Stealth payment inbox Funds are invisible until scanned — inbox is critical. Covers: Scanning, New payment found, Empty - Scan now button - Incoming payment rows - Claim or acknowledge flow ### Privacy onboarding First-time users need metaphor before math. Covers: Opt-in education, Skip - One-time address analogy - When to use public vs private - Do not show keys by default ## Mental Model ### Public wallet Your normal address — full history visible on explorers. ### Stealth meta-address A receiving profile from which one-time addresses are derived — not where funds sit. ### Ephemeral deposit address Sender pays to a unique address linked only to recipient via cryptography. ### Scanning Recipient wallet scans chain to detect payments to addresses only they can recognize. ### Spending Detected funds move to spendable balance after recipient claims with derived keys. ## Seen in the Wild - Umbra: Stealth address pioneer with 77K+ deployments; reference for scan UX. (https://umbra.cash/) - Railgun: Private transfer patterns inform send/receive mental models. (https://railgun.org/) - Safe: Multi-chain wallets exploring privacy receive flows. (https://safe.global/) - Vitalik blog: Stealth address explainer shapes user-facing metaphors. (https://vitalik.eth.limo/) ## UI Components ### StealthMetaAddressDisplay Show and share private receiving profile States: generating, ready, copied Props: metaAddress, onCopy, showQR ### StealthInbox Scan and list stealth payments States: scanning, found-payments, no-payments, error Props: payments[], onClaim, scanProgress ### StealthSendForm Form for sending to a stealth meta-address States: entering, generating, confirming, sent Props: recipientMetaAddress, amount, generatedAddress, onSend ### ClaimDestinationPicker Choose where to claim a stealth payment States: selecting, warning, confirmed Props: mainWallet, freshAddressOption, onSelect ### PrivacyIndicator Show privacy level of an action States: private, partially-private, public Props: privacyLevel, explanation ## On Monad ### Scan throughput Ethereum: Scanning large history is slow Monad: High throughput chains need efficient scan indexing Design implication: Invest in fast inbox scan; show progress for large histories. ### Claim cost Ethereum: Each claim costs gas, discouraging small payments Monad: Cheap claims make small stealth payments viable Design implication: Small private tips and donations become practical. ### Private send cost Ethereum: Stealth txs may cost more Monad: Lower fees reduce barrier to privacy opt-in Design implication: Do not warn heavily about gas for private sends on Monad. ### Claim finality Ethereum: Claim tx takes ~15 seconds Monad: Sub-second claim finality Design implication: Instant access to received funds after claim. ## Key Takeaways - ERC-5564 = privacy through one-time deposit addresses - Share a private receiving profile; receive to unlinkable addresses - Default claims to a fresh wallet; warn before claiming to main - Show scanning progress when checking the inbox - Explain privacy benefits in plain language, not cryptography ## UX Patterns ### Share Stealth Meta-Address Give out a receiving profile that enables private payments. Components: StealthMetaAddressDisplay User flow: - User wants to receive payment privately - Opens private receiving setup - Copies or shows QR of meta-address - Shares with sender Mockup registry key: `concept/stealth-receive` (React UI on the live standard page). ### Send Privately Toggle Optional stealth send in transfer composer. Components: PrivacyToggle, StealthAddressInput, SendButton User flow: - User composes send - Enables Send privately - Enters meta-address - Confirms - Payment sent to ephemeral address Mockup registry key: `concept/stealth-address` (React UI on the live standard page). ### Send to Stealth Address Send payment privately to a recipient meta-address. Components: StealthSendForm, PrivacyIndicator User flow: - User pastes recipient meta-address - Enters amount - System generates unique deposit address - Shows privacy assurances - Sends and publishes announcement for recipient Mockup registry key: `concept/stealth-address` (React UI on the live standard page). ### Stealth Payment Inbox Scan and list incoming private payments. Components: ScanButton, PaymentList, AcceptAction User flow: - User opens inbox - Scan runs - Payments appear - User accepts into balance Mockup registry key: `concept/stealth-inbox` (React UI on the live standard page). ### Claim Stealth Payment Move funds from a stealth deposit to a spendable wallet. Components: ClaimDestinationPicker, PrivacyIndicator User flow: - User selects payment to claim - Sees payment details - Chooses destination (main vs fresh wallet) - Warned if main wallet breaks privacy - Claims to chosen destination Mockup registry key: `concept/stealth-inbox` (React UI on the live standard page). ## Related Standards - ERC-6538: Registry for discovering stealth meta-addresses - ERC-721: Optional NFT privacy extensions ## Technical Notes ERC-5564 stealth requires reliable scanning; never ship receive-only stealth without inbox UX.