I pulled the bytecode from their verifier contract last week. The first thing I looked for was the Merkle path validation. It wasn't there.
That's not a small omission. That's the difference between a valid zero-knowledge proof and a magic show.
This project raised two hundred million dollars. Their website promises "Ethereum-equivalent security with instant finality." The team has PhDs from top universities. The GitHub stars look impressive. But the arithmetic circuit—the core of their ZK-EVM—contains a constraint that doesn't constrain.
Let me walk you through the bug.
The project claims to support arbitrary EVM execution inside a zero-knowledge proof. That means every opcode, every memory read, every storage slot must be correctly represented as a set of polynomial constraints. The prover then produces a succinct proof that the execution was honest.
The standard approach is to represent each step of the EVM as a circuit. For memory operations, you need to prove that a read from address X returns the value that was last written there. That's usually done with a Merkle tree over memory. The circuit checks inclusion proofs.
Their circuit checked inclusion proofs only for writes. Reads were assumed to be consistent with the latest write. But in a zero-knowledge proof, nothing is assumed. Everything must be proven.
Math doesn't care about your assumptions.
In practice, this means a malicious prover could craft a proof where a smart contract reads a value that was never written. Execute code that never existed. Drain a bridge. All while producing a valid-looking proof that passes on-chain verification.
I found this during a routine audit of their prover code. The comment said: "Read values are already validated by the write constraint." That comment is wrong. The write constraint only ensures the write is correct. It doesn't link reads to the correct write. Without that link, the proof proves nothing.
The team responded quickly. They acknowledged the issue and are patching. But the question is: how many other bugs are hidden in the remaining thousands of lines of constraint code?
Privacy is a protocol, not a policy.
This isn't about this one project. It's about the entire ZK-rollup narrative. The market is pricing in perfection. Every new announcement is met with immediate euphoria. The technical complexity is so high that even sophisticated investors cannot audit the claims. They rely on audit reports from firms that sometimes miss these edge cases.
I've been studying zero-knowledge proofs since the early days of Zcash. In 2020, I wrote the analysis of the Groth16 trusted setup ceremony—the one that pointed out the toxic waste could be leaked if the ceremony wasn't truly secure. That paper got cited in academic journals. But it didn't stop the hype then, and it won't stop it now.
The reality is that ZK-EVMs are still in their infancy. The trade-offs are brutal:
- Prover time vs. security: Faster provers mean fewer constraints, which means more assumptions. Every missing constraint is a backdoor.
- Circuit size vs. EVM compatibility: The full EVM is enormous. To fit it into a circuit, projects cut corners. They simplify opcodes. They assume certain values are in range without checking.
- Centralized proving: Most projects run provers on a single machine. If that machine is compromised, the attacker can produce false proofs. Decentralized proving doesn't exist yet at scale.
I've seen five different ZK-rollup architectures this year. Each one has a different set of security assumptions. Some use a separate data availability layer. Some rely on single-sequencer honesty. Some have admin keys that can upgrade the verifier contract—meaning the "immutable" code can be changed.
But the market doesn't distinguish. All ZK-rollups are treated as if they are the same. They're not.
The contrarian angle: Optimistic rollups, with their seven-day challenge window, actually provide a stronger security guarantee right now. Why? Because their security assumptions are simpler. You don't need to trust a proof system. You need to be able to verify one. Verification is just replaying the execution. That's well-understood.
ZK-rollups will eventually win. The math is beautiful. The finality is instant. But right now, the trade-off is complexity for speed. And complexity hides bugs.
I've audited over 200 smart contracts and five ZK circuits. The worst bugs are always in the parts that everybody assumes are correct. The parts that don't get audited because the code looks clean. The parts where the comment says "obviously correct."
Math doesn't have intuition. Math only follows rules. If your circuit doesn't enforce a rule, the proof doesn't enforce it either.
So what do you do? As an investor, look for projects that publish their circuit code with a formal verification report. Not just a smart contract audit—a formal verification of the constraint system. Projects that allow independent researchers to challenge proofs. Projects that have a bug bounty large enough to make finding a vulnerability worth more than exploiting it.
As a developer, never trust a comment. Write your specifications as code. Use tools like Circom or Halo2's compiled output. Add redundant checks. Test with adversarial inputs.
As a user, demand transparency. Ask: "Show me your proof system's specification. Let me verify the verifier contract on-chain."
The current bull market is masking these risks. Prices are rising. Volumes are high. Nobody wants to hear about bugs in a design they don't fully understand. But I've seen this before—in 2021 with the NFT minting contracts that had rounding errors. In 2022 with the algorithmic stablecoins that had game-theoretic flaws. The pattern repeats.
This time, the bug might be in a different place. It might be a missing constraint in a polynomial commitment scheme. It might be a flawed recursive proof composition. It might be an oracle that feeds into the proof generation.
But the underlying cause is the same: complexity is outpacing understanding.
I write these analyses not to scare people. I write them because I believe in zero-knowledge proofs. I've spent a decade working on them. I want them to succeed. But they will only succeed if the community holds them to the highest standard.
Privacy is a protocol, not a policy. The same is true for security. Security is not a checkbox on a whitepaper. It is a protocol enforced by code.
So next time you see a ZK-rollup announcement with a hundred million dollar valuation, ask yourself: "What constraints are they not checking?"
Because I can tell you: somewhere in that constraint system, there is an assumption. And assumptions are vulnerabilities waiting to be exploited.
