No. Ethereum stealth addresses as standardized in ERC-5564 are not quantum-safe: their privacy rests on secp256k1 elliptic-curve Diffie-Hellman (ECDH), and a cryptographically relevant quantum computer could use the permanent on-chain announcement log to work out, after the fact, who received which payment. The new ERC-8441 draft proposes post-quantum stealth addresses that combine ML-KEM-768 with secp256k1. It protects only the announcement layer, though, and it costs considerably more in bytes, gas and scan time.<\/p>\n
This article explains how ERC-5564 works, why the risk is retroactive, what ERC-8441 changes, what it leaves open, and what wallet builders can do now.<\/p>\n
ERC-5564<\/a> was created on 2022-08-13 by Toni Wahrst\u00e4tter, Matt Solomon, Ben DiFrancesco and Vitalik Buterin and now has Final status. It lets a sender “non-interactively generate private accounts” that only the recipient can access. The sender doesn’t need to contact the recipient first.<\/p>\n Under schemeId 1 (secp256k1 with view tags), the mechanism works like this:<\/p>\n To keep scanning fast, the first byte of the hashed shared secret serves as a view tag<\/strong>: “The first byte of the metadata MUST be the view tag.” Recipients can skip most announcements that aren’t theirs after a single check. The spec notes that this reduces the privacy security margin “from 128 bits to 124 bits”, which affects privacy but not the secure generation of the stealth address.<\/p>\n Recipients publish their meta-addresses in the ERC-6538 stealth meta-address registry<\/a>, a Final standard created on 2023-01-24. It is one registry per chain, deployed with CREATE2 at Production wallets also borrow from these conventions. Fluidkey’s technical documentation<\/a> derives spending and viewing keys from a signed message and shares the viewing node at path The unlinkability of an ERC-5564 payment depends on one assumption: nobody can recover the shared secret from the public ephemeral key and the recipient’s public viewing key. That is the elliptic-curve discrete logarithm problem, and Shor’s algorithm on a large enough quantum computer solves it. For the broader picture of which parts of Ethereum are exposed, see our overview of whether quantum computers can break Ethereum<\/a>.<\/p>\n The ERC-8441 draft<\/a> describes the problem plainly. ERC-5564 announcements are “public, permanent, and centralized in one contract.” Under schemeId 1, privacy depends on secp256k1 ECDH, and a cryptographically relevant quantum computer (CRQC) could break that. The privacy loss would therefore be retroactive: every past announcement could be matched against every registered meta-address.<\/p>\n This is the blockchain version of “harvest now, decrypt later.” A March 2026 ethresear.ch post on post-quantum threats to Ethereum privacy<\/a> argues that public, append-only ledgers let attackers archive encrypted data now and break it later. It also draws a key distinction: authenticity failures can be partly repaired with forks, but privacy breaches are “irreversible.” Once a link between a sender and a recipient is revealed, no protocol upgrade can hide it again.<\/p>\n The same post lists the exposures it sees on Ethereum:<\/p>\n It proposes “no new classical privacy debt” as a design principle: new privacy systems shouldn’t add more data that a future quantum attacker could unlock.<\/p>\n ERC-8441, titled “Hybrid post-quantum stealth address scheme,” was created on 2026-08-28 by namnc, Pierre (dmpierre) and kassandra.eth. It is still a Draft<\/strong>. It requires EIP-5564 and EIP-6538 and registers as schemeId 3<\/strong>.<\/p>\n The core idea is to derive the payment secret from two independent sources: an ML-KEM-768 encapsulation (the lattice-based key encapsulation mechanism standardized in FIPS 203) and a classical secp256k1 ECDH secret. The two are combined like this:<\/p>\n The draft says the combiner follows the shape of NIST SP 800-227’s KeyCombineCCA_H, with stated departures. Binding the ephemeral key, the ciphertext and both public keys into the hash ties the derived secret to this specific exchange.<\/p>\n Two further design choices matter:<\/p>\n The classical ECDH half isn’t decoration. The draft calls it a hedge in case ML-KEM-768 is broken classically. As long as either component holds, the shared secret stays hidden.<\/p>\n Lattice-based keys and ciphertexts are large. The ethresear.ch post notes that ML-KEM-768 ciphertexts are 1,088 bytes, about 33x larger than compressed ECDH points. ERC-8441 gives these sizes:<\/p>\n Gas costs rise accordingly. The draft reports these Prague figures:<\/p>\n\n
ERC5564Announcer<\/code> contract at 0x55649E01B5Df198D18D95b5cc5051630cfD45564<\/code>, which emits an Announcement<\/code> event for each payment.<\/li>\n<\/ol>\n0x6538E6bf4B0eBd30A8Ea093027Ac2422ce5d6538<\/code>. Users can register directly, or a third party can register for them using an EIP-712 or EIP-1271 signature.<\/p>\nm\/5564'\/N'<\/code>, where “5564 refers to ERC-5564.” It uses 1\/1 Safe smart accounts as stealth accounts and resolves an ENS name such as username.fkey.id<\/code> to a new stealth address on every query.<\/p>\nWhy quantum computers would de-anonymize stealth payments retroactively<\/h2>\n
\n
ERC-8441: a hybrid ML-KEM-768 post-quantum stealth address scheme<\/h2>\n
ss = SHA3-256(DS || ss_ec || ss_pq || epk || ct || viewing_pk_ec || ek)<\/code>, with DS = \"pq-stealth\/hybrid-payment\/v1\"<\/code>.<\/p>\n\n
What post-quantum stealth addresses cost: bytes, gas and scan time<\/h2>\n
\n