ERC-21 post-quantum

Problem Statement

This project introduces Quantum-resistant ERC-20 Tokens (working title: ERC-21 / ERC-20pq) on today's networks. Fully ERC-20 compliant and built on LayerZero's OFT template for cross-chain use.The Problem: Quantum computers will break ECDSA signatures, letting attackers derive private keys and steal funds from any account.Our Solution: ZK-STARK proofs add a second layer of protection. Even if an attacker steals your private key, they cannot spend your tokens without proving knowledge of your HD secret—stored securely in a MetaMask Snap and never exposed on-chain.STARKs are hash-based (no elliptic curves) and require no trusted setup, making them highly quantum-resistant. The approach could be expanded to lattice-based systems that are quantum-proof to the best of our knowledge.Quantum Canary: Failed theft attempts emit on-chain events, providing real-time alerts when someone tries to steal these type of tokens. The Graph indexes these for monitoring. The canary symbolizing increased attempts in failed ZK proofs could provide evidence that we are post quantum.ERC-21/pq tokens are fully compatible with ERC-20 and can be sent to normal wallets and used in DeFi protocols, although when you do that they are no longer quantum-locked. Protocols will need upgrades to handle post-quantum protection.Your tokens survive the quantum apocalypse—even if it arrives tomorrow.

Solution

Partner Technologies:LayerZero: Cross-chain token transfers out of the boxThe Graph: AMP, running on digital ocean, base and eth, creating successful ZK transfers, and simulating stolen keys that create failed ZK proofs, we setup 2 systems, one using Graph real time indexing from tenderly shows all transaction information, and simulating high volume transactionsProtocol - Took the challenge to create Tools that make the internet harder to kill, censor, or compromise. We are in the frontier technology sector, quantum computers will probably be here sooner then we will be ready for. We are working to solve those problems. Other Technolgies used:Tenderly: Fork testing environment - deploy contracts, setup rpc end points for real time indexing testsMetaMask Snaps: Secure enclave for HD secret storageNotable Hacks:Full STARK implementation in Solidity (most projects use trusted verifier contracts)Client-side proof generation in a MetaMask SnapNon-reverting failures for Graph compatibility - Graph indexing won't see failed attemptsCommitment reduced to STARK field (2^251 + 17·2^192 + 1) for Cairo compatibilitySmart Contracts (Solidity 0.8.28 + Foundry)The core is ERC21PQToken.sol, extending LayerZero's OFT template for cross-chain transfers. We added a ZK Guard system: users bind an HD commitment (hash of their secret), then all transfers require STARK proofs.The StarkVerifier.sol is 540+ lines of hand-written STARK verification—implementing the full FRI (Fast Reed-Solomon IOP) protocol in Solidity:Fiat-Shamir transcript for non-interactive challengesMerkle tree commitment verificationOOD (out-of-domain) evaluation checksFRI layer folding and query verification STARKs are complex and we built a real verifier, not a placeholder.MetaMask Snap (TypeScript) The Snap stores the HD secret securely and generates STARK proofs client-side. We implemented 720+ lines of proof generation:Execution trace computationLow-degree extension (LDE)Merkle tree constructionFRI protocol with proper foldingComplete proof serialization matching the verifier formatThe secret never leaves the Snap—only commitments and proofs go on-chain.Frontend (React + Vite + Tailwind)Clean UI (fun hackathon non boring UI) for connecting wallets, enabling protection, and making ZK transfers. Shows real-time account status, guard state, and transaction results.The Graph (Vitalik's Canary) Subgraph indexes all events including ZKProofFailed—our Digital Canary. We made proof failures non-reverting (emit event + return false) so The Graph can index failed theft attempts. This was a key design decision since reverts don't persist events.We also built graphs amp to run and send transactions of both pass and fail, the sql amp server is up and sending / storing transactions but implementation ran short and actually getting it synced into our demo, is running though.Built during an intense overnight session—the STARK verifier alone took hours to get right!Although we did import our EthVaultPQ project as a subrepo so we could use it as a reference "library" this project uses very little if any of that project. It does not use zk-snark, nor account abstraction or vaults and it uses the SNAP for a different purpose. It was helpful to remind us how a snap works and avoid obvious pitfalls.