Zero-Knowledge Proofs on Ethereum – Can Privacy Be Default—and Comply?

Strong Hook

I stood at a conference booth watching a demo where a wallet whispered: your next transfer can be private by default, no extra steps required. The screen didn’t boast about exotic cryptography; it showed a simple toggle, a shield icon, and a user flow that felt almost human. If privacy could slip into the everyday, what would that do to how we transact, collaborate, and prove who we are on-chain? The question wasn’t just technical. It was about trust, usability, and whether a world where privacy is the default could coexist with regulators, auditors, and everyday users who want a clear sense of what’s happening with their data.

Problem/Situation Presentation

Today’s Ethereum ecosystem is balancing two powerful forces: the demand for privacy and the demand for accountability. Institutions want confidential activity where it makes sense, but they also expect guardrails that prevent illicit use and enable compliance. The regulatory landscape evolved quickly in 2025, with significant developments like official enforcement signals around privacy tooling and the continuing push for selective disclosure and auditable privacy. Reports captured a broad shift: privacy-by-default is moving from a collection of edge-case tools to a cross-cutting design philosophy across wallets, apps, and identities. In practical terms, that means wallet UX that protects sensitive data by default, unless you explicitly reveal it to a DApp, service provider, or regulator. For many developers and leaders, this is not only a technology choice but a product and governance choice.

As background, the Ethereum Foundation began elevating privacy to a core property of the ecosystem—forming a dedicated privacy cluster and supporting a wallet-first privacy layer named Kohaku. Independent coverage has echoed this trajectory, framing it as a shift toward mainstream privacy that must also remain compatible with compliance and neutrality. Read the Ethereum Foundation’s privacy commitment and Kohaku roadmap; industry coverage corroborates a broader ecosystem push. (CoinDesk coverage)

Value of This Article

This piece maps the current privacy-by-default landscape on Ethereum: what technologies exist, how they interlock, and what regulatory realities mean for product design. You’ll get a practical tour of Kohaku (wallet-first privacy), ZK² rollups from Aztec, StarkNet’s S-two approach with Garaga, and the cross-cutting concerns that push privacy from a lab concept into user-friendly experiences. By the end, you’ll see how a developer or business leader can begin wiring privacy-by-default into real products—without waiting for a perfect sunset of risk or a perfectly compliant world.

A snapshot of the tech and the tone the market is adopting

• Kohaku aims to normalize privacy at the wallet layer, offering per-DApp accounts, shielded transfers, and recovery flows, all designed to meet compliance expectations while preserving privacy by default. The goal is not a niche feature, but a default user experience. (Ethereum blog)
• ZK² Rollups from Aztec promise private transactions at scale through a two-layer proving architecture, seeking to keep confidentiality intact as throughput grows. The testnet is live and enterprise interest has been rising. (Aztec blog)
• StarkNet’s S-two prover and Garaga tooling point toward client-side proving and multi-language privacy tooling, broadening the ecosystem for private-by-default apps. (StarkWare)
• The regulatory backdrop remains a critical factor: events like the Tornado Cash delisting in 2025 highlight the need for built-in compliance controls alongside privacy features. (Reuters)
• The Polygon zkEVM situation also shapes downstream strategy, with official sunsetting planned for 2026 and implications for cross-chain privacy pathways. (Polygon docs)

The Landscape of Privacy-by-Default on Ethereum

Privacy-by-default isn’t about turning off data visibility in a vacuum; it’s about reimagining how data is handled, stored, and revealed. A wallet-centric approach envisions a world where you operate with two modes: private by default when interacting with most DApps, and private-on-demand when selective data needs to be shared with a service, auditor, or regulator. The practical trail to this future is multi-layered:

