Hadamard Get the app

Post-Quantum Stealth Addresses: ERC-5564 vs ERC-8441 Explained

Post-Quantum Stealth Addresses: ERC-5564 vs ERC-8441 Explained — Hadamard

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.

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.

How ERC-5564 stealth addresses work

ERC-5564 was created on 2022-08-13 by Toni Wahrstätter, 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.

Under schemeId 1 (secp256k1 with view tags), the mechanism works like this:

  1. The recipient holds a spending key pair and a viewing key pair. The two public keys together form the stealth meta-address.
  2. The sender generates a random ephemeral key, computes a shared secret from it and the recipient’s viewing public key, and hashes that secret.
  3. The stealth public key is the spending public key plus (hashed secret × G). Only the recipient can compute the matching private key: the spending private key plus the hashed secret.
  4. The sender publishes the ephemeral public key through a singleton ERC5564Announcer contract at 0x55649E01B5Df198D18D95b5cc5051630cfD45564, which emits an Announcement event for each payment.

To keep scanning fast, the first byte of the hashed shared secret serves as a view tag: “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.

Recipients publish their meta-addresses in the ERC-6538 stealth meta-address registry, a Final standard created on 2023-01-24. It is one registry per chain, deployed with CREATE2 at 0x6538E6bf4B0eBd30A8Ea093027Ac2422ce5d6538. Users can register directly, or a third party can register for them using an EIP-712 or EIP-1271 signature.

Production wallets also borrow from these conventions. Fluidkey’s technical documentation derives spending and viewing keys from a signed message and shares the viewing node at path m/5564'/N', 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 to a new stealth address on every query.

Why quantum computers would de-anonymize stealth payments retroactively

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.

The ERC-8441 draft 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.

This is the blockchain version of “harvest now, decrypt later.” A March 2026 ethresear.ch post on post-quantum threats to Ethereum privacy 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.

The same post lists the exposures it sees on Ethereum:

  • Stealth address linkages
  • Shielded amounts and notes
  • Selectively disclosed credentials
  • Viewing keys and note discovery

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.

ERC-8441: a hybrid ML-KEM-768 post-quantum stealth address scheme

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. It requires EIP-5564 and EIP-6538 and registers as schemeId 3.

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:

ss = SHA3-256(DS || ss_ec || ss_pq || epk || ct || viewing_pk_ec || ek), with DS = "pq-stealth/hybrid-payment/v1".

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.

Two further design choices matter:

  • The view tag is a separate SHA256 digest. It doesn’t leak bits of the stealth offset, unlike ERC-5564, where the tag is the first byte of the hashed secret. The trade-off is that the tag can only be checked after both the ECDH and the ML-KEM decapsulation.
  • No new infrastructure. ERC-8441 reuses the deployed ERC-5564 announcer and ERC-6538 registry unchanged. It needs no consensus change, no new opcode and no new contract.

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.

What post-quantum stealth addresses cost: bytes, gas and scan time

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:

  • Meta-address: 1,250 bytes (33 + 33 + a 1,184-byte ML-KEM encapsulation key)
  • ephemeralPubKey: 1,121 bytes (33 + a 1,088-byte ciphertext)
  • Per-payment announcement: 1,122 bytes

Gas costs rise accordingly. The draft reports these Prague figures:

Operation schemeId 1 (ERC-5564) schemeId 3 (ERC-8441)
Announce 28,313 69,330 (2.45x)
First-time register 115,310 964,737 (18.9x)
End-to-end native ETH payment not given 111,330

Registration is the expensive step, but recipients do it once. The per-payment overhead that senders pay every time is the 2.45x announce cost.

Scanning slows down too. In the authors’ own Rust measurements, checking one announcement takes about 150 µs, or about 100 µs with a cached decapsulation key, compared with about 55 µs for schemeId 1. Because the view tag can only be checked after decapsulation, every announcement costs the full post-quantum work.

The ethresear.ch post lists “PQ stealth address scalability” as an open problem, citing calldata bloat and memory costs of about 20 GB+ for OMR (oblivious message retrieval) approaches.

What ERC-8441 does not fix

