Hybrid post-quantum stealth addresses (ERC-5564 schemeId 3)

What it is

Draft ERC proposing schemeId 3, a hybrid post-quantum scheme for ERC-5564 stealth addresses. Authors: Nam Ngo, Pierre Daix-Moreux, kassandra.eth. The summary already covers the core mechanism (ML-KEM-768 + secp256k1 ECDH), the combiner, view-tag ordering, the 111,330 gas figure, and the open questions — this adds the concrete key/byte layout and the threat-model argument the summary compresses out.

How it works

A 128-byte seed derives three keys: a spending key, an ECDH viewing key, and an ML-KEM-768 seed (d, z). The meta-address is spending_pk || viewing_pk_ec || ek, 1,250 bytes total, registered once via ERC-6538. A 96-byte tracking key (viewing_ec || d || z) can be delegated to a scanning service — it finds payments but cannot spend them. The announcement's ephemeralPubKey field carries epk || ct (1,121 bytes) instead of ERC-5564's normal 33-byte ephemeral key, reusing the existing metadata slot for the view tag. No new contracts are needed; it piggybacks on the deployed ERC-5564 announcer and ERC-6538 registry.

Preconditions / Affected

Applies to wallets/registries implementing ERC-5564/ERC-6538 stealth addresses. Tools that assume a fixed 33-byte ephemeral key must branch on schemeId to handle the 1,121-byte field. The 1,250-byte meta-address breaks ERC-5564's n/2n length rule — the draft's one stated non-conformance.

Why now (threat model, stated explicitly)

The authors distinguish two quantum threats: deanonymization (an attacker with a future quantum computer can retroactively break discrete logs on today's public, permanent announcement log to unmask recipients) versus theft (requires a quantum computer to exist while funds are still unspent). schemeId 3 only addresses the first — protection must be deployed before quantum computers exist, since the log is already public and permanent. Spending/theft protection is explicitly deferred to a separate future migration.

What to do

Recipients registering under schemeId 3 are advised by the draft to register only schemeId 3, not alongside schemeId 1 — a wallet that only knows schemeId 1 will still pay the schemeId-1 address with no post-quantum protection, and the draft cannot prevent that downgrade by itself.

Caveats

Explicitly stated by the authors as unresolved: schemeId 3 does nothing for spending-side exposure — once a quantum computer exists, a spend reveals the classical public key and the registered spending key falls, so anyone (including a delegated scanner) holding a payment's shared secret ss can spend it; funds still need a separate migration before that point. Scanning requires a full ML-KEM decapsulation plus ECDH plus hash per announcement with no cheaper prefilter — cost impact on wallets/scanners is an open question the authors pose rather than answer.