Skip to main content

Article · 19.02.2021

Responsibility for data on blockchains

As the blockchain technology is steadily descending Gartner’s Hype Curve, it is finding its place in various products and services – in addition to Bitcoin. At the same time, legal issues associated with the technology are becoming more pressing. Issues that were previously ignored as the technology was still in its infancy, not least one of the major issues in the field of blockchains: data protection

Authored by Attorney-at-law Mathias Bartholdy.

This article discusses the issue of when you are considered to be a data controller when using blockchain technology. The overall conclusion is that the answer depends on how the blockchain was designed and how you choose to use it.

This article presupposes a certain level of knowledge of the blockchain technology and its concepts. If you are a novice in this field of technology, you can start by reading or watching the many good web articles and YouTube videos on the subject.

Blockchain and GDPR – a hornet’s nest

How does a business meet its obligations under the General Data Protection Regulation (GDPR) when using blockchain technology? This is a question that most people, and especially those who actually work with the technology, prefer not to think about. Because the answer easily becomes overwhelming.

This article is not intended to cover the entire subject. There would be enough content for a university thesis. The article concerns an important sub-topic, namely who is responsible for personal data when using blockchain technology.

For a business intending to use the technology, it is essential to know whether or not you are the data controller for the personal data processed on your blockchains. If you are the data controller, the GDPR places great demands on you. Several of these demands may be difficult, if not impossible, to comply with due to the very design of the technology. How to address these demands will not be discussed in this article, but in a follow-up article.

There is no one correct answer to the question of when you are considered to be a data controller when using blockchain technology. The answer depends on the design of the blockchain and how you choose to use it.

The diversity of blockchain technology

The blockchain technology, also known as distributed ledger technology (DLT), now comes in all sorts of variations – a byproduct of the technology having been publicly available since its invention in 2009[1].

Blockchain is basically a database technology using cryptography to secure the integrity of the content. It is a technology, just like 5G and semiconductor chips are technologies. You can use it as part of a product to achieve a specific functionality.

Blockchains may be open (i.e. accessible to all, such as Bitcoin[2] and Ethereum[3]), closed (access is often controlled by one or more businesses or organisations that use the blockchain as part of a product or service, such as Maersk’s and IBM’s TRADELENS[4]) or hybrids. They are available with proof-of-work (such as Bitcoin), proof-of-stake (to which Ethereum recently converted from having originally been proof-of-work[5]) or other proof-of-x consensus mechanisms. Some have even developed their own variations of the blockchain technology. These include IOTA[6] (specifically targeting IoT, hence the name), which has a Danish co-founder and has developed a “tangle” variant of the blockchain technology to serve as infrastructure for managing microtransactions in its service.

Once you know how the blockchain is structured and how you intend to use it, the challenge is how to fit the technology into the boxes defined by the data protection legislation.

The data controller determines why and how

Under article 4 no 7 of the GDPR, the data controller is the party which determines the purposes (why[7]) of the processing of personal data and the means (how[8]) of the processing. The means may be blockchain technology, for example. Although, according to the GDPR, having the decision-making power with respect to the purpose and means appears to be equally important in the identification of the data controller, case law and guidance notes have established over time that the purpose is the main criterion, i.e. who determines the purpose of the processing. You can easily find examples of situations in which the data controller determines only the purpose of the processing, while a data processor determines the means, but never the other way around[9].

You would typically determine the purpose if the processing is carried out in your own interest. Thus, if a business offers a service using blockchain technology, and if personal data are processed in that regard, e.g. by registration on the blockchain – the business is generally considered to be the data controller. However, this is not always the case.

Example 1: Simple cryptocurrency service

At the low end of the scale of complexity, you might find a business operating a platform allowing users to transfer cryptocurrency to each other.

In order to transfer currency, you need the address of the transferor, the address of the transferee, the amount and a time stamp. The address is usually a unique ID identifying the user’s e-wallet. If an e-wallet belongs to a natural person, the address is considered to constitute personal data[10]. If the e-wallet belongs to a business, the address does not constitute personal data, with the exception of sole proprietorships and probably also limited partnerships[11].

