Ethereum Privacy Apps: What Zero-Knowledge Proofs Hide

Ethereum privacy apps use zero-knowledge (ZK) proofs to establish a specific fact—such as membership in an approved group—without disclosing the secret that supports it. In a common pattern, a user proves membership in a Merkle tree and publishes a one-use nullifier; a contract verifies the proof without learning which member acted. That can support private voting, claims or access checks. It does not make the whole transaction anonymous: public inputs, contract activity, wallet funding, network data and app logs can still reveal links. ZK is a precise privacy tool, not a blanket anonymity switch.

What a zero-knowledge proof does—and does not—hide

A zero-knowledge proof lets a prover convince a verifier that a defined statement is true without revealing the private witness used to prove it. The application chooses the statement. The proof hides only the values designated as private inputs; values exposed as public inputs, transaction fields, events or contract state remain visible.

That distinction matters on Ethereum. The base layer is public: addresses, balances, transactions, contract calls and events can be inspected. A privacy app can move selected information into a proof, but it does not rewrite the public history around that proof. The Ethereum.org builder guide to privacy apps describes this app-level approach and its limits.

For example, a membership proof may demonstrate that a user belongs to an eligible group without revealing which group member they are. That does not automatically conceal the user's wallet address, the action’s timing, a payment amount, or any public calldata. Those fields are private only if the complete protocol and transaction flow keep them private.

How an anonymous-membership proof works

A common design for anonymous voting, one-time claims or gated access follows four steps:

Register a commitment. A user’s client derives a commitment from a secret and the app records it as one leaf in a Merkle tree. The secret itself should remain offchain.
Prove group membership. Later, the client generates a proof that it knows a secret corresponding to one leaf under the current tree root. The proof does not disclose which leaf, assuming the circuit and implementation are sound.
Create a nullifier. The client derives a public, one-use value for the relevant action. The contract records it and rejects a second use of that same nullifier, limiting repeated signaling within that protocol’s defined scope.
Verify and act. The contract checks the proof against the root and the action’s public inputs, then accepts the vote, claim or access request without receiving the private witness.

This pattern is documented by Semaphore V4, which supports anonymous group membership proofs and uses nullifiers to prevent double signaling. A valid proof establishes the circuit’s statement; it does not prove that the surrounding app, wallet or data-handling process is safe.

Which parts run onchain?

In a typical implementation, the client stores the secret and generates the witness and proof offchain. The chain holds the public group commitment or root, receives the proof and public inputs, and runs a verifier contract. An indexer may help clients find current roots or events, but it becomes another service whose data access and logging practices belong in the threat model.

Account-abstraction components can improve transaction submission. Under ERC-4337, bundlers and paymasters can relay or sponsor user operations. A sponsor may help avoid funding an action from the same wallet used for registration, but sponsorship does not erase transaction timing, network-level metadata or correlations elsewhere in the flow. It is a possible mitigation, not a privacy guarantee.

What can still leak?

Layer	What may remain visible	Why it matters
Contract and transaction	Sender, called contract, timing, gas, public inputs, events and any data placed in calldata or storage	Observers can correlate actions even when a proof hides its witness.
Anonymity set	The number and activity of plausible group members	A proof from a tiny or inactive group has fewer people to blend into.
Wallet and funding	Reused addresses, deposits, withdrawals and timing	A public funding path can reconnect a private action to a known identity.
Network and interface	RPC requests, IP address, browser session, analytics and error logs	The application or its providers can observe data the proof never sees.
User’s secret	Leaked notes, backups, screenshots or compromised devices	If the secret or witness is exposed, cryptographic privacy may not help.

The effective anonymity set is not just the number of registered leaves. Timing, common funding sources, repeated wallet use and a distinctive action can shrink the practical crowd. The Ethereum.org guide specifically warns that privacy can be lost through wallet reuse, traceable funding, IP/RPC exposure, telemetry and public circuit inputs.

Pick the privacy primitive for the data you need to protect

“Private transaction” is too broad to be a useful requirement. An anonymous-membership proof hides which eligible member performed a defined action. A stealth-address design addresses a different problem: making it harder to link a recipient’s public identity to a fresh receiving address. ERC-5564 standardizes a stealth-address mechanism, but its announcement is still an onchain event; using a stealth address does not by itself conceal every transfer detail or network trace.

Write the requirement in terms of an observer and a field: “A public chain observer should not learn which registered voter cast this ballot,” for example, is more testable than “make voting private.” Also state what remains public and which assumptions—such as group size, trusted setup, relayer operation or client security—the design relies on.

For adjacent context, our EU Digital Identity Wallet guide covers the credential and identity side of privacy questions. Privacy and user understanding are separate design problems: our ERC-7730 clear-signing guide looks at making Ethereum transaction intent easier to inspect before signing.

A practical review checklist for builders

Specify the privacy claim. Name the observer, the protected field, the transaction stage and the conditions under which the claim holds.
Inventory public data. Review circuit public inputs, calldata, emitted events, contract storage, explorer-visible transactions and indexer queries.
Size and monitor the anonymity set. Define minimum viable group conditions and consider timing or behavioral correlation, not only tree size.
Scope nullifiers carefully. Bind them to the right app and action so one proof cannot be replayed across unrelated polls or domains, while still enforcing the intended one-use rule.
Protect secrets and operational data. Review local storage, recovery, RPCs, analytics, support logs, relayers and paymasters—not only the Solidity verifier.
Test the whole flow. Have the circuit, contracts and integration independently reviewed; validate privacy assumptions with realistic user journeys and adversarial cases.

Frequently asked questions

Do zero-knowledge apps make Ethereum users anonymous?

No. A proof can hide a particular witness while the transaction, public inputs, funding path, timing or network metadata remain linkable. Anonymity depends on the whole application and transaction flow.

Can a ZK proof hide a wallet address?

Only if the protocol is designed to keep the address out of the public statement and the surrounding transaction does not re-link it. A membership proof alone does not conceal the account that submitted the transaction.

Does a larger anonymity set guarantee privacy?

No. More plausible participants can improve the crowd a user blends into, but funding, timing, repeated behavior or leaked app data can still expose a link. Set size is one assumption to test, not a complete privacy metric.

Sources

Ethereum.org: How to build privacy apps on Ethereum with zero-knowledge proofs — published May 11, 2026.
Ethereum.org: Zero-knowledge proofs — proof fundamentals.
Semaphore V4 documentation — anonymous membership and nullifiers.
ERC-4337: Account Abstraction Using Alt Mempool — bundlers and paymasters.
ERC-5564: Stealth Addresses — recipient-side address privacy.

Building an Ethereum product that needs selective disclosure, private membership or a defensible threat model? Talk with SignorCrypto about the architecture and integration choices before transaction metadata or user data becomes a liability.