Skip to main content
Receiving versus spending comparison

​
Article preview

“The short answer: receiving is PQ-safe, spending is not.”
Original post: Pranshu Rastogi on X, March 9, 2026

​
The short version

SPECTER already upgrades the recipient privacy layer to ML-KEM-768. That is the part that decides whether outsiders can map a public announcement back to you. But once the payment needs to become a spendable Ethereum wallet output, the current implementation derives a secp256k1 key so it can work with today’s wallet stack. That is the tradeoff.

​
Why receiving is the strong side

In specter/specter-stealth/src/payment.rs, the sender:
  1. encapsulates to viewing_pk
  2. gets a shared secret
  3. computes the view_tag
  4. derives the one-time destination
  5. publishes the announcement
The ML-KEM implementation itself is in specter/specter-crypto/src/kyber.rs. That means the on-chain discovery breadcrumb is not resting on classical ECDH.

​
Why spending is still classical

In specter/specter-crypto/src/derive.rs, the shared secret is turned into a valid Ethereum-compatible seed: 
fn derive_eth_key_seed(shared_secret: &[u8], spending_pk: &[u8]) -> Result<[u8; 32]>
Then:
  • derive_eth_address_from_seed derives the address
  • derive_stealth_keys returns a private key object
  • the scan API exposes eth_private_key
So the user ends up with something current Ethereum tooling can spend from. That is useful. It is also the precise point where the flow stops being fully post-quantum.

​
The honest product statement

SPECTER today offers post-quantum recipient privacy and classical spend compatibility.
That is still a meaningful improvement over classical stealth systems because it protects the discovery layer against long-term quantum risk. It is just not the same as fully post-quantum transaction execution.

​
What could close the gap?

​
ERC-4337 smart accounts

ERC-4337 already lets smart accounts define their own verification logic. The standard explicitly says the signature field usage is defined by the smart account implementation, and validateUserOp is where that verification happens. That creates a path for PQ signature validation inside smart accounts. Source: ERC-4337

​
EIP-8141 frame transactions

As of January 29, 2026, EIP-8141 is a draft proposal for frame transactions. Its abstract says transaction validity and gas payment can be defined abstractly and may use any cryptographic system. That makes it the cleanest native-looking future path for post-quantum validation on Ethereum, if it progresses.

​
A realistic SPECTER path

  1. Keep ML-KEM for recipient privacy and discovery.
  2. Move spending into smart-account style validation.
  3. Replace ECDSA verification with a PQ signature scheme when the account layer is ready.

​
Why this article matters

Privacy docs often fail by promising the end state instead of documenting the current boundary. This section exists so SPECTER does not do that.