Building Real Applications With Zero-Knowledge Proofs and FHE in 2026: A Pragmatic Guide

Zero-knowledge proofs and fully homomorphic encryption crossed a line in the last two years. Apple documents production homomorphic-encryption use cases for private lookup and machine learning. Google Wallet proves age with a zero-knowledge proof. Proving an entire Ethereum block now takes seconds, not minutes. And yet projects that start with "let's use ZK" or "let's use FHE" often fail because the technology was never the right first question. This guide is the decision framework we use before writing a single circuit: when these tools make sense, how to estimate their cost in 2026, and the five ways teams burn budget on them.

Engineering perspective, not a vendor pitch. Published measurements are sourced; planning ranges are explicitly labeled as Wavect rules of thumb and must be validated against the target workload. Reference points come from Wavect's zero-knowledge and frontier-tech work.

What do ZK and FHE give you that normal encryption does not?

Standard encryption protects data at rest and in transit. The moment you want to do something with the data, you decrypt it, and whoever runs the computation sees everything. Privacy-enhancing technologies close that gap, each in a different way:

• Zero-knowledge proofs (ZK) let one party prove a statement is true without revealing why. "I am over 18" without showing the birthdate. "This computation ran correctly" without re-running it. ZK is about verifiability with selective disclosure.
• Fully homomorphic encryption (FHE) lets a server compute on data it cannot read. The input arrives encrypted, the computation runs encrypted, the result returns encrypted. FHE is about outsourced computation on data the operator must never see. See our glossary entry for the basics.
• Secure multi-party computation (MPC) lets several parties jointly compute over inputs none of them will share, at the cost of heavy network traffic between them.
• Trusted execution environments (TEE) run code inside a hardware-isolated enclave. Near-native speed, but you trust the chip vendor and the absence of side-channel attacks.

Think of it as a set of different trust boundaries, not a strict ladder. ZK and FHE rely on cryptographic assumptions plus the correctness of implementations, compilers, circuits, parameters, and key handling. MPC adds a protocol-specific threshold and non-collusion assumption. A TEE adds trust in the hardware, firmware, attestation chain, and resistance to side channels. A plain database asks you to trust the operator and its controls. The engineering question is not "which is most secure", it is "which assumptions match the threat model and workload". We compare all four in depth in ZK vs FHE vs MPC vs TEE.

Do you actually need this? Run the decision tree first.

The most expensive mistake in this field is cryptographic overkill. Before any of these technologies enters your architecture, answer four questions honestly:

1. Do your users trust you to see their data? If yes, and the law allows it, use a database, access control, TLS, and encryption at rest. That is not a compromise, it is the correct architecture for the vast majority of products. PETs solve trust problems. If there is no trust problem, they solve nothing and cost plenty.
2. Does a third party need to verify something without seeing the underlying data? Age checks, solvency proofs, credential checks, "this code ran correctly". That is ZK territory, and it is the most mature of the options. Our deep dive: what is actually production-ready in ZK.
3. Must an untrusted party compute on data it may never see? A cloud service processing health records, a lookup against a server database that should learn nothing about the query. That is FHE or MPC territory, and it only works if the workload is small and well-defined. Reality check: what ships and what is still hype in FHE.
4. Is "we cannot see your data" a core product promise or a regulatory requirement, rather than a nice-to-have? If it is a nice-to-have, a TEE gives you most of the story at roughly native speed. If it is the product, budget for real cryptography and the engineering that comes with it.

Notice the pattern: the technology choice falls out of the trust model, not the other way around. Teams that start from "we want to use FHE" and search for a problem afterwards are the ones that end up in the failure list below.

"If your users trust you to see their data, a database beats a cryptosystem. The interesting projects are the ones where that trust is structurally impossible."

What is actually running in production in 2026?

This is not a research field anymore. A short list of deployments you can point your board to, each with a lesson attached:

Two things stand out. First, the clearest publicly documented HE deployments focus on a private lookup or a narrow computation, not "run our whole backend encrypted". Second, many successful ZK deployments hide a single sensitive fact behind a proof rather than making an entire application zero-knowledge. Scope discipline is the common denominator.

What does it cost? The 2026 numbers.

Rules of thumb we use in architecture reviews. These are order-of-magnitude figures for planning, and each deep-dive post carries the precise sourced numbers:

The asymmetry matters more than the absolute numbers. ZK is expensive once for the prover and nearly free for every verifier afterwards, which is why it fits "prove once, verify everywhere" products. FHE is expensive on every single operation, which is why it fits small, high-stakes computations and nothing else yet. If someone quotes you FHE benchmarks that look too good, check whether they are quoting an MPC paper. Mixing those two up is the single most common error in content about this space, and we unpack it in the FHE deep dive.

What are the five ways these projects fail?

We have seen or reviewed each of these. They fail in predictable ways:

• 1. Cryptography where a login would do. The team ships ZK proofs between services that all belong to the same company. There is no adversary in the threat model. The result is a slower, more expensive system with an impressive architecture diagram. If you trust the operator, use access control.
• 2. Under-constrained circuits. A common and critical ZK vulnerability is a circuit that accepts proofs it should reject because a constraint is missing. Research tooling like zkFuzz found dozens of such bugs in 2025, including eleven in the widely used zk-regex component of zkEmail (zkFuzz, arXiv 2025). A ZK system without circuit audits and fuzzing is not a security product, it is a liability.
• 3. Trusted-setup shortcuts. The first documented ZK exploits in the wild were not exotic math, they were mishandled Groth16 trusted setups (zkSecurity). In 2026 you rarely need a per-application trusted setup. Prefer a transparent system or a widely scrutinized universal setup when it meets the product's proof-size, verifier, and ecosystem requirements.
• 4. Privacy tech, consent failure. Apple shipped Enhanced Visual Search with genuinely strong cryptography (FHE plus differential privacy), then turned it on by default without asking users, and took a public backlash in January 2025 (The Register). Perfect math does not replace an opt-in dialog. Regulators and users judge the consent flow, not the lattice parameters.
• 5. FHE without an end-to-end benchmark. Primitive-level speedups do not guarantee an interactive product. Serialization, ciphertext expansion, key switching, bootstrapping, network transfer, and the full operation mix determine whether the latency closes. Start with lookups, matching, scoring, or a narrow model, measure the complete request path, and keep a TEE fallback if the product has a hard latency budget.

How do you scope a first project that survives contact with reality?

The pattern that works, distilled from the deployments above:

1. Isolate the single secret that matters. Not "make the app private", but "the server must never learn the phone number being looked up" or "the venue must never learn the birthdate". One sentence, one secret, one verifier.
2. Put only that on the expensive path. In Apple's documented pattern, the rest of the application stays conventional and the private lookup is the bounded HE step. In Google's pattern, the age check is the bounded ZK step.
3. Pick maintained tooling, then benchmark it. For ZK in 2026 that means a Rust zkVM (SP1, RISC Zero) or Noir rather than hand-written circuits. For FHE, start with TFHE-rs for encrypted logic and Apple's Swift library for BFV lookups. CKKS no longer has one safe performance default: benchmark Poulpy, Lattigo, SEAL, and OpenFHE on CPU, plus a GPU-native option such as FIDESlib when relevant. The ZK post and FHE post carry the full tooling tables and lifecycle notes.
4. Budget for the audit, not just the build. A circuit audit plus fuzzing is a fixed cost of shipping ZK. Skipping it is how bounty writeups get written about you. RISC Zero paid out a 50,000 dollar bounty for a bug found after prior audits, which tells you how hard this is even for the best teams.
5. Have the fallback conversation early. If latency or cost does not close, evaluate a TEE against the threat model and regulatory requirements. Deciding early is much cheaper than changing course after deep integration.

One more driver worth naming: regulation is pulling this field forward. Every EU member state must offer a digital identity wallet by the end of 2026 under eIDAS 2.0, with selective disclosure central to the design. The European Health Data Space requires controlled access, secure processing environments, and strong data protection for secondary use, but it does not prescribe ZK, FHE, or MPC as a universal implementation. If you sell into the EU, map the required property to the simplest architecture that satisfies it and confirm the legal interpretation with counsel. The decision-framework post maps regulations to concrete technology choices.

Sources and verification

1. Apple Machine Learning Research (2024). Production homomorphic-encryption use cases and private lookup design. machinelearning.apple.com
2. Google (2025). Open-source zero-knowledge technology for age assurance. blog.google
3. Microsoft Research (2021). Homomorphic encryption in Edge Password Monitor. microsoft.com
4. Mopro (2026). Mobile and browser proving benchmarks. zkmopro.org
5. zkFuzz (2025). Differential fuzzing results across public ZK circuits. arxiv.org
6. zkSecurity (2026). Documented Groth16 setup exploits. zksecurity.xyz