wallet standards

A draft Ethereum Request for Comments proposes a standard for how wallets derive post-quantum cryptographic keys from BIP-39 recovery phrases, the 12- or 24-word backups that users already control. The specification addresses a fragmentation problem: three different wallets today produce three different keys from the same phrase, making it impossible to restore quantum-resistant accounts across implementations.

• Draft defines deterministic derivation using HMAC-SHA512 and HKDF, no elliptic-curve arithmetic
• Covers five hash-based signature schemes: leanSPHINCS, SLH-DSA, WOTS, FORS, XMSS
• Test vectors and two independent implementations (Python and Rust) verify derivation paths

The post on the Ethereum Magicians forum, published Friday, Nov 13, describes ERC-8499 as a response to a concrete adoption problem. Wallets and signing tools have already begun supporting hash-based signatures through ERC-1271 (contract signature verification) and account abstraction. But without a standard for converting a BIP-39 phrase into a quantum-resistant key, implementations have diverged: one wallet uses Keccak-256 hashing over application labels, another applies a second PBKDF2 round with its own salt, and a hardware wallet in development derives keys through HMAC-SHA512. The same 12-word phrase thus produces incompatible keys across devices, blocking recovery and portability.

Why not BIP-32 for post-quantum keys

The proposal explicitly rejects using the existing BIP-32 hierarchical deterministic standard, which wallets already use for Ethereum and Bitcoin addresses. The reason is quantum-critical: BIP-32 derives child keys from parent public keys using elliptic-curve arithmetic.

A quantum adversary with access to an xpub (extended public key) exported to watch-only software could compute the corresponding private key and then derive every hardened child key below it. Hash-based signatures break that chain.

The draft specifies that “every secret is derived with HMAC-SHA512: in BIP-39’s own PBKDF2, then in HKDF (RFC 5869). No BIP-32, no curve arithmetic.” The root seed flows through HMAC to produce stateless keys (permanent account keys), stateful keys (one-time signature pairs that are never restored), and application-specific secrets.

A wallet that conforms must derive the root and produce a deterministic seed for each stateless key, named by account number and key type.

Interoperability through test vectors and reference code

To ensure different wallets produce identical keys from the same phrase, the draft includes test vectors covering three seed phrases, random roots for devices without phrases, account numbers 0, 1, and 2^32 − 1, and three SLH-DSA key types across the full derivation path.

Two independent implementations, one in Python and one in no_std Rust for browsers and embedded devices, reproduce all test values, demonstrating that the specification is implementable without vendor-specific extensions.

The proposal specifies 12 SLH-DSA key types matching FIPS 205, the U.S. National Institute of Standards and Technology post-quantum standard. When a future cryptographic parameter set becomes standardized, a wallet can derive a new key from the same phrase without a new backup; the old key certifies the new one.

Stateful schemes like WOTS and XMSS are explicitly never restored after account recovery, each instance consuming 32 fresh random bytes stored with its state.

Open design questions for wallet implementers

The draft does not yet decide several points central to wallet UX and agent design. It asks whether the standard should fix the format of a post-recovery fingerprint that two wallets both display to confirm they hold the same keys. It leaves open whether other post-quantum schemes like leanSPHINCS should define their own key-type registries or whether ERC-8499 should maintain a single registry.

For stateful keys on devices without reliable storage, the draft poses whether a deterministic counter might be safer than random instances.

The proposal also seeks feedback from hardware wallet makers on whether the seed-only derivation approach is practical for devices that store only the BIP-39 seed, and from builders of agent wallets, automated signers that might be replicated as VM snapshots or started multiple times from a container image, on whether random roots held separately from the recovery phrase match their threat model.

The draft warns that any automated signer holding a one-time signature key risks signing twice with the same key if the signer is copied.

The CCS read. Hash-based signatures are coming to Ethereum, and this standard removes a major adoption friction: you already back up your accounts with BIP-39. A common derivation path means wallet developers can focus on signature verification and account abstraction, not key synchronization. The open questions, fingerprint format, agent key storage, stateful-key recovery, are engineering details that feedback from production wallet teams will settle. This is how standards mature.

The next milestone is community feedback on the Ethereum Magicians forum and GitHub pull request, followed by revision and a decision on whether ERC-8499 should move to last call. Hardware wallet makers and agent-wallet builders must signal whether the spec fits their constraints before a final recommendation.