Introduction
Zama is one of the leading companies in FHE. Across its $73M Series A and $57M Series B, it has raised roughly $130M in total. The protocol is now in its mainnet phase, and it is increasingly discussed as one of the most credible attempts to bring confidential computation to public blockchains.
Omakase has also been selected as one of the 13 MPC partners in the Zama Protocol. That context matters, but the purpose of this article is still to explain the stack itself: what FHE is, how it differs from ZK, how the architecture works, and why Zama looks important in the broader privacy landscape.
This article covers four questions:
- What is FHE, and how is it different from ZK?
- Why does Zama look like a strong candidate in the privacy space?
- How does the Zama Protocol work, including the design role of $ZAMA?
- What should users and developers pay attention to next?
What FHE is, and how it differs from ZK
FHE, or Fully Homomorphic Encryption, is a cryptographic technique that allows computation on encrypted data. In ordinary encryption systems, arbitrary computation usually requires decryption at some point. FHE is different because data can remain encrypted throughout execution.
In blockchain terms, this matters because it enables state transitions without exposing the underlying values. A transfer, for example, can update balances without publicly revealing the amount or the exact balance of each participant.
ZK, or zero-knowledge proofs, solves a different problem. Its core value is proving that a statement or computation is correct without revealing the underlying input. In other words, ZK is mainly about verifiability, while FHE is mainly about confidential execution.
These technologies are not mutually exclusive. They are often complementary. FHE can keep data encrypted during computation, while ZK can help prove that encrypted inputs are well formed or that certain parts of the process are valid. Zama’s architecture reflects that view by combining FHE with ZK, MPC, and TEE rather than treating any single tool as sufficient on its own.
Why Zama looks like a strong candidate
The case for Zama is not just that it uses FHE. The stronger point is that it connects research, protocol design, and developer tooling into a single stack.
On the research side, CTO Pascal Paillier is one of the most recognized figures in cryptography and the inventor of the Paillier cryptosystem. CEO Rand Hindi brings a separate layer of credibility through prior company-building and commercialization experience. That combination matters in a field where many teams are strong in theory but weaker in productization.
Zama has also become part of the shared infrastructure of the FHE ecosystem. Projects such as Fhenix and Mind Network have relied on Zama open-source components, which gives Zama a meaningful position as a technical base layer rather than just an isolated application team.
Developer experience is another major reason. With FHEVM, Zama is trying to let developers bring confidential logic into a Solidity and EVM workflow instead of forcing them onto a fully separate execution environment. That is a meaningful distinction. In practice, teams care not only about privacy features, but also about whether those features can be adopted without rewriting their entire stack.
This matters even more for enterprise use cases. If confidentiality can be added on top of existing L1 or L2 environments, rather than requiring a move to a dedicated privacy chain, the path to deployment becomes more realistic. That is one reason I view Zama not just as an FHE project, but as one of the strongest candidates to define the confidentiality layer for public blockchains.
The Zama Protocol architecture
The Zama Protocol is not built from FHE alone. It combines FHE, ZK, MPC, and TEE with different responsibilities assigned to each layer.
At a high level, the main components are the Host Chain, confidential smart contracts, Coprocessors, the Gateway, the KMS, and the Oracle or Relayer layer.
- Host Chain: the L1 or L2 where the application is deployed
- Confidential Smart Contract: the contract that references encrypted handles and emits FHE computation requests
- Coprocessor: the off-chain node layer that verifies inputs and executes FHE computation
- Gateway: the coordination layer for validation, ACL synchronization, decryption requests, and consensus aggregation
- KMS: the MPC-based key management layer that supports threshold decryption
- Oracle and Relayer: the connectivity layer that simplifies interaction for contracts and users
It is useful to look at the flow step by step.
1. Registering confidential data
The user first encrypts plaintext data with the FHE public key. At the same time, the user provides a zero-knowledge proof of knowledge so the system can validate that the ciphertext is well formed and that the sender actually knows the underlying plaintext.
The Coprocessor set validates the proof, and the Gateway aggregates the result and issues a handle for the encrypted value. The contract does not hold the plaintext. It holds references to encrypted values through these handles.
2. Setting access control
The protocol uses ACL rules to determine who is allowed to compute on or decrypt a given encrypted value. The confidential contract sets permissions, and those permissions are synchronized across the Coprocessor and Gateway layers.
This is important because confidentiality is not just about hiding data. It is also about defining who is allowed to operate on that data, and under what conditions a value may be decrypted.
3. Executing FHE computation
When a user sends a transaction to a confidential contract on the Host Chain, the contract emits symbolic instructions over encrypted handles. The actual FHE operations are executed off-chain by the Coprocessors.
Those nodes compute on ciphertexts, return a new encrypted handle representing the result, and the Gateway aggregates the outcome. The contract then updates the handle it references, without exposing the plaintext behind it.
This is one of the core properties of the model. The chain can retain public verifiability of execution flow while keeping the underlying values confidential.
4. Decrypting only when needed
If a user or contract needs a plaintext result, the Gateway first checks the ACL, then forwards the request to the KMS for threshold decryption.
The KMS is based on MPC. Each node holds only a share of the key material rather than the full secret key. That avoids a single operator or single machine becoming the point of trust. In addition, secure execution environments are used so even node operators are not meant to access the protected material directly.
For user decryption, the plaintext is not simply returned in the clear. Instead, it is re-encrypted to the user’s public key and sent back through the Relayer. That means access to the decrypted result is still narrowly scoped.
The design role of $ZAMA
In the protocol design, $ZAMA is not just a speculative asset. It has three clear roles: fees, staking, and governance.
First, protocol-level actions such as encrypted input verification, decryption, and bridging are associated with fees. In practice, these fees can be paid by the end user, a relayer, or the application itself, but the protocol still treats those actions as scarce resources that require economic coordination.
Second, operators such as Coprocessors are expected to stake $ZAMA. That creates economic security on top of cryptographic security. Misbehavior can lead to slashing, which is important because the protocol depends not only on correct code, but also on honest and reliable operators.
Third, governance is part of the design. Token holders are expected to participate in decisions around important parameters such as inflation or slashing outcomes. That means $ZAMA sits at the intersection of usage, security, and protocol governance.
What to watch next
The most important question is not simply whether FHE is impressive as a technology. The more practical question is where it becomes indispensable.
The strongest early use cases are likely to be confidential tokens, private transfers, auctions, identity-linked compliance flows, and credit or eligibility logic where public verifiability is necessary but the underlying values should remain hidden.
That is where FHE can change the design space most clearly. Public blockchains have traditionally forced a tradeoff between verifiability and privacy. If that tradeoff becomes less severe, entirely new categories of applications become possible.
For users and developers, the practical next steps are relatively clear:
- Define what data actually needs to stay hidden
- Distinguish whether ZK alone is sufficient, or whether encrypted computation is required
- Check whether the existing EVM or Solidity stack can be reused
- Design ACLs, decryption rights, and operational boundaries early
- Think about node operations, MPC participation, and audit readiness before the product surface expands
Privacy systems are easy to discuss in the abstract, but much harder to evaluate until they are mapped to a real application. Once the questions become concrete, such as what data stays hidden, who can see it, and when it may be decrypted, architectural differences start to matter.
Conclusion
FHE changes the privacy discussion because it allows encrypted computation rather than only encrypted storage or post-hoc proof generation. ZK remains critical for verifiability, but FHE addresses the separate problem of keeping the data encrypted while the computation itself is happening.
Within that landscape, Zama stands out because it is not only advancing the cryptography. It is also packaging the full protocol and developer stack in a form that teams can build on. The combination of FHEVM, Coprocessors, Gateway, KMS, and ACL-based control makes it one of the clearest attempts to define a confidentiality layer on top of existing public chains.
My view is that Zama remains one of the strongest candidates in the privacy space, especially for enterprise and financial use cases where public verifiability and confidentiality are both required at the same time.