Summary: ERC-6538 is best understood not as a minor companion note to ERC-5564, but as the publication-and-discovery control plane for stealth addresses on EVM chains. Its core mechanism is a singleton per-chain registry that maps a registrant and scheme id to a stealth meta-address, with both direct registration and delegated registration on behalf of a user via EIP-712 or EIP-1271 signatures. That makes it analytically useful because it separates stealth-address cryptography from the practical question of where wallets, contracts, indexers, and counterparties discover the recipient’s meta-address in the first place.
What it does:
Standardizes a singleton ERC6538Registry contract that stores stealth meta-addresses keyed by registrant and scheme id
Lets users register their own stealth meta-address directly with registerKeys
Lets third parties register on behalf of a user with registerKeysOnBehalf using EIP-712 or EIP-1271 signatures
Maintains a per-registrant nonce and exposes incrementNonce() so previously signed delegated registrations can be invalidated
Treats the chain identifier as implicit from the chain-local singleton deployment, so the stored bytes are the concatenated public-key material rather than the full st:<chain>:... URI
Gives SDKs and contracts a canonical lookup point for the registry layer that sits beside ERC-5564 announcement and derivation mechanics
Key claims:
The ERC text is explicit that this standard extends ERC-5564 rather than replacing it. That distinction matters: ERC-5564 standardizes stealth-address generation and announcement, while ERC-6538 standardizes where a recipient publishes the reusable meta-address others should target.
The singleton-per-chain requirement is the most important architectural choice in the spec. It turns stealth-meta-address discovery into shared infrastructure rather than a wallet-specific convention, which means registry deployment, indexing, and UI support become part of the practical privacy stack.
registerKeysOnBehalf is analytically important because it makes delegation a first-class feature. Wallets, smart accounts, relayers, or app backends can help manage recipient privacy without taking spend authority, but they still become part of the operational control plane around key publication.
The nonce model is not just replay protection boilerplate. It reveals a second operational surface: recipients can explicitly burn old signatures and rotate who is allowed to publish on their behalf, which matters for account abstraction and delegated wallet flows.
ScopeLift’s canonical contracts repo and SDK are useful evidence that ERC-6538 is not merely a speculative draft. The registry is deployed to multiple production chains and the SDK exposes lookup, registration-payload preparation, scanning, and watch flows that treat ERC-6538 as a real integration layer.
ERC-6538 belongs in the active corpus because otherwise stealth-address coverage gets flattened into pure cryptography. The registry layer determines where discovery power sits, how portable recipient privacy actually is, and which contracts or services become canonical lookup points.
Whitepaper: No standalone ERC-6538 whitepaper or litepaper surfaced in this pass. The clearest primary materials were the final ERC text, the raw ERC markdown, the Ethereum Magicians discussion thread, the ScopeLift canonical contracts repo, and the ScopeLift stealth-address SDK README collected in ../../whitepapers/erc-6538-primary-sources-2026-05-11.md.