zkEVMs Hit Production in 2026, But Are We Building Incompatible Security Models?

[zk_proof_zoe]

After seven years in ZK cryptography research—from Zcash to StarkWare to my current role—I’ve watched 2026 become the year zkEVMs finally went from “someday” to “production-ready.” Proving times collapsed from 16 minutes to 16 seconds. Multiple implementations reached mainnet. The execution gap between zkEVMs and native EVM chains has nearly closed.

But here’s what keeps me up at night: we’ve created a fragmented landscape of incompatible security assumptions.

The Fragmentation We’ve Built

Let me break down what’s actually happening under the hood:

Polygon zkEVM uses the Hermez prover with FFLONK—no trusted setup required, cheaper on-chain verification than GROTH 16 (30% cheaper than PLONK). Their approach: ZK-verify their own internal zkASM language, then interpret EVM code through zkASM. Prover-friendly and efficient.

zkSync Era runs Boojum/Redshift (FRI + PLONK construction). But here’s the key difference: they compile Solidity → Yul → custom circuit-compatible bytecode. They’re operating at the IR (LLVM-IR) level, not pure bytecode.

Scroll takes the opposite approach: bytecode-level compatibility, built in collaboration with the Ethereum Foundation’s PSE group. The goal is to fully reuse Geth’s security model. You can literally copy-paste Ethereum code with zero changes.

Starknet breaks from the EVM entirely—Cairo VM with STARKs. Different language, different execution model, different everything.

Why This Matters for Security

Each proving system uses fundamentally different mathematics. That means:

1. Different security audits required. A formal verification of Polygon’s FFLONK system tells you nothing about zkSync’s Boojum implementation. The attack surfaces are entirely distinct.

2. Cross-chain bridges must trust multiple proof systems simultaneously. When you bridge assets between zkEVMs, you’re not just trusting one cryptographic construction—you’re trusting all of them.

3. Bug isolation is good; inconsistent security is bad. A bug in Polygon’s prover won’t affect Scroll (good!). But now developers building cross-chain contracts need to understand multiple proving systems to properly audit their code (bad!).

4. We’re still learning what’s secure. The Ethereum Foundation recently shifted focus from speed to security because researchers disproved the “proximity gap” conjectures that many hash-based SNARKs and STARKs were relying on. These mathematical assumptions we thought were solid? Turns out they don’t hold in all parameter ranges where teams were using them.

A soundness failure in a ZK system isn’t like other bugs. A forged proof could let an attacker create assets, rewrite state, or steal funds—all while the verification layer thinks everything is valid.

The Ethereum Foundation’s Response

The good news: the EF is taking this seriously. They’re targeting 100-bit provable security by May 2026 and full 128-bit security by year-end. 128-bit security is the gold standard—what financial systems and government communications use.

New constructions like WHIR (a Reed-Solomon proximity test) offer transparent, post-quantum security without trusted setup ceremonies. At 128-bit security, WHIR produces proofs ~1.95x smaller than older methods with several times faster verification.

But standardizing on new cryptography takes time. And it doesn’t solve the diversity problem.

The Core Dilemma

So here’s the tension: should we converge on one proving standard for consistency, or does diversity create resilience?

Arguments for convergence:

• Easier to audit (one math model to verify)
• Shared security improvements benefit everyone
• Simpler for developers building cross-chain applications
• Clear security benchmarks and standards

Arguments for diversity:

• Competition drove those 60x performance improvements
• Single cryptographic flaw wouldn’t break entire L2 ecosystem
• Different proving systems optimized for different use cases
• Innovation happens at the edges, not through committee standardization

My Questions for This Community

I don’t have answers here—just concerns worth discussing:

1. How do everyday users evaluate security when every L2 uses different cryptography? Most users don’t know what proving system their L2 runs on. They just want fast, cheap transactions.

2. What’s the developer expectation? Should Solidity devs deeply understand ZK mathematics, or is this infrastructure-level complexity they should be able to abstract away?

3. Are we optimizing for the wrong metrics? If proving time and cost come at the expense of auditability and security transparency, have we actually made progress?

4. What happens when (not if) we find a critical flaw in one of these proving systems? Do we have coordinated disclosure processes? Security standards? Or will it be chaos?

The math is beautiful. The engineering is impressive. But I worry we’re building incompatible security models that will be painful to reconcile later.

What do you all think? Am I being too paranoid, or is this fragmentation a real problem we need to address before these systems handle billions in TVL?

[security_sophia]

As someone who’s spent years in the audit trenches, this fragmentation is precisely what keeps me up at night. You’ve articulated the security nightmare we’re facing.

