ZK-ACE protects the authorization step — proving you own a wallet and approving a transaction. In a normal Ethereum wallet, this is done by an ECDSA signature, which a quantum computer can forge by deriving your private key from your public key. ZK-ACE replaces that ECDSA signature with a STARK proof that uses only hash functions. A quantum computer cannot forge this proof.
Concretely: if a quantum computer exists tomorrow, an attacker could drain every MetaMask wallet that has ever sent a transaction (because the public key is exposed on-chain). They could NOT drain a ZK-ACE vault, because there is no public key to attack — only a hash commitment that reveals nothing useful to Shor's algorithm.
ZK-ACE does not protect against quantum threats at the protocol level. Specifically:
Think of it like a fireproof safe in a wooden house. The house might burn down (protocol-level quantum attack), but your safe is the last thing standing. More practically:
1. Your wallet authorization is quantum-proof today. Nobody can forge a transaction from your vault using a quantum computer. This is the most likely attack vector — stealing funds by forging signatures — and it's fully addressed.
2. Protocol-level attacks are much harder and less profitable. Breaking BLS consensus requires sustained quantum computation against a distributed system, not a one-shot theft. An attacker with early quantum capabilities would target the easiest, highest-value targets first: individual wallets with exposed public keys and large balances. ZK-ACE removes your wallet from that target list.
3. The protocol will catch up. Ethereum's PQ roadmap targets 2029 for consensus-layer quantum resistance. ZK-ACE provides wallet-level protection during the 3+ year gap. When the protocol upgrades, ZK-ACE vaults will be on a fully quantum-resistant stack end-to-end.
4. Account abstraction makes the transition seamless. When Ethereum adds PQ signature precompiles, ZK-ACE wallets can upgrade their verification backend without changing the user's address or moving any funds. The vault is future-proof by design.
It is the only wallet that verifies post-quantum proofs on-chain on a live EVM mainnet (Arbitrum One and Base) with confirmed transactions. One other project, Anchor Wallet by Pauli Group, uses Lamport signatures with ERC-4337, but falls back to ECDSA for daily transactions and has no verified mainnet deployment.
They can, and eventually will. The question is how long it takes:
ZK-ACE has a working deployment today. The head start is real but time-limited — hence the urgency.
There is no on-chain fee. The current monetization paths are:
On-chain verification of NIST PQ signatures (ML-DSA, Falcon) becomes cheap via native EVM opcodes. At that point, the Solidity STARK verifier becomes a more expensive alternative to precompile-based verification. However:
Total value secured by EVM wallets: hundreds of billions of dollars. The addressable market for quantum-resistant custody is primarily:
The quantum computing market itself is projected at $65B+ by 2030, with post-quantum cryptography migration as a major spending category.
Go to zkace-vault.vercel.app. Click "Create New Vault." Write down the 24-word recovery phrase. That's it. Your vault address is deterministic — it exists on Arbitrum and Base before you even deploy the contract.
Yes, it's a standard BIP-39 24-word mnemonic. The difference is what happens after: MetaMask derives an ECDSA private key (quantum-vulnerable). ZK-ACE derives a Goldilocks field element via PBKDF2-SHA512, then uses it inside a STARK proof (quantum-safe). Same user experience, different cryptography under the hood.
Your funds are permanently lost. There is no recovery mechanism, no customer support, no backdoor. This is the fundamental tradeoff of self-custody. The identity rotation feature lets you migrate to a new phrase while you still have access, but once you lose the phrase entirely, the vault is inaccessible.
About $0.20 on Arbitrum or Base. This is ~10-20x more than a normal ECDSA transaction ($0.01-0.02) because STARK verification is computationally intensive (~5.6M gas). The cost is the price of quantum resistance. As L2 fees continue to decrease with data availability improvements (EIP-4844 blobs), this cost will drop proportionally.
Yes. The vault is a standard ERC-4337 smart account. It can call any contract, hold any ERC-20 token, and interact with any DeFi protocol on the same chain. The vault's execute() function can encode any arbitrary call. The STARK proof authorizes the transaction; after that, the execution is identical to any other smart wallet.
The identity secret (REV) exists in browser memory only during your active session. It is zeroized (overwritten with zeros) when you log out or close the tab. The REV is never transmitted over the network — only the zero-knowledge proof leaves the browser, and the proof reveals nothing about the REV (that's what "zero-knowledge" means).
That said, browser environments are inherently less secure than hardware wallets. A malicious browser extension, compromised dependency, or memory dump could theoretically extract the REV during an active session. For maximum security, use a clean browser profile with no extensions, or wait for the Ledger hardware integration (planned).
ETH and any ERC-20 token on the vault's chain (Arbitrum or Base). The vault is a standard smart contract account — it can receive and hold any token. The vault app displays balances for ETH, USDC, USDT, WETH, ARB, DAI, and WBTC by default.
NIST PQ signatures are designed as drop-in replacements for ECDSA. But on EVM, they face two problems:
1. Gas cost. Verifying ML-DSA in Solidity costs ~500M+ gas (no native opcode exists). This is ~100x more expensive than STARK verification (~5.6M gas) because the lattice math doesn't map efficiently to EVM opcodes.
2. Calldata size. ML-DSA signatures are ~2,420 bytes. On L2 rollups where calldata is posted to L1, this is the dominant cost component. STARK proofs are larger (~44 KB) but the verification efficiency makes the total cost lower on L2.
When EVM-native PQ precompiles arrive (~2029), direct NIST signature verification becomes cheap and these tradeoffs change. Until then, STARKs are the most practical PQ verification option on EVM.
The paper's reference implementation uses Groth16 (BN254 SNARKs), which produces 128-byte proofs. Groth16 achieves this compactness via elliptic curve pairings — the same mathematical structure that Shor's algorithm breaks. We migrated from Groth16 to STARKs specifically to eliminate the quantum vulnerability. The tradeoff is larger proofs: 44 KB (STARK, quantum-safe) vs 128 bytes (Groth16, quantum-vulnerable). There is no known way to achieve Groth16-sized proofs without using quantum-vulnerable mathematics.
Rescue-Prime (Rp64_256) is an algebraically-friendly hash function designed for efficient proving inside STARK circuits. It operates natively over the Goldilocks field, meaning the identity commitment computation maps directly to the STARK's field arithmetic with no conversion overhead.
Keccak256 is used for the outer proof structure (Merkle trees, Fiat-Shamir challenges) because it matches the EVM's native KECCAK256 opcode (30 gas), making on-chain verification efficient. Using Keccak for the inner commitment would make the STARK circuit much larger.
Poseidon is another algebraically-friendly option. Starknet is migrating to Poseidon. A future version of ZK-ACE on Starknet might use Poseidon for better alignment with that ecosystem.
Yes. Rescue-Prime is a symmetric hash function — its security relies on the one-wayness of the permutation, not on any algebraic structure that quantum computers can exploit. Grover's algorithm provides a quadratic speedup against hash functions, reducing 256-bit security to 128-bit. Our full 4-element Rescue-Prime digest provides 256 bits classically and 128 bits post-quantum, meeting the standard security target.
128-bit post-quantum. This comes from multiple independent layers:
| Layer | Security |
|---|---|
| Rescue-Prime commitments (4 × 64-bit elements) | 128-bit PQ (Grover halves 256 to 128) |
| STARK soundness (44 queries, blowup 8) | 132-bit (not quantum-affected) |
| Proof-of-work grinding | 20 bits additional |
| Keccak256 Merkle trees | 128-bit PQ |
The bottleneck is 128-bit from the hash functions, which is the standard post-quantum security target accepted by NIST and the broader cryptographic community.
24-word BIP-39 mnemonic (256 bits of entropy)
→ PBKDF2-HMAC-SHA512 (salt = "ZK-ACE-REV-v1", 600,000 iterations)
→ 64 bytes of derived key material
→ First 8 bytes → REV (reduced modulo Goldilocks prime p)
→ Next 8 bytes → salt (reduced modulo p)
The REV is a single Goldilocks field element (64-bit value < p = 2^64 - 2^32 + 1). The 256-bit mnemonic entropy is reduced to a 64-bit field element because the STARK circuit operates over the Goldilocks field. Combined with the salt (also 64-bit), the search space for an attacker is 128 bits classically, 64 bits post-quantum (Grover). The Rescue-Prime commitment adds a further layer: even knowing the REV and salt, the attacker would need to forge a valid STARK proof, which requires breaking 132-bit soundness.
IDcom = Rescue-Prime(REV, salt, chainId). Including the chainId provides domain separation: a proof generated for Arbitrum (chainId 42161) cannot be used on Base (chainId 8453) because the identity commitment is different. This prevents cross-chain replay attacks. The same mnemonic produces different vault addresses on different chains, but the user experience is unified — one recovery phrase recovers all vaults.
Not yet by a professional third-party audit firm. The codebase has been through systematic internal security review across 6 iterations covering the STARK verifier, smart contracts, and cryptographic circuits. A professional audit is planned, with Arbitrum's $10M audit subsidy program as the intended funding path. The test suite includes 130 tests (43 Rust, 87 Solidity) with 0 failures, including end-to-end STARK proof verification on mainnet.
Winterfell 0.13, a Rust implementation of the STARK protocol by Facebook/Meta Research. The proof is generated in the browser via a WebAssembly (WASM) compilation of the Winterfell prover (484 KB). Winterfell is used in production by several projects and has been through extensive testing, though it is not as widely deployed as some alternatives (Plonky3, Stone).
Yes. Tests check specific inputs; they cannot prove correctness for all inputs. Formal verification (using tools like Halmos or Certora) can provide stronger guarantees, and is planned as a future milestone. The STARK verifier implements 19 discrete verification checks that mirror the Winterfell specification, and the Fiat-Shamir transcript has been cross-validated between Rust and Solidity implementations. However, a professional audit remains the standard for production-grade confidence.
If the Winterfell STARK prover has a soundness bug, it could potentially allow forged proofs. This risk exists for any proof system. Mitigations:
| Contract | Bytecode | Role |
|---|---|---|
| StarkVerifier | ~9.5 KB | STARK proof verification |
| StarkZkAceAccount | ~3.5 KB | Per-user vault |
| StarkZkAceAccountFactory | ~4.5 KB | CREATE2 deployment |
| GoldilocksField | Library (inlined) | Field arithmetic |