Security model
This page is deliberately honest about what PQWeave does and does not protect against. The contracts and the post-quantum verifier are custom code that has not had an independent audit. Do not secure real funds with it yet.
What it defends against
A quantum computer running Shor's algorithm can derive an ECDSA private key from the public key it exposes. Every EVM account reveals its public key the moment it sends a transaction, so funds are harvestable today ("harvest now, decrypt later") and spendable once a sufficient quantum computer exists. PQWeave moves the authority for spending behind a post-quantum signature that such a computer cannot forge.
The cryptographic basis
The default verifier is hash-based — Lamport one-time signatures inside a Merkle tree, an XMSS-style construction. Its security rests only on the preimage and collision resistance of keccak256:
- →Shor's algorithm does not break hash functions.
- →Grover's algorithm only halves the security level, so keccak256 keeps roughly 128-bit strength against a quantum attacker.
- → No lattice or discrete-log assumption. The verifier is pluggable (IPQCVerifier), so NIST lattice schemes (Falcon, ML-DSA) can be swapped in.
Security tiers (choose per account)
| Mode | ECDSA | Post-quantum | Use for |
|---|---|---|---|
| Hybrid | Routine ops | Sensitive ops | Daily wallets — defense-in-depth |
| pqcOnly | Every op | Every op | High-value wallets |
| Sole authority | Never | Every op | Vaults — the only fully quantum-safe mode |
Sole authority is the only fully quantum-safe configuration: the ECDSA key is removed from the trust model entirely, so a quantum break of it grants nothing. The web migration flow defaults to this mode.
Residual risks — what is not solved
Not audited yet
A custom account plus a custom verifier is exactly where implementation bugs live. An independent audit is planned before mainnet — until then, testnets only. No amount of extra code substitutes for review.
"Harden in place" is transitional
Delegating an existing EOA (EIP-7702) keeps the original ECDSA key’s protocol-level authority. True safety requires migrating funds into a sole-authority account, not hardening the old address.
Hybrid mode is not absolute
Sub-threshold operations remain ECDSA-authorized. Use pqcOnly or sole authority for full post-quantum coverage.
Timeline is a projection
“Q-Day” estimates (2029–2030) are forecasts, not facts. The concrete present risk is exposed public keys being harvested today to be broken later.
What "ready for real funds" requires
- 1 One or more independent security audits, ideally with formal verification of the verifier.
- 2 A public bug bounty and time running in production with bounded value.
- 3 Standardization (an ERC) so the wider ecosystem reviews the design, on the path to native protocol-level post-quantum support.
Found a vulnerability? Email security@pqweave.com rather than opening a public issue. Or scan a wallet to see your own exposure.