PQBeat — Post-Quantum Readiness Tracker

Tracking the post-quantum cryptography readiness of the Ethereum ecosystem.

Overview

PQBeat evaluates the post-quantum preparedness of L1/L2 chains, wallets, and protocols.

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.

PQBeat exists to track this long migration and make progress visible.

Stages for L1/L2 Chains

Stage	Criteria	Technical Requirements
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/XMSS/...)
Stage 3	Migration path operational	ZK-recovery + freeze mechanism
Stage 4	Post-Quantum Consensus Layer	Previous stages + BLS replaced by aggregatable PQ signatures

Stage Progression

Stage 0 → 1 : Deploy PQ signature verifier as smart contract (expensive but functional)
Stage 1 → 2 : Precompiles (EIP-8051/8052) + EIP-7701 implementation
Stage 2 → 3 : ZK-recovery circuits + governance-enabled freeze mechanism
Stage 3 → 4 : Consensus layer migration (BLS12-381 → PQ aggregatable signatures via STARK/WHIR)

Stages for Wallets

Wallets inherit the stage of the highest-stage chain they support with PQ smart accounts.

Stage	Criteria
Stage 0	No PQ support
Stage 1	PQ smart account supported on a Stage 1 chain
Stage 2	PQ smart account on Stage 2 chain + BIP32/39 compliant PQ key derivation (per ZKNOX ERC)
Stage 3+	Inherits chain stage + ZK-recovery witness generation

A wallet reaches Stage N when it can:

Create/manage PQ smart accounts
Sign transactions using PQ signatures
On a chain that has reached Stage N
(Stage 2+) Derive PQ keys from BIP39 seed using standardized derivation path

Reminder: a wallet's stage cannot exceed the stage of the chain it operates on.

Stages for Protocols

Protocols have their own progression based on smart wallet compatibility and governance security.

Stage	Criteria
Stage 0	No smart wallet support (EOA-gated via `tx.origin` checks, or ECDSA-only signers)
Stage 1	Accepts transactions from ERC-4337 / EIP-7702 wallets
Stage 2	Governance uses PQ accounts (or protocol is immutable)

Stage 1 Requirements

A protocol reaches Stage 1 when:

No require(tx.origin == msg.sender) checks blocking smart contract wallets
No isContract() restrictions on core functions
Supports ERC-1271 for signature verification (if signatures required)
Smart contract wallets (4337/7702) can interact without friction

Stage 2 Requirements

A protocol reaches Stage 2 when:

Governance multisig/DAO uses PQ-secured accounts, OR
Protocol is fully immutable (no admin keys, no upgradability)

Reminder: a protocol's stage cannot exceed the stage of the chain it is deployed on.

Current Status

L1/L2 Chains

Chain	Stage	Precompiles	EIP-7701	ZK-Recovery	PQ Consensus	Notes
Ethereum	0 → 1	❌	❌	❌	❌	ZKNOX contracts pending deployment
Arbitrum	0 → 1	❌	❌	❌	N/A	Inherits L1 contracts
Base	0 → 1	❌	❌	❌	N/A	Inherits L1 contracts
Optimism	0 → 1	❌	❌	❌	N/A	Inherits L1 contracts
Starknet	0	❌	❌	❌	N/A	STARK-native, no PQ sig verifier

Wallets

Wallet	Stage	PQ Smart Account	BIP39 PQ Derivation	Chains	Type
ZKNOX Kohaku	1	✅ Dilithium/Falcon	✅	Ethereum	Software
ZKNOX Kohaku HW	1	✅ Dilithium/Falcon	✅	Ethereum	Hardware
Ledger	0	❌	❌	-	Hardware
Trezor	0	❌	❌	-	Hardware
MetaMask	0	❌	❌	-	Software
Safe	0	❌	❌	-	Software
Rabby	0	❌	❌	-	Software

Protocols

Protocol	Stage	4337/7702 Support	Governance PQ	Notes
Uniswap V3 Core	2	✅ Permissionless	N/A (immutable)	No admin keys
Uniswap V3 Router	1	✅ Permissionless	❌ ECDSA	Upgradeable
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
Safe Multisig	0	⚠️ ERC-1271 signers	❌ ECDSA signers	Signers must be ECDSA
ENS	1	✅ Permissionless	❌ ECDSA DAO

Protocol Compatibility Analysis

Most major DeFi protocols are permissionless and accept any msg.sender, making them compatible with ERC-4337/EIP-7702 smart wallets by default. The main blockers are:

EOA-Only Patterns (Stage 0 blockers)

// These patterns block smart contract wallets:
require(tx.origin == msg.sender, "No contracts");
require(!isContract(msg.sender), "EOA only");

Early DeFi protocols sometimes used these patterns as anti-bot measures. With EIP-7702, even tx.origin == msg.sender can be bypassed by EOAs delegating to smart contracts.

ERC-1271 Support (Stage 1 enabler)

Protocols requiring off-chain signatures (permits, order signing) need ERC-1271 support:

✅ Uniswap, Aave, OpenSea support ERC-1271
✅ Most modern protocols implement isValidSignature()

Governance Exposure (Stage 1 → 2 gap)

The critical gap: protocols accept PQ users but governance remains ECDSA-vulnerable:

Treasury multisigs use ECDSA keys
DAO voting relies on EOA signatures
Upgrade mechanisms controlled by ECDSA multisigs

Risk: A quantum attacker could compromise protocol governance even if users are PQ-protected.

Evaluation Criteria

L1/L2 Chains

Criteria	Description
PQ Signature Verifier	Smart contract or precompile capable of verifying ML-DSA, Falcon, XMSS, or SPHINCS+
EIP-7701 Support	Native account abstraction with PQ signature support
Precompiles Deployed	EIP-8051 (ML-DSA) and/or EIP-8052 (Falcon) active
ZK-Recovery	Circuit deployed allowing seed-based account recovery post-freeze
Freeze Mechanism	Governance-activated freeze of legacy ECDSA EOAs
PQ Consensus	Validator signatures use post-quantum scheme

Wallets

Criteria	Description
PQ Key Generation	Can derive PQ keypairs (ML-DSA, Falcon, etc.)
PQ Smart Account	Can deploy and manage PQ-secured smart accounts
PQ Signing	Can sign transactions with PQ signatures
BIP32/39 PQ Derivation	PQ keys derived from BIP39 seed phrase using standard PQ derivation path (Stage 2+ requirement, per upcoming ZKNOX ERC)
Recovery Witness	Can generate witness for ZK-recovery (Stage 3+)

Protocols

Criteria	Description
No EOA Gates	No `tx.origin == msg.sender` or `isContract()` restrictions
ERC-1271 Support	Accepts smart contract signatures where signatures required
Smart Wallet Tested	Confirmed working with 4337/7702 wallets
Governance PQ	Admin/governance keys are PQ-secured
Immutable	No upgrade mechanism (automatic Stage 2 for governance)

Risk Metrics

Metric	Source	Description
TVL at Risk	On-chain / Dune	Value locked in ECDSA-only accounts
EOA Exposure %	On-chain	Percentage of assets in legacy EOAs
Governance Exposure	On-chain	Treasury value controlled by ECDSA multisigs
Bridge Exposure	On-chain	Cross-chain value secured by ECDSA
Time to Migration	Estimate	Based on current stage and dependencies

Protocol Governance Exposure (Estimated)

Protocol	Governance TVL	Risk Level
Lido	~$15B+	🔴 Critical
Aave	~$10B+	🔴 Critical
MakerDAO	~$5B+	🔴 Critical
Uniswap (governance)	~$3B+	🔴 Critical
Compound	~$2B+	🟠 High

Note: These are governance-controlled assets, not total TVL. A quantum attacker compromising governance multisigs could potentially drain or manipulate these funds.

Methodology

Verification: All evaluations based on deployed, verifiable on-chain state
No Roadmaps: Announced plans without deployment = Stage 0
Conservative Rating: When in doubt, lower stage applies
Continuous Updates: Re-evaluated as deployments occur
Smart Wallet Testing: Protocols marked Stage 1 should be tested with actual 4337/7702 wallets

FAQ

Why is governance so important?

A protocol can accept PQ users while its governance remains vulnerable. If an attacker compromises the governance multisig, they can:

Upgrade contracts to steal funds
Modify protocol parameters maliciously
Drain treasury

What about immutable protocols?

Immutable protocols (no admin keys, no upgrade mechanism) automatically reach Stage 2 for governance — there's nothing to compromise. However, this also means they can't be upgraded to add PQ features.

How does EIP-7702 change things?

EIP-7702 allows EOAs to delegate to smart contract code, effectively giving them smart wallet capabilities. This:

Breaks tx.origin == msg.sender assumptions
Enables PQ signatures for existing EOA addresses
Provides a migration path without changing addresses

Why does BIP32/39 compliance matter for Stage 2 wallets?

Standard PQ key derivation from BIP39 seed phrases enables:

Interoperability: Users can recover PQ accounts across different wallet implementations
ZK-Recovery: The seed phrase becomes the witness for Stage 3 recovery mechanisms
No new secrets: Users keep their existing seed phrase, PQ keys are derived deterministically

ZKNOX is proposing an ERC to standardize PQ derivation paths, ensuring all compliant wallets derive identical PQ keys from the same seed.

Name		Name	Last commit message	Last commit date
Latest commit History 10 Commits
pqbeat-site		pqbeat-site
readme.md		readme.md

ZKNoxHQ/PQbeat

Folders and files

Latest commit

History

Repository files navigation

PQBeat — Post-Quantum Readiness Tracker

Overview

PQBeat exists to track this long migration and make progress visible.

Stages for L1/L2 Chains

Stage Progression

Stages for Wallets

Stages for Protocols

Stage 1 Requirements

Stage 2 Requirements

Current Status

L1/L2 Chains

Wallets

Protocols

Protocol Compatibility Analysis

EOA-Only Patterns (Stage 0 blockers)

ERC-1271 Support (Stage 1 enabler)

Governance Exposure (Stage 1 → 2 gap)

Evaluation Criteria

L1/L2 Chains

Wallets

Protocols

Risk Metrics

Protocol Governance Exposure (Estimated)

Methodology

FAQ

Why is governance so important?

What about immutable protocols?

How does EIP-7702 change things?

Why does BIP32/39 compliance matter for Stage 2 wallets?

Resources

About

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

Packages