• Wallet UX as the primary battleground: Kohaku’s model treats privacy as a first-class property in the wallet, not a behind-the-scenes feature. If users don’t see the value or complexity, they’ll disable privacy by default. The design challenge is to provide robust privacy without sacrificing recoverability or usability.
• Layered privacy technologies: ZK², S-two, and related tools aim to keep data private at scale, while still enabling verifiable, auditable outcomes. The idea is to separate the data that needs to be private from the proofs that verify the correct behavior, enabling institutions to rely on on-chain proofs without exposing sensitive details.
• Compliance through selective disclosure: Privacy-by-default should also support compliance workflows, where a verifier can access only the minimum necessary information, potentially via portable proofs or identity primitives. The ecosystem has begun incorporating selective disclosure concepts and portable proof tooling into mainstream product plans.
• Regulatory realities: With the Tornado Cash delisting and ongoing regulatory debates, privacy tech is increasingly required to offer built-in governance and screening capabilities, to satisfy risk controls without collapsing privacy benefits. This is not mere “privacy vs. compliance” rhetoric; it’s a practical design constraint that will shape product roadmaps. (Reuters coverage)
• Ecosystem dynamics: The privacy roadmap isn’t owned by a single project. Aztec, StarkNet, Kohaku, Privacy Pools, Railgun, Semaphore, and MACI are part of a broader ecosystem push toward default privacy, with cross-layer integration and evolving governance. (Aztec)

Core technologies to watch (and why they matter for products)

• Kohaku: Privacy-by-default wallet framework. It’s the practical blueprint for enabling private modes alongside per-DApp accounts and shielded transfers, with recovery flows designed to preserve privacy. This is the bridge between cryptography and real user behavior. (Ethereum blog)
• ZK² Rollups (Aztec): A multi-layer design that could unlock private DeFi and private transactions at scale, potentially changing how opaque data becomes auditable without exposure. The public testnet activity and enterprise interest are notable signals. (Aztec blog)
• StarkNet S-two and Garaga: Client-side proving, multi-language tooling, and verifiers generated automatically to reduce barriers for privacy-focused apps. This expands the practical toolkit for developers who want private-kernel logic across ecosystems. (StarkWare)
• Privacy Pools and Railgun: Privacy-preserving pools and shielded flows with built-in compliance controls, reflecting an industry push toward enterprise-friendly privacy tooling. These are practical, real-world examples of how privacy and compliance can coexist. (Coindesk coverage)
• Selective disclosure and portable proofs (Semaphore, MACI, ZKEmail, zkID): Building blocks for privacy-preserving identity and governance, enabling controlled data sharing without revealing everything. (Semaphore docs)

Practical Takeaways for Builders

• Start with a Kohaku-like wallet mental model: design for private-by-default by default, with clear, user-friendly controls to reveal data only when necessary.
• Plan multi-layer privacy integration: leverage ZK² rollups for scalable privacy and StarkNet tooling for cross-language support, but ensure the UX abstracts complexity away from users.
• Build in compliance hooks early: screening, auditable proofs, and controlled disclosures can be embedded in the privacy toolkit to meet enterprise risk requirements without breaking the privacy promise.
• Stay agile with regulatory shifts: regulatory signals around privacy tools are evolving. Design with adaptable governance and modular privacy components so you can pivot as policies emerge. The Tornado Cash delisting episode is a reminder that policy environments will shape feature sets and risk management strategies. (Reuters)
• Consider cross-chain implications: with Polygon’s zkEVM sunset and broader cross-chain privacy work, plan for interoperability and migration routes so privacy propositions don’t become siloed to a single chain.

Critical Questions to Ponder

• If privacy becomes a Wallet Feature by default, who gets to decide what is private in everyday transactions, and who remains responsible for safeguarding those decisions?
• How can we ensure that private proofs remain auditable and trustworthy in the eyes of regulators, clients, and end-users without eroding the privacy benefits themselves?
• What governance models best balance user agency, developer innovation, and institutional risk controls in a privacy-forward Ethereum?

Final Reflection

The arc from niche privacy tooling to an ecosystem-wide, user-friendly default privacy is a story of translating deep cryptography into everyday experience. It’s about wallets that protect what users don’t want to share by default, while still offering pragmatic levers for disclosure when needed. As this journey unfolds, the question isn’t merely whether privacy can be default. It’s how we design a shared future where privacy, trust, and responsibility coexist in a transparent, understandable way. And perhaps the most intriguing question remains: in a world where privacy flows through every transaction, who gets to define what “private” really means for you, your organization, and your community?

