Blockchain and data protection are debated from many angles. This page collects the different positions — the EDPB's draft guidelines and the reactions to them, the views of data protection authorities, and contributions from academia and practice. Where a source is especially relevant to a specific question, a tag links to the corresponding aspect on the overview page.
There was hope that the EDPB's long-awaited guidelines would finally provide a framework for decentralised privacy by design and the legal certainty that blockchain projects need. That hope was disappointed.
Rather than showing how decentralised systems can deliver strong data protection, the draft engages neither in any depth with the range of available legal bases — from consent through contract to legal obligations — nor does it show how blockchain projects could distinguish themselves through good privacy by design. Instead of opening a path to compliance, it largely treats blockchains as a problem. Because the draft was so destructive in its effect, it triggered an unusually large and overwhelmingly critical body of feedback.
The draft formulates 16 recommendations, stresses data protection by design and by default, and recommends a DPIA before processing personal data on a blockchain. It treats hashes and identifiers broadly as personal data, misses the opportunity to provide clear guidance on controllers and processors (what it does say is rather confused), discourages permissionless chains, and insists that technical impossibility cannot excuse non-compliance — but misses that impossibility often also means a lack of control. Overall it offers little practical guidance on how compliance could actually be achieved. Official documents: Guidelines (PDF) · EDPB summary (PDF).
The consultation drew well over 150 published submissions. They come from across the spectrum and are, with few exceptions, critical of the draft's restrictiveness:
All submissions are published in full by the EU. Notable responses: Blockchain for Europe (BC4EU) · EUCI (with signatories) · GBBC · Alastria · Google · Aksoy & Cantisani (academic).
All reactions on the EDPB consultation page →BC4EU supports the GDPR's objectives but finds the draft "technology-prohibitive rather than technology-neutral", and sets out eight recommendations: distinct treatment for different DLT architectures; controller/processor roles that reflect decentralisation (sparing neutral infrastructure providers); recognising key deletion, zero-knowledge rollups and off-chain dereferencing under Art. 17; a contextual personal-data test (per Breyer/Recital 26); encouraging privacy-enhancing technologies; and clarifying that public accessibility is not, by itself, an international transfer. Full response (PDF).
"The suggestion … that the inability to delete personal data from a blockchain may require deletion of the entire blockchain is technically unfeasible, legally disproportionate, and incompatible with both EU constitutional principles and the structure of public blockchain networks. … As such, we find the Guidelines technology-prohibitive rather than technology-neutral."
The report behind the BC4EU response. It argues that the draft differs from the GDPR text and CJEU case-law in several respects — a too-broad definition of personal data, no reference to Lindqvist, limited consideration of eIDAS and financial regulation, and insufficient weight on proportionality — and goes beyond critique to show how good privacy by design can make blockchains a tool for data protection. Read the summary on the overview page or the full report (PDF).
"Blockchain-based systems are often motivated by resilience, censorship resistance, data sovereignty, and by the protection for privacy and fundamental rights that is at least equivalent to — or better than — centralised alternatives. Therefore, they should not be rejected on the basis of a restrictive, non-technology-neutral reading of the GDPR."
The binding interpretation of the GDPR comes from the Court of Justice — and recent case-law on identifiability is directly relevant to blockchains, where most on-chain data exists only as pseudonymous identifiers, hashes or commitments.
The case concerned the Single Resolution Board (SRB) sharing pseudonymised comments with Deloitte. What is clear after the ruling: pseudonymous data is not always personal data. There was no possibility for Deloitte to re-identify the data; however, the SRB would have been able to do so, because it still held the original, fully personalised data. The Court left open why it did not consider the SRB's ability to re-identify the pseudonymous data — three readings are possible:
Missing to provide a stringent reasoning could, on the one hand, mislead actors into prematurely treating data as non-personal data, and, on the other hand, it offered data protection authorities the possibility to dismiss the case as an "Einzelfallentscheidung" (single-case decision) and ignore it. Given that the CJEU does not endorse a pure relative definition of personal data, it seems more likely that a risk- and motivation-based interpretation of "reasonably likely" was desired by the CJEU. Judgment (CJEU).
Several supervisory authorities reduce the ruling to its individual case ("Einzelfallentscheidung") and therefore do not really apply it. The Bavarian DPA (BayLfD) places SRB within the established case-law but treats identifiability largely as a case-by-case question and advises public bodies, in case of doubt, to assume personal data (working paper, PDF). The Danish DPA (Datatilsynet) has largely sidestepped the ruling's consequences: in guidance issued after the judgment it maintains that a controller–processor agreement (Art. 28 GDPR) is still required even where the recipient cannot re-identify the data subjects (Datatilsynet statement).
The Court held that the website operator's logs containing dynamic IP addresses are personal data because, under German law, the operator had actual legal means to have the user identified via the access provider. Conversely, had that identification been impossible, unlikely or prohibited, the IP addresses would not have been personal data. For blockchains this means an on-chain identifier or hash is personal data only where identification is actually, lawfully and realistically possible. Judgment (CJEU).
Loading personal data onto an internet page does not constitute a transfer to a third country — otherwise the special transfer regime would become a regime of general application for the entire internet. The Court expressly held that it is unnecessary to investigate whether the hosting server is physically located in a third country or whether anyone in a third country actually accessed the data. Applied to public blockchains, the global replication of on-chain data across nodes — including nodes in third countries — does not, as such, trigger Chapter V. Judgment (CJEU).
Positions of national authorities and the Article 29 Working Party (the EDPB's predecessor) that frame the current debate.
An introduction to the hash function as a personal-data pseudonymisation technique and a safeguard in data processing. Relevant to the recurring question of when a hash of personal data is itself personal data. Joint paper.
In a case unrelated to blockchain, the Austrian authority held that anonymisation need not be proven to be perfect forever; it is sufficient that there is currently no way to reverse it, and speculative future developments need not be taken into account — such anonymisation then equals deletion. A positive signal for blockchains that use hashing, zero-knowledge proofs or encryption. Decision (RIS).
The CNIL provided early guidance that creates some clarity, leaves many questions open, and introduces some confusion with the position that smart-contract developers can be processors. French original · English version · abstract & comment (Erbguth).
An early national opinion on blockchain in the context of data protection (English translation). The text is hard to follow, probably due to the translation. Opinion (PDF).
Opinion 05/2014 on anonymisation techniques takes a very broad, pre-GDPR view of personal data that has — somewhat ironically — become an obstacle for privacy-enhancing technologies. Opinion 01/2010 on "controller" and "processor" gives background and examples but does not address peer-to-peer settings, where one person can be controller, processor and data subject at once.
Scholarship, standardisation bodies and practitioner analyses on reconciling blockchain with the GDPR.
Blockchains and Data Protection in the EU (MPI, Feb 2018); Smart Contracts as a Form of Solely Automated Processing Under the GDPR (MPI, Jan 2019); and the EPRS study Blockchain and the General Data Protection Regulation (PE 634.445, Jul 2019).
Technical Report FG DLT D4.1 on a distributed-ledger-technology regulatory framework. Report (PDF).
A clear, readable summary of the state of the art. The comment from this site: the treatment of hashes should be more differentiated by use-case, and the description of "smart contracts" is misleading — an Ethereum smart contract can neither send data to external storage nor make on-chain data invisible to some users. A more positive vision is warranted: blockchains can give data subjects superior data sovereignty by removing intermediaries. Guide (PDF).
An early, widely cited report. Its core message: "GDPR compliance is not about the technology, it is about how the technology is used." Report (PDF).
An academic analysis of the tension between immutable ledgers and GDPR principles. Paper (PDF).
A good illustration of the basic points; some aspects are oversimplified and would benefit from additional nuance. Article.
A Framework for Long-Term Revocable Credentials (PhD thesis, University of Geneva, 2022); Five Ways to GDPR-Compliant Use of Blockchains (EDPL 3/2019); Datenschutzkonforme Verwendung von Hashwerten auf Blockchains (MMR 2019, 654); Smart Contracts und die DSGVO (Informatik 2019); Who is the controller of a Bitcoin transaction? (ZD 2017, 560); and the BC4EU status report (2025).