# Ethereum Privacy Pool Proposal Cuts Withdrawal Proof Time to 28.6 Milliseconds

By Simon Yoon

Canonical URL: https://www.tokenpost.com/news/technology/34782
Published: 2026-10-19T12:50:29.000Z
Updated: 2026-10-19T12:50:29.000Z
Section: Technology

> The design batches small SHA-256 circuit steps with Flock and proposes a recovery path for seed-derived deposits in compatible pools.

A proposed Ethereum privacy pool generated a withdrawal proof in 28.6 milliseconds in a benchmark by batching small SHA-256 circuit steps with Flock, testing a faster approach to post-quantum privacy.

The test used a depth-32 Merkle tree, a structure that lets a withdrawal prove its deposit belongs to the pool. The result was about 28 times faster than the initial design’s 0.81-second proof time.

The design adapts a Tornado Cash-style pool to Flock, a proof system aimed at post-quantum security. It uses SHA-256 for the deposit tree and for nullifiers, markers that prevent the same deposit from being withdrawn twice.

The measured speedup came from the way the proof was built. Instead of placing all 34 SHA-256 compression steps in one circuit, the design runs each step through a smaller circuit suited to Flock’s batching.

A separate test combined proofs for four to 128 withdrawals. The final proof remained 343.9 KiB across that range, and verification took 46 to 64 milliseconds. The time needed to combine the proofs rose from 1.7 seconds to 87.6 seconds as the batch grew.

Those figures measure different tasks: generating one withdrawal proof, checking a combined proof and assembling that combined proof. The 28.6-millisecond result applies to one withdrawal in the tested configuration, not to the full aggregation process.

The proposal also describes a recovery path for seed-derived deposits if older cryptography becomes vulnerable to quantum attacks. Wallets would derive deposit secrets from a seed so users could later prove ownership through a post-quantum recovery verifier in a compatible pool.

Deposits made with the older random-secret method could be stranded after the old verifier is disabled. A pool would need to disable that verifier before its cryptography is broken. Immutable pools cannot install the recovery verifier, while an upgradeable pool would need a governance change to add it.