Pause the Blockchain Legal Revolution

The revolutionary potential of blockchains in driving legal change has been long promised but sluggish in delivery. Our forthcoming paper suggests that the mismatch between promise and reality stems in part from a series of misconceptions, including the conflation of legal and technical meanings of certain terms, such as ‘validation’ and ‘immutability’.  We highlight the pitfalls of deploying blockchains as an asset registry technology and explode the myth that ‘smart contracts’ are poised to disrupt the legal profession. Any discussion of blockchains must first distinguish between permissionless blockchains, such as the bitcoin blockchain, and permissioned blockchains, such as Corda. Arguments that hold true in the context of bitcoin are inapplicable in the context of Corda and vice versa.

Most discussions in the legal context concern permissionless blockchains, reflecting a popular fascination with their decentralised, immutable and purportedly trustless nature. All of these terms are poorly understood by lawyers, who too often take them at face value. Many permissionless blockchains, including bitcoin, are highly centralised in terms of the number of coders responsible for their underlying code and/or their mining power. Although the process of validation is distributed, this process is also largely deterministic and devoid of discretion. The structure of such blockchains is thus more plutocratic rather than democratic. 

Although such blockchains are said to promote trustless trust, replacing reliance on human institutions with reliance on code, the oxymoronic trustless trust simply does not exist. Blockchain codes do not ‘self-create’. To trust a particular blockchain requires trust in those who coded it. These are few in number and can make mistakes. Famously, a recent ‘bug’ discovered in the relatively mature code of the bitcoin blockchain would have allowed malicious miners to artificially inflate bitcoin’s theoretically finite supply. 

Perhaps most problematic is the supposed immutable character of blockchains. Many wrongly believe that this means that once information is inscribed into a block and the block is appended to the ledger, it cannot be altered, rendering blockchains the perfect record keeping technology. First, immutability is not an absolute concept but wears sixty shades of grey. Transactions get increasingly immutable as they get buried deeper in the blockchain but are initially unsettled—hence the general advice to wait for six blocks of confirmation before treating a transaction as final in the bitcoin blockchain. Secondly, off-chain events cannot be verified by a blockchain—it cannot verify whether a house was registered by its rightful owner or a fraudster. It cannot determine whether any transfers that meet the technical requirements of validation are legally authorised. This is perhaps best demonstrated by the (now shuttered) absurd project to register consent to sexual relations on a blockchain called Legalfling. A disclaimer explained, ‘[i]t has limitations in case one of the parties blatantly lies’. What is worse, the decentralised nature of permissionless blockchains precludes the possibility of common judicial remedies such as rectification as a means of correcting errors.

There is also a failure to appreciate the role of the law in providing authoritative ownership through registration. Various registration systems exist worldwide, providing greater or lesser assurances as to the accuracy of the register but not one guarantees absolute authority. Mistakes will occur and fraudsters exist in every society. Although the blockchain is often introduced as secure, it provides zero security to the end user, who is faced with the task of protecting his private key. Hacks are commonplace. Given that most frauds today target the end user rather than the registry, it seems predictable that a transition to the blockchain will simply result in a rise in cybercrime.

The permissionless blockchain carries another fundamental flaw as an asset registry. As a form of decentralised registry, multiple copies of the registry exist. The blockchain consensus algorithm is designed to ensure that all these copies are identical but inconsistencies (named forks after the technical language of software revisions called forks) can develop for a number of reasons. Network failures could leave some nodes unconnected to others. More worryingly, the use of inconsistent software (or bugs) may engender lasting hard forks—there are now at least five versions of the bitcoin blockchain: bitcoin (BTC), bitcoin cash ABC (BCH ABC), bitcoin cash SV (BCH SV), bitcoin gold (BTG), and bitcoin private (BTCP). Originally viewed with horror, cryptomaniacs are now more sanguine about forks but forks in asset registries for real world assets are ruinous—a fork in a blockchain land registry will not create a duplicate Blackacre Classic.

Similar confusion surrounds ‘smart-contracts’, which are self-executing ledger-modification instructions. These are often not legally contracts although, from a doctrinal perspective, nothing stands in the way of ‘smart contracts’ having legal effects. The primary problem lies in bugs in coding, demonstrated spectacularly with the infamous DAO (Decentralised Autonomous Organisation) ‘hack’, which allowed a ‘hacker’ to siphon off some US$50m out of US$168m of funds raised. Bugs are surprisingly common within the software industry and statistically more commonplace among ‘smart contracts’. It is also impossible to code for many commonplace open-ended legal terms such as ‘reasonable care’ or ‘best efforts’, which will either prevent consensus to begin with, or result in longer contracts containing consequentially more bugs. The necessity to rely on oracles to determine the occurrence (or otherwise) of certain events means that ‘smart contracts’ embedded on blockchains are also not trustless even to the limited extent of their host blockchains.