ERC-8441 is explicit about its limits, and they matter as much as the construction:

  • Spending stays quantum-vulnerable. In the draft’s words: “Spending stays vulnerable to a quantum attacker.” Stealth accounts are still controlled by secp256k1 ECDSA keys, so funds can still be stolen once a CRQC exists.
  • Only the announcement layer is protected. Funding transfers, sweeps, gas funding and timing stay public. ERC-5564 already warns that funding a stealth address from a wallet linked to its owner can break privacy, and that remains true here.
  • Security assumptions. The draft assumes ML-KEM-768 is ANO-CCA (anonymous under chosen-ciphertext attack), “stated here as an assumption rather than inherited.” Privacy of past announcements holds only as long as ML-KEM-768 holds.
  • Downgrade risk. A recipient registered under both schemes can still be paid under schemeId 1. Senders that support schemeId 3 must prefer it.
  • Tracking keys. Anyone holding a delegated tracking key sees all payments. The key cannot be revoked, only replaced, and after a CRQC it becomes a spending capability.
  • Randomness reuse. Reusing the ephemeral key or the ML-KEM randomness links payments.

In short, ERC-8441 can keep future announcements from being decoded by a quantum attacker. It doesn’t make stealth funds quantum-safe, and it doesn’t hide the transaction graph around them.

The research behind lattice-based stealth address protocols

The idea of lattice-based stealth addresses predates ERC-8441. In “Post-Quantum Stealth Address Protocols”, submitted to arXiv on 2025-01-23, Marija Mikic, Mihajlo Srbakoski and Strahinja Praska propose stealth address protocols (SAPs) based on LWE, Ring-LWE and Module-LWE. The Module-LWE variant is built on Kyber, the scheme NIST standardized as ML-KEM.

The authors report that their Module-LWE SAP “outperforms ECPDKSAP by approximately 66.8% in the scan time of the ephemeral public key registry.” That compares against a specific elliptic-curve protocol variant, not ERC-5564 directly. It still shows that the scanning cost of lattice-based designs is an area of active optimization rather than a fixed penalty.

What wallet builders and users should do now

ERC-8441 is a draft, so its details may change. Even so, some practical steps follow from the published specs:

For wallet and protocol builders

  • Treat schemeId 1 announcements as eventually public. Design on the assumption that links made today could become readable once a CRQC exists.
  • If you implement schemeId 3, prefer it. Always choose it over schemeId 1 for recipients registered under both, to avoid the downgrade the draft warns about.
  • Never reuse ephemeral keys or ML-KEM randomness. Reuse links payments.
  • Handle tracking keys as long-lived secrets. They can’t be revoked, and after a CRQC they become spending capabilities.
  • Budget for size and scan time. Plan for 1,122-byte announcements and roughly 2–3x slower per-announcement scanning in indexers and mobile clients.

For users

  • Don’t rely on today’s stealth addresses for relationships that must stay private for decades.
  • Avoid funding stealth addresses, or paying their gas, from wallets linked to you.
  • Remember that stealth privacy and fund safety are separate problems. Even a post-quantum announcement layer leaves ECDSA spending keys exposed.

Fixing the spending side means replacing ECDSA, either with post-quantum signatures (see our comparison of ML-DSA and SLH-DSA signatures) or with hash-based account designs. That is the approach Hadamard takes with BB84, an ECDSA-free Layer 2 rollup on Ethereum mainnet in which accounts are one-time addresses based on hash commitments instead of ECDSA keys. To see how other chains and standards are progressing, see the Post-Quantum Migration Tracker.

FAQ

Will a quantum computer reveal who received my past stealth address payments?

For ERC-5564 schemeId 1 payments, it could. Their privacy depends on secp256k1 ECDH, and the announcements are public and permanent. The ERC-8441 draft therefore describes the potential privacy loss from a cryptographically relevant quantum computer as retroactive.

Does ERC-8441 make stealth address funds safe from quantum theft?

No. The draft states that “Spending stays vulnerable to a quantum attacker,” because stealth accounts still use secp256k1 ECDSA. ERC-8441 protects only the announcement layer.

Why are post-quantum stealth addresses so much bigger and more expensive?

ML-KEM-768 uses a 1,184-byte encapsulation key and a 1,088-byte ciphertext. That pushes meta-addresses to 1,250 bytes and announcements to 1,122 bytes, which raises announce gas 2.45x and first-time registration gas 18.9x compared with schemeId 1.

Do I need a new contract or a hard fork to use post-quantum stealth addresses?

No. ERC-8441 reuses the deployed ERC-5564 announcer and ERC-6538 registry unchanged. It needs no consensus change, no new opcode and no new contract. Wallets only need to support schemeId 3.

Sources