The privacy stack decoded: Why ZK, FHE, and Encrypted Black Boxes are not solving the same problem

When people talk about blockchain privacy today, they often use the technologies interchangeably. Zero-knowledge proofs, fully homomorphic encryption, trusted execution environments: three terms that appear in the same conversations, sometimes in the same sentence, as if they were competing answers to the same question.

They are not. Each of these technologies was built to solve a different problem. Choosing between them is not a matter of preference or performance benchmarks. It is a matter of understanding what problem you actually have, and whether the technology you are evaluating was designed to solve it.

This distinction matters enormously for regulated institutions. The wrong privacy architecture does not just underperform. It fails in ways that are specific to the problem it was never designed to handle. And in financial infrastructure, that failure tends to surface at exactly the moment you can least afford it: under regulatory scrutiny, during a settlement dispute, or when a counterparty asks for verifiable proof of something your system cannot produce.

The question behind the technology

Before evaluating any privacy technology, it helps to be precise about what you are trying to protect and from whom.

Most institutions, when they examine this carefully, find they have at least three distinct problems that they have been grouping under the single word "privacy."

The first problem is verification without disclosure. You need to prove something is true to a counterparty or regulator, but the underlying data that proves it is itself sensitive. A practical institutional example: a fund or vault offers shares to investors. The investor needs to confirm the fund is correctly backed by its stated collateral. But the collateral may be off-chain (real-world assets, treasuries, receivables) or it may be held on-chain in instruments the manager does not want to disclose for competitive or commercial reasons. The investor needs verification. The manager cannot give them full disclosure. Privacy here is about proving correctness without exposing the underlying composition.

The second problem is computation without exposure. You need to perform operations on data that you cannot or should not decrypt. The data has to remain confidential throughout the process, even from the party running the computation. Consider a delivery-versus-payment settlement between two institutions. Before the trade settles, both parties have committed to specific terms: asset, quantity, price, timing. The settlement system needs to verify that both commitments describe the same deal, otherwise the atomic exchange should not proceed. That check has to happen on the encrypted commitments themselves, because neither party should see the other's terms before execution, and the settlement system itself should not see the deal in clear text. Privacy here is about computing on confidential data without ever decrypting it.

The third problem is execution without observation. You need to run logic in an environment where neither the inputs nor the intermediate states are visible to the infrastructure operator, but you are prepared to trust that the environment itself is secure. The institutional case here is operational rather than transactional: a bank running a proprietary matching engine, a private risk model, or a confidential settlement algorithm on shared infrastructure. The institution does not want competitors or the infrastructure operator to see how the logic works. It does want auditors to be able to verify that the logic is what it claims to be. Privacy here is about hiding the operational logic from the network while giving an auditor a controlled way in.

These are three different problems. They have three different solutions. Understanding which solution addresses which problem is the only reliable way to evaluate a privacy architecture.

Zero-knowledge proofs: solving verification without disclosure

A zero-knowledge proof allows one party to prove to another that a statement is true without revealing any information beyond the truth of the statement itself.

Returning to the fund example: a zero-knowledge proof allows the manager to prove that a vault is fully collateralised, that the collateral satisfies the fund's mandate, and that the share price is calculated correctly, all without disclosing which specific assets back the fund or in what proportions. The investor verifies the proof. The composition of the fund stays private.

‍

The same logic extends across institutional finance. When an institution needs to demonstrate compliance, eligibility, or correctness to a counterparty or regulator, it typically has to hand over the underlying records. A zero-knowledge proof eliminates that requirement. The institution proves what needs to be proved, and nothing else is disclosed.

In the context of payment settlement, this means a transaction can be proved mathematically correct, with valid inputs, authorised by the right keys, and non-duplicative, without the amounts, the sender, or the receiver ever appearing on the ledger. The network verifies the proof, not the data behind it.

The properties this delivers are well-suited to institutional finance. The guarantees are mathematical, not operational. There is no trusted party that processes the data and promises not to look at it. The privacy holds because the mathematics requires it to hold. Proofs are verifiable by anyone who has access to the verification key, which means regulators and auditors can confirm validity without requiring access to the underlying transaction detail.

The limitation is equally specific. Zero-knowledge proofs are excellent at proving properties about data. They are not designed for scenarios where multiple parties need to jointly compute on data that none of them holds in full. They are also computationally intensive relative to an unencrypted transaction, which creates a real performance cost that grows with proof complexity. The trade-off between proof size, generation time, and verification cost is a genuine engineering constraint, not a marketing footnote.