Zero-Knowledge Proofs on Ethereum in 2025–2026: Privacy-by-Default for Compliance and Privacy

I stood at a conference booth, watching a wallet demo where a simple toggle whispered that a transfer could be private by default. No smoke, no mirrors—just a shield icon and a workflow that felt almost human. If privacy could slip into everyday use, what would that change about how we transact, collaborate, and prove who we are on-chain? The question wasn’t just technical. It was about trust, usability, and whether a world where privacy is the default could coexist with regulators, auditors, and ordinary users who want to understand what is happening with their data.

Why privacy-by-default matters now

Two forces are converging in the Ethereum ecosystem. First, the Ethereum Foundation has elevated privacy from a niche capability to a core design principle, forming a privacy cluster and backing wallet-centric privacy initiatives like Kohaku. The goal is clear: make privacy a first class property of wallets, apps, and identities, not something tucked away in experimental tooling. You can read the Ethereum Foundation’s privacy commitment for the most concrete framing, and you’ll see Kohaku positioned as a practical wallet-first privacy layer. Read the Ethereum blog on privacy commitment.

Second, the regulatory and enterprise landscape is shaping how privacy is implemented in practice. Privacy tools are no longer theoretical; institutions want configurable privacy with auditability and controllable disclosures. Coverage across mainline outlets has painted a picture of a broader shift toward privacy by default as a design pattern, not a niche feature. This isn’t just about hiding data; it’s about enabling compliant, trustworthy on-chain activity. For context, see the industry reporting around the privacy push and the growing enterprise interest in privacy tooling. CoinDesk coverage of the privacy push.

In practical terms, that means wallets should operate with privacy by default, and selective disclosure should be a deliberate, user-friendly option rather than a hidden capability. The ecosystem is moving toward this reality through a multi-layered approach: private transaction layers, privacy-preserving identity, and portable proofs that let you demonstrate compliance without exposing sensitive data.

The core technologies shaping privacy by default

• Kohaku: privacy by default at the wallet level

• Kohaku envisions a modular wallet framework that supports private modes by default, per-DApp accounts, optional shielded transfers, and recovery flows that preserve privacy. It’s about turning privacy into a predictable UX, not a cryptography backstage pass. The Ethereum blog outlines Kohaku as part of a broader privacy initiative that connects user experience to compliance needs. Kohaku and privacy in practice

• ZK² Rollups: private throughput at scale

• Aztec has detailed a two-layer proving approach designed to keep data private while increasing throughput. The idea is to cluster private transactions under rollup proofs, then compose many such proofs into an auditable, scalable system. The testnet is active and enterprise interest is rising as organizations seek confidential on-chain activity. Aztec on ZK² rollups

• StarkNet S-two and Garaga: client-side proving and cross-language privacy tooling

• S-two promises private proving that can run client-side, enabling private transactions and private data flows within StarkNet. Garaga is tooling that helps generate Cairo verifiers from Noir, lowering the barrier for privacy-focused apps to run across ecosystems. This expands the practical toolkit for developers aiming to ship private-by-default apps. StarkWare on S-two

• Privacy pools, rails, and selective disclosure tooling: Railgun, Privacy Pools, Semaphore, MACI

• These projects illustrate real-world approaches to privacy with built-in compliance controls. They support shielded transfers, selective disclosure, and governance mechanisms that can be coordinated with enterprise risk controls. Coverage in industry outlets highlights their momentum and practical relevance. Privacy tools coverage

• Selective disclosure and portable proofs: zkID, ZKEmail, zkPassport concepts

• The privacy cluster is consolidating identity primitives that let you prove attributes or qualifications without revealing the underlying data. These concepts are becoming core components of enterprise-ready on-chain identity and access management.

The regulatory and ecosystem backdrop

