Fixed deployments live-tested on Arbitrum, Base, and Optimism; pre-audit

Quantum-resistant
wallets for the EVM

ZK-ACE replaces ECDSA signatures with identity-bound STARK proofs. The original deployment exposed a boundary-only AIR issue; the fixed deployments now proves the Poseidon2 identity commitment in-circuit and binds each proof to the ERC-4337 userOpHash.

STARK Hash-Only Proofs
0 Curves in Authorization
10.4-12.5M Live handleOps Gas
~85 KB ABI Proof Fixture

The Problem

ECDSA is quantum-vulnerable

Every EVM wallet relies on elliptic curve signatures. Shor's algorithm on a fault-tolerant quantum computer breaks them completely. Your funds, your NFTs, your DeFi positions — all at risk.

Post-quantum signatures are too large

NIST-standardized PQ signatures (ML-DSA, Falcon) are 2–5 KB per transaction. On rollups where calldata is the bottleneck, this is a 30–40x increase in authorization data.

Migration requires new chains

Existing quantum-resistant projects require abandoning the EVM ecosystem. Users must bridge assets to new L1s, learn new tooling, and trust untested infrastructure.

The ZK-ACE Solution

Zero-knowledge authorization

Instead of signing transactions, you prove in zero knowledge that you know a secret consistent with an on-chain identity commitment. No signature object ever touches the chain.

Stateless hash-only proofs

A single STARK proof replaces the entire signature. Hash-only cryptography — no elliptic curves, no pairings, no trusted setup, nothing for Shor's algorithm to attack. Unlike lattice or one-time signatures, STARK proofs are stateless: the same identity works forever with no key exhaustion risk.

Drop-in ERC-4337 module

Designed as an ERC-4337 account module for today's EVM. No protocol changes and no new L1 are required. The fixed deployments are live-tested on Arbitrum, Base, and Optimism and still awaiting external audit.

How It Works

Four steps to quantum resistance

From identity creation to authorized transaction, the entire flow uses zero-knowledge proofs with no classical signing keys.

Step 01

Generate Identity

Derive your identity secret from a 24-word recovery phrase via PBKDF2. Compute your identity commitment: a cryptographic hash anchored on-chain.

IDcom = Hash(REV, salt, chainId)
Step 02

Deploy Vault

Call the factory contract with your IDcom. You get a deterministic ERC-4337 smart wallet address — works the same on every EVM chain.

factory.createAccount(IDcom, 0)
Step 03

Prove Authorization

To authorize a transaction, generate a STARK proof that you know the REV and salt whose Poseidon2 hash matches the on-chain IDcom. The account binds the proof to the ERC-4337 userOpHash, chain, and nonce.

proof = STARK.prove(REV, salt, userOpHash, nonce)
Step 04

Execute On-Chain

The smart contract verifies the STARK proof using native EVM keccak256 and Goldilocks field arithmetic. Checks IDcom, userOpHash, domain, reserved inputs, and zkNonce, then advances the nonce and executes.

verifier.verifyProof(proof, inputs)
Technical Specifications

Live-tested, pre-audit

The fixed Poseidon2 AIR and account binding are implemented, deployed on Arbitrum One, Base, and Optimism, and tested with live proof-backed ERC-4337 transactions. The old deployment is obsolete.

Proof System

STARK

FRI-based (Winterfell). Hash-only — zero elliptic curves. Keccak256 for Merkle trees and Fiat-Shamir. No trusted setup. Fully post-quantum.

Field

Goldilocks

p = 264 − 232 + 1. Native 64-bit arithmetic. EVM verification via mulmod/addmod opcodes (8 gas each).

Hash Function

Keccak256

Keccak256 for Merkle trees and Fiat-Shamir; Poseidon2 over Goldilocks for the identity commitment inside the AIR. No elliptic curves in the authorization path.

Proof Size

~85 KB

44 FRI queries, blowup factor 16, quadratic extension field, and 20-bit grinding. Native Winterfell proof is about 21 KB; Solidity ABI fixture is about 83-85 KB.

Verification Cost

10.46M gas

Verifier-only local measurement is about 10.46M gas. Live ERC-4337 handleOps transactions with proof verification measured 12.50M gas on Arbitrum, 10.41M on Base, and 11.04M on Optimism.

Test Coverage

125+

Rust, WASM, and Solidity checks include STARK E2E with real proofs, two sequential account transactions, replay rejection, userOpHash substitution rejection, and tampered-proof rejection.

Security

Security by design

Every layer of the system is built to withstand both classical and quantum adversaries.

Transparent

No trusted setup

STARKs are fully transparent — no toxic waste, no MPC ceremony, no trusted third parties. Security depends only on hash functions.

Hash-Only

Fully post-quantum

Keccak256 + Goldilocks field only — zero elliptic curves, zero pairings. Nothing for Shor's algorithm to attack. 128-bit post-quantum security.

On-Chain

Transaction binding

The account checks the public userOpHash limbs against the ERC-4337 userOpHash supplied by EntryPoint. Domain is checked against block.chainid and all public inputs are validated as field elements.

Internal

Replay prevention

Monotonic nonce internal to the account contract. Only advances after valid ZK proof through the EntryPoint. No external actor can manipulate it.

Timelocked

Identity recovery

2-step timelock rotation: propose a new identity, wait 48 hours, confirm. Emergency pause halts all operations. Both require valid proof.

Zeroized

Memory safety

Identity secrets are zeroized on drop. No Clone or Debug derive. REV is wiped from memory after proof generation.

Deployment Status

Live deployments

These are the fixed Poseidon2/userOpHash contracts tested on May 15, 2026. They are pre-audit; the earlier verifier/factory addresses are obsolete.

Contract Address Network Role
StarkVerifier 0x7b57AfFdEeD8d1F70CA1552EdDc3c67a4F8D2809 Arbitrum One Proof Verification
Vault Factory 0x762D5CC5C19e88d180bf959CCA43b60C7833e65F Arbitrum One CREATE2 Deployment
Live Test Account 0x4F0eC102c0cB6299770a32137dd76Fa96E5D17Db Arbitrum One Valid handleOps: 0xb93b6f87...6205
StarkVerifier 0x4EfAD81ACCd464B4e2aa8Ef1Aa2EB2507285DaB1 Base Proof Verification
Vault Factory 0x318cD1b8D60779F11C5F21e27A2Ad0C62f33436f Base CREATE2 Deployment
Live Test Account 0xAD0e42DC85AE10c9f567C5Dc17776cE3F23e4f55 Base Valid handleOps: 0xba501893...ca6
StarkVerifier 0x85C9C8844806c8C10BFFF2e12B6e578C01CA57A8 Optimism Proof Verification
Vault Factory 0x54Cf047e9DA48AC62C4eeC8fC6cF450cFfEF63be Optimism CREATE2 Deployment
Live Test Account 0xa1a4d1682F63f4a754Ae1529E4eF946a3Ed131eE Optimism Valid handleOps: 0x17c9a4e6...6f4
Get Started

The quantum clock is ticking

Try the pre-audit vault app, inspect the live Arbitrum/Base/Optimism transaction evidence, or read the underlying paper.

Read the Paper View on GitHub