Do ZK Proofs Make Blockchain Transactions Private?

Did you know?

Did you know? A zero-knowledge proof can hide the answer to a secret calculation while the blockchain still reveals which wallet submitted the proof, when it happened and which contract was called. Cryptographic secrecy and transaction privacy are related, but they are not the same thing.

Consider Tricia at a fictional school robotics competition. She wants to show that her verified science score meets a qualifying threshold without publishing the exact score. A properly designed zero-knowledge proof might establish that the score passes the threshold while concealing the score itself. Yet a public event saying “Tricia qualified at 3:02 pm” would immediately disclose other information the proof never promised to hide.

Quick answer: zero-knowledge refers to what a specified proof reveals about private witness data relative to a public statement. A blockchain application can still publish addresses, balances, transaction details, calldata, events or metadata outside the proof. In particular, using validity proofs in a ZK-rollup does not automatically make the rollup’s user transactions confidential.

Pick a reading route

1. What a zero-knowledge proof actually claims
2. A school qualification without revealing the mark
3. Public inputs still mean public information
4. A ZK-rollup is primarily a scaling architecture
5. A validity proof is not necessarily a privacy proof
6. Addresses, balances and events may remain visible
7. A timestamp and a pattern can reveal more than expected
8. The wallet’s network connections matter too
9. A commitment is not the underlying secret
10. The fictional qualification proof: what is public?
11. Data availability and privacy solve different problems
12. A public withdrawal can expose a hidden relationship
13. Privacy depends on what the application chooses to disclose
14. Five claims to question before repeating them
15. Three learners compare proof, public event and source data
16. Zero knowledge is one guarantee inside a larger system
FAQ
Primary sources and further reading

1. What a zero-knowledge proof actually claims

In a proof system, a prover convinces a verifier that a statement satisfies specified rules. The prover may know private inputs called a witness, while the verifier sees a public statement and a proof. If the system has the required zero-knowledge property, the proof reveals no additional information about those private inputs beyond what is implied by the public statement. Soundness and correct implementation are separate essential requirements.

That is more precise than “nothing can ever be learned.” If the public statement is “Tricia’s score is at least 70,” everyone who verifies it learns that the score is at least 70. They should not automatically learn whether the actual score was 74 or 92. The choice of public statement defines part of what is intentionally disclosed.

2. A school qualification without revealing the mark

Suppose Tricia’s fictional, school-certified mark is 82. The club requires a mark of at least 70. An educational circuit can be designed to verify a committed score and the inequality 82 ≥ 70 without placing the exact value 82 in the public output. The proof is valid only when its circuit, witness binding and issuer or data authenticity rules are satisfied.

The design must not let Tricia simply invent a different private number and claim it was issued by the school. A mathematically valid proof of an unchecked invented score would not establish the school qualification. Cryptographic consistency and trustworthy input provenance are separate questions, just as a correct calculator cannot prove who wrote the number on its screen.

3. Public inputs still mean public information

Developers choose which values are public to the verifier. A public group identifier, threshold, timestamp, account address or commitment can be necessary for correct verification, but it also becomes visible to anyone who can inspect the proof or its on-chain submission. Zero-knowledge does not erase those chosen public inputs.

If the public part includes both the exact score and the student’s identity, the proof has nothing left to hide about those items even if the proving algorithm is technically zero-knowledge. This is why a good privacy review starts with a plain table of what will be public, what stays private and what could be inferred from the revealed facts.

4. A ZK-rollup is primarily a scaling architecture

On Ethereum, ZK-rollups are scaling systems that execute transactions off the base layer and submit validity proofs for accepted state transitions. The proof helps the base layer verify that batches follow the rollup’s computation rules without re-executing every individual action. This cryptographic efficiency is valuable for throughput and security.

However, many rollups publish enough transaction or state data to permit independent reconstruction of the layer-2 state. Ethereum’s official scaling documentation explicitly distinguishes proof-based correctness from the privacy of the published data. The label ZK-rollup does not itself promise invisible balances, anonymous transfers or secret recipient addresses.

5. A validity proof is not necessarily a privacy proof