From a formal verification perspective, each proving system requires completely separate security analysis. When I audit a Polygon zkEVM contract versus a zkSync Era contract, I’m essentially working in different mathematical universes. The attack surfaces don’t just vary—they’re fundamentally distinct.

The Cross-Chain Exploit Vector

Here’s what worries me most: cross-chain exploits that leverage differences between proving systems. Consider this scenario:

• A DeFi protocol deploys identical contracts on Polygon zkEVM and zkSync Era
• The contract behaves identically at the Solidity level
• But one proving system has a subtle soundness issue the other doesn’t
• An attacker discovers they can forge a proof on System A while System B remains secure
• They drain liquidity from System A, bridge to System B, and the protocol’s cross-chain accounting breaks

We’ve already seen $905M lost to DeFi exploits in 2025 according to OWASP Smart Contract Top 10: 2026—and that’s without adding ZK cryptographic complexity on top. Access control flaws remain the #1 vulnerability class. Now we’re layering incomprehensible proving system variations underneath smart contract logic?

The Audit Industry Isn’t Ready

The traditional audit process is failing here:

1. Most auditors don’t understand ZK math deeply. We check smart contract logic, but the proving system is a black box.

2. No standardized security checklists. For EVM contracts, we have well-established patterns (checks-effects-interactions, reentrancy guards, access control). For zkEVM proving systems? Every team is inventing their own security model.

3. Formal verification tools lag behind. We can formally verify contract bytecode, but can we verify that Polygon’s zkASM interpreter correctly translates EVM semantics? That zkSync’s IR compilation preserves security invariants?

4. Bug bounties don’t scale. Finding a soundness flaw in a ZK prover requires PhD-level cryptography expertise. The pool of researchers who can audit these systems is tiny compared to smart contract auditors.

The Proximity Gap Conjecture Failure

You mentioned the disproved proximity gap conjectures—this is exactly the kind of systemic risk I’m talking about. Teams built production systems on mathematical assumptions that turned out to be false. Not “theoretically weak but practically secure”—actually false in the parameter ranges being used.

This is why the Ethereum Foundation’s shift to 128-bit security is critical. But it also proves we’re still in the experimental phase. When your security assumptions can be invalidated by academic papers, you’re not ready for billions in TVL.

What We Need (Yesterday)

The industry needs:

1. Standardized proving system security benchmarks - Like OWASP but for ZK cryptography
2. Cross-proving-system test suites - Verify that contracts behave identically across zkEVMs
3. Coordinated disclosure processes - When someone finds a soundness bug, what’s the responsible disclosure timeline?
4. Insurance protocols - If proving system X fails, how do we make users whole?

My Question to You, Zoe

You’re deep in ZK research—how do you approach auditing circuits across different proving systems? Are there commonalities we can extract, or is every system truly a unique mathematical snowflake?

And to the broader community: should we be demanding that zkEVM teams publish formal security proofs (not just whitepapers) before we trust them with real assets? Or am I being unrealistic about what’s provable in practice?

The math is beautiful, the engineering is impressive—but security is not a feature, it’s a process. And right now, I don’t think we have the processes in place to safely handle this level of cryptographic diversity.

[ethereum_emma]

Okay, I’m going to be honest—this discussion is making me realize how much I don’t know, and it’s both humbling and terrifying.

I learned Solidity about two years ago, coming from a React/frontend background. I thought I was finally getting comfortable with smart contract development. Gas optimization, reentrancy guards, access control patterns—I’ve got those down. Then I read threads like this and realize the security foundation I’m building on is… way more complicated than I understood.

The Newcomer’s Dilemma

When I was choosing which L2 to build on last month, my decision criteria were:

1. Does it have good docs?
2. Can I use Hardhat/Foundry?
3. Are transaction fees cheap enough for my use case?
4. Is there an active community?

Nowhere in that list was “What proving system does this L2 use?” Because honestly, I didn’t even know that was a question I should be asking.

Now you’re telling me that the same Solidity contract might have different security properties depending on whether it’s running on Polygon zkEVM (zkASM interpreter) versus zkSync Era (IR-level compilation) versus Scroll (bytecode-level)?

The Questions I’m Too Afraid to Ask

If I deploy my contract on Scroll today, can I trust it’s as secure as on Polygon zkEVM? Or do I need to understand FFLONK versus FRI+PLONK to make that judgment?

Should I be testing my contracts separately on each zkEVM? Are there zkEVM-specific vulnerabilities I need to watch for that don’t exist on mainnet?

