Confidentiality compared: what four privacy architectures promise

Back in late July, Zama switched on a confidential swap venue on Ethereum mainnet, in private beta ahead of a September public launch, that makes it possible for a trader to submit an encrypted intent hiding the amount, the slippage tolerance, and the direction of the trade.

It relies on a small piece of choreography for this. The trader deposits two confidential transfers, one carrying the actual assets and one for the opposite leg with a zero amount, so an observer sees a bidirectional movement of hidden size and cannot tell a buy from a sell. Whitelisted market makers decrypt the intent, see the size but not the direction, and quote both sides. A sealed-bid auction settles on chain, and only the winning maker learns which way the trade moved. The net result is a swap executed at size on a public chain, where no single party outside the trade ever assembles the whole picture.

Zama describes the product as confidential end-to-end, but what does that confidentiality really entail? Confidentiality here requires confidentiality along a whole chain of actions, so that the public sees one thing, the losing bidders see more, since they decrypted the trade's size in order to quote it, and the winning bidder sees more still. To put it simply, each stage of the sequence is that way because of a decision someone made about who needs to know what, and when. It would be nice to sum up confidentiality as "nobody sees anything," but nothing would work in practice. Confidentiality has to be structured, and it has to follow a sequence.

What's interesting is that nearly ten years before that launch, Zcash put the first confidential settlement layer on a public blockchain, using zero-knowledge proofs to hide the sender, receiver, and amount of a transaction while proving to everyone that the transaction was valid. In the decade since, "confidential" has become the adjective for at least four distinct families of technology: shielded transactions, fully homomorphic encryption, multi-party computation, and trusted execution environments. Products from all four families now run in production, several of them on the same chain. So, what's inside the tin?

The four families offer different and sometimes overlapping answers to four different problems, and since every answer now arrives packaged as a product, the real task is to figure out which problem you actually have.

What does a confidentiality claim specify?

Any confidentiality claim, when you strip it down to its undergarments, has to answer four questions. What data is hidden? From whom? During which phase of the data's life? And what has to be trusted for the guarantee to survive?

As an example, take the swap venue. It must hide amount, direction, and slippage. Why not the asset pair? Zama says a future version will conceal that too. From whom: the public and the front-running bots fully, the quoting market makers partially, the winning maker least of all. During which phase: through quoting and auction, with a designed disclosure at settlement. And whom you need to trust: the guarantee rests on the FHE itself, on the smart contracts, and on a threshold key-management system whose operators must not collude past a threshold. Per the litepaper, no single party can ever access the decryption keys.

It's a design for executing size without broadcasting strategy. Market makers see size because they cannot price a quote without it. The winner learns direction because, well, settlement requires it.

What the example shows is that a claim that sounds binary, as if something is confidential or not, actually breaks into a schedule of exclusions. There are very different ways of arriving at claims that sound the same.

What does each confidentiality family provide?

Shielding

A shielded Zcash transaction hides the sender, the receiver, and the amount. What remains public is the proof: a zero-knowledge argument, checkable by anyone running a node, that the hidden transaction follows the rules. Shielded funds exist as encrypted notes, each one a private record of an amount and its owner that appears on chain only as a cryptographic commitment. Spending a note publishes a nullifier, a value that prevents the same note from ever being spent twice without revealing which note it was. This means the network can reject double-spends without ever learning which funds moved, so spending leaves no trail linking one transaction to another. The proof's job is to establish that the spender owned the note, that the transaction's values balance, and that no ZEC was created or destroyed, all without disclosing any of the quantities involved.

The design's distinguishing property is most apparent when considering what must be trusted. There is no committee that can decrypt a shielded transaction, no operator set whose collusion threshold matters, no hardware vendor whose attestation must be believed. What remains in the trust base is the mathematics and the correctness of the circuits that encode the rules. For anyone whose threat model includes the infrastructure itself, operators who can be pressured, vendors who can be compromised, that short list is the product.

As a matter of fact, that trust base was just tested in production. On May 29, Taylor Hornby, a security researcher auditing for Shielded Labs, found a soundness flaw in the Orchard pool's proof circuit, present since the pool's 2022 launch, one that, per Shielded Labs' disclosure, could have allowed unlimited counterfeit ZEC to be minted inside Orchard without any on-chain trace.

