Blockchains: The legal landscape
In our earlier article we provided an introduction to blockchain technology and set out examples of some of its possible applications in light of the development of Blockchain 2.0. In this article we build on that understanding and highlight some of the possible legal implications that may arise from using a distributed ledger, focusing specifically on the regulation and enforcement of blockchains, data protection issues and the use of smart contracts.
Regulation and Enforcement
Bitcoin has shown to date that distributed ledgers can operate without regulation, instead being fully governed by software code and protocols. Every node on the Bitcoin blockchain runs the same software and protocols to maintain its own exact copy of the immutable ledger and nodes are therefore unable to operate outside of the codified rules of the blockchain. If one node did operate outside of these rules in order to take advantage of the other nodes, this discrepancy would be quickly identified by the other nodes and the attempt would ultimately be unsuccessful. This means that the blockchain is self-regulating and outside regulation to govern how the blockchain operates is not required.
However, software codes and protocols do need to be written by coders and are often later updated to fix bugs or issues with the blockchain and this naturally requires some form of human input. The hard fork of the DAO blockchain to rectify the exploitation of faulty coding (discussed in our earlier article) is an example of humans being able to interfere with the supporting code and the chain of records. This is generally possible in any permissioned blockchain, where one entity maintains and controls the blockchain and is the only party responsible for hashing new blocks onto the chain. Clearly, where there is scope for one party to exert such control over the blockchain then regulatory controls may need to be adopted to govern the scope of this control.
One of the main questions facing the regulator is who any new regulations should apply to? This may be easier to determine in a permissioned blockchain, where there is a single controlling party, but regulating an unpermissioned blockchain where every node has equal rights to add transactions to the chain is more difficult. For example, if a data breach occurred due to an error in the code of the underlying software then each node on the blockchain could in theory be equally liable for the loss. This could make enforcement problematic, particularly if the blockchain is cross border as there will be jurisdictional issues to consider.
In attempt to gain some regulatory control of cryptocurrencies, the New York State Department of Financial Services issued the BitLicense to govern any New York resident or business who receives, stores, holds, maintains, controls, administers or performs an exchange service of a virtual currency. Any such resident is also required to obtain a licence before undertaking any of these activities involving the virtual currency. This did however, lead to at least ten bitcoin companies withdrawing their business from the New York State due to the increase in costs and the administrative burden of complying with the new regulations.
So as not to stifle innovation, the European Parliament members (MEPs) voted in June 2016 to take a hands-off approach to regulating blockchain technology, instead calling on the Commission to set up a task force to closely monitor blockchain technology so that it will be able to regulate quickly “if and when it is necessary to do so." In March 2015, HM Treasury published its report on the call for information relating to digital currencies and concluded that anti-money laundering regulation must be applied to digital currency exchanges in the UK and is prepared to work with the British Standards Institution to develop voluntary standards for consumer protection. With the growing use of blockchains it seems inevitable that regulation will be enacted in the near future to govern their use.
One key question for governments is whether these regulations should extend to govern all potential applications of blockchain technology or whether they should be restricted to certain industries. The banking and finance industry is an obvious example of an industry which is likely to adopt tight controls in respect of blockchains, but it remains to be seen whether, for example, blockchains used to record property transactions or other assets will have similar controls.
Blockchains have the ability to hold vast amounts of data and depending on the application of the blockchain some of this data may be classed as personal data under the Data Protection Act 1998. Depending on how the blockchain operates, the pseudonymised public addresses which are recorded in every transaction and hashed onto the chain may also constitute personal data. If personal data is being recorded onto the chain then every node on the network will be a data processor as soon as it receives a new block of data for the purpose of updating its own copy of the ledger. This poses difficulties with ensuring compliance with the Data Protection Act.
In a distributed ledger, personal data will be widely transferred to every other node, some of which may be situated in countries outside of the European Economic Area. Consideration must therefore be given to whether this transfer complies with Principle 8 of the Data Protection Act. Compliance with Principle 8 will be easier to control in a permissioned ledger system as the controlling party could place restrictions to prevent nodes joining the network in certain geographical locations. This could, however, hinder the scalability of the blockchain.
There is also the question of who the data controller is in respect of personal data which is shared across a public network and how legal obligations on data controllers and data processors will be properly apportioned? It is a requirement of the Data Protection Act that a data controller must maintain a written contract with every data processor. This contract must impose obligations on the data processor to only process the personal data in accordance with the instructions of the data controller and to maintain appropriate technical and organisational measures against unauthorised and unlawful processing of personal data and against accidental loss or destruction of or damage to personal data.
In order to comply with this requirement, whichever node is the data controller would need a written contract with every other node on the network. This will be easier to manage over a permissioned network as the controlling party will be able to ensure service contracts are entered into with the other nodes (akin to software-as-a-service contract) but this may be difficult in an unpermissioned blockchain. It may also be possible in some blockchains for every node to be a data controller at some point during the lifecycle of the blockchain. This scenario would require every node on the blockchain to cross-contract with the other nodes as both data controller and data processor, which may be hard to achieve.
Further difficulties arise with how nodes will comply with the requirements of ensuring personal data is accurate and kept up to date and not kept longer than is necessary. One of the key benefits of blockchains is the immutability of the data, with all data being recorded and maintained in the chain from the start of the blockchain as an undisputable record for verification purposes. If this data is made up of personal data then erasure or rectification of the personal data would be impossible without contravening the immutable record of the blockchain. This is likely to pose a greater issue with the upcoming General Data Protection Regulation, which is due to come into force in May 2018, as data subjects will have a right to require data controllers to rectify and erase their data (the “right to be forgotten”). This issue is seemingly resolvable in a permissioned system which would allow the controlling party to use a blockchain editor tool, similar to the one Accenture has recently made an application to patent, but immutable unpermissioned systems are likely to not be compliant.
Whilst these issues in respect of ensuring compliance with applicable data protection legislation are not insurmountable, they must be considered from the outset of the design and build of the blockchain to ensure the coding and protocols of the blockchain are programmed accordingly.
A smart contract is a self-executing computer program that automatically fulfils the codified versions of contractual obligations. As explained in the earlier article, the application of smart contracts is limited due to the pre-programmed nature of the smart contract. This means that smart contracts are only suitable for contracts that have clearly defined obligations at the outset. However, with the growth of internet of things and improvements in artificial intelligence the application of smart contracts will become more widely used. For example, if a smart television has been bought by a customer on finance and the customer fails to make a monthly repayment, the smart contract could be programmed to automatically execute code on the television that locks and prevents use of the television until such time as payment is received.
The automated nature of the smart contracts means they are inflexible and will not take into account the nuances of commercial relationships between parties. Although the same could be said about written contracts (it is after all impossible to draft a contract that covers every contingency), the fact that smart contracts are self-executing and automated means that the contract will be strictly enforced regardless of any extenuating circumstances. This creates a problem where one party contests the execution of the obligations of the contract.
For example, if the customer of the smart television submitted the payment on time to the supplier but the supplier has not properly processed the payment at no fault of the customer, the smart contract will not be able to recognise this as the supplier’s discrepancy and the television will automatically be deactivated. This clearly unfairly penalises the customer. Further, as the smart contract will not include the contractual remedies that you would expect to see in a written contract, the customer will not be able to seek redress in the form of compensation. This raises the question of whether a written side contract between the customer and supplier is still required to govern the operation of the smart contract, particularly if the customer is entitled to certain rights under existing consumer rights laws.
A wider concern with the use of distributing a smart contract across a blockchain network is the privacy of the contracting terms. Although some public blockchains use pseudonyms to hide the identity of the contracting party, the terms of the smart contract would be published onto a public network and made available to every node. However, it is important to note that only the machine readable object code of the smart contract will be published and only if this code can be decompiled into the human readable source code will the terms of the smart contract be known to other nodes. The risk to privacy is being explored by various projects which aim to make blockchain transactions as private as possible but these are in their infancy and at the time of writing have not yet been fully developed.
As is often the case with any advancement of technology, blockchain technology is being developed and implemented at a faster rate than the existing legal framework can be adapted. Some of this can be put down to politicians not wanting to stifle innovation by overregulating blockchains, but regulations will inevitably come into force to govern the use of blockchains, particularly in the banking and finance industry.
Despite the uncertainty surrounding the future of regulation of blockchain technology, it should be remembered that the principles of contract law and existing legislation such as the Data Protection Act and consumer rights law will need to be complied with from the outset. Adaptations may need to be made to how some blockchains are implemented in order to ensure such compliance and these adaptations will be easier to cater for at the design and build stage of the blockchain. This means that coders, developers and lawyers will need to work together to overcome regulatory, contractual and technical issues when implementing new blockchains.
 UK Government Chief Scientific Adviser: Distributed Ledger Technology: beyond block chain, page 42
 Principle 8, Data Protection Act 1998: Personal data shall not be transferred to a country or territory outside the European Economic Area unless that country or territory ensures an adequate level of protection for the rights and freedoms of data subjects in relation to the processing of personal data.
 Principles 4 and 5 of the Data Protection Act 1998.
 The main ones being Hawk Project, zk-SNARKS, Coinjoin and Ring Signatures