In this situation, it is the business behind the platform which decided that the platform would require users to identify themselves by a unique address. Therefore, the business is the data controller for the addresses on the blockchain relating to natural persons. Accordingly, the business must rectify inaccurate data, erase data if the processing no longer has a legitimate purpose, etc. If the blockchain operates like Bitcoin’s blockchain, on which transaction history cannot be changed or erased[12], this is practically impossible.

If, in the above example, the service had only targeted businesses, the business might take the view that it was not processing personal data on its blockchain. That is partially correct. As mentioned above, only personal data of natural persons are protected under the GDPR. Therefore, the data of businesses – e.g. addresses, account information, e-wallet addresses, etc. – are not personal data. However, for data protection law purposes, sole proprietorships and small limited partnerships are in practice identified with their owners, and data on such businesses would therefore constitute personal data.

In this situation, the business can effectively only avoid processing of personal data by only granting businesses other than sole proprietorships or limited partnerships access to the service. That would require strict controls to ensure that the users of the service do not create personal e-wallets or e-wallets linked to specific employees, as such addresses would still constitute personal data.

Example 2: Smart contract platform

The same considerations apply even if the product is more complex. If you allow users to create smart contracts (self-executing contracts that “live” on the blockchain), you are still data controller to the extent your service design requires the processing of personal data. Usually the “birth” of a smart contract on a blockchain would require the address of its originator to be embedded in the contract, i.e. to be made available on the blockchain. If that is the case, and if the originator is a natural person, this would constitute processing of personal data. The business that created the blockchain and chose to include a smart contract functionality requiring an embedded address would thus be the data controller in respect of the processing of the e-wallet address. The same applies to other personal data required to be processed by the service.

Even if the smart contract did not require embedding the address of the originator in the contract, the blockchain would probably contain a transaction in which the originator creates the contract and which would contain the address of the originator and the address of the smart contract. The actions of the smart contract on the blockchain would therefore be linked to the originator.

Allowing the user to independently embed information in the contract, e.g. via a free text box or similar, would make the assessment even more difficult. In that situation, the deciding factor must be whether the business behind the blockchain directly or indirectly decides that the data in question are to be embedded in the contract. Here, the purpose of the service would be a significant factor in the interpretation, including whether the blockchain is open or closed.

If the blockchain – and by extension the service built on the technology – is used for a purpose determined by the business, and if the processing of the relevant personal data follows inherently from the purpose of the service, the business will, as a general rule, be the data controller for the processing. For example, if you have created a music streaming service with payments being made as per-play micropayments, you will be the data controller for the data on the number of times a user has listened to a specific song.

On the other hand, if the service and the underlying blockchain have no specific intended purpose, and if, furthermore, it is accessible to all, the assessment is more complex.

An example could be a service that allows users to create smart contracts for all sorts of purposes. Ethereum Foundation is one of the organisations offering such a service, promoting decentralised applications (dapps) developed by their users and created and living on Ethereum’s blockchain. Ethereum has very little control of the applications developed by its users – which it promotes as a strength of the platform on its website. Accordingly, Ethereum does not decide how their dapps will act, nor what personal data they will collect. Their users do. Ethereum is therefore unlikely to be deemed to be the data controller for personal data processed via its users’ dapps, except in the case of personal data necessary for the creation and birth of the contract. As mentioned above, that could be the originator’s e-wallet address. As for the processing of other personal data that are not required in that context, Ethereum could probably be categorised as data processor – of course only to the extent the user is data controller.

This situation resembles that of a cloud hosting provider requiring users to enter their e-mail address to create an account. The hosting provider will be the data controller with regard to the users’ e-mail addresses, as the hosting provider processes these data for its own purposes (= identification of its customers). However, the hosting provider will not be the data controller for files uploaded to the service by the users and containing personal data. If the user is data controller for the processing of personal data on the platform, the hosting provider may be data processor, depending on the circumstances.

The user may be data controller

So, it is not just the business that may be the data controller. The user may also be the data controller if the user processes other people’s personal data. As a general rule, users who transfer currency from themselves to others or enter into smart contracts with others are data controllers in respect of the personal data on the other party processed in that connection and registered on the blockchain. The reason is that the users determine why the data are to be processed (to transfer currency to or enter into a contract with the other party).

