Zama

Name: Zama
Brand: Zama
Rating: 4 (1 reviews)

AI NativeLeader

Zama is an open-source cryptography company that provides developer tools and protocol infrastructure for Fully Homomorphic Encryption (FHE), enabling computation on encrypted data and a confidentiality layer for blockchains to support confidential smart contracts and encrypted on-chain state.

Est 2020|Valuation $840.3M|Raised $175.6M|2 Ref Customers

LinkedIn 2K|Website|Web traffic 6K|FTEs 90|HQ Paris, France

Published Aug 18, 2026

01Common complaints

- When you require a fully audited, production-grade confidentiality solution immediately and cannot wait for mainnet maturity and audit disclosures - When you need a clear, self-serve SaaS price sheet and predictable per-seat or per-API pricing; Zama’s public materials indicate a more enterprise/BD-led approach - When your organization cannot accept commercial patent licensing for code that is otherwise open-source - When your application is highly throughput-sensitive and cannot tolerate the compute overhead of encrypted execution - When your security model cannot accept additional off-chain components (relayers/gateways/coprocessors) or you lack the team to operate and secure them

Deal disqualifiers (poor fit)

Requirement for an immediately audited, production-grade confidentiality solution
Organizational policies that conflict with commercial patent licensing for otherwise open-source code
Use cases where throughput and latency requirements are incompatible with encrypted execution

Vendor-acknowledged limitations

Testnet is explicitly noted in documentation as not audited and not for production use; documentation warns not to publish critical or sensitive data on the testnet

Roadmap sensitivity

Mainnet timelines and token mechanics are subject to change; crypto community reporting and social sources often discuss plans that require direct confirmation from official documentation for enterprise planning

Scale limitations (practical)

FHE is computationally expensive, and scaling typically requires substantial infrastructure investments and careful workload design

Security/compliance gaps

Formal certifications such as SOC 2 or ISO 27001 were not clearly published in the reviewed materials
Public audit reports for protocol components and cryptographic implementations were not located in the gathered sources; this is a key due-diligence item

API / integration constraints

Reliance on relayers, gateways, and off-chain compute introduces additional points of failure and operational burden

02Why they buy

Unique selling points supported by evidence (with caveats)

FHE-based confidential computation: Zama’s tooling is built around FHE, which enables encrypted-state smart contracts in principle
Developer-facing tooling (documentation, SDKs, and guides): documentation is available and has recent updates
Funding and media coverage: major funding rounds and media reports document investor interest and public visibility

Claims that require careful validation

Scalability and TPS claims require independent benchmarking and reproducible methodology
Statements that imply a wide roster of large enterprise customers should be validated against a public customer list or direct references

Areas where competitors have advantages

Competitors with operational mainnets and longer track records may present fewer barriers for teams that need immediate production deployments
ZK-based approaches and TEE-based networks are alternative privacy architectures with different trade-offs in developer UX, trust, and performance

03Field reports

Important limitation: review platforms

Zama is not commonly listed on mainstream B2B review platforms in a product-relevant way. As a result, publicly available feedback is concentrated in:

Developer community posts (Reddit, Hacker News)
GitHub issues and project FAQs (indicating areas of friction)
Partner- or vendor-authored case studies

Community quotes (Reddit)

- "Just tried out the testnet and I'm impressed! … RPC setup was smooth … Active and helpful community … A few minor bugs and challenges." - In a discussion about on-chain blind auctions enabled by fhEVM, a commenter said: "This is low-key a big deal. having privacy from people wanting to see your balances in a tx is actually useful." - A community post noted a reputable security firm joining as an MPC operator and framed that as potentially strengthening security assumptions around the protocol’s key custody. These community contributions are anecdotal and should not be treated as representative of broad customer sentiment.

Vendor/partner-authored case study

A cloud provider customer story describes how Zama used cloud services to operationalize homomorphic encryption at scale. This material is a partner-authored case study and not an independent review. It provides information about infrastructure approach and engineering choices but does not provide independent ROI, cost, or benchmark data.

Common criticisms and complaints observed

Observed criticisms are mainly technical and procurement-oriented rather than consumer-style star ratings:

Testnet and community mentions of bugs and operational challenges consistent with early-stage infrastructure
Documentation warnings that the testnet is not audited and not intended for production
Licensing friction: commercial use requires a commercial patent license, which can complicate procurement and deter some open-source-first organizations

Why customers choose Zama (inferred)

Based on positioning and community discussion, customers choose Zama when they require confidential computation onchain while retaining EVM-compatible patterns, or when they prefer an FHE-based approach instead of migrating to a privacy-specialized chain.

Why some customers might leave (inferred)

Potential reasons for churn compared with alternatives include:

Performance or cost not meeting expectations, given the computational intensity of FHE
Need for a mature mainnet and production-ready guarantees where competitors already provide operational networks
Legal or licensing constraints related to the commercial patent license

Cloud provider customer story: homomorphic encryption