Fully homomorphic encryption: solving computation without exposure

Fully homomorphic encryption allows a party to perform arbitrary computations on encrypted data and produce an encrypted result, without ever decrypting the data during the process.

This is what makes the DvP matching problem tractable in a privacy-preserving way. Both parties to the trade can encrypt their commitments to the deal terms. The settlement system, without decrypting either commitment, can compute whether the two describe the same trade. If they match, the atomic exchange proceeds. If they do not, neither leg releases. Neither party sees the other's terms before execution, and the settlement infrastructure itself sees nothing in clear text at any point.

The same principle extends to other institutional workflows where computation has to happen on data that should not be decrypted: confidential order matching, encrypted analytics, credit scoring on protected inputs, joint computation between parties that do not trust each other with raw data.

The performance constraint is currently decisive. FHE operations are orders of magnitude slower than the equivalent plaintext computation. The overhead is not a marginal inefficiency. For most real-time financial workflows, the latency introduced by FHE makes it impractical as a transaction-layer primitive today. This is a statement about the current state of the technology, not a permanent ceiling. Hardware acceleration and algorithmic improvements are advancing quickly, and Zama's mainnet launch in late 2025 demonstrated that FHE for specific use cases has moved from academic theory into production. But "production for specific use cases" and "production for institutional settlement at scale" are different thresholds. The gap between them remains real in 2026.

There is a second limitation worth understanding precisely, because it shapes how FHE-based systems handle authorisation and access. In a typical FHE design, the secret key is the single point of control: whoever holds it can decrypt every value that was encrypted under the corresponding public key. In institutional implementations, that same key often also authorises operations on the encrypted data. The two powers are fused into one cryptographic credential.

This concentration is a problem for regulated environments. If the secret key is compromised, the attacker does not just gain visibility into historical data. They gain the ability to operate on it. There is no native way to give an auditor the right to inspect transactions without also giving them the ability to act on them, and no native way to revoke the ability to act while preserving the audit trail. The privacy guarantee and the authority guarantee live in the same key.

In well-designed institutional privacy systems, these two functions are separated. A spending key controls authority. A separate viewing key controls visibility. The two are bound mathematically but operate independently: an auditor can be given a viewing key with no spending power, and a spending key can be rotated without affecting historical auditability. This separation is foundational to how Enygma supports selective disclosure, and we will return to it in detail in a later post. For now, the relevant point is that FHE alone does not provide this separation, and any institutional design that depends on FHE for confidentiality needs to be honest about that limitation.

FHE also does not natively address auditability of the computation itself. Encrypted computation produces an encrypted result. The process that produced it is not inherently verifiable to a third party. If a regulator needs to confirm that a computation was performed correctly, FHE alone does not provide that confirmation. Hybrid designs that combine FHE with zero-knowledge proofs can address this, but they compound the performance cost.

Trusted execution environments: solving execution without observation

A trusted execution environment is a hardware-secured enclave inside a processor. Code runs inside it, and neither the operating system, the cloud provider, nor any external observer can read the data being processed or observe the intermediate states. The enclave is, from the outside, a black box.

The business problem this solves is different again. It is not about proving properties of data, and it is not about computing on encrypted data. It is about running logic in a place where you are confident nobody is watching, even if that place is physically controlled by someone else.

The institutional applications are operational. A bank running a proprietary matching engine for an institutional dark pool wants the matching logic, the order book, and the participant identities all hidden from the infrastructure operator and from other participants, while accepting that auditors will need attested access to verify the system. A stablecoin operator running its reserve management and redemption logic on shared infrastructure wants the operational rules hidden from competitors and from the network, while remaining auditable to its regulator. A confidential settlement engine running netting calculations for a group of institutions wants the netting rules and the resulting positions hidden from anyone who is not party to the netting set.

These are problems about hiding how the system works, not just what it holds. That is the distinctive characteristic of a TEE workload. The institution has proprietary operational logic, the logic needs to execute at near-native speed (cryptographic alternatives are currently too slow for many of these cases), and the institution is prepared to accept hardware-rooted trust as the basis for confidentiality.

The performance characteristics of TEEs are attractive. Because execution happens in hardware, the overhead is minimal relative to the cryptographic alternatives. Complex logic, large datasets, and high-throughput operations are all feasible in ways that remain impractical for ZK proofs or FHE at current maturity.

