Public blockchains were designed around radical transparency. Every transaction, balance, and state transition is visible to anyone, anywhere. While this openness enables trust and composability, it also creates a hard ceiling on adoption: sensitive data cannot live on-chain without being exposed.
This transparency paradox has real consequences. Institutions cannot deploy proprietary financial logic on public ledgers. Users are vulnerable to front-running and MEV. Developers are blocked from building applications that require confidentiality by design.
Zama addresses this limitation by introducing programmable privacy to existing blockchains. Rather than replacing the base layer, Zama adds a modular confidentiality layer that allows smart contracts to compute directly on encrypted data using Fully Homomorphic Encryption (FHE). Transactions, balances, and application logic remain private end-to-end, while execution remains verifiable and composable.
To understand the basics on Zama, read our “First Look” article here. Below, this article walks through Zama’s architecture in detail, explaining how confidential computation is coordinated across on-chain contracts, off-chain FHE coprocessors, and a decentralized key management system, without requiring any changes to the underlying blockchain.
Under the Hood
Zama’s architecture is designed to enable encrypted computation on existing blockchains without modifying the base layer.
At a high level, confidential transactions are expressed on a host chain, executed off-chain by FHE coprocessors, and selectively decrypted through a threshold Key Management System (KMS) orchestrated by the Gateway, with an Access Control List (ACL) enforcing permissions at every step.
Source: Zama Protocol Overview
This modular design cleanly separates concerns:
- Developers deploy confidential smart contracts
- Users transact privately without revealing sensitive data
- Infrastructure operators run computation and key services under clear economic and cryptographic guarantees
all while the base chain remains fully unaware of encrypted data.
Core Components
Host Chains
Host chains (such as Ethereum and Ethereum L2s) handle transaction ordering, consensus, and standard smart contract execution. Confidential applications deploy directly on these chains using Zama’s contracts and libraries.The host chain never:
- Sees plaintext data
- Performs FHE computations
- Manages encryption keys
This preserves full compatibility with existing chain infrastructure and security assumptions.
FHEVM Library
The FHEVM library is the developer-facing interface for building confidential smart contracts.
It extends Solidity with encrypted primitives (euint, ebool, eaddress) and FHE-enabled operations, allowing developers to write logic that operates on private data without cryptographic expertise. Under the hood, contracts manipulate encrypted handles, not plaintext values.
The library emits structured calls to the FHEVM Executor, translating developer intent into symbolic computation requests.
FHEVM Executor
The FHEVM Executor is an on-chain contract that records requested encrypted operations and emits events, leaving the actual computation to coprocessors
These events form an auditable, deterministic transcript of the confidential computation. The executor itself never performs cryptography, it simply defines what should be computed, leaving the how to off-chain infrastructure.
Access Control List (ACL)
The ACL defines who is allowed to:
- Use encrypted values
- Decrypt encrypted values
- Access values temporarily within a transaction
ACL updates are emitted on-chain and relayed to the Gateway, making confidentiality an explicit, programmable policy enforced by smart contracts.
Both coprocessors and KMS nodes rely entirely on the ACL when deciding whether to compute on or decrypt data.
Gateway
The Gateway coordinates off-chain components and acts as the canonical reference point for encrypted state. It:
- Stores ciphertexts and computation outputs
- Synchronizes ACL state across coprocessors and KMS nodes
- Verifies commitments from coprocessors
- Orchestrates decryption requests
The Gateway is the control plane that ties computation, permissions, and key management together.
Coprocessors
Coprocessors are off-chain nodes responsible for executing the encrypted operations specified by the FHEVM Executor. They:
- Monitor host chains for FHE operation events emitted by the FHEVM Executor
- Fetch encrypted inputs from storage
- Execute the requested computations using TFHE
- Store resulting ciphertexts and commit them to the Gateway
Multiple coprocessors operate in parallel, with majority agreement on commitments used to ensure correctness and fault tolerance. Coprocessors are staked, providing an economic security layer that discourages malicious computation and strengthens the integrity of off-chain execution.
Key Management Service (KMS)
The Key Management Service (KMS) is operated by a set of MPC nodes and is responsible for authorizing and performing decryption of encrypted values produced during confidential smart contract execution.
KMS nodes manage decryption keys using a threshold cryptography scheme. No single MPC node ever holds a complete decryption key. Instead, decryption requires participation from a quorum of MPC nodes and is only performed when the on-chain Access Control List (ACL) conditions are satisfied. This ensures that encrypted data can only be decrypted according to explicit, programmable policy.
MPC nodes are staked, aligning operators with correct behavior and discouraging unauthorized decryption or refusal to participate. Together, they form a secure, decentralized key management layer,
Relayer & Oracle
The Relayer and Oracle layer bridges off-chain results back to host chains by:
- Relaying verified coprocessor commitments
- Publishing finalized encrypted outputs
- Synchronizing cross-chain state where required
Lifecycle of a Confidential Transaction
To illustrate the process, let’s explore the lifecycle of a confidential transaction within the Zama ecosystem using a practical example.
Narrative Example: Alice sends 50 USDC to Bob without revealing her balance or the transaction amount)
- User encryption and ZK proof generation
The user encrypts their data locally and generates a Zero-Knowledge Proof (ZKPoK) to verify validity.
Example: Alice wants to send funds to Bob. She encrypts the transfer amount (50 USDC) on her device. She generates a ZK proof showing she has sufficient funds (balance 50$) and that the amount is positive, without revealing her total balance or the transfer size.
- ZKPoK validation
The user requests validation through the Gateway, paying fees in $ZAMA. The Gateway coordinates coprocessors to verify the proof and returns an attestation.
Example: The network verifies Alice’s proof. The system confirms Alice is following the rules (she isn’t trying to spend money she doesn’t have), even though the third-parties don’t know how much she is sending.
- On-chain interaction
The user submits the transaction to the dApp on the host chain, including the validation attestation. The dApp instructs the FHEVM Executor to schedule the operation.
Example: Alice submits the “transfer” transaction to the Stablecoin Smart Contract on Ethereum. The contract sees a request to move encrypted funds but cannot see the amount.
- Off-chain FHE computation
Coprocessors execute the encrypted logic off-chain and commit the resulting ciphertext to the Gateway.
Example: The coprocessors perform the math on the encrypted data. They subtract the encrypted “50” from Alice’s encrypted balance and add the encrypted “50” to Bob’s encrypted balance. The new balances are calculated, but they remain encrypted.
- Access control enforcement
The dApp updates the Access Control List (ACL) to specify who is allowed to decrypt the result and when.
Example: The smart contract updates the permissions so that ONLY Bob can decrypt his new balance to see he received the funds, and ONLY Alice can decrypt her new remaining balance.
- Decryption request
When the conditions are met, a user (or the dApp) requests decryption. The Gateway verifies permissions against the global ACL.
Example: Bob opens his wallet app to check his balance. His wallet requests decryption of his current account total.
- Threshold decryption
MPC nodes collaboratively decrypt the requested value. No single node holds the key; they must work together to reveal the specific data point.
Example: The MPC nodes verify Bob is authorized to view his own balance. They collaboratively decrypt his specific balance value and send it to him.
- Final delivery
The Gateway sends the decrypted value back to the user or smart contract, completing the lifecycle.
Example: Bob’s wallet displays his new balance, now 50 USDC higher. To the rest of the world (including block explorers like Etherscan), the transaction details and both balances remain completely hidden.
Source: Zama Protocol Litepaper
Looking Forward
Zama fundamentally changes what is possible on public blockchains. By enabling computation over encrypted data, it removes the tradeoff between privacy and programmability that has constrained blockchain adoption for years.
Through a carefully modular architecture—combining on-chain execution, off-chain FHE computation, programmable access controls, and threshold decryption—Zama allows developers to build applications where confidentiality is enforced by code, not trust assumptions. Balances, transaction details, and business logic remain private, while correctness, auditability, and decentralization are preserved.
This design unlocks entirely new categories of use cases, from compliant stablecoins and confidential DeFi to institutional asset tokenization and private financial workflows. Just as importantly, it does so without fragmenting the ecosystem or compromising the security assumptions of existing chains.
By making privacy programmable and verifiable, Zama moves public blockchains closer to becoming viable, global financial infrastructure, where sensitive data can remain confidential without sacrificing openness, composability, or trust.
