Designing a Quantum-Secure Ethereum Wallet
The smart contract architecture behind a wallet that transitions from classical to quantum-secure cryptography without ever moving your funds.
Quantum computers are getting closer to breaking the elliptic curve cryptography that secures every Ethereum account. When that day comes, any wallet signed with ECDSA becomes vulnerable. I'm proposing an open-source smart wallet that's ready for that future, using post-quantum signature schemes that already verify on-chain today.
The core idea: this is a wallet for the transition period. Start with ECDSA. It's secure today and compatible with everything. Register post-quantum keys when you're ready. When Q-Day arrives and ECDSA is no longer safe, disable it in one transaction. Your funds stay in the same account, at the same address, with no migration. The account evolves from classical to quantum-secure without ever moving assets.
This post walks through the smart contract architecture. The whole system is a few hundred lines of Solidity on top of existing open standards, and I think the design is interesting enough to share before the code is finished.
The Architecture
The account itself is ZeroDev's Kernel v3.3, an open-source ERC-4337 smart account with ERC-7579 module support. All the post-quantum logic lives in a single validator module, PQValidator, that Kernel calls whenever it needs to verify a signature. Here's how the pieces fit together:
ERC-4337 EntryPoint
│
▼
┌────────────────────┐
│ Kernel v3.3 │
│ (ZeroDev, MIT) │
└─────────┬──────────┘
│ validateUserOp
▼
┌────────────────────┐
│ PQValidator │
│ (key management, │
│ scheme allowlist)│
└─────────┬──────────┘
│ routes by scheme ID
▼
┌────────────────────┐
│ PQSignatureRouter │
└──┬──────┬──────┬───┘
│ │ │
┌────────────┘ │ └────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌───────────────┐ ┌────────────────────┐
│ EcdsaVerifier │ │ EthFalcon │ │ ComposedVerifier │
│ │ │ Adapter │ │ (any two schemes) │
└─────────────────┘ ├───────────────┤ └────────────────────┘
│ MldsaAdapter │
└───────┬───────┘
│
▼
┌────────────────────┐
│ ZKNOX on-chain │
│ PQ verifiers │
└────────────────────┘
PQValidator manages per-account configuration: which keys are approved, which schemes are allowed. It routes signatures by scheme ID to adapters that wrap the ZKNOX on-chain verifiers. Both ETHFALCON and MLDSAETH are Ethereum-optimized variants of their respective PQ algorithms, replacing SHAKE with Keccak for significantly cheaper on-chain verification.
PQValidator is an ERC-7579 module, not a custom account. No fork to maintain. Kernel handles everything else: deployment, execution, module management. Other module types (executors, hooks, spending limits) can be installed alongside without compromising quantum security.
On-Chain Key Storage
Post-quantum public keys are large. An ETHFALCON key is 1,024 bytes, an expanded MLDSAETH key is several kilobytes. Sending the full key in every transaction would waste significant calldata gas.
Instead, each adapter stores keys on-chain at registration time and returns a compact 32-byte keyId. Every subsequent signature references the key by this ID rather than embedding the full key. This saves ~1,000 bytes of calldata per ETHFALCON transaction, roughly 16K gas that would otherwise be wasted on every single UserOp.
Hybrid Verification
During the transition, it makes sense to require both classical and post-quantum signatures. We don't know yet which PQ schemes will survive long-term scrutiny, so requiring two independent schemes means you're only vulnerable if both are broken simultaneously. A ComposedVerifier combines any two adapters and requires both to pass. Any PQ scheme can be paired with ECDSA for extra security.
Account Lifecycle
This is where I think the design gets most interesting. The wallet isn't just "use PQ keys instead of ECDSA." It's a progression. Your account can evolve its security model over time without changing its address or moving funds. Once quantum computers can actually break elliptic curves, post-quantum cryptography needs to be at the protocol layer. No application-level solution can fully protect accounts at that point. But protocol-level changes take years, and L2s will likely move on their own timeline. This wallet covers the gap: it lets accounts start preparing now, on any chain, without waiting for L1 consensus on a PQ standard.
Creation
Account deployment and PQ setup are intentionally separate. KernelFactory deploys the account with just an ECDSA owner. The address depends only on the owner and a salt, nothing PQ-related. This keeps address derivation simple and stable: the address can be shared before choosing a PQ scheme, stays the same across chains (via CREATE2), and doesn't change if PQ keys are rotated later. PQ key registration still needs to happen separately on each chain, but the account address is deterministic everywhere.
Becoming Quantum-Ready
A separate transaction registers the PQ public key and enables the scheme. After this the account is quantum-ready: ECDSA still works for everyday signing, but the PQ keys are on-chain and approved. There's no urgency here. The user can keep signing with ECDSA as long as it's secure.
The user can also choose a hybrid scheme instead, which is just another signing scheme available in the router. A hybrid scheme requires both ECDSA and PQ signatures for every transaction, giving extra protection during the transition period.
Disabling ECDSA
When the quantum threat becomes real, the user calls disableECDSA on the validator. This is one atomic action that disables ECDSA and ensures a PQ scheme is active. The atomic switch prevents a dangerous window where neither scheme is active. From that point, all transactions require the PQ signature. The ECDSA key can no longer authorize transactions. Even if a quantum computer cracks it, there's nothing it can do.
Adding New Schemes Later
The PQSignatureRouter is a separate contract with a registry of scheme IDs to adapters. A registry operator, in practice a multisig or a DAO, can register new adapters when better PQ algorithms or verifiers become available. Crucially, the operator can also disable a scheme if it's found to be broken or insecure, acting as a safety mechanism for all accounts using the router.
Existing accounts can opt into new schemes by registering a key and updating their allowlist. No contract upgrades or migrations needed. This matters because the PQ landscape is still evolving. NIST only finalized their first standards recently. New schemes will come, and some current ones might be weakened. The architecture needs to handle that gracefully.
UX Considerations
Most of the architecture described above should be invisible to the user. A few things worth calling out:
Setup feels normal. The user gets a standard 24-word mnemonic. Behind the scenes, three keys are derived from it (ECDSA, ETHFALCON, and MLDSAETH) but the user never sees this. The account address is computed from the ECDSA key, same as any smart wallet.
Account deployment is lazy. The address exists (and can receive funds) before the account is deployed on-chain. The first transaction triggers deployment via the bundler. Standard ERC-4337 behavior.
Enabling PQ is one action. From the user's perspective, they tap "Enable quantum protection" and confirm a transaction. The SDK handles key registration and scheme activation behind the scenes.
Signing is the same UX regardless of scheme. Whether the account uses ECDSA, ETHFALCON, or both, the user just confirms a transaction. The SDK handles key selection and signature encoding behind the scenes.
The ECDSA key is never deleted. Even after upgrading to PQ-only, the ECDSA private key stays in the keystore. It's needed for address derivation. Its role changes from "signing key" to "address derivation input," but it's always recoverable from the mnemonic.
The real cost is gas. PQ verification is ~15x more expensive than ECDSA on-chain. On L1 this is significant. On L2s like Arbitrum or Base it's negligible, and that's where most users will be. The keys are larger, the verification needs more compute. That's the cost of post-quantum security until native chain-level solutions are in place.
What's Next
I'm working on an open-source repository that implements everything described here: the contracts, a TypeScript SDK for account creation and signing, and a CLI wallet to make these concepts actionable. Follow my GitHub for updates.