This might seem odd because the users have no influence on how the data are processed on the blockchain, but this view does seem to tally with the current, and rather wide, interpretation of the concept of data controller applied by the Court of Justice of the European Union (CJEU)[13].

In some instances, these circumstances will be covered by the exemption applying to processing by natural persons in the course of a purely personal or household activity, which falls outside the scope of the GDPR. However, this applies only to private blockchains, on which the data are not made accessible to an indefinite number of people[14]. If the transfer is made to a business, the data are generally not considered to be personal data.

In principle, however, this leaves sole proprietorships, limited partnerships and natural persons, to whom the above exemption does not apply, in a situation in which they may be data controllers for personal data processed on a blockchain which they effectively do not control.

Miners and nodes not likely to be data controllers

A concern raised at the birth of the blockchain (when the technology was used for Bitcoin only) was that anyone who made their computer power available for validation of transactions on the blockchain (so-called miners) and anyone who had a copy of the blockchain (nodes) would be data controllers. The concern was raised in part because miners and nodes (usually) have full copies of the entire blockchain.

When a node or a miner has a copy of the blockchain, there is really no doubt that personal data are being processed (if it contains personal data, that is).

Nodes play a passive role by disseminating new transactions in the blockchain network as and when they are made, and they typically have a full copy of the blockchain. They follow the rules of the blockchain network and “reject” non-compliant transactions. It therefore seems difficult to argue that nodes determine the purpose of the processing of personal data on the blockchain. Nodes are an integral part of the blockchain infrastructure and may for that reason – from a GDPR perspective – more correctly be identified as a “means” of processing personal data.

The miner is also a node[15] but plays a more active role because the miner, as mentioned above, validates new transactions and adds them to the blockchain by following the relevant blockchain procedures (e.g. proof-of-work or proof-of-stake). Miners would rarely be data controllers, however. At least not when applying the more conventional consensus mechanisms such as proof-of-work or proof-of-stake, with consensus being achieved via joint automated and coordinated efforts among the miners participating in the blockchain network.

It is difficult to imagine a consensus mechanism in which the miner exercises control over the purpose and means in such a way that the miner would become data controller, and which could also be efficiently categorised. On the other hand, it is not entirely inconceivable that a blockchain could be designed to facilitate the segregation of certain transactions for validation by selected individuals, against a higher transaction fee, or validation with partial human involvement. An example of this could be a transfer of particularly sensitive data, for which you would want full assurance that the data does not fall into the wrong hands. In those circumstances, the miner may also be data controller.

If the miner is not data controller, which would be the case more often than not, the question is then whether the miner is data processor. The same question applies to nodes.

Firstly, that would require the processing to be carried out on behalf of a data controller.
The data controller may the business providing the blockchain-based service or the user of the service (or even both – see below).

Next, if there is one or more data controllers, the question is whether the validation of an individual transaction and the addition of the transaction to the blockchain – whether a cryptocurrency transfer or a smart contract action – constitute processing on behalf of the data controller(s).

That is generally the case. The miner may be data processor for the user that arranges and is the data controller for the transaction, because the miner would be processing personal data at the instructions of the user. The miner may also be data processor for the business if the business is the data controller for the transaction; by being part of the business’ blockchain network, the miner accepts that transactions are validated by processing of personal data on its behalf (= instructions). The same must apply to nodes, which – although the processing is of a more passive nature than in the case of miners – disseminate new transactions on the network and therefore process personal data on behalf of the data controllers for the transactions.

Thus, if a business – and possibly its users – are identified as data controllers for personal data on the blockchain linked to the service, and if the business uses consensus mechanisms involving the processing of personal data, the business would be wise to sign data processing agreements with its nodes and miners.

Joint controllership may arise – especially in light of recent case law

If the business making the blockchain-based service available to its users is the data controller for the processing on the blockchain, the business and its users might, depending on the circumstances, become joint data controllers.