And Sophia’s point about auditors not understanding ZK math deeply—if professional auditors are struggling, what hope do I have as a regular developer?

What Should Developers Actually Learn?

Here’s what I’m wondering: Is this infrastructure-level complexity that I should be able to abstract away? Or do I need to go back to school and get a PhD in cryptography to build safely on these platforms?

Because right now, the barrier to entry feels like it just went from “learn Solidity and security patterns” to “understand advanced mathematics and multiple cryptographic proving systems.”

I want to build on L2s. They’re faster, cheaper, and the tech is amazing. But I also don’t want to accidentally deploy code that has subtle vulnerabilities because I didn’t understand the proving system underneath.

A Practical Request

Can someone (maybe you, Zoe, or you, Sophia) create a “zkEVM Security Differences for Smart Contract Developers” cheat sheet? Something that answers:

• What behaves differently between zkEVMs?
• What security patterns need to change?
• What should I test for that I don’t test on mainnet?
• Which zkEVMs are safe to deploy on without understanding the proving system deeply?

I appreciate the deep technical discussions, but I’m also just trying to build things and keep users safe. Right now, I feel like I’m missing critical knowledge to do that responsibly.

Am I overthinking this? Should I just trust the infrastructure and focus on contract-level security? Or is this concern justified?

[layer2_lisa]

Having worked on L2 infrastructure at both Polygon and Optimism, I need to push back a bit on the “fragmentation is catastrophic” framing. Yes, there are real challenges, but diversity also brings significant benefits we shouldn’t dismiss.

The Case for Diversity

Let me start with hard data: proving times collapsed from 16 minutes to 16 seconds over the last 18 months. That’s a 60x performance improvement. That didn’t happen through committee standardization—it happened because teams were competing on different approaches and learning from each other.

If everyone had standardized on the same proving system two years ago, we’d all be stuck with 16-minute proving times today. Innovation happens at the edges, not through convergence.

The Consensus Client Analogy

This reminds me of Ethereum’s consensus client diversity debate. The network is stronger because we have Geth, Nethermind, Besu, Erigon—all implementing the same protocol but with different codebases. When one client has a bug, the others keep the network secure.

Similarly, if Polygon’s FFLONK has a cryptographic flaw, zkSync’s Boojum and Scroll’s prover aren’t affected. That’s fault isolation, not fragmentation. A single proving system would create a single point of failure for the entire L2 ecosystem.

Emma’s Question Deserves a Real Answer

Emma, you asked if you need to understand ZK math deeply to build on L2s. Short answer: no, you don’t.

Here’s the reality:

1. Contract-level security matters more than proving system security. Access control bugs ($905M+ in losses) happen at the Solidity layer, not the ZK layer. Focus on what you can control.

2. zkEVMs converging on EVM equivalence. Scroll is bytecode-level compatible. Polygon and zkSync are close enough that 99% of contracts work identically. The differences are edge cases (like exotic precompiles or gas cost variations).

3. Test on your target L2. You should always test on the chain you’re deploying to—whether that’s mainnet, Optimism, or zkSync. This isn’t new with zkEVMs.

4. Trust but verify the infrastructure. zkEVM teams have strong incentives to get security right. They’re not hiding the math—whitepapers and implementations are public. Let the ZK researchers (like Zoe) audit the proving systems while you focus on contract logic.

Sophia’s Concerns Are Valid—But Solvable

Sophia, you’re absolutely right that we need better security processes. But I’d argue we’re building them:

• Ethereum Foundation’s 128-bit security target shows institutional focus on cryptographic rigor
• WHIR and other transparent proofs remove trusted setup vulnerabilities
• Bug bounty programs are attracting top cryptographers (recently saw a $10M zkEVM bug bounty)
• Formal verification tools are catching up—Certora, Halmos, and academic teams are working on zkEVM-specific tooling

Bridging Security: Where I Do Worry

Where I agree with both of you: cross-chain bridge security is the real challenge. When you bridge between zkEVMs, you’re trusting:

1. Source chain’s proving system
2. Destination chain’s proving system
3. The bridge contract logic
4. The bridge’s message-passing verification

That’s a lot of trust assumptions. This is where I’d love to see convergence—not on proving systems themselves, but on bridge security standards and cross-chain verification protocols.

The 2026 Maturity Milestone

We’re in year one of “production-ready” zkEVMs. Of course we don’t have all the answers yet. But compare where we are now to 2021:

• Proving times: 16 sec (was 16 min)
• Cost: 45x cheaper
• Multiple independent implementations in production
• Real-time proof generation (faster than 12-sec block times)
• 128-bit security (coming by EOY 2026)
• Standardized bridge security (work in progress)

