Post-quantum owners for Safe: hash-based signers (Winterlock)

Safe Ecosystem Initiatives
1

TL;DR
Every Safe is ultimately controlled by ECDSA owner keys. Winterlock replaces them with hash-based owners — WOTS for daily signing, SPHINCS+ for recovery — that an existing Safe can adopt in place, without moving funds. Feedback welcome. We’d also ask the foundation to consider an open call for post-quantum owner support.

Why now
This week Vitalik argued that AI-accelerated math could weaken elliptic-curve and lattice cryptography sooner than expected, and recommended hash-based constructions wherever possible. Ethereum’s post-quantum roadmap targets core L1 upgrades for 2029. Wallet migration will take longer.

For Safe specifically:

  • A Safe has no key of its own, but its owners are almost always ECDSA.
  • Every executed transaction publishes owner signatures, so each signer’s public key is recoverable. If ECDSA weakens, those keys are the first targets.
  • Owners can be swapped in place, without moving funds — avoiding the migration mistakes Vitalik says have cost him more than hacks.

What we propose

  1. Hash-based owner. An EIP-1271 contract that verifies WOTS signatures against a Merkle tree of one-time keys. Each key is valid for one Safe nonce only. A stateless SPHINCS+ key is the backup and recovery path.
  2. Migration. Tooling to add a Winterlock owner, raise the threshold, and retire the ECDSA owners, after checking modules, guards, and fallback handlers so no ECDSA path to the funds remains.
  3. Shared verification cost. A WOTS signature is about 2 KB and takes hundreds of hashes to check, far more gas than ECDSA. An off-chain prover can collect many signatures and post one STARK proof that they are all valid, splitting the on-chain cost across the batch. STARKs are hash-based, so the stack stays free of elliptic curves and lattices. Anyone can skip the batch and verify directly at full price. Batching is optional and cannot block a transaction.
  4. Signing app. Existing hardware wallets first; dedicated hardware only if demand justifies it.

Once owners are hash-based, publishing signatures on-chain no longer exposes a reusable key.

Open questions

  • Long term, does Safe prefer an EIP-1271 owner, a module, or a guard?
  • Some flows sign more than once per nonce (rejections, off-chain messages, permits). We plan separate key slots so no one-time key is reused. Better ideas welcome.
  • Would Safe{Wallet} flag owners whose public keys are already exposed?
  • Which chains first? Verification gas is easier to absorb on L2s.
  • Any DAOs or treasuries interested as design partners?

What we’re asking for

  • Design feedback.
  • A foundation open call or grant track for post-quantum owner support.
  • Help with Safe app integration, and audit funding through the security track.

Rough milestones

  1. Spec, reference contracts, test suite
  2. Audited owner contract and migration tool on testnet
  3. Batched verification beta, with direct verification as fallback
  4. Hardware wallet signing app

About us
Johann & Max, Berlin
winterlock.eth.limo

3 Likes