Thanks @Igor for the proposal, and for engaging seriously with TZEs / L2 paths. I appreciate the effort and the tone. I also want to explicitly say up front: there are real ideas here, and it’s healthy that the Zcash community sees multiple concrete approaches and we reason about tradeoffs in public.
Also, I’d like to avoid any “proposal war” dynamic. I’m aligned with the spirit Igor shared privately: we should collaborate and ship code, not compete for no reason. I’m personally happy to work together on whatever best advances Zcash.
With that said, I still have a strong view on the strategic direction.
TL;DR (my current stance)
My proposal is to EXTEND Zcash in a SOVEREIGN way (no dependency on Ethereum governance/liveness/politics), and in a FUTURE-PROOF direction (post-quantum plausible).
Igor’s proposal is primarily about exporting / bridging utility (starting with Ethereum). That can be valuable infrastructure, but I don’t think it should be positioned as a substitute for a native extension path (technically it’s not framed as a substitute, but the overall impression of the proposal is less Zcash aligned in my opinion).
So the framing I’d propose to the community is:
- Best direction for Zcash long-term: a native
STARK_VERIFYTZE enabling Zcash anchored L2s (i.e Ztarknet, Aztec, ZkSync). - Complementary track: a trustless bridge TZE to Ethereum (and maybe others) as an application of Zcash extension primitives, not as “the” extension strategy.
In other words: this bridge proposal can be seen as complementary, and even as something we could build on top of a more foundational verifier primitive, but it shouldn’t replace the “Zcash grows itself” path.
Strategic framing: Sovereign Zcash vs Zcash as an external asset
This is the key strategic question for the community:
Do we want Zcash to become primarily a base layer settlement + privacy engine that grows its own execution economy, or do we want ZEC to become primarily a wrapped asset that finds most of its new utility in Ethereum’s execution environment?
The bridge-first path naturally shifts:
- execution → Ethereum
- gas / MEV economics → Ethereum
- app gravity / liquidity routing → Ethereum
A native L2 path keeps:
- settlement → Zcash
- fees to L1 miners/validators → Zcash
- and optionally L2 gas → ZEC (policy choice)
Bridges can be useful, but they’re structurally biased toward exporting activity. A native L2 is structurally biased toward extending Zcash.
Economic linkage: value accrual matters (and is a real design axis)
One reason I’m pushing so hard for a native extension path is economic linkage.
In a bridge-first world, a large fraction of the “new utility” ends up being paid for in ETH and mediated by Ethereum’s execution environment. In a native L2 world, Zcash keeps being the settlement engine and fee sink, and ZEC can remain the native unit of account for the expanded economy.
This isn’t a moral statement. It’s a practical one: if the goal is long-term Zcash sustainability and relevance, preserving a tight ZEC ↔ utility loop is a feature, not a nice-to-have.
Quantum posture: this is a big differentiator and it should be explicit
Zcash has always built with a multi-decade horizon, and ECC has explicitly stated that quantum computers are a realistic potential threat to some Zcash cryptography within a 3–10 year timeframe, and that it’s worth taking steps now given protocol lead times.
Halo2 is fundamentally based on elliptic-curve discrete log assumptions (classical hardness).
That means it is not post-quantum.
STARK verification is hash-based and widely treated as post-quantum plausible.
So if we are adding new consensus-level capability, I think it’s rational for Zcash to prioritize the primitive that pushes us toward future-proofing, rather than entrenching more functionality around non-PQ assumptions.
“Wrapping everything into Halo2 reduces complexity” is not obviously true
One of the core claims is: “Zcash already has Halo2 integrated; adding another proving system increases failure points.”
I get the instinct, but the “wrap anything into Halo2” approach often increases the hardest-to-audit surface area:
- You now rely on the inner proof system, plus
- the correctness of the verifier-in-circuit, plus
- Halo2 itself.
By contrast, a native STARK_VERIFY primitive can be deliberately narrow: pinned parameters, bounded verification costs, byte caps, and no minting path. That’s the design intent in the Ztarknet/STARK_VERIFY threads.
I’m not claiming “STARK code is magically safer.” I’m saying: there is a credible path to making the consensus surface small and auditable, and it’s not clear that “Halo2 everywhere” achieves that in practice.
Ethereum censorship resistance: helpful properties, but not an escape from hard problems
The bridge proposal leans on Ethereum’s decentralization as a way to get better censorship resistance guarantees, and notes that worst-case recovery exists via social coordination (snapshot / hard fork).
Two collaborative points here:
- I agree Ethereum has strong properties and a huge ecosystem.
- I also think we should be sober that Ethereum has had meaningful censorship pressure in practice (MEV relay dynamics). MEV Watch tracks OFAC-compliant block shares over time.
For Zcash, a privacy-first system, I’d rather treat censorship resistance as a requirement to engineer natively (escape hatches, forced withdrawals, etc.) than as something we “import” from another chain plus a social-recovery story.
Where I think the two proposals can actually meet
This is the part I want to emphasize: we can likely align these paths instead of positioning them as mutually exclusive. (which is not what @Igor did, clarifying for the readers to avoid any confusion)
A reasonable synthesis could be:
- Zcash adds a minimal, pinned verification primitive that is forward-looking (my bias: STARK verification).
- Ztarknet (and other L2s that wish to build on top of Zcash) are one major application of it (native extension, ZEC as base asset, sovereign scaling).
- A trustless bridge to Ethereum can be another application / track (useful interoperability and liquidity routing), built with clear caveats and threat models.
Closing
Again: thank you Igor for putting this forward, and I genuinely want us to collaborate rather than spar. I believe the best outcome for Zcash is that we extend Zcash natively in a sovereign, future-proof way, and bridges can exist as complementary infrastructure rather than as the primary scaling narrative.
