ERC-5564

Developers at Ethereum Magicians have published a draft extension to ERC-5564 stealth addresses that layers post-quantum encryption onto payment privacy, protecting against the threat of future quantum computers breaking the current scheme. The proposal, schemeId 3, keeps spending classical while securing the link between a public announcement and its recipient using ML-KEM-768 alongside secp256k1 ECDH.

• Full payment cycle costs 111,330 gas on Prague testnet against canonical contracts.
• Meta-address reaches 1,250 bytes, exceeding ERC-5564’s design ratio.
• Scanning requires one ECDH, one ML-KEM decapsulation and one hash per announcement with no optimization available.

• 1,250 bytes: meta-address size, combining spending key, viewing key and KEM encapsulation
• 111,330 gas: full announcement, funding and spend transaction on Prague
• 128 bytes: seed required to derive all three key components

The draft ERC for hybrid post-quantum stealth addresses extends the existing stealth address standard by adding a quantum-resistant payment secret that combines ML-KEM-768 encapsulation with ECDH. Under the current schemeId 1, anyone who later builds a quantum computer can decrypt the viewing key from the public announcement log and learn all past recipients. SchemeId 3 prevents this by encoding the payment secret as

SHA3-256(DS || ss_ec || ss_pq || epk || ct || viewing_pk_ec || ek)

the draft specification, hashing both the classical ECDH secret and the post-quantum shared secret derived from ML-KEM.

No protocol or contract changes required

The scheme reuses the existing ERC-5564 announcer contract and ERC-6538 registry with no modifications. Each stealth address remains an ordinary secp256k1 externally owned account, and spending logic does not change. Only the announcement structure expands: the ephemeralPubKey grows from 33 bytes under schemeId 1 to 1,121 bytes to accommodate the ML-KEM ciphertext.

A scanning service can accept a 96-byte tracking key comprising the ECDH viewing key, the ML-KEM decapsulation seed and related material, allowing it to find payments without access to the spending key. The view tag is derived from separate domain-separated SHA-256 digests of the payment secret, computed after the KEM decapsulation, so a quantum adversary cannot use it alone to filter candidates.

Quantum threat timeline and key exposure

The scheme protects only the link between announcement and recipient. Once a quantum computer exists, any spend reveals the classical spending public key, exposing the address even if announcements remain secret. A quantum computer built today would also compromise any registered spending key in the ERC-6538 registry, meaning a delegated scanner holding the payment secret could spend the funds.

Users must migrate funds to a fresh classical account before a large-scale quantum computer is deployed.

Funding amounts, transfer patterns, timing and sweep transactions remain linkable as in any stealth address scheme. The protection is narrow: it prevents retroactive de-anonymization of announcements from the viewing key alone, assuming ML-KEM-768 remains secure.

Open questions on tooling, KEM assumptions and standards compliance

The draft raises several unresolved design questions. The meta-address at 1,250 bytes violates ERC-5564’s stated design ratio, which assumes addresses fit within a n / 2n envelope. Tools expecting a 33-byte ephemeral key will need to dispatch on schemeId, adding conditional logic to wallets and indexers. The authors ask whether this overhead is acceptable.

The combiner hashes all six inputs (both shared secrets, both ciphertexts, and both public keys) rather than following NIST’s X-Wing construction or SP 800-56C approval. The post-quantum anonymity proof for ML-KEM as standardised has not been published separately; the authors cite CRYPTREC’s assertion that Kyber proofs transfer but flag this as an assumption.

Scanning performance is also open: every announcement requires full ML-KEM decapsulation before the view tag can filter candidates, with no cheaper prefilter available. The authors ask how much this matters for large-scale scanning services.

Backwards compatibility risk

A recipient can register both schemeId 1 and schemeId 3 simultaneously in ERC-6538. A wallet that only recognizes schemeId 1 will pay without post-quantum protection, even if the recipient prefers it. The draft advises senders implementing schemeId 3 to prefer it and recipients to register only schemeId 3, but the standard cannot enforce this choice.

The CCS read. The proposal protects announcement privacy retroactively, but at a cost: 1,250-byte addresses and mandatory full decapsulation per scan. The choice to preserve classical spending exposes the scheme the moment a spend occurs after quantum computers exist. For now, the bigger risk is adoption friction: if wallets and scanning services must condition logic on schemeId and bear higher scanning costs, the narrower protection may not justify deployment at scale.

The draft is open for community feedback on Ethereum Magicians with no activation date yet proposed. The next milestone is resolution of the meta-address size question, the ML-KEM anonymity assumption, and performance data from production scanning services.