The emergency fix shipped in five days: Orchard paused on June 2, then was restored on June 3 with a corrected circuit. ZODL's remediation post drew the impact more narrowly than Shielded Labs did, describing a risk of double-spending inside the pool rather than counterfeit supply, and reported user privacy and the total supply cap unaffected.

The verifiability rebuild shipped later. Ironwood, activated as NU6.3 on July 28, seals the Orchard pool permanently, opens a fresh pool on the corrected circuit, backed by independent audits and formal verification work, and routes all exiting funds through a turnstile that caps withdrawals at what verifiably entered, restoring every user's ability to independently check the circulating supply without seeing anyone's transactions. The episode is the trust-base ledger in action. When circuit correctness failed, the remedy was mathematics and migration, not a committee's discretion, and the blast radius was bounded by auditability the architecture had built in at the pool boundary years earlier.

What shielding buys with that minimal trust base is narrow on purpose. The hidden state is a payment, value moving from one party to another. There is no shared encrypted state that many parties compute over, no confidential contract logic, and no encrypted order book.

Fully homomorphic encryption

FHE lets computation run on ciphertext. In Zama's protocol, the version now live on Ethereum, balances and transfer amounts exist on chain as encrypted handles under the draft ERC-7984 standard, coprocessors perform the encrypted arithmetic off chain, and decryption requires a quorum of independent key-management operators, thirteen organizations at mainnet launch, selected for reputation and operational stakes, so no single party can read the data. This is what makes an encrypted order book or a confidential lending pool possible at all: many parties' hidden state, composing inside shared contract logic.

But what about the key-management committee? Someone has to be able to decrypt, or the data is not usable. The design's response is to make that someone a threshold of independent operators rather than a single custodian, and to govern who may decrypt which values through access control written into the contracts themselves, extendable to designated parties such as auditors, a delegation mechanism whose compliance implications belong to the next piece in this series. The question for someone evaluating solutions is whether the committee's composition, incentives, and threshold match the evaluator's threat model.

Multi-party computation

Multi-party computation splits data into shares distributed across independent nodes, which jointly compute a result without any node reconstructing the inputs. Avishay Yanai, co-founder and CEO of Soda Labs, whose garbled-circuit virtual machine executes EVM-compatible contract logic over encrypted values in production on the COTI network, describes good MPC design in production as ensuring that no single party, whether an observer, a node running the computation, or the vendor, ever sees plaintext inputs or intermediate state, and everyone sees only what the disclosure policy grants them. The guarantee only depends on non-collusion, and that is an assumption you can engineer and contract around, such as with operators in separate jurisdictions, on separate clouds, and under independent audits, with legal exposure for collusion. Cryptography's job here is what he calls a tremendous trust reduction rather than trust elimination, to reach equivalence with the trust institutions place in clearinghouses. Collusion past the threshold breaks privacy, but not correctness, since in designs with public auditability, external validators can still check that reported results are right without joining the computation.

The caveat is merely that such an observer sees that a transaction happened, when, against which contract, who submitted it, plus batch sizes and fees. A participating node can learn which function ran and its throughput patterns. Timing correlation is another consideration, as activity levels can leak even when amounts don't. And whatever the application outputs in plaintext, repeated small disclosures could grow into potential patterns for a party that is on the lookout for them. "It's the boundary of the promise," he clarifies, so evaluators should demand vendors draw it explicitly. No computation model repairs the submission of plaintext by, for example, a compromised client. The protocol computes faithfully on whatever it is given. Who talks to whom is a transport problem, and compliance is policy rather than mechanism: "No cryptography makes that judgment for you."

Garbled-circuit designs run in constant rounds with the heavy cryptographic material precomputed before inputs exist, which is what makes transaction-rate workloads feasible where secret-sharing protocols pay network round trips per operation, and where, per Yanai, some MPC families protect the values but not the fact of computation, garbled-circuit designs can extend cover to counterparty addresses and asset types. The family's most consequential property for this comparison, though, is that MPC is an architecture in its own right, and it is also an ingredient inside the other families: the threshold key committee under an FHE deployment is itself a multi-party computation. The evaluator's question, in Yanai's framing, is "what does my committee do, and what do I pay on top of it?" If the committee exists either way, running the computation itself in MPC can remove an expensive outer layer.

