ERC-21 post-quantum

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.

Partner Technologies:

• LayerZero: Cross-chain token transfers out of the box
• The 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 transactions
• Protocol - 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 tests
• MetaMask Snaps: Secure enclave for HD secret storage

Notable Hacks:

• Full STARK implementation in Solidity (most projects use trusted verifier contracts)
• Client-side proof generation in a MetaMask Snap
• Non-reverting failures for Graph compatibility - Graph indexing won't see failed attempts
• Commitment reduced to STARK field (2^251 + 17·2^192 + 1) for Cairo compatibility

Smart 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 challenges
• Merkle tree commitment verification
• OOD (out-of-domain) evaluation checks
• FRI 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 computation
• Low-degree extension (LDE)
• Merkle tree construction
• FRI protocol with proper folding
• Complete proof serialization matching the verifier format

The 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.