Some proving systems emphasize compactness and efficient verification. Others also implement the stronger zero-knowledge property that hides witness information. Even a proof with sound zero-knowledge guarantees only hides what its formal statement and implementation say it hides. A proof that a batch was computed correctly can coexist with very public records of the transactions inside that batch.

The term zkEVM can therefore mislead readers if they assume that every EVM-compatible validity proof provides end-to-end anonymity. The Ethereum privacy roadmap discusses this nuance. Ask what is public at the transaction, account and network level rather than infer confidentiality from an acronym.

6. Addresses, balances and events may remain visible

Ordinary Ethereum transactions expose addresses and execution-related information, and public ERC-20 transfers commonly generate events that explorers index. An application that uses an ordinary public wallet to submit a proof still generates a public transaction associated with that wallet unless it has a separate mechanism to control what is disclosed.

A cryptographic proof can correctly hide a private eligibility score while a visible contract event reveals the student’s wallet or a success flag. Nothing contradictory has happened. The proof and the surrounding transaction are different channels carrying different information.

7. A timestamp and a pattern can reveal more than expected

Information can leak through transaction time, frequency, gas-paying account, public recipients and correlations with external events. An observer may not need the witness to make a plausible inference about who participated. That inference can be uncertain, but it still challenges sweeping claims that a particular proof made the entire action anonymous.

For example, if exactly one registered team submitted a proof a minute after a publicly announced finalist, readers might infer the participant from timing. The circuit cannot undo what the organiser announced. Privacy depends on the wider workflow, including operational metadata, not solely on proof mathematics.

8. The wallet’s network connections matter too

Public-chain privacy also depends on how wallets retrieve balances and communicate with network services. RPC providers may see which addresses are queried from a connection, while a website may collect account data, session identifiers or analytics events. These are off-chain observation paths and are not automatically hidden by an on-chain zero-knowledge circuit.

Ethereum’s 2026 educational writing on private wallets and ZK applications stresses that privacy can be undermined by ordinary product design. Learning the concept should make readers ask about data collection notices and access permissions, rather than assume that a mathematically private witness means no other system is observing anything.

9. A commitment is not the underlying secret

Privacy applications may publish a cryptographic commitment to an underlying value or membership record. A commitment can support later verification without disclosing the original data directly, provided the scheme is used correctly. However, commitments can still be correlated by reuse, public metadata or an overly small set of possible inputs.

A beginner should distinguish “the commitment hides a value” from “all uses of this commitment are untraceable.” An app can accidentally reveal the link through its public identifiers or events. Correct cryptography can coexist with avoidable product-level information leakage.

10. The fictional qualification proof: what is public?

The following table is an original teaching example about a school activity, not a deployed proof circuit or observed record. It shows why a correct private inequality proof can coexist with public information that was disclosed elsewhere. Read each row separately, then ask what the organiser could change without changing the mathematical threshold.

Students should write down the actual privacy promise: “The exact score is not disclosed by the proof.” They should not expand it into “nobody can know Tricia joined the robotics competition” if the application publicly lists her name.

Illustrative item	Possible public visibility	What the proof does or does not hide
Score 82	Private witness in an appropriate circuit	Can remain hidden if not included in public inputs
Threshold 70	Public statement	Verifier learns the threshold and qualification result
Qualifies = true	Public output	Verifier learns the student met the condition
Wallet that submitted proof	Public transaction address in a normal submission	Not automatically hidden by the witness proof
Submission time	Public chain metadata	Still observable at the transaction layer
Name announced by organiser	Public school announcement	Outside the cryptographic proof’s confidentiality guarantee

11. Data availability and privacy solve different problems

Rollups need appropriate data availability so that independent participants can reconstruct state and apply the system’s security rules. Publishing transaction data to Ethereum as calldata or temporary blobs provides availability under defined assumptions. That availability is useful for verification, yet data made public for reconstruction may also reveal transaction facts.

Privacy-preserving systems can use designs in which sensitive values are represented by commitments and proofs, with other data available for independent verification. Such designs require careful architecture. Simply replacing calldata with blobs does not turn published transaction data into a secret; temporary storage and confidentiality are different properties.

