Migration Playbook: Smart Contract Platforms
How Ethereum, Solana, and EVM-compatible chains can upgrade signature verification without breaking DeFi. Account abstraction provides a path forward—but gas costs and ecosystem coordination remain critical challenges.
The Smart Contract Challenge
Smart contract platforms face unique PQC migration challenges beyond base-layer upgrades. Signature verification happens both at the protocol level and inside smart contracts. DeFi protocols, NFT marketplaces, and DAOs all rely on signature validation—each requiring updates when PQC arrives.
Why Smart Contracts Are Different
Layer-1 blockchains verify signatures at the protocol level—a single upgrade can change how all transactions are validated. Smart contract platforms add a second layer of complexity: application-level signature verification.
| Verification Layer | Who Controls It | Upgrade Path |
|---|---|---|
| Protocol-Level | Core developers, validators | Hard fork or soft fork (network-wide) |
| Smart Contract | Contract deployers, DAOs | Contract upgrade or migration (per-application) |
| Wallet/User | Individual users | Account abstraction (ERC-4337, EIP-7702) |
Key insight: Even if Ethereum upgrades to support PQC signatures at the protocol level, every DeFi protocol, NFT marketplace, and DAO that verifies signatures in their contracts will need separate updates.
How Smart Contracts Verify Signatures Today
Smart contracts use signatures for authorization beyond basic transactions. Understanding where signatures are verified reveals the scope of migration work:
| Use Case | Verification Method | Gas Cost (ECDSA) |
|---|---|---|
| Transaction authorization | ECRECOVER precompile | 3,000 gas |
| ERC-20 permit (gasless approvals) | ECRECOVER in contract | ~5,000 gas |
| Multi-sig wallets | Multiple ECRECOVER calls | 3,000 × n signers |
| NFT marketplace listings | Off-chain signatures verified on-chain | ~5,000 gas |
| DAO voting | Snapshot + on-chain execution | Varies by implementation |
| Meta-transactions | Relayer verifies user signature | ~5,000 gas |
The Gas Cost Problem
Post-quantum signature verification is orders of magnitude more expensive than ECDSA. Before ZKnox optimizations, FALCON verification cost 24 million gas—compared to 3,000 gas for ECRECOVER. Even with 12× optimization, PQC signatures remain ~700× more expensive than ECDSA.
PQC Gas Costs: The Current State
Thanks to work by ZKnox (funded by Ethereum Foundation, March 2025), on-chain PQC verification is now feasible for experimentation—but costs remain high:
| Algorithm | Gas Cost | vs ECRECOVER | Status |
|---|---|---|---|
| ECRECOVER (ECDSA) | 3,000 gas | 1× (baseline) | Native precompile |
| secp256r1 (P-256) | 6,900 gas | 2.3× | EIP-7951 (draft) |
| FALCON (optimized) | ~2,000,000 gas | ~667× | ZKnox Solidity (experimental) |
| ML-DSA/Dilithium | ~8,000,000 gas | ~2,667× | ZKnox Solidity (experimental) |
| FALCON (unoptimized) | 24,000,000 gas | 8,000× | Previous implementations |
ZKnox Breakthrough (March 2025)
ZKnox achieved a 12× reduction in FALCON verification costs by implementing Number Theoretic Transform (NTT) in Yul, Ethereum’s low-level language. They’ve proposed EIP-7885 to add NTT as a precompile, which would further reduce costs and enable multiple PQC schemes.
Bottom line: PQC signatures are currently too expensive for most DeFi operations on L1. Layer-2 solutions with lower gas costs may be the first practical deployment path.
Proposed Precompiles for PQC
Native precompiles would dramatically reduce PQC gas costs. Several proposals are in development:
| Proposal | Algorithm | Purpose | Status |
|---|---|---|---|
| EIP-7885 | NTT (Number Theoretic Transform) | Accelerate lattice-based operations | Draft |
| EIP-8051 | ML-DSA (Dilithium) | NIST FIPS 204 signature verification | Draft |
| EIP-8052 | FALCON | Compact lattice-based signatures | Draft |
| EIP-7592 | FALCON | Earlier FALCON precompile proposal | Draft |
FALCON vs Dilithium Trade-offs
FALCON: Smaller signatures (1,281 bytes), faster on-chain verification, but complex signer implementation. Preferred for Ethereum on-chain use.
ML-DSA/Dilithium: 4× larger footprint, slower verification, but easier to implement in hardware wallets. Preferred for secure element integration.
Why Precompiles Matter
Precompiles execute at the protocol level, bypassing EVM interpretation overhead. A native FALCON precompile could reduce verification from 2M gas to ~50,000–100,000 gas—making PQC practical for DeFi.
Challenge: Precompiles require hard forks, adding years to deployment timelines.
Account Abstraction: The Migration Path
Account abstraction (ERC-4337, EIP-7702) provides an immediate path to PQC without protocol-level changes. Smart contract wallets can define custom signature validation logic—including post-quantum schemes.
Why Account Abstraction Matters for PQC
- No hard fork required: Users can adopt PQC signatures today
- Opt-in migration: Individual wallets upgrade independently
- Hybrid support: Combine ECDSA + PQC for transition period
- Experimentation: Test PQC in production without network-wide risk
| Standard | What It Enables | Status |
|---|---|---|
| ERC-4337 | Smart contract wallets with custom signature validation | Deployed (mainnet) |
| EIP-7702 | EOAs can delegate to smart contract code | Pectra upgrade (2025) |
| EIP-1271 | Standard interface for contract signature verification | Deployed (widely adopted) |
Lessons from Ethereum
What worked: ERC-4337 allows developers to deploy PQC wallets as smart contracts today—no hard fork needed. ZKnox is already building hybrid (ECDSA + FALCON) wallets.
What didn’t: Multiple competing EIPs (7932, 7693, etc.) fragmented progress. No single approach has achieved consensus yet.
ZKnox PQKINGS Project
Hybrid protection: Uses EIP-7702 to combine FALCON and ECDSA signatures. Assets protected by both—quantum attack requires breaking both schemes.
Status: Experimental. Gas costs make it impractical for frequent transactions, but suitable for high-value vaults.
DeFi Protocol Implications
DeFi protocols using on-chain signature verification will need updates. The complexity varies by protocol type:
| Protocol Type | Signature Usage | Migration Complexity |
|---|---|---|
| DEXs (Uniswap, etc.) | Minimal—mostly on-chain swaps | Low (if no permit() usage) |
| Lending (Aave, Compound) | Permit signatures, governance | Medium |
| NFT Marketplaces | Heavy off-chain signature usage | High |
| Multi-sig Wallets | Multiple signatures per transaction | High (gas multiplied by signers) |
| Bridges | Validator signatures for cross-chain | Critical (security bottleneck) |
| Oracles | Data provider signatures | Medium to High |
The Permit Function Problem
ERC-20 permit (EIP-2612) enables gasless token approvals via signatures. Millions of tokens support permit()—each contract would need updates to support PQC signatures. Alternatively, users would need to revoke permit-based approvals and use traditional approve() calls.
Migration Strategy for Smart Contract Platforms
A phased approach balancing security, cost, and ecosystem coordination:
Phase 1: Account Abstraction Adoption (Now–2026)
- Deploy ERC-4337 smart contract wallets with PQC signature support
- Use hybrid signatures (ECDSA + FALCON) for high-value accounts
- Test on Layer-2 networks where gas costs are lower
- Build user migration tooling and education
Phase 2: Precompile Integration (2026–2028)
- Advocate for EIP-7885 (NTT precompile) inclusion in Ethereum roadmap
- Support EIP-8051/8052 for native ML-DSA and FALCON verification
- Deploy precompiles on testnets; audit and benchmark
- Coordinate with Layer-2 rollups for early adoption
Phase 3: DeFi Protocol Updates (2027–2030)
- Update signature verification in major DeFi protocols
- Support both ECDSA and PQC signatures during transition
- Migrate oracle and bridge validator keys to PQC
- Deprecate ECDSA-only paths as Q-Day approaches
Layer-2 First Strategy
PQC deployment will likely happen on Layer-2 networks before Ethereum mainnet. Lower gas costs make PQC signatures practical, and L2s can upgrade faster than L1. Arbitrum, Optimism, and zkSync are natural testing grounds.
Special Considerations
ZK-Rollups Face Extra Challenges
Current ZK proof systems (SNARKs, STARKs) use elliptic curve math vulnerable to quantum attacks. ZK-rollups need post-quantum proof systems—an active research area with no production solutions yet. STARKs are more quantum-resistant than SNARKs but still require hash function upgrades.
BLS Signatures in Consensus
Ethereum aggregates ~100,000+ BLS signatures per slot for validator attestations. BLS is quantum-vulnerable. Replacing consensus-layer BLS with PQC signatures is a massive undertaking beyond smart contract scope—see the Layer-1 Playbook.
Action Checklist for Smart Contract Developers
Steps to prepare your protocol for post-quantum migration:
- ☐ Inventory signature usage: Identify all places your contracts verify signatures
- ☐ Assess upgrade paths: Can your contracts be upgraded? Via proxy? DAO vote?
- ☐ Support EIP-1271: Enable smart contract wallets to authenticate with your protocol
- ☐ Abstract signature verification: Design for algorithm flexibility (not hardcoded ECDSA)
- ☐ Monitor gas costs: Track ZKnox and precompile progress for practical PQC deployment
- ☐ Test on Layer-2: Experiment with PQC signatures where gas costs are lower
- ☐ Plan permit() migration: Prepare for gasless approval alternatives
- ☐ Coordinate with ecosystem: Wallets, indexers, and frontends need aligned updates
Additional Resources
Technical References
ZKnox GitHub – FALCON & Dilithium implementations
ERC-4337 – Account Abstraction specification
EIP-1271 – Contract signature verification standard
Track Smart Contract Platform Readiness
See how Ethereum, Solana, and other smart contract platforms score on quantum resistance.
Last updated: December 4, 2025 | For protocol teams: Contact us for migration guidance