Future work

Priorities#

1. XMSS and message signing#

Problem. A WOTS key is consumed by its first signature, so the account cannot sign off-chain messages. dApp logins (Sign-In with Ethereum, ERC-4361), gasless approvals (Permit2) and intent-based trading (UniswapX) all depend on signed messages. Today the wallet refuses them, and the account rewrites its key hash on every transaction.

Design. Use XMSS, the stateful hash-based scheme standardised in RFC 8391 and approved by NIST in SP 800-208. Instead of one key at a time, the account commits to the Merkle root of many WOTS keys:

root ── a Merkle tree whose leaves are WOTS public keys (2^h of them)
signature = leaf index ‖ WOTS signature ‖ authentication path (h × 32 bytes)
verify    = recover the leaf from the WOTS signature, hash up the path, compare with the root

• Two layers (XMSS^MT). A single tree of a million leaves would take far too long to generate in a browser. A top tree of 2^10 subtree roots, each signing a subtree of 2^10 WOTS keys, gives about a million signatures while generating only about a thousand keys at a time, in a few seconds.
• Message signing. The account implements ERC-1271 isValidSignature, verifying an XMSS signature against the root, so any contract or dApp can check a message signature.
• Cheaper transactions. With a fixed root, a transaction no longer rewrites the key on-chain; it only advances a leaf counter. A subtree root can be certified once and cached, so later signatures in that subtree verify a single WOTS signature plus a short path.

Trade-offs. Signatures grow by the authentication path (about 320 bytes per layer), which costs extra calldata on L2s. XMSS is stateful like WOTS: a leaf must never sign twice. The key journal that protects WOTS keys today extends to leaves, and multi-device use needs an encrypted, shared journal (planned with this work).

Depends on: nothing external; it is contract and SDK work.

2. ERC-7579 validator module#

Problem. People already hold funds in smart accounts such as Safe. Asking them to move to a new wallet is the biggest barrier to adoption.

Design. ERC-7579 defines modular smart accounts. A validator module decides whether a UserOperation is authorised. We package the WOTS (and later XMSS) verifier as such a module:

• The module stores each account's current key hash and index, keyed by the account's address. ERC-4337's validation rules allow this storage access.
• Install it on any ERC-7579 account: Safe (through the Safe7579 adapter), Kernel, Nexus and others. The account keeps its address and its assets.
• The same SDK and key journal sign for it, so the web wallet and extension can manage a module-protected account.

Trade-offs. An account is only as quantum-safe as its weakest validator. While an ECDSA owner or validator remains installed, a quantum attacker can still use it. The module's setup flow therefore offers to remove the other validators, and the UI states plainly when it cannot.

Depends on: compatibility testing per account implementation.

3. Paymaster#

Problem. Every operation needs ETH for gas, and a WOTS operation uses about 2.4× the gas of an ECDSA one (benchmarks). A new user holding only USDC or Stock Tokens cannot transact at all.

Design. ERC-4337 lets a paymaster contract pay an operation's gas:

• ERC-20 paymaster. The account pays the fee in USDC (or USDG on Robinhood Chain) inside the same operation; the paymaster fronts the ETH. Prices come from an on-chain oracle, with a margin the user sees before signing.
• Sponsored operations. An app can cover its users' gas, for example the first transaction that deploys the account.
• The fee estimate already shown before every send extends to the token the user pays in.

Trade-offs. A paymaster authorises sponsorship with its own key, which is not quantum-safe. That key can at worst refuse or waste sponsorship; it can never move the user's funds, which only the user's WOTS signature authorises.

Depends on: a funded paymaster deployment and a price oracle per network.

4. Quantum readiness and migration#

Problem. Most Ethereum users hold funds in ordinary addresses (EOAs) protected by ECDSA. An address's public key becomes visible once it sends a transaction, and from then on a large quantum computer could derive its private key. Few users know whether they are exposed.

In March 2024 Vitalik Buterin proposed an emergency hard fork for exactly this case: disable EOA transactions, and let users prove with a STARK that they know the hash preimage their key was derived from (such as the seed), then move the account to smart-contract validation. Our work aims to make that transition smooth.

Design.

• Readiness check. Enter an address: the tool reports whether its public key is already exposed (it has sent transactions), what it holds, and what to do. It runs entirely in the browser against public RPCs, and stores nothing.
• Move to a quantum-safe account. One guided flow transfers assets from an exposed address to a Winternitz account. This is fully quantum-safe today.
• Keep the address (EIP-7702). EIP-7702, live on Ethereum since the Pectra upgrade, lets an address delegate to contract code. The address can adopt the Winternitz account logic and register a WOTS key, so it is ready to keep operating if the network later disables ECDSA, as in the proposal above.

Trade-offs. The check cannot see off-chain signatures (such as permits) that may also have revealed a key, and it says so. Under EIP-7702 the original ECDSA key still controls the address, so it is not quantum-safe until Ethereum retires ECDSA. The UI will be explicit: moving funds protects you now; keeping the address prepares you for later.

Depends on: EIP-7702 support on each target network; the second half of the migration depends on Ethereum's own decisions.

5. Independent audit#

Problem. The contracts, the key journal and the extension decide who controls funds. Our own tests (security model) are extensive but are not an independent review.

Plan.

• Scope: WOTS.sol, QuantumSafeAccount, the factory, the recovery path, the SDK signing and journal code, and the extension's key storage and message handling.
• Formal checks that the Solidity verifier matches the specification, in addition to the existing differential tests against the TypeScript implementation.
• Public report and a bug bounty before mainnet.

The account contract is deliberately not upgradeable, so no one can change the rules of an existing account. The flip side is that fixes after launch mean a new version at a new address. That is why the audit comes before mainnet, not after.

Watching the field#

Other post-quantum signatures are maturing. NIST published SLH-DSA (stateless hash-based, FIPS 205) and ML-DSA (lattice-based, FIPS 204) in 2024, and Falcon is being standardised as FN-DSA.

• SLH-DSA removes key state entirely, at the cost of larger signatures.
• Lattice schemes have much smaller signatures but are expensive to verify in the EVM without new precompiles, which researchers are discussing.

A modular validator (priority 2) lets an account adopt a new scheme without changing its address, so the wallet can follow the field as it settles.