Introducing PQbeat: A Post-Quantum Readiness Tracker for Ethereum
2026 Jan 05
See all posts
Introducing PQbeat: A Post-Quantum Readiness Tracker for Ethereum
The quantum threat to blockchain cryptography is no longer a theoretical exercise. With NIST finalizing post-quantum standards in 2024 and major technology companies announcing quantum computing milestones, the question has shifted from “if” to “when.” For the Ethereum ecosystem — securing hundreds of billions in value through ECDSA signatures — this transition requires coordination, transparency, and measurable progress. Today we introduce PQbeat, a public tracker that evaluates the post-quantum preparedness of L1/L2 chains, wallets, and protocols across the Ethereum ecosystem.
The Problem: No Visibility Into Readiness
The Ethereum community has no standardized way to assess post-quantum preparedness. Roadmaps are published, research papers are written, but there is no objective measurement of what has actually been deployed and tested in production.
This creates multiple risks. Users cannot evaluate whether their assets are protected. Developers cannot identify which infrastructure components are ready for integration. And the ecosystem cannot coordinate an orderly transition because there is no shared understanding of current capabilities.
PQbeat addresses this gap by tracking only deployed capabilities — not announcements, not roadmaps, not promises.
Methodology: Stages of Readiness
PQbeat evaluates entities across five stages (0-4) based on verifiable, deployed functionality. The staging system differs by entity type.
L1/L2 Chains
| Stage 0 |
No PQ capability deployed |
ECDSA only |
| Stage 1 |
PQ accounts usable in production |
ERC-4337 / EIP-7702 + PQ signature verification via smart contract |
| Stage 2 |
Native PQ accounts in production |
EIP-7701 + precompiles (ML-DSA, Falcon, or equivalent) |
| Stage 3 |
Migration path operational |
ZK-recovery mechanism + governance-enabled freeze |
| Stage 4 |
Post-Quantum Consensus Layer |
BLS12-381 replaced by aggregatable PQ signatures |
The progression is intentionally strict. A chain reaches Stage 1 only when users can create and operate post-quantum smart accounts in production — not on testnets, not in audits, but deployed and functional.
The consensus layer is the easy part. When the time comes, a coordinated hard fork will migrate all validators at once — a single, synchronized upgrade.
The execution layer is the real challenge. There is no hard fork for user accounts, smart contracts, or protocol governance. Each wallet must adopt PQ signatures. Each protocol must accept smart accounts. Each user must migrate their assets. This fragmented landscape — millions of independent actors with no forced upgrade path — will take years of advocacy, tooling, and incremental adoption.
Stage Progression
Stage 0 → 1 : Deploy PQ signature verifier as smart contract (high gas cost, but functional)
Stage 1 → 2 : Implement precompiles (EIP-8051/8052) + EIP-7701 native account abstraction
Stage 2 → 3 : Deploy ZK-recovery circuits + governance-enabled freeze mechanism
Stage 3 → 4 : Migrate consensus layer (BLS12-381 → aggregatable PQ signatures via STARK/WHIR)
Each transition represents a significant engineering effort. Stage 1 can be achieved relatively quickly with existing infrastructure. Stage 4 requires fundamental changes to the consensus mechanism.
Wallets
Wallets inherit the stage of the highest-stage chain they support with full PQ smart account functionality.
| Stage 0 |
No PQ support |
| Stage N |
PQ smart account supported on a Stage N chain |
A wallet reaches Stage N when it can: 1. Create and manage PQ smart accounts 2. Sign transactions using post-quantum signature schemes 3. Operate on a chain that has achieved Stage N
This inheritance model reflects reality: a wallet’s PQ capabilities are limited by the chains it supports.
Protocols
Protocols follow a simplified staging based on smart wallet compatibility and governance security.
| Stage 0 |
No PQ support — EOA-gated or ECDSA multisig only |
| Stage 1 |
Accepts ERC-4337 / EIP-7702 smart accounts as signers |
| Stage 2 |
Stage 1 + governance secured by PQ signatures |
A protocol that uses ERC-1271 for signature validation and accepts arbitrary smart contract accounts (without tx.origin == msg.sender checks) can reach Stage 1 on any Stage 1+ chain. Stage 2 requires that the protocol’s own governance — typically a multisig or DAO — also uses post-quantum signatures.
Immutable protocols present an interesting case: if the contract logic is frozen but accepts smart accounts, it achieves Stage 1 permanently. The governance component of Stage 2 is marked as not applicable.
What PQbeat Tracks
Chains
For each L1 and L2, PQbeat evaluates:
- PQ Signature Verifier: Is there a deployed contract or precompile that can verify ML-DSA, Falcon, or other NIST-approved PQ signatures?
- Account Abstraction Support: Is ERC-4337, EIP-7702, or EIP-7701 available in production?
- Precompile Status: Are gas-efficient precompiles for PQ verification deployed or in active development?
- Recovery Infrastructure: Is a ZK-recovery mechanism deployed that would allow emergency migration?
- Consensus PQ Readiness: What is the status of replacing BLS signatures in the consensus layer?
Wallets
For hardware and software wallets:
- PQ Algorithm Support: Which post-quantum signature schemes are implemented?
- Smart Account Compatibility: Can the wallet create and manage ERC-4337/7702 accounts?
- Chain Coverage: On which Stage 1+ chains does the wallet operate?
- Key Derivation: Does the wallet support PQ-compatible derivation paths while preserving seed phrase compatibility?
Protocols
For DeFi protocols and applications:
- Smart Account Acceptance: Can users interact via ERC-4337 accounts?
- ERC-1271 Support: Does the protocol properly validate smart contract signatures?
- Governance Security: Is the protocol’s governance mechanism PQ-secured?
- TVL Exposure: What value is at risk if the protocol remains at Stage 0?
Tracked Entities
PQbeat tracks three categories of entities across the Ethereum ecosystem.
L1/L2 Chains
| Ethereum |
0 → 1 |
❌ |
❌ |
❌ |
ZKNOX contracts pending deployment |
| Arbitrum |
0 → 1 |
❌ |
❌ |
❌ |
Inherits L1 contracts |
| Base |
0 → 1 |
❌ |
❌ |
❌ |
Inherits L1 contracts |
| Optimism |
0 → 1 |
❌ |
❌ |
❌ |
Inherits L1 contracts |
| Starknet |
0 |
❌ |
❌ |
❌ |
STARK-native, no PQ sig verifier deployed |
Ethereum L1 will transition to Stage 1 once post-quantum signature verification contracts are deployed in production. L2s that inherit L1 contract availability (Arbitrum, Base, Optimism) will transition simultaneously.
Wallets
| ZKNOX Kohaku |
1 |
ML-DSA, Falcon |
Software |
ERC-4337 smart accounts |
| Ledger |
0 |
❌ |
Hardware |
No PQ support |
| Trezor |
0 |
❌ |
Hardware |
No PQ support |
| MetaMask |
0 |
❌ |
Software |
No PQ support |
| Safe |
0 |
❌ |
Software |
ECDSA signers only |
| Rabby |
0 |
❌ |
Software |
No PQ support |
Hardware wallets represent a critical dependency. Until vendors like Ledger and Trezor implement PQ signature generation, users must choose between hardware security and post-quantum protection.
Protocols
| Uniswap V3 Core |
2 |
✅ Permissionless |
N/A (immutable) |
No admin keys |
| Uniswap Governance |
1 |
✅ |
❌ ECDSA DAO |
UNI token voting |
| Aave V3 |
1 |
✅ Permissionless + ERC-1271 |
❌ ECDSA multisig |
|
| Compound V3 |
1 |
✅ Permissionless |
❌ ECDSA multisig |
|
| MakerDAO |
1 |
✅ Permissionless |
❌ ECDSA multisig |
|
| Lido |
1 |
✅ Permissionless |
❌ ECDSA multisig |
Large TVL exposure |
| CoW Protocol |
1 |
✅ ERC-1271 |
❌ ECDSA |
Intent-based, smart wallet compatible |
| 1inch Fusion |
1 |
✅ ERC-1271 |
❌ ECDSA |
Order signing via smart wallets |
| UniswapX |
1 |
✅ ERC-1271 |
❌ ECDSA |
Dutch auction with smart wallet support |
| Safe Multisig |
0 |
⚠️ ERC-1271 signers |
❌ ECDSA signers |
Signers must use ECDSA |
| ENS |
1 |
✅ Permissionless |
❌ ECDSA DAO |
|
Most major DeFi protocols are permissionless and accept any msg.sender, making them compatible with ERC-4337/EIP-7702 smart wallets by default. The primary vulnerability lies in governance mechanisms, which remain secured by ECDSA multisigs or DAOs.
Immutable protocols (like Uniswap V3 Core) achieve Stage 2 automatically — there is no governance to compromise.
Roadmap: Current Initiatives
Ethereum Protocol Efforts
| EIP-8051 |
Draft |
Precompile for ML-DSA (FIPS-204) signature verification |
| EIP-8052 |
Draft |
Precompile for Falcon signature verification |
| EIP-7701 |
Draft |
Native account abstraction for efficient smart accounts |
| PQ Consensus Layer |
Research |
Replacing BLS12-381 with aggregatable PQ signatures |
| ZK Recovery Mechanism |
Research |
Circuits for seed-based account recovery post-freeze |
Stage Progression Dependencies
Stage 0 → 1 : Deploy PQ signature verifier (smart contract)
└─ ZKNOX: Dilithium/Falcon verifiers ready for deployment
Stage 1 → 2 : EIP-8051/8052 precompiles + EIP-7701 implementation
└─ Reduces verification cost from ~5M gas to ~50k gas
Stage 2 → 3 : ZK-recovery circuits + governance freeze mechanism
└─ Requires ecosystem coordination for emergency procedures
Stage 3 → 4 : Consensus layer migration
└─ BLS12-381 → PQ aggregatable signatures (STARK/WHIR)
└─ ~1GB per epoch without aggregation; requires ZK compression
Identified PQ Projects
| ZKNOX |
Smart accounts, signature verifiers, EIPs |
Active development |
| Ethereum Foundation PQ Research |
Protocol-level migration planning |
Active research |
| NIST PQC Standards |
ML-DSA (FIPS-204), Falcon, SPHINCS+ |
Finalized (2024) |
| Tetration Lab |
Emergency hard fork mechanisms |
Research |
Current State Summary
As of December 2025, the Ethereum ecosystem is predominantly at Stage 0. Most chains have no deployed PQ verification capability. Most wallets cannot sign with post-quantum algorithms. Most protocol governance relies entirely on ECDSA.
This is expected. The transition is early. But it underscores the importance of tracking progress systematically.
The path to Stage 1 is imminent — ZKNOX contracts for ML-DSA and Falcon verification are pending deployment. Once live, any ERC-4337 or EIP-7702 wallet can create post-quantum secured accounts on Ethereum mainnet.
The path to Stage 2 depends on EIP-8051 and EIP-8052 precompile adoption, which would reduce signature verification costs by two orders of magnitude.
The path to Stage 3 and 4 requires significant protocol-level coordination that has not yet begun in earnest.
Why This Matters
The post-quantum transition is not a single event but a multi-year process. Assets secured by ECDSA today will remain vulnerable until they are migrated to PQ-secured accounts. The longer this takes, the greater the exposure window.
PQbeat provides three functions:
- Transparency: Users can evaluate the security posture of chains, wallets, and protocols they rely on
- Coordination: Developers can identify bottlenecks and prioritize integration work
- Accountability: The ecosystem can measure progress against stated goals
The tracker is designed to be objective and verifiable. Claims are evaluated against deployed code, not roadmaps.
Contributing
PQbeat is maintained by ZKNOX as a public resource. The data model is designed for community contribution:
- Chain, wallet, and protocol entries are stored as structured data
- Stage assessments follow documented criteria
- Pull requests with evidence of deployed capabilities are welcome
If your project has achieved a higher stage than currently listed, submit evidence of deployed functionality. If you identify errors in our assessments, open an issue.
Conclusion
The quantum threat to Ethereum is real but manageable — if the ecosystem transitions in an orderly manner. PQbeat exists to make that transition visible.
Stage 3 readiness — with ZK-recovery deployed and freeze mechanisms available — represents the minimum insurance policy against an accelerated quantum timeline. Even if we are fortunate enough to reach Stage 4 gracefully, having Stage 3 infrastructure ready is prudent risk management.
Track the ecosystem’s progress at pqbeat.zknox.com.
References
Reach Us
🔐 Practical security on the whole chain.
Github | Website | Twitter | Blog | Contact
Found a typo or want to improve this post? Our blog is open to PRs.
ZKNOX — Post-Quantum Cryptography for Ethereum
Introducing PQbeat: A Post-Quantum Readiness Tracker for Ethereum
2026 Jan 05 See all postsThe quantum threat to blockchain cryptography is no longer a theoretical exercise. With NIST finalizing post-quantum standards in 2024 and major technology companies announcing quantum computing milestones, the question has shifted from “if” to “when.” For the Ethereum ecosystem — securing hundreds of billions in value through ECDSA signatures — this transition requires coordination, transparency, and measurable progress. Today we introduce PQbeat, a public tracker that evaluates the post-quantum preparedness of L1/L2 chains, wallets, and protocols across the Ethereum ecosystem.
The Problem: No Visibility Into Readiness
The Ethereum community has no standardized way to assess post-quantum preparedness. Roadmaps are published, research papers are written, but there is no objective measurement of what has actually been deployed and tested in production.
This creates multiple risks. Users cannot evaluate whether their assets are protected. Developers cannot identify which infrastructure components are ready for integration. And the ecosystem cannot coordinate an orderly transition because there is no shared understanding of current capabilities.
PQbeat addresses this gap by tracking only deployed capabilities — not announcements, not roadmaps, not promises.
Methodology: Stages of Readiness
PQbeat evaluates entities across five stages (0-4) based on verifiable, deployed functionality. The staging system differs by entity type.
L1/L2 Chains
The progression is intentionally strict. A chain reaches Stage 1 only when users can create and operate post-quantum smart accounts in production — not on testnets, not in audits, but deployed and functional.
The consensus layer is the easy part. When the time comes, a coordinated hard fork will migrate all validators at once — a single, synchronized upgrade.
The execution layer is the real challenge. There is no hard fork for user accounts, smart contracts, or protocol governance. Each wallet must adopt PQ signatures. Each protocol must accept smart accounts. Each user must migrate their assets. This fragmented landscape — millions of independent actors with no forced upgrade path — will take years of advocacy, tooling, and incremental adoption.
Stage Progression
Each transition represents a significant engineering effort. Stage 1 can be achieved relatively quickly with existing infrastructure. Stage 4 requires fundamental changes to the consensus mechanism.
Wallets
Wallets inherit the stage of the highest-stage chain they support with full PQ smart account functionality.
A wallet reaches Stage N when it can: 1. Create and manage PQ smart accounts 2. Sign transactions using post-quantum signature schemes 3. Operate on a chain that has achieved Stage N
This inheritance model reflects reality: a wallet’s PQ capabilities are limited by the chains it supports.
Protocols
Protocols follow a simplified staging based on smart wallet compatibility and governance security.
A protocol that uses ERC-1271 for signature validation and accepts arbitrary smart contract accounts (without
tx.origin == msg.senderchecks) can reach Stage 1 on any Stage 1+ chain. Stage 2 requires that the protocol’s own governance — typically a multisig or DAO — also uses post-quantum signatures.Immutable protocols present an interesting case: if the contract logic is frozen but accepts smart accounts, it achieves Stage 1 permanently. The governance component of Stage 2 is marked as not applicable.
What PQbeat Tracks
Chains
For each L1 and L2, PQbeat evaluates:
Wallets
For hardware and software wallets:
Protocols
For DeFi protocols and applications:
Tracked Entities
PQbeat tracks three categories of entities across the Ethereum ecosystem.
L1/L2 Chains
Ethereum L1 will transition to Stage 1 once post-quantum signature verification contracts are deployed in production. L2s that inherit L1 contract availability (Arbitrum, Base, Optimism) will transition simultaneously.
Wallets
Hardware wallets represent a critical dependency. Until vendors like Ledger and Trezor implement PQ signature generation, users must choose between hardware security and post-quantum protection.
Protocols
Most major DeFi protocols are permissionless and accept any
msg.sender, making them compatible with ERC-4337/EIP-7702 smart wallets by default. The primary vulnerability lies in governance mechanisms, which remain secured by ECDSA multisigs or DAOs.Immutable protocols (like Uniswap V3 Core) achieve Stage 2 automatically — there is no governance to compromise.
Roadmap: Current Initiatives
Ethereum Protocol Efforts
Stage Progression Dependencies
Identified PQ Projects
Current State Summary
As of December 2025, the Ethereum ecosystem is predominantly at Stage 0. Most chains have no deployed PQ verification capability. Most wallets cannot sign with post-quantum algorithms. Most protocol governance relies entirely on ECDSA.
This is expected. The transition is early. But it underscores the importance of tracking progress systematically.
The path to Stage 1 is imminent — ZKNOX contracts for ML-DSA and Falcon verification are pending deployment. Once live, any ERC-4337 or EIP-7702 wallet can create post-quantum secured accounts on Ethereum mainnet.
The path to Stage 2 depends on EIP-8051 and EIP-8052 precompile adoption, which would reduce signature verification costs by two orders of magnitude.
The path to Stage 3 and 4 requires significant protocol-level coordination that has not yet begun in earnest.
Why This Matters
The post-quantum transition is not a single event but a multi-year process. Assets secured by ECDSA today will remain vulnerable until they are migrated to PQ-secured accounts. The longer this takes, the greater the exposure window.
PQbeat provides three functions:
The tracker is designed to be objective and verifiable. Claims are evaluated against deployed code, not roadmaps.
Contributing
PQbeat is maintained by ZKNOX as a public resource. The data model is designed for community contribution:
If your project has achieved a higher stage than currently listed, submit evidence of deployed functionality. If you identify errors in our assessments, open an issue.
Conclusion
The quantum threat to Ethereum is real but manageable — if the ecosystem transitions in an orderly manner. PQbeat exists to make that transition visible.
Stage 3 readiness — with ZK-recovery deployed and freeze mechanisms available — represents the minimum insurance policy against an accelerated quantum timeline. Even if we are fortunate enough to reach Stage 4 gracefully, having Stage 3 infrastructure ready is prudent risk management.
Track the ecosystem’s progress at pqbeat.zknox.com.
References
Reach Us
🔐 Practical security on the whole chain.
Github | Website | Twitter | Blog | Contact
Found a typo or want to improve this post? Our blog is open to PRs.
ZKNOX — Post-Quantum Cryptography for Ethereum