Between November 19-21, the zero-knowledge community gathered in Buenos Aires for EthProof Days. If you were paying attention, one thing became unmistakably clear: the Ethereum Foundation is betting heavily on ZK scaling, and they’re doing it with an unusual level of urgency around security.
This isn’t business as usual.
The Ethereum Foundation’s ZK Push
EthProof Days devoted significant attention to zero-knowledge virtual machines (zkVMs) as a cornerstone of Ethereum’s scaling strategy. The Foundation isn’t just funding research. They’re actively pushing production teams to move faster while simultaneously emphasizing that security cannot be an afterthought.
It’s a delicate balance. And judging from conversations with ZK teams in Buenos Aires, that balance isn’t quite working yet. The Ethereum Foundation is funding ZK research at unprecedented levels while warning teams that security shortcuts will be catastrophic. But funding doesn’t solve the fundamental tension: how do you move fast when verification is slow?
Here’s the problem ZK teams face: the technology is evolving faster than security practices can adapt. When we asked production ZK teams what they’re struggling with most, the answer was consistent. It wasn’t about finding talent or securing funding. It was about keeping up with ecosystem changes while quickly iterating on their products.
The ZK space is experiencing rapid evolution that makes traditional security review cycles nearly obsolete by the time they complete. Frameworks mature, new vulnerability classes emerge, and best practices evolve between the start and end of a typical audit engagement.
Why ZK Circuits Are Orders of Magnitude Harder to Audit
Zero-knowledge circuits are fundamentally more challenging to audit than smart contracts. Where smart contract bugs manifest as incorrect state transitions or failed transactions, ZK circuit vulnerabilities exist at the mathematical constraint level, making them nearly impossible to detect through conventional testing.
Consider what an under-constrained circuit vulnerability looks like in practice: an attacker could forge a valid proof showing they own 1000 tokens when they actually own zero. The proof verifies correctly, the transaction succeeds, but the entire system’s security model just collapsed silently. Unit tests cannot catch these vulnerabilities. They require formal verification techniques that most development teams don’t have in-house expertise to deploy. This technical complexity creates an operational crisis.
Here’s what that means practically: you can’t just hire more auditors or run more tests. You need fundamentally different verification approaches, and most teams don’t have those capabilities built internally.
The Continuous Iteration Problem
The Ethereum Foundation’s aggressive timeline for ZK scaling adoption means production teams can’t afford to slow down. They need to iterate quickly, incorporate feedback from testnet deployments, and adapt as the broader ecosystem evolves.
Traditional security review models break down here. Waiting weeks or months for an audit, receiving findings, implementing fixes, then re-auditing creates bottlenecks that ZK teams simply can’t tolerate given their development velocity requirements.
What emerged from conversations at EthProof Days is that leading ZK teams are looking for security approaches that integrate into their development workflow rather than gating it. They need continuous verification, not point-in-time audits. But here’s the tension: most teams acknowledge they lack the internal resources to build this capability themselves. They need external security tooling that can actually keep pace with their iteration speed.
This creates a knowledge problem as much as a process problem. Teams know what they need. They just don’t have clear paths to get there without either slowing down development or accepting unacceptable security risks.
The Moving Target Problem
When people talk about “ecosystem maturity” in ZK, they often mean standardization, established patterns, and settled best practices. But we’re not there yet.
Keeping up with changes in the ZK ecosystem doesn’t just mean tracking new libraries or framework updates. It means understanding evolving threat models, newly discovered vulnerability classes, and shifting architectural patterns for how ZK systems should be designed.
An optimization that works safely in one zkVM architecture could break soundness guarantees in another. What worked in development six months ago might introduce critical vulnerabilities today.
The security implications of these changes are non-obvious. Circuit optimizations that improve performance can inadvertently weaken security guarantees. Framework updates that fix one vulnerability class can expose another.
Teams building in this space are navigating without a complete map. And the traditional security review model, designed for more stable technology, struggles to provide the ongoing guidance they need.
Where This Leads
The Ethereum Foundation’s emphasis on ZK security at EthProof Days wasn’t just about preventing hacks. It was acknowledging a structural challenge: the technology is moving faster than traditional security processes can accommodate.
For ZK teams, this creates a binary choice. Either slow down to fit traditional audit timelines and risk falling behind competitively, or find security approaches that integrate directly into development workflows.
The teams that succeed in Ethereum’s ZK scaling future won’t be the ones with the biggest audit budgets. They’ll be the ones that made security verification as fast as their development cycles, catching underconstrained circuits in CI/CD pipelines rather than in post-deployment audits.
Because in a space evolving this fast, security can’t be something you bolt on at the end. It has to be built into how you develop.
Ready to catch vulnerabilities before they become costly delays?
Book a Demo → See how continuous detection works in your development workflow.
Explore Documentation → Learn about Vanguard, Picus, and OrCa detection capabilities.
