ERC-8441: Hybrid post-quantum stealth address scheme

What it is

ERC-8441 defines schemeId 3 for ERC-5564 stealth addresses, built by Nam Ngo, Pierre Daix-Moreux, and kassandra.eth, with a public reference implementation, test vectors, and gas harness on GitHub (namnc/pq-stealth-scheme3-public).

How it works

Key generation starts from a single 128-byte seed that derives three things: a spending key, an ECDH viewing key, and an ML-KEM-768 seed pair (d, z). The registered meta-address is spending_pk || viewing_pk_ec || ek, 1,250 bytes total via ERC-6538. A separate 96-byte tracking key (viewing_ec || d || z) can be handed to a third-party scanning service — it can detect incoming payments but cannot spend them, since spending still requires the classical spending key.

The payment secret is ss = SHA3-256(DS || ss_ec || ss_pq || epk || ct || viewing_pk_ec || ek), hashing both the ECDH and ML-KEM shared secrets plus both ciphertexts together. The authors state this keeps the scheme IND-CCA as long as either component is, without depending on ML-KEM-specific properties. The announcement field packs epk || ct into 1,121 bytes, reusing ERC-5564's existing metadata layout and method signatures unchanged. The view tag is deliberately derived after the KEM step (from a domain-separated SHA-256 digest of ss), because a tag computed from the ECDH secret alone would let a future quantum adversary narrow down recipients using only the classical secret.

Preconditions / Affected

Applies to any ERC-5564/ERC-6538 stealth-address deployment wanting to pre-empt harvest-now-decrypt-later deanonymization of payment announcement logs. No contract changes are needed — it reuses the deployed ERC-5564 announcer and ERC-6538 registry as-is.

What to do

Measured cost on Prague, against the canonical contracts: a full schemeId 3 payment (announce, fund, spend) costs 111,330 gas, with the announcement itself landing on the EIP-7623 calldata floor — so its cost is driven purely by calldata size. Scanning each announcement requires one ECDH operation, one ML-KEM-768 decapsulation, and one hash, with no cheaper prefilter available — a real throughput cost for wallets or scanning services processing many announcements. Sender randomness must come from a CSPRNG, and encapsulation uses plain ML-KEM.Encaps(ek), so FIPS-validated ML-KEM libraries are compatible.

To avoid the downgrade attack, the draft advises recipients to register only under schemeId 3 (not both 1 and 3), and requires schemeId-3-aware senders to prefer it when available.

Caveats

The authors flag unresolved open questions directly: tools assuming a 33-byte ephemeral key will need to dispatch on schemeId to handle the 1,121-byte epk || ct field; the 1,250-byte meta-address breaks ERC-5564's n/2n sizing rule, the one deliberate spec departure; and the combiner hashes all six inputs rather than following X-Wing, and is not an SP 800-56C approved construction — the authors explicitly ask whether NIST approval is needed. They also note the ANO-CCA anonymity proofs available cover round-3 Kyber, not ML-KEM as standardized, though CRYPTREC's evaluation states the arguments carry over — treated as an assumption, not a proof.