The privacy discussion cannot ignore policy dynamics. A notable development in 2025 was the delisting of Tornado Cash by OFAC, a signal that regulators are pushing for governance and risk controls around privacy tooling. This event has influenced how teams design privacy features, nudging them to incorporate screening and auditable controls to align with compliance expectations. Tornado Cash delisting coverage.

Another moving piece is Polygon’s zkEVM journey, with official plans to sunset zkEVM by 2026. This shapes policy and engineering decisions about where privacy tooling will cluster across ecosystems and how cross-chain privacy capabilities will evolve. Polygon zkEVM sunset notice.

Vitalik Buterin has reiterated a practical privacy roadmap focused on wallet-level privacy and default shielded flows, reinforcing the product design imperative for privacy-by-default. Industry outlets covered this practical orientation as a key driver for developers and product teams. Vitalik’s privacy roadmap coverage.

A practical product architecture for privacy by default

What does a privacy-by-default wallet-first architecture look like in real products? A useful mental model is two modes: private by default and private on demand. The UX should make it obvious how and when data is revealed, with safeguards that prevent accidental leakage.

• Wallet UX as the primary battleground
• The design challenge is to present strong privacy without sacrificing recoverability or usability. Kohaku embodies this push by integrating private by default with recoverable, user-friendly flows.
• Layered privacy technologies
• Combine private transaction layers (ZK² rollups) with client-side proving (S-two) and multi-language tooling (Garaga) so developers can build privacy at scale without requiring cryptography PhDs. The outcome is private outcomes that can still be verified publicly.
• Compliance through selective disclosure
• Privacy-by-default should enable verifiers to access only the minimum necessary information, via portable proofs or identity primitives. This is where zkID, zkEmail, and related mechanisms come into play.
• Governance and risk controls
• Built-in governance hooks, whitelisting/blacklisting, and screening features are becoming standard in privacy toolchains to satisfy enterprise risk management and regulator expectations.
• Cross-chain interoperability
• With shifts like Polygon’s zkEVM timeline, it is important to architect privacy so that users and apps can migrate or interoperate across chains without losing privacy guarantees.

A hands-on playbook you can try now

If you want to translate this into a practical blueprint, here is a compact, actionable plan you can start implementing today.

1) Define privacy by default policy for your product
– Decide what data is private by default, what needs to be disclosed, and under which conditions. Map data flows from user action to on-chain proof.
– Align with regulatory expectations by identifying selective disclosure points and audit hooks.

2) Integrate a Kohaku-like wallet model
– Build or adopt a wallet framework that supports per-DApp accounts, default shielded transfers, and simple recovery options that do not expose private data by default.
– Ensure the user interface clearly communicates privacy state and data disclosure controls.

3) Layer in a ZK privacy backbone
– Start with a ZK² rollup approach for private transactions and gradually layer in additional privacy features as you scale.
– Use testnets to validate private transaction flows and throughput, gradually introducing enterprise-oriented features like selective disclosures.

4) Enable client-side proving and multi-language tooling
– Explore S-two style client-side proving to move proving work closer to the user, enabling faster, more private interactions.
– Leverage Garaga or similar tooling to generate verifiers across languages, lowering the barrier to multi-platform privacy apps.

5) Build in compliance controls from day one
– Add screening logic, auditable proofs, and controlled disclosures that regulators and institutions expect.
– Document data handling and governance policies for external auditors.

6) Prepare for cross-chain realities
– Design with interoperable privacy by default in mind, so you can migrate or adapt as ecosystems shift (for example, as zkEVM plans evolve on Polygon or as cross-chain privacy tooling matures).

7) Test, iterate, and publish user stories
– Run user tests focusing on understanding privacy states and data disclosure controls.
– Publish practical case studies showing how privacy-by-default improves trust and compliance outcomes.

Practical insights for builders and leaders

