Skip to main content
Receiving versus spending comparison

​
The short answer

Receiving is post-quantum safer than spending. More precisely:
  • the recipient discovery layer uses ML-KEM-768
  • the current spendable wallet output is still secp256k1
That is the core design tension in SPECTER today.

​
Why receiving is stronger

When a sender creates a payment, the shared secret comes from ML-KEM encapsulation. That logic is implemented in:
  • specter/specter-stealth/src/payment.rs
  • specter/specter-crypto/src/kyber.rs
The sender publishes a ciphertext and a view_tag. The recipient later decapsulates and discovers the payment. So the public discovery path is not built on classical ECDH.

​
Where the spend boundary appears

The spendable compatibility path is in specter/specter-crypto/src/derive.rs. The key details are:
  • derive_eth_key_seed(shared_secret, spending_pk) creates a valid secp256k1 seed
  • derive_eth_address_from_seed turns that into an Ethereum address
  • scan responses include eth_private_key
That means the recovered spend result is still classical Ethereum key material.

​
What this means in practice

ScenarioCurrent status
Sender creates a stealth destination for youStronger PQ posture than classical stealth systems
Announcement privacy and recipient discoveryBuilt on ML-KEM-768
Funds sitting at an unspent one-time addressBetter protected than classical ECDH receive paths
Spending through today’s Ethereum wallet modelStill tied to secp256k1

​
Visual boundary

Quantum defense visual Green side: stronger post-quantum posture. Amber side: classical execution compatibility.

​
Why the docs are explicit about this now

Because the repo itself makes the distinction visible:
  • the shared-secret path is ML-KEM
  • the spendable output path is Ethereum-compatible secp256k1
So the correct product positioning is: post-quantum recipient privacy, classical spend security

​
How could SPECTER become fully post-quantum end to end?

​
Path 1: ERC-4337 smart accounts

This is the most practical route available today at the account layer. Official ERC-4337 text states that:
  • smart accounts can contain arbitrary verification logic
  • the signature field usage is defined by the smart account implementation
That means a SPECTER smart account could, in principle, verify a PQ signature scheme inside validateUserOp instead of ECDSA. Source: ERC-4337

​
Path 2: EIP-8141 frame transactions

As of January 29, 2026, EIP-8141 is a Draft core proposal. Its abstract says transaction validity can be defined abstractly and may use any cryptographic system. That makes it a strong long-term fit for native PQ transaction validation, but it is not a live product dependency for SPECTER today.

​
Path 3: hybrid migration

A realistic migration path is:
  1. Keep SPECTER’s ML-KEM receive/discovery model.
  2. Route spending through smart-account validation.
  3. Swap ECDSA verification for a PQ signature scheme when wallet and account infrastructure is ready.

​
What we document as available today

The current repo demonstrates post-quantum recipient privacy and a wallet-compatible spend path. It does not yet implement ERC-4337 PQ smart-account spending or EIP-8141 execution.