It's worth clarifying that two very different products get discussed using the same acronym. Custody MPC splits a signing key across several parties so that no single one of them can sign alone; it protects one secret, and the joint computation involved is a single fixed operation, producing a signature. Compute MPC runs general program logic over data that stays hidden throughout, and involves many parties' inputs, arbitrary contract logic, and continuous operation. The mathematics is what the two have in common. Operationally, though, one is used for key management and the other is a confidential execution environment.

Trusted execution environments

A TEE is a hardware-isolated region of a processor that keeps data encrypted in memory and shielded from the operating system, the hypervisor, and the machine's operator, with remote attestation letting an outside party verify what code is running inside. The design buys the two things the cryptographic families pay dearly for, generality and speed: an enclave runs ordinary programs at close to ordinary cost, which is why TEEs anchor most confidential-compute offerings from the major clouds and a growing set of chain infrastructure.

The trust base is the trade, because the guarantee is only as strong as the hardware vendor's design and supply chain, the attestation infrastructure, and the enclave's resistance to side-channel extraction, a class of attack with a long published history. TEE designers know this ledger better than their critics do. Choosing the architecture means making a considered bet that hardware trust plus attestation is the right price for running real workloads at real speed, and for many deployments it is.

Where does shielding fit?

Could shielded Zcash serve the confidential trading venue use case? No, but that's not a shortfall. An RFQ venue is shared encrypted state under contract logic, many parties' hidden intents composing inside an auction that itself runs blind. That's more applicable for something like MPC, with shared private state under frequent interaction, an order book, a netting cycle. Shielding has no substrate for that; its hidden state is a payment between two parties. The venue itself is suited for FHE or MPC, and it is worth noticing that when Zama built it, the confidentiality it delivers is a schedule of disclosures to whitelisted, identified market makers, which is necessary for institutional trading. But that is a different product than what a shielded transaction offers, which is confidentiality with no whitelist and no party who eventually learns your direction.

What about corporate payments and payroll? This is a market every FHE and MPC vendor now courts, and it's actually exactly the problem shielding was built for: having the amounts hidden, the counterparties hidden, yet the validity public. In principle a shielded chain is the strongest-trust-base answer available, because there's no committee, no vendor, and no operator set. In practice the corporate-payments market is being won on rails, ERC-20 integration, existing custodians, existing compliance tooling, stablecoin denominations, and shielded Zcash offers a different asset on a different chain. But it's a solid fit at the level of problem shape and is simply awaiting integration. The cryptography can do it, so the practical concerns have to do with what the surrounding stack connects to.

It's also worth looking at what the other three families offer, and shielding does not: a party who can be compelled. A threshold committee can receive a court order, an enclave vendor can be subpoenaed for its signing keys, and an operator set has a jurisdiction. An institution that needs a compliance path may count the committee as the product. It is also, from another seat, the vulnerability.

Which trust base can you live with?

If we look again at the cases surveyed above, we see a picture that overlaps. Most FHE deployments have threshold MPC underneath as the decryption layer. Zero-knowledge proofs certify encrypted inputs before FHE consumes them, and in garbled-circuit systems can certify them after the fact, giving users a forced exit that does not depend on the network's availability, a practice borrowed from rollup architectures. TEEs appear inside MPC nodes as defense in depth, Zama's key-management nodes run their share of the computation inside hardware enclaves, and TEEs increasingly host the provers and builders of systems whose end guarantees are cryptographic. A comparison written in five years may find the seams hard to locate. But composition runs one direction only.

Which is why the durable form of the evaluator's question isn't about "which technology" at all. The thing to look for is how the confidentiality is sequenced, what is excluded, and what enforces the exclusion, whether that's mathematics and circuit correctness, a committee's non-collusion, a threshold of honest nodes, or a vendor's silicon. Read any confidentiality claim by asking what is hidden, from whom, until when, and on whose word, and then you'll know.

Disclosure: this piece was supported by a Zcash Community Grant. ZCG did not review or approve this piece before publication. Proof Street's funding commitments are listed on the funding page.