ERC-5564 primary sources — 2026-05-11

Project status in this pass

• No standalone ERC-5564 whitepaper or litepaper surfaced.
• The clearest primary materials were the final ERC text, the raw ERC markdown, the reference announcer contract, the related ERC-6538 registry standard, and the ScopeLift stealth-address SDK README.
• The sources consistently frame ERC-5564 as a reusable recipient-privacy primitive rather than as a single wallet or app.

Primary-source snapshots

1) Final ERC text

• URLs:
  • https://eips.ethereum.org/EIPS/eip-5564
  • https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-5564.md
• Key excerpt/signals:
  • The ERC standardizes non-interactive stealth-address generation so a sender can derive a recipient-only address from a published stealth meta-address.
  • It defines interfaces for address generation, recipient-side checking, and stealth-key derivation.
  • It explicitly distinguishes viewing keys from spending keys.
• Why it mattered:
  • This is the clearest evidence that ERC-5564 should be cataloged as recipient-privacy infrastructure, with key publication and scanning roles as first-class components.

2) Singleton announcer contract

• URL: https://eips.ethereum.org/assets/eip-5564/contracts/ERC5564Announcer.sol
• Key excerpt/signals:
  • The reference contract emits a standard Announcement event containing schemeId, stealthAddress, caller, ephemeralPubKey, and metadata.
  • The first metadata byte must be the view tag.
• Why it mattered:
  • This makes the monitoring surface explicit: wallets, scanners, and indexers can all watch a common event interface instead of each product inventing its own announcement rail.

3) View-tag and parsing design

• URLs:
  • https://eips.ethereum.org/EIPS/eip-5564
  • https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-5564.md
• Key excerpt/signals:
  • The ERC says one-byte view tags reduce parsing work by around 6x.
  • The spec explains the exact privacy/performance tradeoff: recipients can skip most non-matching announcements, but one byte of the shared secret is revealed.
• Why it mattered:
  • This is the most analytically useful systems detail in the ERC, because it turns scanning economics and UX cost into a visible design tradeoff rather than an implementation footnote.

4) ERC-6538 registry companion standard

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-6538.md
• Key excerpt/signals:
  • ERC-6538 standardizes a singleton registry for storing stealth meta-addresses and supports both direct registration and registration on behalf of a user using EIP-712 or EIP-1271 signatures.
  • The registry exposes stealthMetaAddressOf, nonce management, and signature-based update flows.
• Why it mattered:
  • ERC-5564 describes the stealth-address mechanics, but ERC-6538 makes the publication/discovery layer explicit. Together they separate the privacy primitive from the registry/control plane around it.

5) ScopeLift stealth-address SDK

• URL: https://raw.githubusercontent.com/ScopeLift/stealth-address-sdk/main/README.md
• Key excerpt/signals:
  • The SDK explicitly implements ERC-5564 and ERC-6538 flows for generating addresses, computing stealth keys, scanning announcements, subgraph pagination, and live watch behavior.
  • The README treats announcement fetching, user-specific filtering, and scan-to-watch handoff as first-class operational concerns.
• Why it mattered:
  • This is strong evidence that the standard is already being used as an integration layer, and that scanning/indexing infrastructure is a major part of the real-world control surface.

Working conclusion

ERC-5564 belongs in the corpus because it gives the library a spec-level baseline for recipient privacy. The durable insight is that stealth-address systems are not only about cryptographic address derivation; they are also about how users publish meta-addresses, how scanners detect relevant announcements, how metadata trades privacy for usability, and who operates the surrounding registry and indexing layers.