12. A public withdrawal can expose a hidden relationship

Even if an application protects the inputs to a private computation, an ordinary visible bridge withdrawal or payment on a public chain can reveal accounts, amounts and timing associated with the next stage. The separate stage might undo much of the user’s hoped-for confidentiality if it makes the relationship obvious.

Read the claim narrowly. A proof may establish that a withdrawal is authorised without revealing the reason, but the public destination and settlement record can still be visible. A realistic explanation should state which chain and which part of the workflow disclose information.

13. Privacy depends on what the application chooses to disclose

An application’s privacy policy is not interchangeable with the cryptographic zero-knowledge property. The former governs information handling by an operator; the latter concerns the proof transcript relative to a specific statement. An operator can collect account identifiers, publish event details or share analytics even when a proof hides its witness.

Likewise, using a privacy-related brand name does not verify the implementation. Good readers should look for technical documentation describing public inputs, the actual circuit, verifier contract, audit scope and operational data-handling practices. No one screenshot can establish all of those properties.

14. Five claims to question before repeating them

“It uses a ZK-rollup, so transfers are anonymous” is unsupported without a specific privacy design. “The verifier learns absolutely nothing” ignores the chosen public statement. “A commitment can never be linked” ignores reused identifiers and surrounding data. “Proof verified means the school issued this score” ignores input authenticity. “The website cannot track me” ignores off-chain sessions and analytics.

These are not reasons to dismiss zero-knowledge technology. They are reasons to appreciate exactly what it can prove. The responsible standard is to identify the hidden witness, the public statement, the trust assumptions and the data emitted around the proof.

15. Three learners compare proof, public event and source data

Alicia receives a fictional proof transcript showing only “qualifies = true.” Kai Kai receives a public event saying that wallet 0xSchoolClub submitted the proof at 15:02. Tricia receives a school record confirming her score is 82, which is not published on the blockchain. Ask what each document proves and whether any of them alone proves the real-world identity of the wallet owner.

Change the problem: the verifier’s public input now includes score = 82. Does zero-knowledge still hide that mark from viewers of the proof transaction? No; the application itself disclosed it. Next change the school record to an unsigned handwritten note. Can a correct inequality proof establish that the school actually awarded the mark? Not without an appropriate trusted input-binding mechanism.

16. Zero knowledge is one guarantee inside a larger system

The practical reader should keep three questions separate: is the mathematical statement correctly verified, are the intended private inputs hidden, and what other information is visible? A good protocol can satisfy the first while failing the second or third. A good educational explanation never bundles these into a claim of automatic anonymity.

Zero-knowledge proofs are useful precisely because they allow selective disclosure and verifiable computation. Their promise becomes stronger, not weaker, when applications state clearly what remains public. Privacy is an end-to-end property that requires attention to blockchain records, software design and operational habits as well as cryptography.

Reader FAQs

Does ZK mean no one can see my transaction?

No. A zero-knowledge proof may hide specific witness data. Public-chain transaction fields, events and network metadata can remain visible.

Are all ZK-rollups anonymous networks?

No. Their validity proofs support correctness and scaling; transaction privacy requires additional measures and suitable data design.

Can a proof reveal some information intentionally?

Yes. The public statement and public inputs are disclosed by design. Zero knowledge concerns what is learned beyond that information.

Can a valid proof be based on a dishonest off-chain score?

If the application does not correctly bind the witness to a trusted issuer or record, a valid proof of a condition need not establish the claimed real-world source.

Does a blob make transaction data private?

No. Blob data are made available under Ethereum’s data availability rules. Retention duration and confidentiality are distinct concepts.

Is a proof enough to establish an application’s privacy policy?

No. Review on-chain disclosures, wallet/RPC connections, analytics and organisational information practices.

Primary sources and further reading

Scope note: The school marks, club participants, wallet names and examples are fictional; they are not student records or observed cryptocurrency transactions. Zero-knowledge properties depend on the actual statement, proof system, public inputs and deployment. This discussion is educational rather than a privacy guarantee for any named application.

How Blockchain Technology Works | Why Zero-Knowledge Proofs Do Not Make Every Transaction Private