The European Data Protection Board (EDPB) has published draft guidelines on the processing of personal data through blockchain technologies. In my assessment, the draft adopts a relatively restrictive reading that is not fully grounded in a contextual reading of the GDPR's text, its recitals and the case-law of the Court of Justice of the EU (CJEU).
This page summarises a status report — prepared for Blockchain for Europe (BC4EU) — that seeks to restore the balance the French CNIL struck in 2018: recognising the privacy and data-sovereignty gains of decentralisation while keeping the risks to data subjects comparable to those of centralised designs. EDPB guidelines are not binding on courts; the binding sources remain the GDPR, its recitals and CJEU case-law.
Early blockchain development was driven by a cypherpunk ethos — empowering users and reducing the leverage of central intermediaries. This overlaps strongly with the goals of data protection.
The GDPR endorses privacy-preserving technologies, yet its governance model presupposes hierarchical, identifiable parties that determine purposes and means. That assumption fits traditional centralised architectures, but does not match decentralised systems. When applying the GDPR to blockchain-based processing, the Regulation should not be read as mandating centralisation.
A technology-neutral interpretation must account for the privacy and sovereignty gains achievable through decentralisation — while setting guardrails so that risks to data subjects remain comparable to centralised designs. Centralised and decentralised systems carry different risks; where zero risk is unattainable, users should be free to choose among risk profiles rather than be forced into one. Public permissionless blockchains are often motivated by resilience, censorship resistance and data sovereignty, offering protection for fundamental rights at least equivalent to centralised alternatives. They should therefore not be rejected on a restrictive, non-technology-neutral reading of the GDPR.
Read more in the report (Part One)The GDPR applies only to personal data (material scope, Art. 2) and only obliges controllers and processors. From this follow the two questions that decide whether — and to whom — it applies on a blockchain: does the data qualify as personal data, and do you qualify as a controller or processor? (The territorial scope of Art. 3 must also be met.)
Personal data is any information relating to an identified or identifiable person (Art. 4(1)); anonymous information is out of scope (Recital 26). Identifiability follows the "means reasonably likely to be used" test and must be assessed per actor (CJEU Breyer; EDPS v SRB) — merely theoretical re-identification is insufficient. The draft assumes that hashes and identifiers are always personal data; the report argues this does not hold for everyone in every case. Hashes, commitments, salting or keyed hashing and zero-knowledge proofs can prevent identification for most actors.
Read more in the report (section 3.2)A controller is whoever actually determines purposes and means (Art. 4(7)); the role follows the factual situation and cannot simply be assigned. Blockchains are engineered to disperse control across three levels — the transaction, the smart-contract / DAO, and the blockchain-infrastructure level. Because Art. 4(7) keys on actual determination rather than mandatory designation, some blockchain contexts may have no entity that qualifies as a controller — notably miners and validators on permissionless chains.
Read more in the report (section 3.3)Where on-chain data is personal data, the GDPR applies and there is a controller, processing requires one of the legal bases of Art. 6(1) GDPR. A legal basis — a justification of the processing — strongly depends on the use case. The legal basis can be consent, contract, legal obligation or legitimate interest:
Consent must be freely given, specific, informed and unambiguous, and withdrawable at any time. Once a transaction is broadcast, the originator no longer determines the purposes and means of its decentralised replication; withdrawal cannot undo processing that already took place. On withdrawal the (former) controller must stop any processing still within its control and render off-chain linkages unusable. A sender who no longer stores a copy may no longer be a controller at all.
Read more in the report (section 3.4.1)Processing must be objectively indispensable for a service integral to the contract — not merely useful or referenced in it (CJEU Meta v Bundeskartellamt). When a data subject directly buys or sells a crypto-asset, the on-chain transaction is itself indispensable to perform that contract and has no less intrusive alternative. Terminating a contract does not require reversing or deleting on-chain transactions; only continued off-chain processing may have to stop.
Read more in the report (section 3.4.2)Obligations may arise from EU or member-state law. Qualified electronic ledgers under the revised eIDAS must preserve the integrity and immutability of their records — which justifies the continued storage of blocks and blocks the right to erasure (for the qualified trust service provider operating them). Crypto-asset and anti-money-laundering rules (MiCA, AMLR, the Transfer-of-Funds Regulation) can likewise mandate processing of on-chain transaction data.
Read more in the report (section 3.4.3)A legitimate interest can justify processing where it is necessary and not overridden by the data subject's interests or fundamental rights (three cumulative CJEU conditions). Example: the integrity, completeness and verifiability of a crypto-asset's transaction history is required for holders to trade and for crypto-asset service providers to meet their analysis duties — so keeping that data on-chain is a legitimate interest, and a mere unverifiable copy would not suffice.
Read more in the report (section 3.4.4)Blockchains often have unlimited lifetimes, longer than typical retention periods — but unlimited retention is not unprecedented (qualified electronic ledgers under eIDAS, books, and public archives have none either).
Personal data should preferably be stored off-chain; where retention must be limited, responsibility lies with the entity sending the data to the chain. Data subject rights (Arts. 12–22) bind the current controller and have to be balanced with the rights of others. Access can be answered by reference to the on-chain data. The right to erasure is limited where a continuing legal basis exists, and withdrawal of consent does not affect processing that already took place. Rectification can be achieved by appending corrected entries.
Read more in the report (sections 3.7 & 3.9)Public blockchains are global; a broadcast can replicate to nodes in any country, including third countries. The Court of Justice of the EU held in Lindqvist that publication should not be restricted by the third-country transfer regime.
In Lindqvist (C-101/01) the CJEU held that merely loading personal data onto an internet page does not, as such, constitute a transfer to a third country — otherwise the special transfer regime would become a regime of general application for the entire internet. The GDPR preserves these principles (adequacy, appropriate safeguards, derogations). Intentional publication to the public therefore does not trigger Chapter V merely because of global accessibility or a third-country server location. The report criticises that the draft does not reflect Lindqvist.
Read more in the report (section 3.6)Where processing is likely to result in a high risk to rights and freedoms — for example with innovative blockchain technology or publicly accessible data — a data protection impact assessment (DPIA) is required.
A DPIA must describe the processing, assess necessity and proportionality, evaluate the risks for data subjects, and define measures to address them (Art. 35(7)). Supervisory authorities can whitelist established use cases, and an existing DPIA for an identical implementation can be reused as a template. The report recommends that guidelines positively list privacy-preserving blockchain use cases and provide templates for addressing blockchain-specific risks — turning the DPIA into an enabler rather than a barrier. If you are considering a DPIA, I am happy to support you in carrying one out.
Read more in the report (section 3.11)In my assessment, the EDPB draft guidelines differ from the GDPR and CJEU case-law in several respects: a too-broad definition of personal data, no express reference to Lindqvist, limited consideration of related EU law such as eIDAS, and insufficient weight on proportionality. Mandating the deletion of an entire blockchain because of a single non-compliant record would generally be disproportionate. The report's aim is not to weaken data protection enforcement, but to enable privacy by design in decentralised applications. It sees itself as a contribution to an informed dialogue on how existing principles can be applied in ways that reflect technological realities and foster fundamental rights.