- Source: Partner-authored customer story. - Summary: Describes how the vendor used cloud services to operationalize homomorphic encryption at scale and discusses architectural choices. Critical evaluation: - The case study is partner-authored and should be treated as such; it provides useful detail on infrastructure choices but does not replace independent benchmarks or audited security reports. It does indicate collaboration with a major cloud provider on infrastructure as an operational data point.

Protocol announcements and partnerships

Public posts describe partnerships with security and infrastructure ecosystem participants and position the protocol as a confidentiality layer.

Critical evaluation:

Partnerships can indicate ecosystem engagement but may reflect early-stage collaborations rather than broad production deployments. Operator or partner involvement does not by itself confirm that the entire protocol stack is audited or generically production-safe.

04Best fit

Company sizes

Likely best fit: well-funded startups and mid-market teams with small to mid-sized engineering organizations building crypto protocols or financial applications
Potential fit: enterprises exploring onchain rails (banks, fintechs, infrastructure providers) that can accommodate audit and integration requirements

Industries / verticals

DeFi infrastructure and protocols
Payments and stablecoins
Tokenization and real-world assets
Onchain identity and credentials
Governance and voting systems where coercion resistance or selective disclosure is required

Roles/personas

Decision makers: CTO, Head of Protocol/Engineering, Security lead, Product lead
End users: Solidity developers, cryptography engineers, infrastructure/platform engineers

Pain points Zama addresses

Need to keep balances, amounts, or positions private while leveraging public blockchains
Desire for selective disclosure patterns where privacy and compliance-friendly reveal paths coexist

Qualification criteria (good fit)

Team can tolerate early-stage complexity and commit to security reviews
Use case derives material value from confidentiality rather than privacy being an optional feature
Budget exists for licensing and infrastructure costs

05The pitch

What the product does (objective value proposition)

Zama is an open-source cryptography company developing developer tools and infrastructure for Fully Homomorphic Encryption (FHE), a technique that enables computation on encrypted data without decrypting it. The company’s primary commercial focus is a confidentiality layer for blockchains, enabling confidential smart contracts and encrypted onchain state via the Zama Confidential Blockchain Protocol and fhEVM/FHEVM tooling. Zama’s public positioning includes: - Keeping transaction inputs and smart contract state encrypted end-to-end - Allowing confidential computation while retaining public verifiability via protocol architecture (coprocessors / gateway-style orchestration) - Providing higher-level libraries and SDKs intended to reduce the need for deep cryptography expertise for developers Key product surfaces: - Zama Confidential Blockchain Protocol documentation (developer documentation for building confidential dApps and understanding architecture and governance/token concepts) - fhEVM / FHEVM tooling (libraries, backend services, and SDKs, primarily surfaced via GitHub and documentation)

Target market and market positioning

Zama targets: - Web3 and blockchain teams building DeFi, tokenization/RWA, identity, payments, governance, and other use cases that require confidentiality - Enterprises and institutions that want the transparency of public blockchains while keeping sensitive business logic or data confidential - A broader privacy-preserving computing market (including ML inference on encrypted inputs), although publicly described go-to-market traction has been most evident in blockchain contexts Positioning: Zama positions itself as a confidentiality layer for blockchains (cross-chain) rather than a new L1/L2 chain.

Get a comprehensive analysis of Zama including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Published Aug 18, 2026

01Common complaints

When you require a fully audited, production-grade confidentiality solution immediately and cannot wait for mainnet maturity and audit disclosures
When you need a clear, self-serve SaaS price sheet and predictable per-seat or per-API pricing; Zama’s public materials indicate a more enterprise/BD-led approach
When your organization cannot accept commercial patent licensing for code that is otherwise open-source
When your application is highly throughput-sensitive and cannot tolerate the compute overhead of encrypted execution
When your security model cannot accept additional off-chain components (relayers/gateways/coprocessors) or you lack the team to operate and secure them

Deal disqualifiers (poor fit)

Requirement for an immediately audited, production-grade confidentiality solution
Organizational policies that conflict with commercial patent licensing for otherwise open-source code
Use cases where throughput and latency requirements are incompatible with encrypted execution

Vendor-acknowledged limitations

Testnet is explicitly noted in documentation as not audited and not for production use; documentation warns not to publish critical or sensitive data on the testnet

Roadmap sensitivity

Mainnet timelines and token mechanics are subject to change; crypto community reporting and social sources often discuss plans that require direct confirmation from official documentation for enterprise planning

Scale limitations (practical)

FHE is computationally expensive, and scaling typically requires substantial infrastructure investments and careful workload design

Security/compliance gaps

Formal certifications such as SOC 2 or ISO 27001 were not clearly published in the reviewed materials
Public audit reports for protocol components and cryptographic implementations were not located in the gathered sources; this is a key due-diligence item

API / integration constraints

Reliance on relayers, gateways, and off-chain compute introduces additional points of failure and operational burden

02Why they buy

Unique selling points supported by evidence (with caveats)

FHE-based confidential computation: Zama’s tooling is built around FHE, which enables encrypted-state smart contracts in principle
Developer-facing tooling (documentation, SDKs, and guides): documentation is available and has recent updates
Funding and media coverage: major funding rounds and media reports document investor interest and public visibility