• Start with a wallet-centric narrative: users should feel privacy as a feature, not a hidden capability. Kohaku-like UX is the bridge between cryptography and everyday usage.
• Treat privacy as a product experience, not only a technical feature: privacy flows should be intuitive, recoverable, and auditable.
• Build for compliance as a feature, not a bolt-on: think about selective disclosure, portable proofs, and governance hooks early in the design.
• Stay adaptable: regulatory signals will continue to evolve; modular privacy components help you pivot without overhauling the entire stack.

What to watch next in the privacy-by-default landscape

• Kohaku and privacy cluster developments: wallet-first privacy, two-factor protection, and enterprise onboarding flows. Ethereum privacy commitment
• ZK² rollups and the practical path to privacy at scale: testnet activity and enterprise pilots. Aztec ZK² rollup
• Client-side proving and cross-language tooling in StarkNet: expanding privacy deployment options. StarkWare S-two
• Regulatory context and governance: the Tornado Cash delisting and related policy developments. Reuters coverage
• Cross-chain privacy trajectories and ecosystem shifts like zkEVM sunsets on other chains. Polygon zkEVM sunset

Final reflections and opening questions

• If privacy becomes a wallet feature by default, who decides what stays private in everyday transactions, and who is responsible for safeguarding those decisions?
• How can we ensure that private proofs stay auditable and trustworthy for regulators, clients, and end users without eroding privacy benefits themselves?
• Which governance models best balance user agency, developer innovation, and institutional risk controls in a privacy-forward Ethereum?

This journey of turning cryptography into everyday experience is about more than private data; it is about trust, clarity, and responsibility. The challenge is not only to make privacy possible, but to make it inevitable in a way that is understandable, actionable, and compliant. The next frontier is a world where privacy-by-default is not a fringe feature but the everyday baseline for how we transact, verify, and prove who we are on-chain.

Further reading and anchors for deeper exploration:
– Ethereum Foundation privacy commitment and Kohaku roadmap: https://blog.ethereum.org/2025/10/08/privacy-commitment
– Aztec ZK² rollup progress and testnet activity: https://aztec.network/blog/aztec-fast-privacy-with-zk2-rollup?utm_source=openai
– StarkNet S-two and Garaga tooling: https://starkware.co/blog/s-two-prover/?utm_source=openai
– Tornado Cash regulatory context and delisting: https://www.reuters.com/business/finance/us-scraps-sanctions-tornado-cash-crypto-mixer-accused-laundering-north-korea-2025-03-21/?utm_source=openai
– Polygon zkEVM sunset timeline: https://docs.polygon.technology/zkEVM/overview/?utm_source=openai

I stood at a conference booth, watching a wallet demo where a simple toggle whispered that a transfer could be private by default. No smoke, no mirrors—just a shield icon and a human-centered flow that felt almost easy. If privacy could slip into everyday use, what would that change about how we transact, collaborate, and prove who we are on-chain? The question wasn’t merely technical. It was about trust, usability, and whether a world where privacy is the default could coexist with regulators, auditors, and everyday users who want a transparent sense of what’s happening with their data.

Two forces are converging in the Ethereum ecosystem. On one hand, the Ethereum Foundation has raised privacy from a niche capability to a core design principle, backing wallet-centric privacy initiatives like Kohaku. The aim isn’t to hide data as a gimmick but to bake privacy into the everyday wallet experience—without abandoning recoverability or usability. On the other hand, the regulatory and enterprise landscape is insisting on configurable privacy with auditability and controllable disclosures. In practice, this means a design pattern where wallets operate with privacy by default, and selective disclosure is a deliberate, user-friendly toggle rather than a hidden capability. You can see this trajectory echoed in Kohaku’s wallet-first framing, ZK² rollups for scalable private throughput, and the broader ecosystem push toward auditable privacy that still respects user agency. (For context, review the Ethereum Foundation’s privacy commitment; Aztec and StarkNet are actively building the practical toolchains; and coverage from Reuters and CoinDesk traces how policy signals shape product roadmaps.)

