Current status: the original public deployment is obsolete because its STARK AIR did not prove the identity commitment in-circuit. Fixed Poseidon2/userOpHash deployments are now live-tested on Arbitrum One, Base, and Optimism, but remain pre-audit.
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. The fixed design removes ECDSA from wallet authorization. Once audited, an attacker would need to forge a hash-based STARK proof rather than derive an ECDSA key. The obsolete deployment should not be treated as providing that guarantee.
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.
ZK-ACE previously demonstrated on-chain STARK proof verification on live EVM deployments; those older deployments are now legacy. The fixed build is live-tested on Arbitrum One, Base, and Optimism and pre-audit, so current claims should distinguish live evidence from production security assurance.
They can, and eventually will. The question is how long it takes:
ZK-ACE has a working fixed implementation, fixed Arbitrum/Base/Optimism deployments, and historical deployment experience. It still needs professional audit before it should secure serious funds.
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 vault.zkace.io. Click "Create New Vault." Write down the 24-word recovery phrase. That's it. Your vault address is deterministic — the fixed contracts now exist on Arbitrum, Base, and Optimism, though the browser app is still Arbitrum-first.
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.
The fixed verifier costs about 10.46M gas for proof verification in local Foundry tests. Live ERC-4337 handleOps transactions with proof verification measured 12.50M gas on Arbitrum, 10.41M on Base, and 11.04M on Optimism; USD cost depends on calldata pricing, bundler settings, and current L2 fees.
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. The fixed contracts are live-tested on Arbitrum, Base, and Optimism; the current browser app is still Arbitrum-first. The vault is a standard smart contract account and can receive and hold any token on its chain.
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 far more expensive than the fixed STARK verifier's current ~10.46M gas measurement 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. The fixed STARK proof fixture is larger (~83-85 KB ABI encoded), so final cost needs ongoing live measurement.
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. The fixed STARK path avoids pairings and now constrains Poseidon2 in the AIR, so the Solidity ABI proof fixture is about 83-85 KB.
Poseidon2 over the Goldilocks field is now the default identity-commitment hash in ZK-ACE. It is algebraically friendly, uses the canonical Plonky3 parameter set, and fits the off-chain witness-derivation step cleanly without requiring any smart contract or AIR rewrite.
Keccak256 is still 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. The commitment hash itself is not recomputed on-chain; the contract stores idCom as an opaque bytes32.
Rescue-Prime remains supported only for pre-migration vaults so users can still recover older vaults and voluntarily rotate them to Poseidon2 through the existing 48-hour timelock, with no contract migration.
Yes. Poseidon2 and Rescue-Prime are both symmetric hash functions. Their security relies on one-wayness, not on elliptic-curve or pairing assumptions that Shor's algorithm breaks. Grover's algorithm gives only a quadratic speedup, reducing a 256-bit hash target to 128-bit post-quantum security. ZK-ACE's 4-element digest therefore preserves the standard 128-bit post-quantum target in both the new Poseidon2 path and the legacy Rescue-Prime path.
128-bit post-quantum. This comes from multiple independent layers:
| Layer | Security |
|---|---|
| Poseidon2 commitments (legacy Rescue-Prime supported) | 128-bit PQ (Grover halves 256 to 128) |
| STARK soundness (44 queries, blowup 16) | 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-v2-poseidon2", 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 Poseidon2 commitment adds a further layer for new vaults, and legacy Rescue-Prime vaults retain the same 128-bit post-quantum target; in both cases an attacker would still need to forge a valid STARK proof, which requires breaking 132-bit soundness.
For new vaults, IDcom = Poseidon2(REV, salt, chainId). Legacy vaults continue to use their original Rescue-Prime commitment until the user rotates. 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 old boundary-only STARK relation was found to be unsound and has been replaced by a Poseidon2-in-AIR relation bound to zkNonce, chainId, and ERC-4337 userOpHash. Current checks pass: 25 Rust STARK tests, 9 WASM tests, 91 Solidity tests with 2 skipped, plus live Arbitrum positive and adversarial transaction tests. A professional audit is still required before production use.
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 (551 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 |