Does the EU GDPR make public blockchains illegal?

The European Data Protection Board (EDPB), a sort of an EU assembly composed of national data protection authorities, has published draft Guidelines on applying the EU's primary data protection law (the GDPR) to "blockchain technologies." The European Crypto Initiative (EUCI) rightly raised an alarm, noting that the Guidelines call for deleting entire blockchains to achieve GDPR compliance. As some of you may know, I work extensively on EU data protection law (see my EUTechReg.com), and I thus thought it would be useful for me to explain why the EDPB document is as problematic. I should also add that the document is still formally a draft subject to consultation, to which everyone can respond.

Without getting into too much GDPR detail, the key ideas are that

  1. the GDPR only applies to the processing of "personal data," and
  2. that when personal data is being processed, then certain obligations kick in.

The GDPR obligations include the obligation to rectify inaccurate date or even "the right to request deletion of the personal data (also known as the right to be forgotten or the right to erasure). The issue with public blockchains is that both rectification and erasure may be impossible regarding the data already added to the blockchain. At the same time, the EDPB insists that "technical impossibility cannot be invoked to justify non-compliance with GDPR requirements."[1] I'll come back to that later.

What blockchain data could the GDPR cover

First, let's look at what kind of blockchain data the GDPR could apply to according to the EDPB.

Wallet or account addresses (Ethereum EOAs, Bitcoin addresses): the EDPB Guidelines suggest that they constitute personal data whenever it is "reasonably likely" to connect an address with a person.[2]

Transaction data (e.g. data on calls to decentralised exchange smart contracts): like with addresses—if the data is related to a person (and it is reasonably likely to make this connection), then it is personal data according to the EDPB.[3]

Given that individuals use public blockchains like Ethereum, the question is then who can make the connection between addresses/transaction data and specific people. Centralised exchanges and blockchain surveillance solution providers certaintly can identify many people. In fact, they are often legally required to collect such data for AML/KYC purposes. Also, many people "doxx" themselves or are "doxxed" by others, for example on Twitter/X. So, the main public blockchains likely include personal data, at least on doxxed users and for those organisations who can identify individuals.

Who could be affected

To be precise, the GDPR doesn't make data processing illegal in general—it always applies to specific actors (called "data controllers" and "data processors"). The GDPR is also unlikely to be enforced against you if you put your own data on a public blockchain. However, you may be surprised to hear, the EU authorities may argue that it technically applies even then.[4]

Stablecoin issuers (and other smart contract maintainers)

To take one example, following the EDPB's logic, Circle, as the issuer of USDC and EURC, could be considered a GDPR data controller for the Ethereum address (EOA) data within the USDC smart contract's balance mapping (at least for those EOAs that relate to doxxed individuals). The EDPB could argue that Circle determines both the purposes for processing this data—namely, the operation and functionality of the USDC stablecoin—and the essential means, through its design and deployment of the USDC smart contract, which dictates how EOA balances are recorded and managed. Furthermore, functionalities such as blacklisting addresses, which Circle can implement, could be argued to show a level of control over the data processing that aligns with the responsibilities of a data controller under GDPR.

Would this also apply to developers of smart contracts deployed without any administrative functions or (proxy) "upgradeability"? On a maximalist view of the GDPR, they could still be considered as those who determine the purposes and means of data processing and enable it by deploying the contracts.[5]

Validators, sequencers, block builders

The EDPB suggests that network nodes could be "data controllers" under the GDPR when they exercise "exercise a decisive influence on the determination of purposes and essential means of the processing activity."[6] Concrete examples given by the EDPB are forking and "decisive influence on the subset of transactions to be added to the next block." In other words, they suggest that in blockchain like Ethereum or Bitcoin, whoever decides which transactions get included in a next block, can be legally responsible under the GDPR for the personal data involved. Let's remember that transaction data and even blockchain addresses (EOAs and so on) may be personal data on their view. There are many nuances to this, including a debate whether data is personal to you only if you (and not just someone else) are reasonably likely to link the data to an individual. But, on a maximalist GDPR interpretation the EDPB tends to push, this would likely lead to seeing Bitcoin miners and Ethereum validators (or maybe even MEV-Boost block builders) as covered by GDPR restrictions and duties.

You may very well think that this is disproportionate and that it puts blockchain infrastructure in a worse situation than, for example, telecom infrastructure. However, the legal problem with this analogy is that telecom services have a partial GDPR exemption that likely does not apply to blockchain infrastructural participants. (And, even if the exemption applied, that would have its own negative consequences.)[7]

Potential consequences

In brief, the EDPB frowns on the store of personal data as plain text, which—on their broad definition of "personal data"—would apply to blockchain addresses and to much transaction data (e.g. in DeFi—like interactions with stablecoin smart contracts). They say that "it is not advisable to store personal data on the blockchain, and it should not be stored in the content of transactions."[8] They at least very strongly imply that it would be incompatible with the GDPR to "store personal data" on a blockchain without some of the following measures:

Encryption: this is not applicable in today's Ethereum or Bitcoin when a blockchain address (e.g., EOA) itself is considered personal data. Also, encryption of transaction data (e.g. calls to a stablecoin smart contract) may break DeFi composability and at least may require significant changes to how things are done in DeFi compared with status quo.

Hashing: similar issues like with encryption.

Cryptographic committments: presumably this is meant to include ZKPs, which of course is an interesting avenue of research, but faces similar issues like the other suggestions.

This list doesn't look very practical for today's on-chain applications. Perhaps recognising this, the EDPB added a potentially important paragraph:

In some cases, data controllers may need to make some information public and accessible with a retention period equal to the life of the blockchain. In these particular cases, it may be appropriate to store personal data on a public blockchain in a directly identifying form, but only if it is justified by the purpose of the processing and a DPIA has been conducted and concluded that the risks for data subjects have been properly addressed and mitigated.[9]

At a first glance it may look like the EDPB's acceptance that developers and other network participants can easily comply with the GDPR even at the current stage of technological evolution of blockchains like Bitcoin and Ethereum.

However, if you read it carefully and in the context of the rest of the document and EDPB's other documents, then you should be concerned about the qualification starting with "only if it is justified..." In practice, this could be treated by EU data protection authorities as a de facto ban—if, for any reason, any of them (and there are dozens) makes blockchains an enforcement priority.

Deleting the blockchain

Having this in mind, the paragraph on "storage limitation" is, indeed, worrying. The EDPB says:

When deletion has not been taken into account by design, this may require deleting the whole blockchain. (...) Whichever approach to storage limitation is chosen, it must be effective. Where this would require the deletion of part of the blockchain, including the deletion of any copies held by nodes or other parties, controllers should ensure that sufficient technical and organisational measures are in place for doing so.[10]

Similarly:

where the storing of personal data is justified on the basis of consent, the personal data must be deleted or rendered anonymous if that consent is withdrawn.[11]

And, regarding the right to erasure of personal data:

The rights to erasure and to object must be complied with by design. The EDPB observes that it might be technically impracticable to grant the request for actual deletion made by a data subject when personal data is stored directly on a blockchain. (...) Since the full blockchain or information stored on it might not be easily deleted, controllers should consider this requirement early in the design phase and make sure that any personal data stored on the blockchain can be effectively rendered anonymous if an erasure request or objection is received. It is technically demanding and often difficult to grant the request for rectification or for erasure made by a data subject when clear text, encrypted or hashed data is recorded on a blockchain. It is therefore not advisable to register personal data in those forms on a blockchain. Instead, personal data in those forms should be stored off-chain.[12]

A different GDPR interpretation is possible

I did not discuss all the possible problems that arise from the EDPB guidance (e.g. what about the restrictions on international transfers of data?). And even in the areas I mentioned, there is much more to be said. What I wanted to achieve here, is to show that the maximalist interpretation of the GDPR that the EDPB has been consisently pushing for years is on a colision course with public permissionless blockchains.

This is not the possible only way to interpret the GDPR and, I'd argue, it's not even the correct way. As Michèle Fink[13] and others[14] have written, EU law allows for much more pragmatic and proportionate approaches, which would not amount to the kind of uncertainty, or even a de facto prohibition of a technology, we're now facing.

  1. EDPB Guidelines, para. 50. ↩︎

  2. EDPB Guidelines, para. 26: "Metadata of transactions includes both identifiers of the users who are participants of the transactions and other metadata. Each user participating in a transaction may, for instance, be associated with an identifier comprised of a series of alphanumeric characters which looks random, and which constitutes a public key derived from a private key known to the user. If the user is a natural person and those public keys can be used to identify the individuals by means reasonably likely to be used, for example in case of a data breach, then those identifiers qualify as personal data." ↩︎

  3. EDPB Guidelines, para. 29: "Transactions on a blockchain are generally associated with content data (also called the 'payload' of a transaction). This can be an amount of cryptocurrency, a link to a document, an item purchased, a smart contract procedure call, etc. This payload can also include personal data, related either to the users involved in the transaction or to other natural persons." ↩︎

  4. The GDPR contains a purely personal or household processing exemption (GDPR, Art. 2(2)(c)), but the authorities and the courts have been interpreting this exemption very narrowly. The EU Court of Justice opined, e.g. in Buivids, that when "permitting access to personal data to an indefinite number of people, the processing of personal data at issue in the main proceedings does not come within the context of purely personal or household activities" under the previous Directive 95/46/EC (a precursor to GDPR with similar principles). ↩︎

  5. Possibly by analogy with the Court of Justice judgment in Wirtschaftsakademie Schleswig-Holstein, C‑210/16, EU:C:2018:388. ↩︎

  6. EDPB Guidelines, para. 43. ↩︎

  7. Providers of Electronic Communications Services (ECS) are subject to specific data protection rules under the ePrivacy Directive (Directive 2002/58/EC), which acts as lex specialis to the GDPR. This means that for matters specifically governed by the ePrivacy Directive (e.g., confidentiality of communications, processing of traffic and location data), its targeted provisions apply and take precedence over the general rules of the GDPR for ECS providers (see GDPR Art. 95), rather than granting a wholesale exemption from GDPR. Should Ethereum validators be classified as ECS, this regulatory framework would likely result in significant negative consequences, such as: (a) severe compliance burdens that are ill-suited to their decentralized operational model; (b) fundamental incompatibilities between blockchain's inherent transparency and the ePrivacy Directive's requirements for communication confidentiality; and (c) technically challenging or unworkable obligations regarding data handling, retention, or lawful interception. ↩︎

  8. EDPB Guidelines, para. 48. ↩︎

  9. EDPB Guidelines, para. 55. ↩︎

  10. EDPB Guidelines, para. 63. ↩︎

  11. EDPB Guidelines, para. 71. ↩︎

  12. EDPB Guidelines, paras. 102-104. ↩︎

  13. Michèle Finck, Blockchains and Data Protection in the European Union. ↩︎

  14. See, e.g., Centre for Information Policy Leadership, Digital Assets and Privacy. ↩︎