IIP-64: Post-Quantum Cryptographic Migration for IoTeX

[xinxin-crypto]

Description
This pull request introduces a comprehensive Standards Track IoTeX Improvement Proposal specifying the end-to-end migration of IoTeX from quantum-vulnerable secp256k1/ECDSA cryptography to NIST-standardized post-quantum cryptographic (PQC) algorithms. The proposal is the product of an extensive cross-ecosystem analysis synthesizing primary sources spanning Ethereum, Bitcoin, Sui, QRL, Google Quantum AI, the Coinbase Independent Advisory Board, Meta, and Paradigm.

Motivation
Google Quantum AI's April 2026 whitepaper demonstrates that breaking ECDLP-256 now requires ~20× fewer physical qubits than previously estimated (<500,000 physical qubits, executable in minutes). IoTeX's secp256k1-based account model, 5-second block finality, 24-delegate Roll-DPoS consensus, and long-lived DePIN device identities (10–20 year lifetimes) create unique quantum-risk amplifications that demand a tailored migration strategy aligned with NIST's 2030 deprecation and 2035 disallowance mandates.

Files
iip-64.md — Full IIP specification

Review Guidance
Reviewers should pay particular attention to the gas cost calibration for the PQ precompile, the Phase 2 governance vote framework and iPACT cutoff date determination, the block-size throughput impact analysis and mitigation strategies, and the emergency track acceleration triggers and their threshold conditions. Community feedback on algorithm selection (ML-DSA-65 as primary vs. alternatives), roadmap timeline realism, and dormant-wallet policy preferences is especially welcome.

[ConWan30]

Reviewing this as a DePIN protocol building on IoTeX that expects to be a direct downstream consumer of the precompile and PQ Key Registry proposed here. QorTroller — a presence- and device-auth credential layer for competitive gaming, controller-bound — is architected on a SHA-256 commitment family for its credential primitive, the same hash-based construction §2.4 identifies as providing ≥128-bit post-quantum preimage security. Credential signing is designed as hybrid ECDSA + ML-DSA, tiered following §4.1 and §4.6 (ML-DSA-44 for user-equivalent paths, SLH-DSA-128s for device-identity), with a Groth16 → SP1/STARK ZK migration on our roadmap. Our broader protocol — 49 contracts plus a SHA-256 grind-integrity chain — is already live on IoTeX testnet. The structural fit with §4.6 (DePIN device-identity migration) and §4.8.5 (iPACT-DePIN), grounded in the §3.11 IoTeX-specific insights, is striking, and the architecture looks like a natural deployment target for Phase 0–1 of this roadmap.

Two questions where clarification would meaningfully help downstream protocols plan against the spec:
Application-layer credential carve-out. §4.6 addresses DePIN device-identity migration but frames device keys at the account-equivalent layer. For protocols that issue device-bound attestation credentials — verified hardware proofs, embodied-presence credentials, interactive challenge-response attestations — at the application layer, separately from account-level transaction signing: would the spec consider explicitly acknowledging that the PQ precompile (0x0B) and PQ Key Registry can be consumed for application-layer credential issuance independently of account-level enforcement timing? Concretely, a DePIN credential layer could be PQ-deployable on Phase 1's timeline (2027 Q3) without waiting for Phase 2's hybrid enforcement on user accounts.

iPACT-DePIN refinement. §4.8.5 is the cleanest fit for our use case but is sketched in a single paragraph relative to §4.8.1–4.8.4. It notes manufacturers should generate iPACTs "during firmware updates or during provisioning" — two clarifications would help downstream protocols build against it: (a) does that imply a refreshable cadence rather than one-time, and what are the replay/timestamp semantics across refreshes; and (b) how is iPACT-DePIN intended to interact with verified-hardware-proof renewal cadences for devices that periodically re-attest? We've been working through exactly this renewal model and would value coordinating on it.

Two small editorial notes on §4.1/§4.2: (1) the signature selection in §4.1 is nuanced and well-justified by the verify-cost analysis — ML-DSA-44 for user transactions, ML-DSA-65 reserved for consensus/admin keys; to the extent the surrounding discussion gets compressed to "ML-DSA-65 as primary," it may be worth keeping the per-tier framing front-and-centre so reviewers pressure-test the actual decision. (2) Minor inconsistency: §4.2's precompile input comment maps SLH-DSA-128s/128f to algorithm_id 0x04/0x05, while the §4.1 identifier table assigns them 0x10/0x11 — worth reconciling so implementers key off one canonical table.

Happy to engage further on any of these, and to share our device-credential and renewal design when it's useful.