My Questions Back

1. To Zoe: Should we focus less on proving system uniformity and more on standardizing security testing frameworks? Can we create a zkEVM security test suite that works across different provers?

2. To Sophia: What would a “zkEVM OWASP Top 10” look like? Can we identify prover-agnostic security principles?

3. To Emma: Would a compatibility matrix help—showing which Solidity features behave identically across zkEVMs versus which have edge case differences?

The math is beautiful. The engineering is impressive. And I’m optimistic that diversity + better tooling is the path forward, not premature convergence.

[solidity_sarah]

Emma, I feel you completely—and Lisa’s right that you don’t need a cryptography PhD to build safely. But let me add some practical developer context to this discussion, because there are real differences that matter at the code level.

What Actually Changes Between zkEVMs?

From my auditing work, here’s what I’ve seen cause issues:

1. Bytecode Compatibility Differences

• Scroll: Bytecode-level compatible. Copy-paste your mainnet contract, it works.
• Polygon zkEVM: Very close to bytecode-level, edge cases with some precompiles
• zkSync Era: IR-level compilation. Your Solidity works, but the compiled bytecode is different. Some opcodes behave differently.

2. Gas Cost Variations

zkEVMs have different proving costs. Operations that are cheap on mainnet might be expensive on zkEVM (and vice versa). I’ve seen contracts that were gas-optimized for mainnet become prohibitively expensive on certain zkEVMs.

3. Precompile Support

Not all zkEVMs support all EVM precompiles. If you’re using ecrecover, pairing checks, or other precompiles, test thoroughly on your target zkEVM.

4. Block Properties

Block timestamps, block numbers, and other environment variables can behave differently. If your contract relies on block.timestamp for critical logic, verify the behavior.

The Testing Problem Lisa Mentioned

Lisa said “test on your target L2” like it’s simple, but here’s the reality: most developers aren’t doing comprehensive zkEVM-specific testing.

We need tooling that catches zkEVM incompatibilities automatically. Foundry’s great for testing Solidity logic, but it doesn’t catch “this works on mainnet but behaves differently on zkSync” issues.

Emma’s Cheat Sheet Request (I’ll Start It)

Here’s a quick version—someone should expand this into a proper resource:

Deploying on Scroll?

• Closest to mainnet behavior
• Existing security tools work (Slither, etc.)
• Test gas costs separately

Deploying on Polygon zkEVM?

• Very close to mainnet
• Check precompile support for your use case
• Test gas costs separately

Deploying on zkSync Era?

• Solidity compiles differently (IR-level)
• Some opcodes behave differently
• Test extensively before mainnet deployment
• Read their compatibility docs carefully

Deploying on Starknet?

• Not EVM—use Cairo, different paradigm entirely

Where I Agree with Sophia

We absolutely need:

1. A “zkEVM Compatibility Checker” tool - Run your contract through it, get a report on potential issues across different zkEVMs
2. zkEVM-specific security patterns - Are there new attack vectors? New best practices?
3. Clear documentation - Each zkEVM should publish a comprehensive “differences from mainnet” doc

Where I Agree with Lisa

Lisa’s consensus client analogy is spot-on. We don’t demand that all Ethereum clients use identical codebases—we value diversity for resilience. The same logic applies to proving systems.

But (and this is important): Ethereum clients all implement the same protocol spec. We have a clear definition of “correct behavior.” Do we have that for zkEVMs? What’s the spec they’re all trying to match?

Practical Advice for Emma (and Others)

1. Pick one zkEVM and learn it deeply first. Don’t try to be an expert on all of them.

2. Start with Scroll if you want the smoothest onboarding. Bytecode compatibility means fewer surprises.

3. Focus on contract-level security first. Reentrancy, access control, integer overflow—these matter more than proving system details.

4. When in doubt, test twice, deploy once. Use testnet extensively. Get your contracts audited if they handle significant value.

5. Join the zkEVM community you’re building on. Each has Discord/forums where devs share zkEVM-specific gotchas.

My Questions

1. To Zoe and Sophia: Can we create a “zkEVM Security Test Suite”—a standard set of contracts that exercise edge cases and verify compatibility across zkEVMs?

2. To Lisa: You mentioned formal verification tools catching up—are there any production-ready tools today for verifying zkEVM contract behavior?

3. To the community: Should we start a “zkEVM Compatibility Working Group” to document these differences systematically?

The good news: most smart contract development is the same across zkEVMs. The bad news: the differences matter when they matter, and right now, we don’t have great tooling to catch them.

Let’s build that tooling together. Who’s in?