Skip to main content
EU Blockchain Observatory and Forum
News article8 June 20186 min read

Opposites attract: Reconciling GDPR and blockchain

Opposites attract: Reconciling GDPR and blockchain

What happened at the EU Blockchain Observatory and Forum’s workshop on GDPR, June 8, 2018 in Brussels

The full minutes of the workshop are available here.

Video from the workshop is available here.


Data has become the life blood of our technology-driven civilisation. That has made it one of our most valuable assets – and the question of who controls data one of the central issues of our time.

When the General Data Protection Regulation (GDPR) was enacted in the European Union in 2016 (it came into force on May 25, 2018), it was a significant update to Europe’s data protection regime, one meant to take the technological developments of the past 25 years into account.

But GDPR was conceived before the rise to prominence of what is considered to be one of the most disruptive new information technologies on the horizon today – blockchain. Based on the implicit assumption that databases are centralised data repositories, GDPR would seem inherently incompatible with blockchain’s decentralized information storing and processing paradigm.

On June 8, members of the EU Blockchain Observatory and Forum’s Working Groups, as well as selected thought leaders, met in Brussels to discuss what all this means. Are the tensions between GDPR and blockchain irreconcilable, or can decentralized technologies actually support GDPR’s fundamental principles and objectives? And if so, how? How can we ensure blockchain’s compliance with the GDPR? These were the questions that filled the air on a warm day in the heart of Europe. Below are some highlights from the discussion these questions catalysed.

Key concepts

To understand the issues at the intersection of GDPR and blockchain, it is important first to understand the key GDPR concepts that are relevant to this technology. These include:

  • Personal data: Every piece of data related to an identifiable person.
  • Anonymous data: Data that can in no way be attributable to an identifiable person. Such data does not fall under the protections of GDPR.
  • Controllership: The idea that there is always a person or entity that is ultimately accountable for how the data is used.
  • Data protection by design: The prescription that any new tool, service or product has to be designed to intrinsically take data protection into account (and not, for instance, add it as a layer on top).
  • Data minimization: The principle that only the data needed for a specific purpose is collected, and that the purpose and the duration of data storage is always clearly defined.
  • Right to amendment: The principle that data be kept accurate.
  • Right to erasure: The principle that, unless there are specific reasons not to, personal data be erased upon request (also known as the right to be forgotten).
  • Data movement: GDPR's stated goal, often overlooked in the discussion, of not only protecting data, but also facilitating its movement within the EU. GDPR also stipulates that data can only be moved outside the EU if the destination location offers the same levels of protection available in Europe.

Putting these and the other principles of GDPR into practice boils down to the interplay between three key actors: the data subject (the individual), data controllers, and data processors. It is in defining what these mean and how the interactions take place in the new, decentralised world of the blockchain that many of the tensions between GDPR and blockchain lie.


In the blockchain world it can for example be difficult to identify how and when it is ok to use personal data on a ledger. While transactional information, including messages or any other content traceable to an individual, is clearly personal data, there is growing consensus that data that is hashed or encrypted (which data on a blockchain typically is) is personal data too so long as it relates back to a natural person. But it remains unclear what this means for the use of things like public keys used to identify the encrypted data.  

In blockchain it can be difficult to identify the data controller, particularly in public, permissionless blockchains where all full nodes could appear to be data controllers – or none of them could. GDPR stipulates that data can only be exchanged with locations outside the EU that ensure the same level of data protection as the EU. Permissionless blockchains are global in nature. If we cannot definitively identify data controllers, we cannot makes such assurances.

Blockchains, which are constantly growing databases into which information can (in theory) only be added and not deleted, also seemingly clash with GDPR's principles of data minimization and right to amendment/erasure. In Article 22 GDPR provides data subjects protection from the automated processing of data, putting it seemingly at odds with one of blockchain's great innovations: the ability to automatically process many transactions via smart contracts. On the other hand, since the code of smart contracts can be examined, they can support more transparency in automated data processing, both for the parties involved and the authorities.

Because it is a peer-to-peer technology, it is a much more fluid environment than the centralized, client-server model we are used to: actors generally interact directly with each other, and often perform a wide variety of changing functions.

This raises a number of tricky questions. How can we identify what GDPR-recognised roles the different actors are playing on a blockchain network at any given time? How can we handle governance in a fully decentralised network, not just in terms of technology but also off-chain? If roles are fluid so are responsibilities: how do we determine liability if something goes wrong?

It is also unclear how well blockchain technology can protect personal data. Today’s encryption algorithms can – and likely will – be broken over time, particularly with the advent of quantum computing. This is a serious issue in a blockchain environment, where all records are stored in perpetuity and the database is copied on all nodes, as well as in other areas that rely on encryption. And while permissionless blockchains have shown a remarkable resiliency to hacking to date, they are subject to data breaches or manipulation from within, for example if one miner accumulates a majority of the hashing power. These issues can be mitigated by the use of permissioned blockchains, where roles, responsibilities and liability can be attributed through a dedicated governance framework.


With all these tensions and questions, it can seem that GDPR and blockchain technologies are indeed fundamentally incompatible. Yet there is another side to the coin as well.  

GDPR and blockchain technologies share most of the underlying objectives of providing data sovereignty and data control to the individual. Still an immature technology, blockchain could conceivably evolve to become a powerful tool to support many of GDPR's core principles.

Techniques like chameleon hashes, zero knowledge proofs, and homomorphic encryption, can for example be used to better secure personal data. Blockchain’s high degree of auditability and transparency can help in protecting data subjects and enforcing GDPR. Blockchains can in theory also greatly facilitate GDPR's goal to improve the free movement and portability of data and avoid data capture by large, centralised entities.

During the workshop there was a general consensus on not storing personal data directly on a blockchain. In a vast majority of use cases it is not even necessary. This would allow developers to avoid incompatibilities between GDPR and their blockchain-based platform or dApp by storing personally identifiable information off-chain.

When personal data must be on chain, obfuscation and data transformation methods like ring signatures, zero-knowledge proofs and peppered hashes can (potentially at least) keep such data truly anonymous, making it GDPR compatible.

If developers and designers are careful to ask themselves what kind of data is being processed, for what purpose, and for how long they need it, and possibly implement truly privacy-by-design systems, they stand a good chance of being able to reconcile their applications with GDPR.

That could bode quite well for the cause of data sovereignty and data freedom in the Europe Union.


Publication date
8 June 2018