Proving something usually means handing it over. You show an ID to prove your age. You share a statement to prove what you hold. You publish the data so anyone can redo the math. Each time, proving a fact means exposing the information behind it.
A zero-knowledge proof breaks that link. It lets one party convince another that a statement is true without revealing the information that makes it true. The verifier ends up sure of the claim and no wiser about the data.
This piece stays vendor-neutral. It explains what a zero-knowledge proof is, the properties it needs, where blockchains use the idea, and where its guarantee ends. You do not need any cryptography to follow it. You need to know which question a proof answers, and which questions it leaves open.
Key Takeaways
- A zero-knowledge proof convinces a verifier that a statement is true without revealing the data that makes it true.
- A sound system lets an honest prover convince, stops a cheater in all but negligible cases, and reveals nothing more.
- Non-interactive proofs can be published once and checked by anyone, including a smart contract.
- A proof is only as good as the statement it encodes: correct math about the wrong question still answers the wrong question.
- A Merkle inclusion proof shows that data was included; a zero-knowledge proof can keep the data hidden.
What a Zero-Knowledge Proof Is
Every zero-knowledge proof has a prover and a verifier. The prover knows something and wants to show that a statement about it is true. The verifier wants to be convinced without being shown the secret itself.
The statement can be simple or complex. It might be "I know the password to this account", or "this transfer spends funds I actually control", or "this computation, run on data you cannot see, produced this output". In each case the secret, often called the witness, stays with the prover. What travels to the verifier is the proof.
The verifier runs a check on that proof and gets a yes or a no. You learn the claim is true, nothing more. Not the password, not the holdings, not the inputs. That is the zero in zero-knowledge: the verifier gains no knowledge beyond the fact that the statement holds.
A Simple Way to Picture It
A classic teaching example uses a pair of balls that look identical to you but differ in color. Your friend claims to tell them apart. You want proof of that, but you do not want to be told which ball is which.
So you hold the balls behind your back, a ball in each hand. You either swap them or leave them, without saying which, and show them again. Your friend says whether you swapped. If they really see the difference, they answer correctly every time. If they cannot, they are guessing.
A single round proves little, because a guess can be right. Repeat the round, though. Luck runs out fast.
After enough rounds you are convinced, and you still do not know which ball is which. You learned that your friend can tell them apart. You learned nothing about how. Real zero-knowledge proofs run on mathematics rather than colored balls, but the logic carries over: repeated checks that a cheater would fail, and no step that gives the secret away.
The Properties a Proof Needs
Cryptographers define a zero-knowledge proof through the properties below. A system that misses any of them is something else, even if it is called a proof.
- Completeness. If the statement is true and the prover follows the rules, the verifier accepts. An honest prover can always make the case.
- Soundness. If the statement is false, a cheating prover cannot convince the verifier, except with a probability so small that it can be ignored in practice.
- Zero-knowledge. The verifier learns nothing beyond the fact that the statement is true.
The last property sounds abstract, so here it is plainly. Whatever the verifier sees during the check, they could have generated on their own, without the secret. If the record of a check can be produced without the secret, it cannot be carrying the secret.
Soundness is the property you rely on as the person checking. Zero-knowledge is the property the prover relies on. A proof that is sound but leaks data protects you and exposes them. A proof that hides everything but is not sound protects nobody. You need both.
Interactive and Non-Interactive Proofs
The ball example is interactive. The verifier sends a challenge, the prover answers, and the two repeat. That works when both sides are present at the same time. It does not scale. A blockchain cannot hold a live conversation with every user who wants to check something.
Non-interactive proofs solve this. The prover produces a single proof, and anyone can check it later without talking to the prover.
The challenge is derived from the data itself instead of being sent by a live verifier. Once the proof exists, it can be published, stored and checked as often as needed.
That is what makes zero-knowledge proofs practical on-chain. A smart contract can play the verifier. It runs a fixed checking routine on the proof and accepts or rejects it, the same way for everyone. The check is public; the data is not. Anyone can rerun the check and get the same answer.
The family names SNARK and STARK come up in this area. Both are ways of building non-interactive proofs that are small and fast to verify. They differ in how they are set up and in how large their proofs are.
Some constructions depend on an initial setup whose secret inputs must be destroyed afterwards; others are designed to avoid that step, usually at the cost of larger proofs. For reading a project's claims, the more useful question is not which family it uses. It is what statement the proof actually covers.
Where Blockchains Use Zero-Knowledge Proofs
A public chain is visible by default. Every balance and every transfer can be read by anyone. Zero-knowledge proofs let a system keep the check public while keeping some of the data private, or let it compress a large amount of work into a short proof. The uses below follow from those abilities.
Scaling: proving a batch was handled correctly
A zero-knowledge rollup processes many transactions outside the main chain, then posts a compact proof that all of them followed the rules. The main chain checks the proof instead of re-executing every transaction. If the proof verifies, the new state is accepted. The work happens elsewhere. The guarantee lands on-chain.
Private transfers: proving validity without the details
A private payment system can use a zero-knowledge proof to show that a transfer is valid: the sender controls the funds, the amounts add up, and nothing was spent twice. The chain verifies that proof without learning who paid whom or how much. Validity is public. The details are not.
Credentials: proving a fact about yourself
Identity is an intuitive case. A proof can show that you meet a requirement, such as being above a minimum age or holding a credential from a trusted issuer, without revealing your name, your date of birth or the document itself. The checker learns that the condition is met and keeps no copy of the data that met it.
Reserves: proving totals without exposing accounts
Zero-knowledge proofs can also extend a proof of reserves. A plain Merkle-tree proof lets you confirm that your own entry was included in a published total. A zero-knowledge version can go further. It can show that the total was computed correctly and that no negative entries were hidden inside it, while revealing no individual account. Our guide to what a proof of reserves can and cannot show covers the reserves side in detail.
The two are easy to confuse because both prove something about data you cannot fully see. The difference is what you get to see along the way.
What a Zero-Knowledge Proof Does Not Prove
A valid proof is strong evidence of exactly one thing: that the statement it encodes is true. Everything around that statement sits outside the proof. That is where careful reading starts.
It does not prove the statement was the right one. A proof answers the question it was built to answer. If a system proves that a calculation followed a rule, the proof says nothing about whether that rule is the one you were promised. Read the statement, not the word proof.
It does not prove the inputs were honest. A proof often covers a computation over data that came from somewhere else: a price, a record, a reading from another system. The proof can show that the computation was correct for those inputs. It cannot show that the inputs matched reality. Wrong data in, valid proof out.
It does not rule out bugs in the circuit. The statement a proof covers is written as code, often called a circuit, and that code can contain mistakes like any other. A flaw there can let a proof verify for something its authors never meant to allow. That is the same reason smart contracts get reviewed, and our piece on what a smart contract audit does and doesn't prove explains how such reviews work and where they stop.
It does not cover the setup. Where a proof system depends on an initial setup, its soundness rests on that setup having been carried out properly. That is a question about process, not about any single proof.
And it does not tell you about intentions. A proof verifies math, not motives. A team can publish valid proofs about one part of a system while making decisions elsewhere that no proof touches.
Zero-Knowledge Proofs Next to Other Ways to Verify
Zero-knowledge proofs are one way to make a system checkable. They are not the only one, and each approach asks you to rely on something different.
| Approach | What you can check | What you still rely on |
|---|---|---|
| Open data | Every input and every step, by recomputing it yourself | Your own effort to do the recomputation |
| Merkle inclusion proof | That a specific item is part of a published set | That the set itself was built honestly and completely |
| Zero-knowledge proof | That a stated claim or computation is true, without seeing the data | The circuit, the inputs and, for some systems, the setup |
| Trusted execution environment | A signed attestation that specific code produced a result inside protected hardware | The isolation of the hardware and the keys that sign the attestation |
A trusted execution environment, often shortened to TEE, is a protected area of a processor. Code runs inside it, isolated from the rest of the machine, and the hardware can sign a statement, called an attestation, about what ran and what it produced. It is a different route to verifiable computation. The guarantee rests on the hardware and its signing keys rather than on a mathematical proof about the computation itself.
Neither route is a shortcut. Each one moves trust to a different place. Trust moves. It does not vanish. A clear claim tells you where.
What This Means When You Evaluate a Prop Firm
A prop firm that calls its process verifiable is making a claim you can test. The useful first step is to ask what kind of verification it means. Proof is a broad word. A zero-knowledge proof, a trusted execution environment and a published dataset all earn the label in different ways, and they leave different questions open. Ask which one.
Before you rely on the label, pin down the following:
- what the proof covers: which calculations, which rules, which outcomes;
- which method produces it: a zero-knowledge proof, a trusted execution environment, or open data you can recompute;
- where you can check it yourself, without relying on the firm's own summary.
The FAQ describes ROFL as a cryptographic verification layer that independently re-executes every evaluation and order decision inside a Trusted Execution Environment (TEE), the approach in the last row of the table above. Neither page describes these proofs as zero-knowledge proofs, and this article does not claim that they are. Our post on why we chose ROFL explains the reasoning behind that design. The transparency and on-chain proofs documentation lists the wallets and smart contracts behind the platform.
Conclusion
A zero-knowledge proof lets you check a claim without seeing the data behind it. That makes it powerful, and it also makes it easy to over-read. The proof settles a single question: whether a specific statement is true. It does not settle whether that statement was the right one, whether the inputs were honest, or whether the circuit was built correctly.
So the real decision is where to place your trust, not whether to trust at all. When a platform says its process is proven, find out what the proof covers and which method produced it. Then check the part you can check yourself.
FAQ
Is a zero-knowledge proof the same as encryption?
No. Encryption hides data so that only someone with the key can read it later. A zero-knowledge proof does not hide data for later reading; it proves a statement about data without revealing that data at all. A system can use both: encrypt what it stores, and use a proof to show that a rule was followed without decrypting anything.
Can a zero-knowledge proof be faked?
Not if the proof system is sound and correctly built. Soundness means a false statement passes only with a probability small enough to ignore. The weak spots lie outside the math rather than in it: a bug in the circuit, a compromised setup in systems that need one, or dishonest inputs. Those are the places to look when you assess a proof.
Does zero-knowledge mean the verifier learns nothing at all?
No. The verifier learns that the statement is true and nothing beyond it. If the statement itself is revealing, the proof does not hide that part. Proving that a value clears a threshold tells the verifier exactly that much, by design. What stays hidden is the value itself and anything else the prover used.
Why are zero-knowledge proofs used for scaling if they are about privacy?
Because the same idea does both jobs. A proof can hide data, and it can also stand in for work. A short proof is quick to check, while re-running every transaction it covers is slow and costly. Rollups rely on that second ability: the proof replaces re-execution, whether or not any data is kept private.
Do I need to understand the math to rely on a proof?
No more than you need to read a contract's code to use it. What you do need is the statement the proof covers, the method behind it and a place where someone other than the party that produced it can check it. If any of those is missing, you are relying on a description, not a proof.