But TEEs introduce a trust assumption that the other two approaches do not require: you must trust the hardware manufacturer. The security guarantee of a TEE rests on the integrity of the chip's root of trust. If that is compromised, whether by a hardware flaw, a supply chain attack, or a vulnerability in the attestation mechanism, the enclave's confidentiality can be broken. This has happened. Intel SGX has had documented vulnerabilities that broke the isolation guarantees under certain conditions.

For a regulated institution, there is a further and more specific problem. A TEE is, by design, a black box. The institution, the counterparty, and the regulator can all be told that certain code ran correctly inside the enclave. They can receive an attestation from the hardware that the code hash matches what was expected. But they cannot independently verify what the code actually does. They cannot confirm, from first principles, that the logic inside the enclave enforces the rules they believe it enforces.

This means TEE-based privacy requires trusting the code as well as the hardware. For institutions operating under regulatory obligations that require demonstrable compliance, that is a problematic dependency. Auditability, in the regulatory sense, means being able to show exactly what happened and why. An attestation that says "the right code ran" is not the same as a verifiable proof that the right outcome was produced by the right logic on the right inputs. The difference between those two statements is the difference between institutional-grade auditability and a promise.

Why Enygma is built on the first model

Enygma's transaction layer is built on zero-knowledge proofs, with post-quantum key exchange and homomorphic operations used selectively where they solve specific problems within the settlement flow.

This is a deliberate design choice, not a default.

The core institutional requirement that Enygma was built to satisfy is verifiable, selective disclosure. A regulated institution needs to be able to prove to a regulator that a transaction occurred, that it was authorised, and that it settled correctly, without exposing the full transaction detail to the broader network or to any party that is not entitled to see it. That is precisely the problem zero-knowledge proofs were designed to solve.

The auditability model in Enygma is enforced mathematically. A viewing key can be scoped to a specific counterparty or regulator and grants the ability to inspect what that key is entitled to inspect, nothing more and nothing less. That boundary is not a policy that an administrator can override. It is a cryptographic constraint. The institution does not need to trust a hardware manufacturer, a platform operator, or an internal process to enforce it.

The homomorphic operations in Enygma are not transaction-layer primitives. They are used where the specific business problem requires computation on confidential values, such as the verification of atomic settlement where neither party should see the other's position before execution is complete. This is a targeted application of a technology that is well-matched to the problem.

FHE as a general transaction layer remains outside the performance envelope that institutional settlement requires. That is an honest assessment of where the technology stands today. As FHE matures, the design of Enygma is modular enough to incorporate it where it becomes viable. But deploying it prematurely, at the cost of settlement performance and operational reliability, would be a different kind of failure.

TEEs are absent from the Enygma transaction layer for a reason that is easier to state simply: mathematical guarantees are stronger than hardware trust for the specific class of institutions Enygma was built to serve. Regulated financial institutions cannot outsource their assurance model to a chip manufacturer's attestation. The cryptographic proof has to stand on its own.

Choosing the right tool

For institutions evaluating privacy technology, the practical implication of all of this is straightforward.

If your primary requirement is proving transaction correctness and compliance to regulators without exposing underlying data, zero-knowledge proofs are the right tool. They were designed for this problem.

If your primary requirement is running confidential analytics or matching on data you cannot decrypt, fully homomorphic encryption is the right tool, with the honest caveats that for real-time, high-volume settlement it is not yet production-ready at the performance levels institutional finance requires, and that the single-key model concentrates visibility and authority in ways institutional designs need to compensate for.

If your primary requirement is running complex proprietary logic at speed in an environment where the infrastructure operator cannot observe the inputs, trusted execution environments are the right tool, with the equally honest caveat that auditability depends on trusting both the hardware manufacturer and the code running inside the enclave.

Most real institutional deployments will involve more than one of these problems. The question is not which technology wins, but which technology was designed for each specific problem in your architecture, and whether the combination you are using actually solves all of them.

Enygma makes a specific set of choices in answering those questions, with academic specifications published on the IACR cryptology archive and a live deployment that has been validated in production. The choices are deliberate. The trade-offs are real. And the design is modular enough that, as the technology landscape evolves, the architecture can evolve with it.

That is what it means to build institutional privacy on a principled foundation rather than a convenient one.

‍