What this means for product teams isn’t merely “use cryptography” but a deliberate shift in product design: privacy as a first-class UX property, not an afterthought tucked into advanced settings. The landscape is multi-layered—privacy at the wallet level (Kohaku), private transaction layers that scale (ZK² rollups), client-side proving and cross-language tooling (S-two and Garaga), and real-world compliance controls baked into the toolchain (selective disclosure, auditable proofs, governance hooks). It’s not a lone project; it’s an ecosystem-wide reimagining that must stay responsive to regulatory shifts, like the Tornado Cash delisting, while still enabling auditable trust. (Key sources: Ethereum’s privacy commitment; Aztec’s ZK² roadmap; StarkNet’s S-two insights; ongoing policy developments reported by Reuters.)

Core technologies to monitor aren’t abstract abstractions; they’re design primitives that shape your product’s philosophy and its users’ experiences:
– Kohaku: a wallet-layer approach that makes privacy by default visible, usable, and recoverable. This is the pragmatic bridge between cryptography and everyday behavior.
– ZK² Rollups: a multi-layer approach aiming to keep data private at scale while preserving verifiability and throughput.
– StarkNet’s S-two and Garaga: client-side proving and cross-language tooling that lowers the barrier to building private-by-default apps across ecosystems.
– Privacy pools, rails, and selective disclosure tooling: real-world mechanisms for shielding data while enabling governance and risk controls.
– Portable proofs and identity primitives (zkID, zkEmail, zkPassport concepts): building blocks for privacy-preserving identity and compliance workflows.

Practical takeaways for builders
– Start with a Kohaku-like wallet mindset: privacy should be a default, with clear controls to reveal data only when needed.
– Plan a layered privacy strategy: leverage private transaction layers for scale, while keeping UX and accessibility front and center.
– Build in compliance hooks from day one: screening, auditable proofs, and controlled disclosures should be native, not bolted on later.
– Stay adaptable to policy shifts: modular privacy components can pivot as regulations evolve, so design governance and data flows with flexibility.
– Expect cross-chain realities: as ecosystems shift (for example, Polygon’s zkEVM sunset plans), build interoperability into the privacy fabric so users aren’t locked into a single chain.

A compact playbook you can start today
1) Define your privacy default policy: decide what stays private by default, what must be disclosed, and under which conditions. Map data flows from user action to on-chain proof.
2) Embrace a Kohaku-like wallet model: two-factor-like privacy states, per-DApp accounts, and simple recovery that doesn’t require exposing sensitive data.
3) Layer in a ZK privacy backbone: begin with a ZK² approach for private transactions, validating throughput and privacy in tandem, with enterprise considerations in mind.
4) Move proving closer to the user: explore client-side proving concepts (S-two) and tooling that generates verifiers across languages (Garaga) to reduce friction.
5) Bake in compliance controls: implement screening logic, portable proofs, and auditable disclosure primitives to satisfy regulators without compromising user privacy.
6) Prepare for cross-chain reality: design with interoperability in mind so privacy stays intact across migrations and chain transitions.
7) Test, share, and iterate: gather user stories that demonstrate how default privacy increases trust and reduces cognitive load, then publish practical findings to guide others.

Final reflection and invitation
If privacy becomes the default across wallets and apps, who gets to decide what stays private in everyday life, and who bears the responsibility for safeguarding those choices? How can we keep private proofs both auditable and trustworthy without eroding their privacy benefits? These aren’t merely engineering questions—they’re governance questions about who we want to be as a community, as developers, and as users. The era of privacy-by-default isn’t a future bonus; it’s an invitation to redesign trust itself in the on-chain world.

So, what will you build, starting today? If this resonates, try mapping your data flows and drafting a privacy-default policy for your product. Run a small pilot with Kohaku-like UX, add a ZK²-backed privacy layer, and begin integrating selective disclosure so auditors can see what matters without seeing everything. Start the conversation with your team, your users, and your regulators. The best time to begin is now, because privacy-by-default isn’t a feature you flip on later—it’s a product principle you design into your everyday decisions.

Closing question
In a world where privacy threads through every transaction, what does “private” mean for you, your organization, and your community—and who gets to decide that in practice?