Zero-Knowledge Proofs and GDPR: A Guide for European Developers

A Berlin fintech wants to know whether a new customer is over eighteen. The obvious implementation collects a date of birth, stores it, and checks it. Under GDPR, that is more personal data than the question requires — and it comes with retention schedules, access requests, and deletion workflows attached. A zero-knowledge proof offers a different shape: the user proves the statement "I am over eighteen" and the verifier learns nothing else. Not the birthday. Not the name. Just the fact.

That is an appealing pitch for European teams, and it is partly true. ZK is a real tool for data minimisation and for reducing what you must erase later. It is not a compliance shortcut, and a few popular versions of the pitch are wrong enough to cause trouble in a supervisory audit. Here is how the pieces actually fit together.

What GDPR Actually Asks of You

Two principles do most of the work in this discussion. Article 5(1)(c) requires personal data to be adequate, relevant, and limited to what is necessary for the purpose. Article 5(1)(e) limits how long you keep it. Article 17 then gives people the right to erasure when there is no remaining lawful basis.

Notice the pattern: both problems are caused by collection. If a date of birth never reaches your database, you have nothing to minimise and nothing to delete. Most compliance burden in verification flows comes from data you did not need in the first place, and that is exactly the surface ZK proofs shrink.

The Core Move: Prove a Property, Not a Record

A zero-knowledge proof lets a prover convince a verifier that a statement is true, without revealing why it is true. In circuit terms, the prover holds a private witness — the birth date, the account balance, the Merkle path — and the verifier sees only the public inputs and a short proof.

Three properties matter for engineering decisions. Completeness means honest provers can always convince the verifier. Soundness means a dishonest prover cannot fake a valid proof. Zero-knowledge means the proof reveals nothing beyond the truth of the statement.

Concretely: a user's birth date sits in a signed credential on their phone. Your circuit checks that the date falls before today minus eighteen years, and that the credential is signed by a trusted issuer. Your server receives a proof and a boolean. That is the entire record you now hold. Your retention policy for "verification artefacts" can be measured in seconds rather than years.

Data Minimisation in Practice

The minimisation gain is straightforward, and it compounds. Verifiers that store proofs instead of source records end up with a much smaller breach surface, fewer fields in a subject access request, and a shorter list in your Article 30 records of processing.

• Verification servers store proofs and public inputs, not raw attributes. A leak of proofs is far less damaging than a leak of identity documents.
• Issuers can sign credentials once and stay out of individual transactions, which keeps them from becoming a central log of every check a user performs.
• Blockchains can hold commitments, nullifiers, and verification keys rather than names, dates, and document numbers.

The second bullet deserves emphasis. In many deployments the biggest privacy win is not the proof itself, but the fact that the issuer no longer needs to be online for every verification. Fewer parties touching the data means fewer processors, fewer transfer questions, and fewer places where something can go wrong.

Right to Erasure: What ZK Can and Cannot Fix

Erasure is where the enthusiasm needs tempering. ZK proofs do not make an immutable ledger erasable. If you wrote a personal data point into a smart contract, no circuit will take it back out.

What ZK does is keep you from needing to write it there. An architecture that works: personal data lives in an off-chain store you control, and the chain holds only a commitment — a hash, or a Pedersen commitment — with proofs of correct updates. Deleting the off-chain record and its associated key material breaks ordinary access.

Be careful with the phrase "cryptographically erased". Hashing and encryption are not the same as anonymisation. Under the GDPR definition, data that can still be attributed to a person using additional information remains personal data, and destroying a key is a factual question, not an automatic legal conclusion.

So the honest framing is this: ZK shrinks the set of systems that ever hold personal data, which shrinks the erasure problem. It does not convert personal data into anonymous data by itself. Whether a given design reaches true anonymisation depends on how much auxiliary information exists, how the commitments are linked, and what a determined adversary can combine. If erasure is a central risk for your product, involve a data protection lawyer early and consider a DPIA under Article 35.

Patterns Worth Knowing

• Range proofs. Age over eighteen, income above a threshold, credit score in a band — without the underlying number.
• Set membership. Prove a wallet or user appears on an allowlist, or absent from a sanctions list, using a Merkle path.
• Selective disclosure credentials. Formats such as SD-JWT and BBS-style signatures let a holder reveal chosen attributes and hide the rest, with unlinkability between presentations.
• Nullifiers. Prove uniqueness — one vote, one claim, one account — without exposing identity. A nullifier is derived from a secret so it cannot be reused, but it should not be a stable public identifier across contexts.
• Aggregate proofs. Prove that a set of records is internally consistent, useful for audits and solvency reporting, without publishing the records.

Where It Leaks

Zero-knowledge is a property of a specific proof, not of your whole system. Several leaks are common.

Small input spaces. A proof that someone's birth year is in a two-year window narrows the field a lot. Choose thresholds that match the actual business need, not the smallest number you can prove.

Nullifiers as identifiers. If the same nullifier appears across services, it becomes a pseudonymous identifier and you are back to linkability problems. Derive nullifiers per context.

Metadata. Timing, IP addresses, and which verifier was used often reveal more than the proof. Proof generation takes seconds, and that timing can be a fingerprint on low-powered devices.

Revocation. A credential that can never be revoked is a liability for KYC use cases. Plan for revocation lists or short validity windows, and decide who can trigger them.

A Practical Checklist Before You Ship

1. Write down the question you are actually answering. "Is this person over eighteen?" is a proof. "What is this person's birthday?" is collection.
2. Decide what the verifier stores. If the answer is a proof, define a retention period and delete on schedule.
3. Keep personal data off-chain and off-ledger. Commitments only, with a documented key management plan.
4. Run a linkability review: can two proofs from the same user be tied together by a nullifier, an address, or timing?
5. Check your circuits for narrow ranges and equality checks that leak through the public inputs.
6. Document the legal basis, update your Article 30 records, and get a DPIA opinion if the processing is high risk.

None of this is legal advice, and supervisory authorities have not settled every question about on-chain commitments and pseudonymisation. Treat ZK as one strong instrument in a data protection by design programme — very good at reducing what you hold, and no substitute for deciding carefully whether you should hold it at all.

Photo: GregMontani / Pixabay