EXPLAINER

Prove vs. compute.

Zero-knowledge proofs and fully homomorphic encryption hide different things. The difference decides which applications are possible — and why a serious confidential chain uses both.

Correction — 1 September 2026. This post originally stated a 79-of-100 decryption threshold. The deployed figure is 24-of-100 in production ceremonies; 79-of-100 remains the design target. Whitepaper §7.1 states both figures and the path between them. The text below has been updated; this note records what changed.

On-chain privacy has become almost synonymous with zero-knowledge proofs — and that's earned. ZK is real, deployed, and powerful. But it has quietly narrowed what people assume privacy on a blockchain can be, and the gap it leaves is exactly the part most financial applications need.

The short version: ZK lets you prove things about data you hold. FHE lets a network compute on data nobody can read. Those are different capabilities, and the difference decides which applications are possible.

Prove without revealing, or compute without revealing — not the same thing.

01 /What ZK actually does

A zero-knowledge proof convinces a verifier that a statement about hidden data is true, without revealing the data. On-chain, that usually means you hold a secret — a note, a balance, a preimage — and you prove a fact about it ("this spend is valid," "this is a correct state transition") while keeping the secret to yourself.

This is genuinely strong, and it's the right tool for a large class of problems: private payments, membership proofs, validity rollups, identity. The defining feature is that the secret is yours. You know it; you prove things about it; the chain checks the proof.

The limit follows from that same feature. If the data is a secret only you hold, the network can't compute over it collaboratively while it stays hidden — a ZK proof needs a prover who knows the witness. When the interesting state belongs to no single party, "prove without revealing" runs out of room.

02 /What FHE adds

Fully homomorphic encryption changes the question from proving to computing. A contract runs directly on ciphertexts — adding, comparing, selecting over encrypted values — and returns an encrypted result, without ever decrypting. The network operates on data it cannot read.

That unlocks the case ZK alone can't reach: shared encrypted state. A value lives on-chain, gets updated by many parties, and stays hidden from all of them — including the validators processing the transactions. The examples are the ones that never worked on transparent chains: encrypted balances that still verify against the supply invariant; private orderbooks and sealed-bid auctions with nothing to front-run; confidential contract state no observer, and no operator, can see.

These aren't ZK applications with the privacy turned up. They're structurally different, because the secret doesn't belong to a single prover — it belongs to the encrypted state itself.

03 /This is not FHE vs. ZK

Here's what the tribal version of this debate gets wrong: you don't pick one. The honest architecture uses each where it's strongest. Celar is three tiers, one chain:

TIER_01
FHE state

Contracts compute on encrypted balances and state — the compute-on-hidden-data layer no ZK-only chain can offer.

TIER_02
Stealth addressing

Recipient unlinkability — every payment lands on a fresh one-time address.

TIER_03
ZK shielded pool

Anonymity that holds even if every validator colludes — the one guarantee that must rest on cryptography alone. Exactly ZK's job.

So the interesting question was never "which primitive wins." It's "which primitive for which guarantee" — and a serious confidential chain needs more than one.

04 /What it costs, and what still leaks

FHE isn't free. Computing on ciphertexts is far heavier than on plaintext, and making it practical is real engineering — which is why Celar puts the FHE work behind precompiles and a threshold committee rather than pretending the cost away. The decryption capability never sits with one party:

(c, t) = (100, 24)  // committee size, deployed decryption threshold
shares refresh every epoch · partials signed, attributable, slashable

And even then, some things still leak — transaction timing, the fee tier, and in v1, call targets. We don't bury that. Celar publishes a full leakage matrix and a PF-1 privacy label that marks its own weak cells EXPOSED, because a privacy claim you can't check isn't worth much. Compute-on-encrypted-state is a big step, not a magic eraser — and the useful version of this technology is the one that tells you where its edges are.

05 /Why this matters

The next wave of on-chain applications — confidential DeFi, RWAs with real reporting constraints, anything with a counterparty who shouldn't see your position — needs computation over data that stays hidden from the people running the chain. That's the FHE-shaped hole in a ZK-only world.

Celar's bet is that you get there by combining primitives honestly and publishing exactly what each one does and doesn't hide. Prove and compute — and say where the edges are.


CONTACT — press@celar.network · LIVE METRIC — celar.network/health · $CELAR