In recent case law, Facebook and its users have been held to be joint controllers (Wirtschaftsakademie[16], in connection with the establishment of Facebook Sites, and Fashion ID[17], in connection with embedding the Like button on own website) as have Jehovah’s Witnesses and its members’ activities[18]. The decisions demonstrate a clear line from the CJEU; it does not take much to be considered to be joint data controllers.

Wirtschaftsakademie and Fashion ID, in particular, are good examples of how a court would view joint controllership in the context of blockchain technology.

In Wirtschaftsakademie, the Court of Justice held that using a social medium does not per se imply that the user and the medium are joint controllers with respect to the processing for which the medium is data controller[19]. However, as the user – by establishing a site – granted Facebook access to storing a cookie on visitors’ devices, the user contributed to determining the purpose and the means of the processing.

It should be possible to apply this reasoning to blockchain services to the effect that using a blockchain platform does not per se imply that the user and the business making the platform available would be joint controllers for the processing carried out by the business on the platform.

If, however, the user creates a smart contract which collects and processes other individuals’ personal data, it will be a situation similar to that in the decision: Via the platform, the business offers the creation of a smart contract (in Wirtschaftsakademie, a Facebook page), which allows the user to collect personal data (in Wirtschaftsakademie, via a cookie) on others interacting with the smart contract (in Wirtschaftsakademie, the visitors’ Facebook page).

The CJEU reached the same conclusion in Fashion ID[20], in which data were collected via the script used for embedding Facebook’s Like button on a website. This in spite of the prior warning by the Advocate General against a too broad interpretation and application of the concept of joint controllers[21].

In case of joint controllership, you would have to sign an agreement with your users on the distribution of the responsibility and obligations under the GDPR; especially on where and how users may exercise their individual rights. See e.g. Facebook’s joint controller addendum[22], which was added after the Wirtschaftsakademie judgment.

So, based on current case law, there is a risk that providers of blockchain-based services may, in some circumstances, come to struggle with handling joint controllership.


As the length of this article might suggest, assessing data controllership in the context of blockchain technology is by no means straightforward. All relevant factors, both technical and commercial, must be taken into consideration.

The technical details, including the design of the blockchain and how it is used in a commercial context, are important factors in determining why and how personal data are processed on the blockchain.

The use of smart contract functionality complicates things, and the purpose of the service and what information is necessary to achieve that purpose – and not least what information is not necessary – should be clarified.

If you reach the conclusion that you are the data controller for personal data on your blockchain, the miners assisting you in validating the blockchain content will, in turn, be data processors, depending on the circumstances. In that situation, you would be well advised to sign a data processing agreement with your miners. Similarly, if you consider your users to be data controllers in some circumstances, you may want to examine whether in those circumstances miners are data processors for them.

You should also consider the extent to which you are data controller for your users and ensure that you have the necessary contractual framework with respect to data processing in place.

Lastly, especially in light of current case law, you may find yourself in a situation in which you, as a business, and your users have joint controllership for the processing of personal data on your blockchain. In that event, an agreement on shared responsibility should be signed, especially on how and vis-á-vis whom data subjects may exercise their rights.








[7] Article 29 Working Party, WP 169, on the concepts of controller and processor, p. 13.

[8] Ibid.

[9] Ibid., p. 14

[10] The European Parliament’s study on blockchain and GDPR (PE 634.445), 2019: Can distributed ledgers be squared with European data protection law?, p. 26ff.

[11] Henrik Waaben and Kristian Korfits Nielsen: Lov om behandling af personoplysninger – med kommentarer (2015) (Danish Act on Processing of Personal Data – annotated), third edition, DJØF Publishing, p. 142.


[13] E.g. judgment by the CJEU in C-131/12 (Google Spain), paragraph 34.

[14] Judgment by the CJEU in C-101/01 (Lindqvist), paragraph 47, and recently repeated in C-345/17 (Buivids), paragraph 43.


[16] C-210/16 (Wirtschaftsakademie)

[17] C-40/17 (Fashion ID)

[18] C-25/17 (Jehovah’s Witnesses)

[19] Wirtschaftsakademie, paragraph 35

[20] Fashion ID, paragraph 80

[21] Opinion of Advocate General Bobek in case C-40/17 (Fashion ID), paragraphs 73–75.