Skip to content
Blockchain LabTHE VENTURE STUDIO

LibraryPrivacy2020Design paperCorpus record

Zexe: Enabling Decentralized Private Computation

Zexe. Sean Bowe, Alessandro Chiesa, Matthew Green, Ian Miers, Pratyush Mishra and Howard Wu.

A model for private computation over records. Each record has a birth predicate and a death predicate. A transaction proves that some records died and others were born, without showing which, or showing the data.

Zexe lets someone prove that private records were consumed and created according to their predicates, without showing the records or which ones they were. The computation happens off-chain. The ledger sees a proof.

The five-minute read

Records, not accounts

The state is a set of committed records. Spending is the death of some records and the birth of others. There is no public account balance to read.

Two predicates

A death predicate says when a record may be consumed. A birth predicate says when a new record may appear. Applications are written as those rules, not as arbitrary on-chain bytecode in the paper's model.

Offline proving

The user does the heavy work and posts a succinct proof. The chain verifies the proof and the nullifiers that stop a record being killed twice.

Zerocash is the payment special case

A simple transfer is a Zexe program. The paper's ambition is every state transition that can be written as record predicates, which includes trades and votes, and also includes bugs in those predicates.

One action, walked through

  1. A user holds secrets that open one or more records committed on the ledger.
  2. They compute the new records off-chain, satisfying birth and death predicates.
  3. They publish nullifiers for the consumed records and commitments for the new ones, plus a proof.
  4. The ledger rejects a nullifier it has seen before, and rejects a proof that does not verify.
  5. Observers learn that some valid transition happened, not which records, and not the data inside them.

The argument, unpacked

The predicates are the program

Privacy does not stop a bad rule. If the death predicate allows a record to be consumed without conserving value, the proof will hide the theft and the ledger will accept it. Review moves to the predicate, which users cannot watch execute in the clear.

Counterparty privacy is not observer privacy

Someone who already knows the secret, because they were the other side of the trade, is not blinded by the proof. The paper hides state from the public ledger. It does not hide a deal from its parties.

What has to be true

  • The proof system is sound for the predicate circuit. A broken SNARK breaks every application at once.
  • Nullifiers are deterministic functions of the record secret, so a double death collides and is rejected.
  • Commitments hide the record data. A commitment that includes a public memo may leak it.
  • Users can actually produce the proofs on their own hardware, or the 'offline' step quietly becomes a trusted prover.

What happened after the paper

Aleo and other private-computation projects cite Zexe as the model and then change the proof system, the record format, and the fees. The 2018 paper remains the right picture of birth and death predicates. It is not a description of any of those networks' live circuits.

What to check before you use the idea

  • What is the birth predicate, and what is the death predicate?
  • Are nullifiers unique per record, and where are they stored?
  • Who generates the proof: the user or a service?
  • Which SNARK sits underneath, and does it have a setup?

Terms

Record
A committed piece of state with rules for how it may be created and consumed.
Nullifier
A public marker that a record has been consumed, which does not reveal which record.

The problem the paper names

Zerocash hides payments of one asset. Zexe asks for the same offline-proof pattern when the state transition is a program: a trade, a vote, a custom asset.

What the design proposes

  • Records sit committed on a ledger.
  • A transaction proves knowledge of records that satisfy the predicates, and of a newly created set.
  • The heavy computation happens off-chain. The chain checks a proof.

How the mechanism is specified

  • Birth predicates constrain creation. Death predicates constrain consumption. That split is the programming model.
  • Privacy is over the data and the which-record relation. The fact that a proof was posted is public.
  • The paper's efficiency depends on the proof system underneath. The model and the SNARK are separable.

What this page does not treat as proven

  • Aleo and other later systems are implementations, with their own curves, fees, and failures.
  • Predicates are programs. A private bug is still a bug.
  • This does not hide activity from an observer who learns the secret by being a counterparty.

Why a venture studio still reads it

If a team says private computation, ask whether the chain sees inputs or only a proof, and what the birth and death rules actually allow. Zexe is the template for that question.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.