# 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:
1. Create/manage PQ smart accounts
2. Sign transactions using PQ signatures
3. On a chain that has reached Stage N
4. (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)

```solidity
// 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

1. **Verification**: All evaluations based on deployed, verifiable on-chain state
2. **No Roadmaps**: Announced plans without deployment = Stage 0
3. **Conservative Rating**: When in doubt, lower stage applies
4. **Continuous Updates**: Re-evaluated as deployments occur
5. **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.

---

## Resources

- [EIP-8051: ML-DSA Precompile](https://eips.ethereum.org/EIPS/eip-8051)
- [EIP-8052: Falcon Precompile](https://eips.ethereum.org/EIPS/eip-8052)
- [EIP-7701: Native Account Abstraction](https://eips.ethereum.org/EIPS/eip-7701)
- [ERC-4337: Account Abstraction](https://eips.ethereum.org/EIPS/eip-4337)
- [EIP-7702: EOA Code Delegation](https://eips.ethereum.org/EIPS/eip-7702)
- [ERC-1271: Standard Signature Validation](https://eips.ethereum.org/EIPS/eip-1271)
- [Vitalik: How to hard-fork to save most users](https://ethresear.ch/t/how-to-hard-fork-to-save-most-users/18901)

---