Claims that require careful validation

Scalability and TPS claims require independent benchmarking and reproducible methodology
Statements that imply a wide roster of large enterprise customers should be validated against a public customer list or direct references

Areas where competitors have advantages

Competitors with operational mainnets and longer track records may present fewer barriers for teams that need immediate production deployments
ZK-based approaches and TEE-based networks are alternative privacy architectures with different trade-offs in developer UX, trust, and performance

03Field reports

Important limitation: review platforms

Zama is not commonly listed on mainstream B2B review platforms in a product-relevant way. As a result, publicly available feedback is concentrated in:

Developer community posts (Reddit, Hacker News)
GitHub issues and project FAQs (indicating areas of friction)
Partner- or vendor-authored case studies

Community quotes (Reddit)

"Just tried out the testnet and I'm impressed! … RPC setup was smooth … Active and helpful community … A few minor bugs and challenges."
In a discussion about on-chain blind auctions enabled by fhEVM, a commenter said: "This is low-key a big deal. having privacy from people wanting to see your balances in a tx is actually useful."
A community post noted a reputable security firm joining as an MPC operator and framed that as potentially strengthening security assumptions around the protocol’s key custody.

These community contributions are anecdotal and should not be treated as representative of broad customer sentiment.

Vendor/partner-authored case study

Common criticisms and complaints observed

Observed criticisms are mainly technical and procurement-oriented rather than consumer-style star ratings:

Testnet and community mentions of bugs and operational challenges consistent with early-stage infrastructure
Documentation warnings that the testnet is not audited and not intended for production
Licensing friction: commercial use requires a commercial patent license, which can complicate procurement and deter some open-source-first organizations

Why customers choose Zama (inferred)

Why some customers might leave (inferred)

Potential reasons for churn compared with alternatives include:

Performance or cost not meeting expectations, given the computational intensity of FHE
Need for a mature mainnet and production-ready guarantees where competitors already provide operational networks
Legal or licensing constraints related to the commercial patent license

Cloud provider customer story: homomorphic encryption

Source: Partner-authored customer story.
Summary: Describes how the vendor used cloud services to operationalize homomorphic encryption at scale and discusses architectural choices.

Critical evaluation:

The case study is partner-authored and should be treated as such; it provides useful detail on infrastructure choices but does not replace independent benchmarks or audited security reports. It does indicate collaboration with a major cloud provider on infrastructure as an operational data point.

Protocol announcements and partnerships

Public posts describe partnerships with security and infrastructure ecosystem participants and position the protocol as a confidentiality layer.

Critical evaluation:

Partnerships can indicate ecosystem engagement but may reflect early-stage collaborations rather than broad production deployments. Operator or partner involvement does not by itself confirm that the entire protocol stack is audited or generically production-safe.

04Best fit

Company sizes

Likely best fit: well-funded startups and mid-market teams with small to mid-sized engineering organizations building crypto protocols or financial applications
Potential fit: enterprises exploring onchain rails (banks, fintechs, infrastructure providers) that can accommodate audit and integration requirements

Industries / verticals

DeFi infrastructure and protocols
Payments and stablecoins
Tokenization and real-world assets
Onchain identity and credentials
Governance and voting systems where coercion resistance or selective disclosure is required

Roles/personas

Decision makers: CTO, Head of Protocol/Engineering, Security lead, Product lead
End users: Solidity developers, cryptography engineers, infrastructure/platform engineers

Pain points Zama addresses

Need to keep balances, amounts, or positions private while leveraging public blockchains
Desire for selective disclosure patterns where privacy and compliance-friendly reveal paths coexist

Qualification criteria (good fit)

Team can tolerate early-stage complexity and commit to security reviews
Use case derives material value from confidentiality rather than privacy being an optional feature
Budget exists for licensing and infrastructure costs

05The pitch

What the product does (objective value proposition)

Zama’s public positioning includes:

Keeping transaction inputs and smart contract state encrypted end-to-end
Allowing confidential computation while retaining public verifiability via protocol architecture (coprocessors / gateway-style orchestration)
Providing higher-level libraries and SDKs intended to reduce the need for deep cryptography expertise for developers

Key product surfaces:

Zama Confidential Blockchain Protocol documentation (developer documentation for building confidential dApps and understanding architecture and governance/token concepts)
fhEVM / FHEVM tooling (libraries, backend services, and SDKs, primarily surfaced via GitHub and documentation)

Target market and market positioning

Zama targets:

Web3 and blockchain teams building DeFi, tokenization/RWA, identity, payments, governance, and other use cases that require confidentiality
Enterprises and institutions that want the transparency of public blockchains while keeping sensitive business logic or data confidential
A broader privacy-preserving computing market (including ML inference on encrypted inputs), although publicly described go-to-market traction has been most evident in blockchain contexts

Positioning: Zama positions itself as a confidentiality layer for blockchains (cross-chain) rather than a new L1/L2 chain.

Get a comprehensive analysis of Zama including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →