A. Definitional Conundrums

There is no single accepted definition of a blockchain and no agreement as to which attributes are indispensable for something to be a blockchain.Footnote ¹⁸ Blockchain is often defined as ‘[a]n open-source technology that supports trusted, immutable records of transactions stored in publicly accessible, decentralised, distributed, automated ledgers’,Footnote ¹⁹ but this definition is underinclusive. Many blockchains are not open-source, publicly accessible, or decentralised. In principle, blockchains are a species of distributed databases that are maintained by a network of geographically dispersed computers, or ‘nodes’. This means that there is no central authority in charge of the ledger and its management is instead dispersed among the nodes. In theory, this means that there is no single point of failure and no ability on the part of a single keeper of the ledger to falsify it, but it does necessarily create the challenge of ensuring that all these multiple ledgers conform to one another. As its name suggests, the ledger is made up of a chain of interconnected blocks, each block containing a list of aggregated transactions. The blocks are connected by means of cryptographic hashes,Footnote ²⁰ so that alterations in an earlier block are readily detected by checking the hash included in the block immediately following. Beyond this basic commonality, blockchains may be equipped with varying configurations of technical features.Footnote ²¹ Sometimes, it is more appropriate to speak of distributed ledgers,Footnote ²² as some distributed ledgers do not record data in interconnected blocks.Footnote ²³

B. Permissioned and Permissionless: A Key Distinction

We must first begin by distinguishing between permissioned and permissionless blockchains.Footnote ²⁴ The main distinguishing criterion between them is whether the nodes processing transactions are pre-defined or unrestricted, ie whether anyone can operate a node or whether doing so requires permission. A ‘node’ is a computer running the relevant software that enables the participation in a given blockchain network;Footnote ²⁵ ‘processing’ denotes the ability to view, create, validate, and/or add transactions to the blockchain. Permissionless blockchains, such as bitcoin or Ethereum, are constrained by ideological underpinnings. Their focus is on decentralisation and disintermediation, irrespective of whether such features are commercially necessary, simply because many enthusiasts believe that they are self-evidently desirable. In contrast, permissioned blockchains are more malleable and respond to actual, commercial needs. Free of ideological constraints, permissioned blockchains display a wider range of variations.

Permissionless blockchains are open and anonymous. They allow anyone to join the network without disclosing their identity and agreeing to any system rules or terms of use. It is only necessary to run the requisite software. The only rules that the participants must follow are those encoded in the algorithm. In principle, all participating nodes are equal and enjoy the same rights to access, use and edit the given blockchain.Footnote ²⁶ Permissionless blockchains typically involve a native crypto-asset, such as bitcoin or ether, which serves as an economic incentive to produce blocks and hence maintain the integrity of the entire system.Footnote ²⁷ They also rely on a consensus algorithm that leverages game theoryFootnote ²⁸ to compel strangers to cooperate in the absence of trust. This is necessary to ensure that all copies of the ledger conform to one another. A distributed network with non-conforming ledgers is worse than useless—confusing rather than authoritative. Today, most permissionless blockchains are based on the so-called ‘proof-of-work’Footnote ²⁹ algorithm. ‘Proof-of-work’ requires some nodes to solve a mathematical puzzle that is computationally difficult but which solution is easily verified before a new block can be added to the blockchain. This process has been christened ‘mining’, and nodes that perform this function ‘miners’, drawing an explicit, if inapt, metaphorical connection to gold mining.Footnote ³⁰ As the process is extremely expensive in terms of computer equipmentFootnote ³¹ and electricity,Footnote ³² it is more economical to produce valid blocks (ie follow the rules) than to attempt to change previous blocks (ie break the rules). Given the cost of retrospectively changing existing blocks, the possibility of altering or reversing a transaction that has been included in a block is supposedly infinitesimal.Footnote ³³

The technical attributes described above guarantee the supposed ‘trustlessness’ of the entire system, which differs from traditional ledgers where the trustworthiness of the keeper of the ledger is indispensable. The reasoning is that one can trust the code alone, without having to trust any of the nodes running the network.Footnote ³⁴ Trust in the code supposedly engenders trust in non-trusted counterparties or what enthusiasts call ‘trustless trust’. Reliance on human institutions, such as banks or courts, is replaced with reliance on technology. It can be difficult for agnostics to understand how the ‘trustless’ character of blockchains eliminates the need to trust humans since it obviously overlooks the fact that there is no immaculate conception of blockchain code.Footnote ³⁵ It must have been coded by a human or, more likely, a group of humans. Although the process of appending individual blocks is decentralised, the process of coding the blockchain is highly centralised. For example, data from May 2015 reveals that seven individuals alone were responsible for 68 per cent of the code for the bitcoin blockchain, earning them the epithet of ‘core developers’.Footnote ³⁶ Many altcoin blockchains are coded by rank amateurs, and even the core developers of more established blockchains remain frustratingly human. The recent discovery of a flaw in the bitcoin code revealed that it contained a bugFootnote ³⁷ which would have allowed malicious miners to artificially inflate bitcoin's theoretically finite supply,Footnote ³⁸ defeating its raison d’être.

Permissioned blockchains are a different beast altogether, limiting participation to identified participants who subscribe to system rules.Footnote ³⁹ The latter, virtually synonymous with ‘terms of use’ or ‘master agreements,’ govern who can join the system and how it operates. As the participants are known and legally bound to adhere to certain rules, the system itself need not be ‘trustless’, ie their consensus algorithms would not need to contain code designed to curb selfish behaviour. There is no need to trust the code of the blockchain if it is possible to trust those who operate the individual nodes. A formalised governance process is usually followed—the coders are known and the code is formally vetted before inclusion. In the absence of ‘mining’, there is no economic incentive contained within their consensus algorithms to curb selfish behaviour by participants. Non-compliant participants are instead held accountable legally. In short, they rely on good old-fashioned trust.

C. The ‘Validation’ Delusion

The technical literature often states that blockchains (or, to be more precise, their underlying consensus algorithms) ‘validate’ transactions or other events. This has confused many into thinking that the technical meaning of the term overlaps with the legal meaning—establishing compliance with the law, declaring something legally valid, or otherwise demonstrating the truth of a statement.Footnote ⁴⁰ It is necessary, however, to understand who validates what and against what criteria.

In the bitcoin blockchain, validation is inextricably linked to the concept of decentralised consensus.Footnote ⁴¹ Simply put, it is the process by which conformity of all copies of the ledger is ensured. Devotees often describe this process as involving democratisation, implying that the ability to make decisions is granted to all participants. Yet choice does not feature in decentralised decision-making. The validation process is fully automated, deterministic and almost entirely controlled by the algorithm. With few qualifications, it is devoid of room for human discretion. More importantly, ‘validation’ is premised on the fulfilment of technical conditions. In principle, a node cannot ‘decide’ to reject a transaction meeting the validation criteria or accept one that does not. Blockchain ‘consensus’ is thus difficult to map onto the legal and political meaning of the term, which denotes the process of reaching agreement among a group. There is some limited choice for miners, who can decide which valid transactions to include in the blocks that they mine, but miners do not represent the demos of a blockchain network. Given the expense involved, mining power is highly concentrated.Footnote ⁴² Choice in mining is thus more plutocratic than democratic. There is also an assumption that the very crude democracy inherent in blockchain consensus algorithms is inherently good without acknowledging that majoritarian rule can be extremely prejudicial to minorities, an acknowledgment that finds expression in most legal systems as constitutional freedoms in the political sphere and derivative actions in the economic sphere. An alternative consensus algorithm based on ‘proof-of-stake’ is even more explicitly plutocratic.Footnote ⁴³

Validation relates to transactions and blocks. In law, a transaction is associated with a bilateral or multilateral arrangement. This often takes the form of a contract or associated property transfer but it is notable that even gifts are bilateral.Footnote ⁴⁴ In the context of a blockchain, however, a ‘transaction’ denotes the unilateral transfer of crypto-assets from one account to another as identified by their respective public addresses or ‘a signed data structure expressing a transfer of value’.Footnote ⁴⁵ Technically, a ‘transaction’ is a change to the state of the blockchainFootnote ⁴⁶—not an exchange of bitcoins. What, then, does it mean that transactions are validated? To understand this, we must understand the process of generating blocks. Blocks contain lists of transactions. The appending of transactions in blocks rather than individually facilitates the use of cryptography to detect alterations to earlier transactions because the aggregated transactions are used to generate the aforementioned cryptographic hash linking one block to the next. If transactions are not appended in blocks, then some other method needs to be employed to detect/prevent ex-post alterations to distributed ledgers. To be included in a block, all nodes must establish that each transaction is correctly structured, uses previously unspent inputs, and contains sufficient transaction fees.Footnote ⁴⁷ Nodes must also confirm that the unlocking scripts match the corresponding locking scripts.Footnote ⁴⁸ Only a valid transaction can be aggregated into a block—but this does not mean that it has become part of the blockchain. Next, the block itself must be validated by the mining process. Mining consists of finding a solution to the ‘proof-of-work’ algorithm by repeatedly hashing (ie applying a cryptographic algorithm to) the data comprising the block, which includes the transactions to be included as well as some random data, until the resulting hash matches the requisite specific target. Subsequently, each newly mined block is validated by every node in the network against certain technical criteria.Footnote ⁴⁹ Validation thus signifies an automated, deterministic process of confirming that certain technical conditions have been met and carries no legal implications.

Obviously, the validation process cannot confirm off-chain events, ie events occurring in the real world. No consensus algorithm can establish or verify whether, for example, the transfer of bitcoin was actually due, whether it resulted from a legally enforceable contract, or, perhaps most significantly, whether the private key initiating the transfer of bitcoin was used by its rightful holder. As the English Law Commission recently explained, ‘[t]he question of whether an electronic signature is secure or reliable is a different matter from whether that signature is valid in law’.Footnote ⁵⁰ In technical terms, the ‘execution environment of a blockchain is self-contained as it can only access information in the blockchain. Information about external systems is not directly accessible.’Footnote ⁵¹ Blockchains can only ‘see and react’ to on-chain events—an important point often overlooked by Nelsonian enthusiasts. It is, for example, reasonable to assume that most ‘contracts’ formed on the online marketplace called Silk RoadFootnote ⁵² were invalid or unenforceable as they were almost invariably tainted with illegality. Yet, the bitcoin payments for such goods or services were all validated by the bitcoin blockchain. The failure to understand the limitations of validation have led to such absurd projects as Legalfling,Footnote ⁵³ an initiative to register consent to sexual relations on a blockchain.Footnote ⁵⁴ As its developers acknowledge, ‘[i]t has limitations in case one of the parties blatantly lies’.Footnote ⁵⁵ Simply put, its blockchain is utterly useless precisely when it is most necessary.

D. The Highly Mutable Meaning of ‘Immutability’

Blockchains are often referred to as ‘immutable’. The term can relate to three discrete situations: to the transactions or ‘assets’ recorded in the blockchain, to other information recorded in the blockchain, or to the code of blockchain-based applications. In the first instance, it is stated that once a transaction is accepted into a block and once a block is appended to the ledger, it cannot be changed or reversed. This feature is commonly associated with guaranteed performance and transaction finality. The second situation concerns the possibility to inscribe ‘other information’ into the blockchain, such as any arbitrary content that was not envisaged to be recorded by the bitcoin protocol. Examples of such content range from the original bitcoin white paper, political commentary, to more commercially-oriented content such as information about the ownership of real world assets, and even illicit content such as child pornography.Footnote ⁵⁶ Once such content is embedded in the blockchain, it cannot be removed or changed. As a result, blockchains are often regarded a perfect record-keeping technology.Footnote ⁵⁷ After all, everything that is inscribed in them stays there forever and cannot be changed. The inclusion of such information in the blockchain is the result of a ‘hack’ of bitcoin addresses.Footnote ⁵⁸ However, it is clear that the veracity of said information cannot be validated by the consensus algorithm. The third situation in which the concept of immutability becomes relevant concerns the fact that (in most permissionless blockchains) it is impossible to change the code of applications running ‘on’ it.

‘Immutability’, it turns out, is a surprisingly mutable concept. First, not all blockchains are immutable.Footnote ⁵⁹ Permissioned blockchains may give certain nodes the right to retrospectively edit the contents of a block, reverse transactions or, as part of formalised system upgrades, amend the underlying code. To the extent that such permission exists, it detracts from one of the main attractions of a distributed system: the absence of a single point of failure. It is unnecessary to hack the network if you only need to hack a single node with the permission to revise the network. Indeed, this is arguably less secure than a centralised register as each such node is a potential point of failure. Such permissioned blockchains trade the single point of failure of a centralised register for multiple points of failure.

Second, although ‘immutability’ implies that something cannot be changed at all, immutability for permissionless blockchains turns out to be highly attenuated. Most infamously, a hard forkFootnote ⁶⁰ (ie incompatible revision) of Ethereum's code was adopted by a majority of nodes in order to ‘undo’ a hack. This also ‘undid’ all transactions appended to the blockchain, including perfectly legitimate ones, since it rolled the Ethereum blockchain back to its pre-hack state. However, not all users agreed with the decision to do so and a small but significant number of users persisted in using the older code, leading to two inconsistent Ethereum blockchains – subsequently christened Ethereum and Ethereum Classic. Apart from such hard forks in the code, random temporary forks in the blockchain records themselves recur frequently for ‘proof-of-work’ blockchains. This is because ‘proof-of-work’ only ‘acts as a randomised concurrency control mechanism, in which the block frequency is adjusted such that block collisions (i.e., concurrent appends of different blocks to the blockchain) are rare’.Footnote ⁶¹ In plain English, it minimises but cannot eliminate the existence of incompatible copies of blockchains across all nodes. Such inconsistencies, or blockchain forks, arise when two or more miners successfully append different blocks onto the blockchain almost simultaneously. This results in two or more inconsistent blockchains, and although the consensus algorithm incentivises miners to mine the longest chain, it is impossible to predict which of the forked blockchains will prevail. It thus appears that blockchain immutability is not an absolute concept but rather more 60 blocks/shades of grey. Transactions get increasingly immutable as more blocks are added ahead of the block they are included in; hence the general advice to wait for six blocks of confirmation before treating a transaction as final.Footnote ⁶² In the parlance of the computer science community, ‘proof-of-work’ blockchains lack ‘consensus finality,’Footnote ⁶³ ie consensus in such blockchains can be both apparent (since nodes are unaware of forks) and fleeting (since, if a fork exists, they have no way of knowing whether their version of the blockchain will prevail). Try as it might, there are limits to how far the blockchain technology can limit the potential for multiple copies of a ledger from containing discrepancies but the scale of the challenge must also be borne in mind—today, there are more than 10,000 nodes in the bitcoin network.

Third, when speaking of blockchains as a perfect record-keeping technology, particularly in the field of provenance tracking and asset registries, the immutability of the recorded information is incorrectly associated with its veracity. Phrases like ‘the truth machine’, obfuscate the fact that if the information relates to off-chain assets or events, its inscription in a block does not guarantee its accuracy. The consensus algorithm is technically incapable of establishing the occurrence of off-chain events. In the provenance tracking and asset registration context, it cannot verify, for example, whether it was the rightful owner who ‘registered’ his cow or whether a particular batch of fish was actually caught in a certain location. Nor can it determine whether subsequent transfers are authorised. Any errors, either in recording or authorisation, married to immutability, simply produce enduring errors.

Fourth, even if a blockchain were technically immutable in an absolute sense, it would still be possible to substantially undo the effects of a transaction by way of a further transaction of equal value in reverse. To the extent that such transactions may be coerced by law, the ‘immutability’ of even native crypto-assets may be suspect.Footnote ⁶⁴ It is not difficult to imagine that a court may order such a reversal or at least compensation if, for example, the ‘transferor's’ private key had been misused by a hacker. Any law reform contemplating the use of blockchain should clarify how the law relates to each of these various conceptions of immutability but none do so.

E. Blockchains as Databases

From a technical perspective, blockchains are cryptographically secured ledgers. Traditionally, ledgers are databases (ie collections of data) recording either transactions or assets occurring or existing outside of them. Within the law, the preferred term of art where a ledger records assets is register. For our purposes, we can treat ‘ledger’ and ‘register’ as synonyms and regard both as a type of database. Logically, transactions are not executed ‘by’ or ‘on’ the pages of ledgers. Ledgers only record information about their occurrence. Exceptionally, blockchains can be regarded as enabling transactions in the sense that transfers of native crypto-assets, such as bitcoin or ether, cannot occur otherwise than ‘in’ the ledger.Footnote ⁶⁵ But ‘traditional’ assets, such as houses or cars and (less obviously) even copyright and carbon credits, do not exist solely on the pages of ledgers—ledgers reflect a state of the world outside of them.

This leads to the next point: the attributes of the blockchain must be differentiated from the attributes of other applications that run ‘on’ the blockchain or form part of a ‘blockchain system’. The differentiation requires an understanding of the technical limitations of the original blockchain. In a centralised database, modifications to its contents can only be made by a single entity, subject always to judicial oversight where asset registries are concerned. This entity controls the contents of the database and determines what other entities have read and write permissions, if any. By contrast, in a decentralised blockchain database, modifications can, in theory, be made by any node. Given that the individual nodes cannot be trusted and no single entity controls such modifications, the database itself must be trusted and incorruptible. This in turn requires the restriction of the type of permissible modifications and the manner of performing them.Footnote ⁶⁶ In short, if no one is in control and anyone has the right to modify the database, such modifications must be kept simple. Broadly speaking, an increase in the complexity of transactions that can be supported by a blockchain requires that the blockchain be equipped with additional functionalities, including the ability to accept external input—protocol layers must be added on top of them.Footnote ⁶⁷ Consequently, unless the usability of blockchains is to be confined to the generation and transfer of native crypto-assets, blockchains must be seen as only a part of a larger ecosystem of technologies built around them.Footnote ⁶⁸ Even if the blockchain is ‘trustless’ etc, this does not imply that the other components in the system share these attributes. If only the database is ‘trustless’ but none of the other system components are, then—when evaluated as a whole—the entire system is only as good as its weakest link. Cryptomaniacs tout the opposite.

A. Private Blockchain Asset Registries

First, to the extent that many of these early initiatives are entirely private, they will not be able to provide the sort of proof of ownership of the underlying assets that a public registry can provide. In this respect, we are referring not to the public or private nature of the blockchain employed but the involvement or in this case, lack thereof, of government and hence, the law. Some of these private initiatives employ permissioned blockchains but many employ permissionless blockchains. Many initiatives, especially because they tout the immutability of blockchains, implicitly assume that registries provide an authoritative record of ownership. This stems in part from a failure to distinguish between the thing that is the object of ownership and the record of the right to the thing. This is self-evident in bitcoin, where the object of ownership, ‘an electronic coin’, is defined by its ledger entries, being ‘a chain of digital signatures’.Footnote ⁷¹

Although many do not perceive the difference in form between native crypto-assets and so-called electronic bank money,Footnote ⁷² the legal nature of these two forms of assets could hardly be more different. Native crypto-assetsFootnote ⁷³ may well be electronic assets properly so-called because their legal nature is irrevocably tied to the electronic blockchain register.Footnote ⁷⁴ But that is not the case with so-called electronic bank money. Money held in bank accounts is today firmly established in most legal systems as taking the legal form of in personam claims against the bank.Footnote ⁷⁵ This was not always the caseFootnote ⁷⁶ but the historical position is now irrelevant and it is its modern form that permits its ‘transfer’ in the sense that is so misunderstood today. Such property is intangible and formless. Any register's representation of property is merely a record of the property right rather than the property right itself. The temptation to confuse the record with the right is easily dispelled when we examine registers recording tangible assets. Many jurisdictions with developed economies have well-established land registers and these registers are increasingly migrating from paper to electronic form.Footnote ⁷⁷ Yet no one supposes that the transition results in land, as opposed to its record, existing in electronic form.

The confusion stems in part from a key difference between tangible and intangible property. The category of tangible property coincides with the category of in rem rights strictly so-called and, insofar as property is regarded as a right rather than a thing, such property entail rights that relate to things, or res to employ the Latin, that are separable from and distinct from the right.Footnote ⁷⁸ While some would confine the category of property to such rights,Footnote ⁷⁹ and it is arguable that the civilian traditions, particularly those with Germanic roots, follow such a narrow conception of property,Footnote ⁸⁰ this is not true of common law systems. Common law systems have a long tradition of regarding choses in action as personal property. But it is important to observe that such property differs from that of tangible property in important respects. Unlike tangible property, where the object of the right is distinct and separable from the right itself, no such separable object exists for intangible property. This is perhaps more obvious from the supposedly archaic terminology of chose in action. Where property is in action, Blackstone explained,Footnote ⁸¹ ‘a man hath only a bare right.’ ‘The right is the res.’Footnote ⁸²

The absence of a separable object renders it easier to confuse right with record, especially where the record, like the right, is itself also intangible. We see the same temptation to confuse right and record with carbon credits in Armstrong DLW GmbH v Winnington Networks Ltd, where carbon credits recorded in electronic registries were regarded as existing ‘only in electronic form’.Footnote ⁸³ A similar confusion between right and record can be found in Article 2(2) of Directive 2009/110/EC of the European Parliament and of the Council, which defines ‘electronic money’ as ‘electronically, including magnetically, stored monetary value as represented by a claim on the issuer which is issued on receipt of funds for the purpose of making payment transactions … and which is accepted by a natural or legal person other than the electronic money issuer’.Footnote ⁸⁴ That which is stored electronically is not value per se but a record of a claim that is valuable and the muddle between record, claim, and value can lead to much unnecessary confusion.Footnote ⁸⁵ This same confusion can be found in one of Wyoming's many new blockchain ‘enabling’ laws, which defines ‘digital asset’ as ‘a representation of economic, proprietary or access rights that is stored in a computer readable format’.Footnote ⁸⁶

Unlike the case for native crypto-assets,Footnote ⁸⁷ the use of blockchain technology as an asset registry system poses entirely different challenges. These pre-existing rights are subject to well-established rules of law, particularly in relation to their transfer. Any record keeping system that is not fully compatible with these existing legal rules will therefore require legal amendments in order to be effective. Contrary to popular belief, public registration systems are remarkably heterogeneous so far as their role as indicia of title is concerned, as amply demonstrated by the various registers in English law. Some registration systems provide prima facie evidence of title such as in the case of shares,Footnote ⁸⁸ patents,Footnote ⁸⁹ and registered designs.Footnote ⁹⁰ Some registration systems, such as that for trademarks, do not purport to provide any indication as to title at all, prima facie or otherwise.Footnote ⁹¹ Where this is the case, such as for bank ledgers, ‘in the absence of fraud, the customer is not precluded by the bank statement or the pass-book from disputing an error or an incorrect debit made by the bank or from insisting on its correction’.Footnote ⁹² On the other hand, registration of a fee simple title to land in England provides far greater protection than prima facie evidence of title, going so far as to validate an otherwise void transfer.Footnote ⁹³ Torrens systems of land registration, which also have a similar effect, vividly, if misleadingly, describe such validation as indefeasibility.Footnote ⁹⁴ The entry of a notice on the register of an equitable interest in land in England behaves differently again, providing priority without validating invalid transfers,Footnote ⁹⁵ an effect similar to that provided in older legislation for the registration of deeds. Civilian registration systems are equally diverse. Although the German land register (Grundbuch) has a constitutive effect, this is not true of the French land register.Footnote ⁹⁶ To the extent that a public register confers any benefits in terms of proof of ownership, this is achieved through legislation and not the mere existence of the register itself yet it is notable that practically all blockchain legal reforms to date have been completely silent as to what happens when a blockchain record departs from a traditional analysis of title. Is the record rectifiable, as is the case with most centralised registers? If so, how can rectification work in the context of a distributed and immutable register?Footnote ⁹⁷ The form of such orders and the parties they are directed at would have to change, and questions of their efficacy would also have to be addressed. First, rectification can no longer operate by deleting the erroneous record. Instead, a new record would have to be added to the register to substantively though not formally undo it. Secondly, as there is no centralised authority against whom such an order can be made, and it makes no sense to make orders against thousands of operators of nodes, many of whom will be beyond the jurisdiction of a single court, such ‘rectification’ orders would have to be directed towards individual defendants instead to use their private keys to authorise equal and opposite transactions, likely backed by the threat of contempt proceedings. However, and consequentially, if the defendant is either out of the jurisdiction or otherwise recalcitrant, the law may be powerless to rectify such errors unless the relevant blockchain permits revisions. No permissionless blockchains can allow for such revisions and not all permissioned blockchains do. Those that do introduce single or multiple points of failure within the registry depending on the number of nodes with such permission.

Accordingly, private registers cannot guarantee title and are at best the basis of a contractual agreement as to risk allocation among participants, with many probably even failing to amount to such. Given the origins of the blockchain in bitcoin and the comparison of its blockchain to bank ledgers, it is pertinent to explain why bank ledgers, a private arrangement between banker and customer, are a poor foundation upon which to build aspirations for private blockchain asset registries. First, the nature of bank money as an asset and the means of their ‘transfer’ make them an inapposite case study for most other instances of property dealing. Because bank money essentially takes the form of a debt, they are fundamentally contractual in nature. As a result, it is theoretically within the rights of the parties to the contract, being the bank and its customer, to agree upon the scope of its availability within the limits of freedom of contract. But any agreement by two or more parties to the effect that other property would behave in a particular manner different to the default rules established by the law would fall foul of the numerus clausus (Latin for closed number) principle,Footnote ⁹⁸ which limits the types of proprietary rights the law recognises.

Nor do ‘transfers’ of bank money operate as transfers in the orthodox sense of the word, again because of its contractual nature. The doctrine of privity of contract prevents outright transfers of contractual rights. Modern civilian systems avoided this traditional Roman law by way of explicit statutory provisions,Footnote ⁹⁹ effectively reifying such claims. Common law systems circumvented the doctrine of privity by employing the notion of a derivative transfer via assignment in equity.Footnote ¹⁰⁰ Equitable assignment permitted the law to square the circle by allocating control of the right to bring the action to the assignee whilst insisting on the interposition of the assignor as claimant in any action against the obligor. Thus, the economic result of a transfer was achieved without offending the formal rule of privity. But such assignments, under both systems, which deal with the same asset, ie the very same debt claim, have nothing to do with bank ‘transfers’ of money, which do not deal in the same asset. As Fox explained, ‘[t]he chose in action representing the money transferred to the recipient's bank account is a distinct item of property from the chose in action representing the funds which were originally in the payer's account’.Footnote ¹⁰¹ To describe the process as a ‘transfer’ is ‘a misnomer’ as ‘in fact nothing tangible or intangible is transferred’.Footnote ¹⁰² Rather, a debt owed by a bank to the payer is extinguished and another debt, owed by the same or another bank to the payee, is substituted for the same amount. Through this process of extinction and creation, which is not necessarily simultaneous (again unlike a true transfer),Footnote ¹⁰³ value is transferred without a transfer of property.Footnote ¹⁰⁴ But transfers of other forms of property do not behave this way. They are true transfers properly so-called. When A sells Blackacre to B, B acquires that precise plot of land. The same is also true of cars and cows and copyright in songs.

Secondly, despite the somewhat fearsome and unsettling contractual language in standard form banking contracts, such as ‘You agree to be liable for any transactions which, according to our records, were made using your password, whether you actually made them or not’,Footnote ¹⁰⁵ the legal efficacy of such clauses is largely untested. Although most legal systems in principle respect freedom of contract, such freedom is hardly unfettered. In the United Kingdom, all standard terms that exclude liability are subject to scrutiny for reasonableness under the Unfair Contract Terms Act 1977. Where the terms are imposed on a consumer, the terms are further subject to scrutiny under the Consumer Rights Act 2015. Significantly, such clauses contradict the standards set out in the ‘Banking: Conduct of Business Sourcebook’ issued by the Financial Conduct Authority.Footnote ¹⁰⁶ In Australia, consumer protection is provided by the Australian Consumer Law.Footnote ¹⁰⁷

As such, no private initiative to establish a blockchain asset registry will be effective in establishing title beyond proving that the correct private key was used to initiate a transaction. They can no more establish that the private key was used by its rightful holder than legally prevent the owner from effecting a transfer off-chain.Footnote ¹⁰⁸ Even if we assume that this enhances transparency to some degree, private initiatives to establish blockchain asset registries face a further challenge. Where among the dozens of private blockchains should a purchaser look to identify the owner of any particular asset? For copyright in music alone, there are at least five blockchain initiatives that we are aware of at the time of writing: Berklee College of Music's Open Music Initiative,Footnote ¹⁰⁹ Blὸkur,Footnote ¹¹⁰ Mycelia,Footnote ¹¹¹ Soundac,Footnote ¹¹² and Ujo.Footnote ¹¹³ Then, there is the vexing problem of forks where the initiative utilises a permissionless blockchain, which will be examined in greater detail hereafter.

B. The Byzantine Quest for Decentralisation

Before considering the suitability of permissionless or permissioned blockchains as the technological backbone of asset registries, it is necessary to consider the very different perspectives of lawyers and technologists to what can appear at first glance to be the same problem. At its heart, the law of property is concerned with the allocation of scarce resources. Although some aspects of the law deal with initial allocations of property, many of the core rules that are well known to lawyers deal with subsequent transfers, in particular when such transfers lead to conflicting claims to the same asset. The difficult question of how such conflicting claims are to be resolved lies at the heart of the law of property. The problem is challenging because the circumstances are multifarious and competing claimants are often both innocent. The complexity of the problem is demonstrated by the range of different rules that apply in common law systems depending on the nature of the claims asserted by the competing claimants (eg, legal or equitable) and the nature of the asset claimed (money, goods, land, or other property). Registration plays only a minor role in most disputes simply because most assets are either not registered (eg, goods, notes and coins, copyright) or registration serves limitedFootnote ¹¹⁴ or noFootnote ¹¹⁵ authoritative function in establishing title to the asset. The association of registration with authoritative evidence of ownership is most commonly developed through familiarity with land registration but even here, authoritative registers are a relatively recent phenomenon. For reasons that will become obvious, a study of land registration at common law is instructive. The earliest land registries in the common law were registries of deeds,Footnote ¹¹⁶ for which registration conferred priority in disputes where conflicting claims had to be resolved but which was not authoritative.Footnote ¹¹⁷

Dissatisfied with the half measures of the deed registration system, Sir Robert Torrens of South Australia is credited with the birth of modern title registration, whereby registration is given authoritative effect. The Torrens system spread throughout the Australian colonies, New Zealand and beyond,Footnote ¹¹⁸ won admiration from English lawyers,Footnote ¹¹⁹ and served as inspiration for both the Land Registration Act 1925Footnote ¹²⁰ and the Land Registration Act 2002.Footnote ¹²¹ In order to understand the advantages and drawbacks wrought by these changes, it is necessary to first understand the devil's choice that the law of property often faces. Where C through fraud effects a ‘transfer’ of property from A to B, whose claim to the asset ‘transferred’ should prevail as between A and B? There is no universally accepted correct answer to this problem but fundamentally, any rule that favours A is said to favour what the French jurist Demogue called ‘static’ security whereas any rule that tends to favour B is said to favour what he called ‘dynamic’ security.Footnote ¹²² Static security, which prefers A, favours the policy that it ought not to be possible for a property owner to be deprived of his property by the unauthorised act of another. Dynamic security, on the other hand, which prefers B, favours subsequent bona fide purchasers at the expense of the original owner. The two aspects of security, unfortunately, lie in opposition to each other. Any improvement in static security must come at the expense of dynamic security and vice versa.

For common law systems, both the common law's default rule, which is nemo dat quod non habet,Footnote ¹²³ as well as equity's maxim, qui prior est tempore potior jure,Footnote ¹²⁴ favour static security. Lest the common law be considered peculiar, it is notable that civilian systems’ default rule, nemo plus iuris ad alium transferre potest quam ipse habet,Footnote ¹²⁵ though expressed differently, likewise favours static security.Footnote ¹²⁶ The unfortunate consequence of this policy for common law systems was that conveyancing became cumbersome, expensive and fraught with risk. Title registration along the lines of the Torrens statutes and more modern English land registers ‘decisively shifted the conveyancing law towards the opposing principle of dynamic security’.Footnote ¹²⁷ Although Sir Robert Torrens claims to have been inspired by the registration of ships,Footnote ¹²⁸ claims that its origins are in fact German and the work of Dr. Ulrich Hübbe refuse to be quieted.Footnote ¹²⁹ Although its Hanseatic origins are controversial, even doubters acknowledge the similarity of the Torrens registration system with those that existed in Hamburg at the time.Footnote ¹³⁰ By making registration more authoritative, conveyancing was simplified but carried an often forgotten cost.Footnote ¹³¹ A shift from static to dynamic security does not in and of itself prevent fraud, as a comparative analysis of Singapore and Malaysia, both operating Torrens systems, tellingly demonstrates.Footnote ¹³² All it does is shift losses when frauds occur and property owners are occasionally rudely reminded of the high cost of dynamic security. For example, in 2006 in Singapore, a 90-year-old Bebe bte Mohammad, who was suffering from Alzheimer's disease, was defrauded of her property when one of her adopted daughters forged a mortgage, which was registered, in favour of a bank.Footnote ¹³³ Another Torrens jurisdiction, New Zealand, has recently shifted slightly away from dynamic security through a controversial amendment to its legislation.Footnote ¹³⁴ It has also been suggested that Torrens registration facilitated the dispossession and exclusion of indigenous people in British colonies.Footnote ¹³⁵ It is not difficult to imagine the process of transitioning to blockchain asset registration being used as a similar opportunity to dispossess the underprivileged since the initial recording process will be dependent on the trustworthiness of third parties who tag, map, and register the off-chain assets,Footnote ¹³⁶ a problem vividly described as, ‘garbage in, garbage out’.Footnote ¹³⁷ It is thus unsurprising that by some accounts, the Honduras Title Project stalled owing to ‘political issues’.Footnote ¹³⁸

The ‘insurance principle’ underlying most Torrens registration systems is also telling. Although often heralded as the thirdFootnote ¹³⁹ key principle of Torrens registration, it was most likely established to overcome the hostilities of vested interests opposed to the shift from static to dynamic security.Footnote ¹⁴⁰ However, insurance needs to be funded and unless taxes are raised, this can only be achieved through higher transaction fees but this partly recreates one of the problems title registration was supposed to solve. That title registration legislation is not some magic wand that will cure all ills can be seen in the Hong Kong experience, where differences over the adequacy of insurance have prevented the Land Titles Ordinance,Footnote ¹⁴¹ enacted in 2004, from being brought into force.Footnote ¹⁴²

There is a further cost to the shift to title registration—all such systems operate in a ‘bijural’ fashion.Footnote ¹⁴³ They are bijural in the sense that they straddle two conflicting bodies of law. Many title registration systems confer title to the interest recorded regardless of the validity of the registered instrument. Whilst in theory no void instrument should ever be registered, in practice some defects will pass undetected by the registry and appear on the register. This necessitates a system of rules to determine when such registrations may be set aside or overridden. Bijuralism demonstrates that whilst modern title registration systems are more authoritative,Footnote ¹⁴⁴ they are not absolutely authoritative. An absolute monojural title registration system is theoretically possible but it will operate extremely harshly—as ‘indefeasibility on steroids’Footnote ¹⁴⁵—unless all possibility of error can be precluded. History reminds us that hard-edged rules emphasising certainty tend to invite pushback in the form of ambiguous rules whenever the former dictate harsh outcomes that are undesirable.Footnote ¹⁴⁶ For example, the ‘muddy’ doctrine of part performance was judicially engineered to undermine the ‘crystalline’ formalities demanded by the Statute of Frauds 1677. Given the many vulnerabilities of blockchains, particularly its dependence on the end user's ability to safeguard their private keys, the adoption of an absolute rule of ‘code as law’ for blockchain asset registries is simply untenable. All well-drafted asset registration systems contain provisions for the rectification and/or alteration of errors that can creep into the register.Footnote ¹⁴⁷ But the ‘immutability’ of blockchains is an obstacle to rectification.

The perspective of computer scientists is very different. The key advantage of a distributed system is its built-in redundancy. However, the price of distribution is the potential for inconsistency. Where the distributed system is a database, this entails the possibility that dispersed copies of the database might contain different information. This is, of course, a non-existent problem in centralised databases. The challenge for computer scientists is to ensure consensus throughout the distributed system (ie all end users see the same content) in addition to reliability. There are two main causes of failure of consensus in a distributed system. First, there could be a network failure in which, although the nodes forming the network work perfectly, the network that connects them fails, usually partially, leaving some nodes unconnected to others. Whilst such failures can be minimised, they cannot be wholly avoided. Secondly, the network could be fully functional but one or more nodes could fail. Node failures can be divided into ‘fail stop’ and Byzantine failures. When a node encounters a fail stop, the other nodes would at least be aware that it has failed because it stops working altogether. A Byzantine failure, on the other hand, is any failure in which a node operates in a flawed manner. The reasons for such failure are infinitely varied, ranging from data corruption, a bit flip in memory, to the node having been compromised by malicious software. The name originates in a seminal computer science paper that used the metaphor of several divisions of a Byzantine army camped outside an enemy city to describe the problems of achieving consensus in distributed systems when parts of it malfunction in a way that other parts are unaware of.Footnote ¹⁴⁸ Consequently, the task of building distributed systems tolerant to such malfunctions came to be known as developing Byzantine fault-tolerance. Traditional Byzantine fault-tolerant systems were designed with so-called state machine replication, in which a service is deployed in a set of servers rather than a single central server. State machine replication is also known as active replication and can be contrasted with the primary-backup, or passive, replication that most computer users are familiar with. State machine replication generally tolerates under a third of ‘malicious’ nodesFootnote ¹⁴⁹ but is limited in scalability in terms of numbers of nodes.Footnote ¹⁵⁰

The bitcoin blockchain employs a different technique to ensure distributed consensus. Although not explicit in his white paper, an archived email connects the bitcoin ‘proof-of-work’ algorithm to the problem of Byzantine failure.Footnote ¹⁵¹ The ‘proof-of-work’ consensus greatly enhances scalability in terms of the number of nodes that a network can accommodate but it is notoriously energy intensive and arguably environmentally unsustainable.Footnote ¹⁵² It also does not offer the same consensus finality afforded by state machine replication. Conventional wisdom suggests that the ‘proof-of-work’ protocol is resistant to up to 50 per cent malicious nodes, hence the popular references to what is called the 51 per cent attack. This is because the bitcoin blockchain code favours the longest blockchain. Since mining is resource intensive, short of controlling a majority of the computing power, it is extremely difficult if not impossible for malicious parties to corrupt the ledger by ‘undoing’ earlier transactions. However, it has been demonstrated that, under certain circumstances, only 25 per cent of nodes needs to be compromised in order to undermine ‘proof-of-work’ blockchains.Footnote ¹⁵³ Furthermore, actual instances of 51 per cent attacks are already happening.Footnote ¹⁵⁴ Although such attacks have primarily targeted altcoins with smaller networks, they nevertheless serve as an important cautionary tale. Permissioned blockchains where multiple nodes enjoy editing privileges are an even worse cybersecurity nightmare as each node with editing privileges is a separate and additional point of failure.

Although these security flaws are concerning, the main difficulty with transposing computer science approaches to security onto those of property law is one of incompatible perspectives. In designing distributed computer systems, computer scientists generally focus on network security. However, the weakest link in any computer network is invariably the end user rather than the network hardware or software. Whilst securing the machines rather than their human users may be the best that computer scientists can do, such an approach is wholly inadequate as a matter of property law to support a transition to unqualified dynamic security. Transfers on a blockchain are initiated by the use of private keys, which act like passwords when accessing the blockchain-based accounts identified by public keys. Whilst asymmetric key cryptography, which underlies the private–public key pair, is extremely secure when it comes to ensuring the integrity and secrecy of communications, it cannot determine that the private key was used by its rightful holder—a point recently emphasised by the Law Commission.Footnote ¹⁵⁵ There is an undisputable, mathematical link between the private and public key, but there is no similar link between a private key and its user.Footnote ¹⁵⁶ End users must maintain a delicate balance between maintaining absolute secrecy of one's private key and simultaneously ensuring that it has sufficient backups in case a copy of the key is inadvertently lost.Footnote ¹⁵⁷ If the private key is stored on a device connected to the Internet, it can be hacked like any computing device. Blockchain trustlessness provides ‘zero protection from … hacking, which is not only possible but commonplace’.Footnote ¹⁵⁸ ‘Online lists curated by bitcoin community members suggest bitcoin exchanges have been involved in up to 60 high-profile hacking incidents since the digital asset class was created in 2009. The true scale of the hacking problem, however, is hard to estimate’.Footnote ¹⁵⁹ Although most high-profile hacks have been directed at exchanges, individuals have also been targeted.Footnote ¹⁶⁰ What is the point of securing the network if the end users are left exposed? ‘Only amateurs attack machines; professionals target people.’Footnote ¹⁶¹ The risks of hacking have resulted in the practice of keeping private keys in so-called cold wallets, which are media, including paper, unconnected to the Internet. However, this trades off convenience for security. Such keys can also be ‘stolen’ if they are gleaned by dishonest strangers.Footnote ¹⁶² Good old-fashioned violence will also do the trick.Footnote ¹⁶³ To the extent that any blockchain anticipates the use of smart contracts, the coding vulnerabilities of such ‘contracts’ could expose asset holders to the sort of hack that gripped the crypto-community when the DAO was hacked. Given that the vast majority of land title frauds today target the end user rather than the registry,Footnote ¹⁶⁴ the implementation of blockchain technology for traditional asset registries is unlikely to reduce incidences of fraud, especially considering the poor cybersecurity practices of the average computer user.Footnote ¹⁶⁵ Moreover, the elderly are likely to be disproportionately exposed to such frauds.Footnote ¹⁶⁶ Apart from the difficulties in transitioning to a blockchain asset registration system in developing countries with inadequate trusted institutions, the exposure of end users who are neither technologically savvy nor able to afford satisfactory computer security is another cause to doubt that the blockchain can solve the murky title problems of these states. It is notable that a leading security technologist has recently declared that ‘[t]here's no good reason to trust blockchain technology’.Footnote ¹⁶⁷

C. Essential ‘Centralisation’?

One common refrain among enthusiasts advocating blockchain asset registries is that decentralisation will speed up certain transactions by eliminating intermediaries and simplifying clearing and settlement.Footnote ¹⁶⁸ It is not obvious, however, that speed is necessarily desirable for certain transactions. Conveyancing is, in many jurisdictions, a multi-stage transaction mired in formality. This can make it appear outmoded and unnecessarily complicated. Yet, on closer examination, such formalities, to the extent that they are slowing down the transaction, may be serving their intended function. Many jurisdictions require contracts relating to transfers or other dealings in land to take on written form because the formal documentation serves a cautionary function.Footnote ¹⁶⁹ This in turn is justified because transactions relating to land are likely to be by far the most financially significant transactions that most people will undertake in their lifetime. The time taken between contract and conveyance also facilitates fraud detection.Footnote ¹⁷⁰

It may be that improving the speed of transactions is more desirable in financial markets but does the use of a blockchain per se permit the elimination of intermediaries and the simplification of the processes of clearing and settlement? Although this is widely assumed to be the case among blockchain enthusiasts,Footnote ¹⁷¹ it is only partially true. According to Geva, ‘[i]n its narrow sense, ‘clearing system’ is a mechanism for the calculation of mutual positions within a group of participants (‘counterparties’) with a view to facilitate the settlement of their mutual obligations on a net basis. In its broad sense, the term further encompasses the settlement of the obligations, that is the completion of payment discharging them.’Footnote ¹⁷² Where the subject of intermediation is securities, disintermediation through the use of blockchain technology should not be too difficult,Footnote ¹⁷³ particularly in jurisdictions like the UK, where intermediation is not mandatory to begin with.Footnote ¹⁷⁴ Since one of the main advantages of intermediation was ‘the ease of trading and settlement’,Footnote ¹⁷⁵ provided relevant legislation is passed, the use of a blockchain could in theory provide similar ease of trading and settlement without the need for intermediation. However, intermediation in securities ownership became widespread not merely because they enabled faster transacting, but also because intermediaries offered other services ‘such as record keeping, investment management services and the provision of finance’.Footnote ¹⁷⁶ Considering that crypto-assets are native to decentralised blockchains, the proliferation of crypto-asset exchanges suggests that there is a commercial demand for intermediation that blockchains will not eliminate and a proposal for scaling bitcoin, the Lightning Network,Footnote ¹⁷⁷ bears an eerie resemblance to clearing and settlement.Footnote ¹⁷⁸

Securities are, moreover, the easy case for a blockchain asset registry because a single issue of securities is essentially fungible.Footnote ¹⁷⁹ This is not the case where derivatives trading or inter-bank money ‘transfers’ are concerned. It is convenient to use the example of inter-bank money ‘transfers’ since it is the very example used by Nakamoto to illustrate the means by which blockchain technology can facilitate money transfers through disintermediation. Nakamoto misunderstands the role of financial institutions in inter-bank payment systems. The central problem, according to him, is double-spending and the role of these financial institutions is to serve as a trusted third party to ensure that no double spending occurs. Accordingly, if the same function can be performed by an algorithm, these trusted third parties can be disintermediated. He predicted that this would lower transaction costs because the presence of these intermediaries makes it impossible for ‘[c]ompletely non-reversible transactions … since financial institutions cannot avoid mediating disputes’.Footnote ¹⁸⁰ If this is correct, then we could simply apply the blockchain technology to the banking industry and achieve Nakamoto's objectives without the need to create a crypto-asset such as bitcoin. In short, continue dealing in the same fundamental asset—fiat money—but keep records using the blockchain. The problem with this view, apart from its misprediction as to fees,Footnote ¹⁸¹ is that it misunderstands how an inter-bank money ‘transfer’ works and the nature of the trust a depositor invests in his bank when he deposits money with it. By depositing his money, a depositor is effectively lending it to the bank,Footnote ¹⁸² who is free to deal with it as it wishes. The trust inherent in the process lies in the depositor's belief in the bank's creditworthiness and predates inter-bank transfers. What we call an inter-bank money ‘transfer’ is far more complicated than most technologists appreciate. If bank money is simply a debt owing by a bank, then it must be obvious that an inter-bank money transfer cannot possibly involve the transfer of a fundamentally fungible asset since a debt is only as valuable as the creditworthiness of its debtor. In fact, there is no ‘transfer’ of any property, only a transfer of value.

Bank ‘intermediaries’ are essential to the process of such transfers. This is demonstrated by examining what happens with an ‘in-house’ money transfer where both payer and payee have accounts at the same bank.Footnote ¹⁸³ Here, the bank simultaneously reduces its liability to one customer (the payer) and increases its liability to another (the payee). It can do so not because it helps solve a double-spending problem but because it is a common obligor to both payer and payee. Where there is an inter-bank money transfer, the absence of a single common obligor complicates matters. For inter-bank money transfers within a single jurisdiction of the fiat currency of that jurisdiction, this complication is typically resolved by the banks’ relationship to the central bank. The central bank serves as the common obligor to the payer's bank and the payee's bank, thus allowing the adjustment of accounts across all four relationships: (i) between the payer and the payee; (ii) between the payer's bank and the central bank; (iii) between the payee's bank and the central bank; and (iv) between the payee and the payee's bank. The role played by the central bank may sometimes be taken by a correspondent bank where the transfer crosses borders and/or is made in a foreign currency. There may also be multiple correspondent banks involved if the payer's bank and the payee's bank do not share a banking relationship with a single bank so multiple banks must be used to bridge their accounts. Such payments are the source of the most chagrin among bank customers, but they are slow and expensive because multiple banks are involved and thus many more accounts need to be settled before a transfer can be finalised. To apply blockchain technology without fundamentally changing the nature of banking and inter-bank money transfer would therefore entail the creation of not one blockchain ledger but hundreds of thousands of inter-linked sub-ledgers,Footnote ¹⁸⁴ which, if they utilise different blockchains, create problems of interoperability.

The nature of inter-bank transfers also highlights the risks that attach to the blockchain's vaunted immutability and the price of speed. Where fiat bank money is concerned, most hacks of accounts will involve cross-border fund transfers. This is because a hacker who operates outside the jurisdiction of the victim is more likely to avoid arrest given that existing mechanisms for international police cooperation are expensive and slow.Footnote ¹⁸⁵ Such fund transfers are slow but this then affords the time to detect and prevent the fraud, as occurred with respect to one of the transfers in the stunning Bangladesh Central Bank cyberheist of 2016.Footnote ¹⁸⁶ Although most of the public attention was focused on the sums successfully ‘stolen’ by transfer to the Rizal Commercial Banking Corporation in the Philippines, it is the unsuccessful transfer to the Pan Asia Banking Corporation in Sri Lanka that is instructive. Owing to the size of the transfer and a simple typo—where the recipient's name was spelt as Shalika Fandation instead of Shalika Foundation—suspicions were aroused and the funds were not released. The purported transfer was subsequently simply reversed when the fraud was detected despite the hackers’ careful choice of timing of the weekend to ensure that no one at the New York Fed would be able to promptly respond to attempts by the Bangladesh Central Bank to halt the transfers. The ease of reversal and opportunity for detection contribute to the affordability of insurance whereas the immutability of blockchain transfers and their speed advantage across borders combine with its novelty to deter insurers from properly servicing cryptocurrency exchanges, whose insurance provisions are often inadequate.Footnote ¹⁸⁷

D. Forks in Chains: Stumbling Blocks?

All distributed ledgers, whether they employ blockchains or not, have the potential to fork (ie develop inconsistencies). Network failures can leave some nodes unconnected to other nodes. This is a problem for any distributed asset registry as one of the functions of a register is to allow the public to determine who they should be dealing with in relation to a particular asset. Such network failures cannot be wholly precluded and inconsistent records will be exacerbated by the use of ‘proof-of-work’ blockchains, which occasionally fork randomly even in the absence of network failure. Such temporary random forks are arguably inconsequential where the particular asset is not constantly traded, such as land, where the time between transactions tends to be measured in years rather than milliseconds. In that time, any prior transaction to a particular plot of land would have been buried under hundreds of blocks and any temporary aberrant fork long abandoned. However, it is less difficult to ignore for asset classes which are actively traded on a consistent basis such as securities. To the extent that some blockchain enthusiasts see the blockchain as accelerating even land transactions, such random forks necessarily take on a more problematic manifestation.

However, even worse than these random temporary inconsistencies are the more lasting hard forksFootnote ¹⁸⁸ (ie incompatible revisions) of the blockchain code, which though less common, have occurred with disturbing frequency. The Ethereum blockchain famously forked permanently into Ethereum (ETH) and Ethereum classic (ETC) in 2016 when a hard fork of its code was adopted by a majority of nodes to reverse a hack but a minority persisted in running the ‘classic’ code. Bitcoin forked into bitcoin (BTC) and bitcoin cash (BCH) in 2017 over ideological differences, before forking again into bitcoin gold (BTG) in the same year, and forking and merging with ZClassic, itself a fork of an altcoin, ZCash, to form bitcoin private (BTCP) in 2018. Most recently, in November 2018, bitcoin cash further forked into bitcoin ABC (BCH ABC) and bitcoin SV (BSV). Such forks can have dramatic negative economic consequences, as the recent fork of bitcoin cash demonstrated.Footnote ¹⁸⁹ Compared to forks of asset registries of real world off-chain assets, however, such consequences are trivial as there is no need to match forked registers to real world assets—a fork in a blockchain land registry does not create a duplicate Blackacre Classic. The solution to the problem of forks is not obvious. Taking the Ethereum hard fork as an example, it is not obvious that the choice of a majority of users to adopt the revised code should prevail over that of the minority. The majority users’ decision to do so was obviously self-serving in that they wished to regain control over assets which they lost. Yet in doing so, some perfectly legitimate transactions were simultaneously undone, with the consequence that some innocent parties may have suffered losses which was not compensated. But if the solution is not to be found in majoritarian decision-making, then on what basis should the law resolve such forks? As was the case with resolving the question of the finality of a blockchain register in the face of an unauthorised transfer, no legislation supposedly facilitating blockchain asset registries have provided any clues as to how this problem may be resolved. Instead, lawmakers who clearly do not understand the technology present such legislation on the basis that the blockchain is merely an iterative rather than revolutionary form of registry. However, it is simply not true that the use of blockchain registers, ‘is from a technological point of view a new type of dematerialized security, but one that legally has attached to it the same rights as conventional dematerialized securities’,Footnote ¹⁹⁰ as Luxembourg's lawmakers suggest. The use of the blockchain technology creates fundamentally different problems which the existing law has no solutions for.

Apart from forks, the absence of a centralised registry withdraws the simple remedy of rectification from among the legal arsenal of courts since it is impractical if not impossible to order all nodes, many of whom are outside the jurisdiction, to rectify their copies of the blockchain when an error is proven.Footnote ¹⁹¹ If some nodes rectify their copies of the blockchain and others don't, this simply creates a fork of the blockchain. The futility of the remedy of rectification thus creates a problem that may perhaps be seen to be the mirror image of what in the common law's private international law rule is known as the Moçambique rule.Footnote ¹⁹² According to this rule, a common law court has no jurisdiction to entertain an action for the determination of title to an immovable in a foreign jurisdiction. Famously, one exception to this rule by common law jurisdictions is their reliance on equity's in personam jurisdiction to enforce orders against persons holding such property occasioning from personal equities between litigants.Footnote ¹⁹³ If permissionless blockchain asset registries are adopted by a legal system, the impracticalities of rectification may force them to rely on similar personal orders even in a purely domestic dispute. Should the defendant be outside the jurisdiction, such courts may find themselves hostage to the willingness of foreign courts to enforce their orders, without which a successful plaintiff may find itself without any adequate remedy.

A. Maybe Contracts?

At a technical level, smart contracts are self-executing ledger-modification instructions, eg, ‘if X occurs, send Y amount of tokens from account A to account B’. Attempts at analysing the term from a legal (or technical) perspective are, however, rendered difficult by the existence of a multitude of inconsistent descriptions.Footnote ¹⁹⁶ Although the original definition of ‘smart contracts’ associates them with the embedding of legal terms in hardware and software to prevent breach or to control assets by digital means,Footnote ¹⁹⁷ the term has evolved to include many unrelated concepts, ranging from ERC20 tokens, Hyperledger Fabric's ChainCodeFootnote ¹⁹⁸ to ‘stateful executable objects’ hosted on a blockchainFootnote ¹⁹⁹ or ‘programs that can be deployed and run on a blockchain’.Footnote ²⁰⁰ While the original definition positions ‘smart contracts’ firmly within the legal arena and assumes that they will affect legal relations, many of the newer definitions regard ‘smart contracts’ as purely technological phenomena, virtually synonymous with Distributed

Applications on the Ethereum blockchain.Footnote ²⁰¹ Consequently, it is illogical to inquire whether smart contracts are enforceable in general because each ‘smart contract’ is different and some ‘smart contracts’ have no legal implications whatsoever. Absent a common understanding what ‘smart contracts’ are, legal scholarship struggles to form a cohesive argument, particularly when attempting to distinguish them from other ‘digital,’ ‘electronic’, or ‘online’ agreements. In principle, ‘smart contracts’ are not contracts in the legal sense although nothing stands in the way of them having legal effects. In law, a ‘contract’ is a concept that refers to an agreement between two or more parties or to the embodiment of such agreement, usually taking the form of a document containing writing. In contrast, technical writings refer to ‘smart contracts’ as entities or a particular type of technology. It is common, for example, to encounter sentences where ‘smart contracts’ do, receive or communicate with something.

Setting aside those instances where the term is used in a strictly technical sense, the common misconception that ‘smart contracts’ have the potential to disrupt the legal system derives from both the confusion in terminology and the assumption that the technical characteristics of blockchains, decentralisation and trustlessness in particular, somehow render traditional legal institutions redundant. The key term in the ‘smart contract’ narrative is ‘self-enforcement’. Purportedly, instead of being enforced by tradition legal institutions, ‘smart contracts’ can self-enforce ‘on’ or be enforced ‘by’ a blockchain, thus ‘strengthening promissory obligations without state involvement’.Footnote ²⁰² Unfortunately, the meaning of self-enforcement remains unclear as it seems to conflate two distinct stages in the life of a contract: performance and adjudication— a conflation built on top of the confusion between ‘rights’ and ‘records’. The blockchain supposedly executes the ‘smart contract’ in an unbiased and unstoppable manner. Its performance is guaranteed as neither of the parties can change their mind and refuse to perform. The execution of the code is thus synonymous with the performance of the obligation embodied therein. If performance is guaranteed, however, enforcement should not be required—assuming that ‘enforcement’ refers to the ability to seek judicial assistance in the event of breach. Performance and enforcement are mutually exclusive. The assistance of the courts is only required if ‘things go wrong’—and ‘smart contracts’ purportedly prevent things from going wrong. Upon closer analysis, most ‘smart contracts’ are simply technological tools for automating the performance of certain obligations rather than a source of obligations.Footnote ²⁰³ To complicate matters, it has also sometimes been claimed that while ‘smart contracts’ eliminate the need for judicial enforcement, the parties retain the option to do so.Footnote ²⁰⁴ The underlying reasoning is that although legal enforcement is unnecessary, it should remain possible. This approach seeks to reconcile the indiscriminate trust in technology with the practical recognition that, for ‘smart contracts’ to gain commercial acceptance, it helps that they are legally enforceable.

As a matter of contract law, both in common law and in civil law jurisdictions, there are no legal obstacles to representing contractual obligations in code or to automating certain aspects of formation or performance.Footnote ²⁰⁵ The prerequisites of enforceability for common law systems can be reduced to the idea of an agreement intended to be legally binding in which promises are supported by consideration.Footnote ²⁰⁶ It is trite law that agreement can be expressed in any manner.Footnote ²⁰⁷ A contract can be formed orally or by conduct, it can be expressed in words (either spoken or written) or in computer instructions. At least theoretically, there are no obstacles to an agreement being manifested in code in its entirety. Moreover, it is also possible to express intention by means of automated processes. This has been expressly recognised by the common law since at least 1970Footnote ²⁰⁸ and is also true of civilian systems.Footnote ²⁰⁹ Nor, as vending machines and algorithmic trading demonstrate, is automated performance legally problematic, except where automation fails due to technical problems.Footnote ²¹⁰ Indeed, the automation of aspects of formation and/or performance of standardised, mass-market contracts has been gaining in popularity since the mainstream adoption of computers and the development of the Internet—well before blockchains existed.

There are also no legal obstacles with regard to consideration so far as common law systems are concerned.Footnote ²¹¹ Consideration need not be adequate, it only needs to be sufficient in the eyes of the law.Footnote ²¹² The focus is on reciprocity, not on equivalence of value.Footnote ²¹³ The parties can exchange money in return for goods or services, or bitcoinsFootnote ²¹⁴ in return for a music download. One must also be careful not to equate ‘smart contracts’ with transactions in the technical sense, within the blockchain environment. The latter are unilateral acts, though in a ‘smart contract’, consideration will often take the form of such transactions, ie transfers of crypto-assets from one account to another. In this sense, the ‘smart contract’ can be regarded as a mechanism of transferring consideration in the form of crypto-assets and not a contract in itself. Such view is entrenched in German scholarship, which does not regard ‘smart contracts’ as contracts and thus does not address the problem of causa, the ‘reason’ for enforcing contracts or protecting promises.Footnote ²¹⁵ In principle, although crypto-assets can constitute consideration, it is arguable that questions of consideration—and questions of enforceability in general—may be misplaced. While contract law does not require equivalence of value, it requires or assumes reciprocity. Footnote ²¹⁶ Most contracts are bilateral in nature: two parties make and receive executory promises. In unilateral contracts: one party makes an executory promise in return for the doing of an act. Absent an exchange, there can be no contract. Most legal and technical writings, however, fail to acknowledge the fact that in practice ‘smart contracts’ constitute unilateral transfer mechanisms or technologies automating certain types of contractual performance.Footnote ²¹⁷ The law in most legal systems is thus no obstacle to ‘smart contracts’ and no legal reform is necessary in order to ‘encourage’ their adoption. It is simple naiveté and wishful thinking that has seen the inflated promise of ‘smart contracts’ outstrip commercial adoption. If anything, the most pressing legal reform lies in identifying the appropriate legal solution to algorithmic failures when ‘smart contracts,’ whether embedded on blockchains or not, are deployed.

B. Guaranteeing Performance?

The main selling point of ‘smart contracts’ is their purported ability to reduce transaction costs by eliminating the need to trust the other transacting party by technologically precluding the possibility of breach. Code is final, deterministic and impartial, and hence superior to humans, who are indecisive, unpredictable, and biased. Once a ‘smart contract’ is set in motion upon a blockchain—its code cannot be changedFootnote ²¹⁸ and its execution cannot be stopped. Performance is guaranteed because any subsequent human interference is impossible. Alas, this both overestimates the technical capabilities of ‘smart contracts’ and underestimates the difficulties of the contracting process.

First, the blockchain narrative often fails to distinguish between the code of the blockchain and the code of ‘smart contracts’. As indicated, applications running ‘on top of’ or connecting to the blockchain do not share its characteristics. Thus, ‘smart contracts’ running on blockchains are not even trustless to the limited extent that the blockchains may be. As ‘smart contracts’ may control the transfer of crypto-assets and tokens, a coder tasked with writing a ‘smart contract’ has an economic incentive to intentionally include ‘errors’, such as ‘backdoors’, designed to steal such assets. To the extent that consensus algorithms, such as ‘proof of work’, may curb incentives to behave selfishly, they are irrelevant to the coding of ‘smart contracts’ since the latter are created off-chain before being deployed on the blockchain. The open source character of ‘smart contracts’ is generally irrelevant as it is impossible to establish how they will operate without subjecting them to extensive testing. The ability to inspect the code cannot guarantee its quality. Moreover, as most parties will likely lack the expertise to evaluate the viability of a particular ‘smart contract’, they will have to rely on external security audits.Footnote ²¹⁹ In effect, in order to trust the code of a ‘smart contract’, the parties will have to trust its coder(s) and/or its auditor(s). It is also notable that ‘smart contracts’, as a technological innovation, predate the blockchain.Footnote ²²⁰ What the blockchain adds to ‘smart contracts’ is that it ensures the integrity of their code and guarantees their decentralised and hence secure execution. Once activated on the blockchain, the ‘smart contract’ becomes immutable to the same extent as their host blockchain. While blockchain-based ‘smart contracts’ can achieve the same limited immutability as blockchains, it should not be assumed that immutability is necessarily desirable.Footnote ²²¹ The inability to alter the code of the ‘smart contract’ will prevent the correction of errors or the introduction of new functionality that reflect changed commercial circumstances.

Secondly, apart from the transfer of native, on-chain crypto-assets, common sense dictates that few contractual obligations can be automated or enforced ‘by’ a smart contract. Logically, the ‘smart contract’ will not move trucks or build houses. In practice, mainly payment obligations can be automated. ‘Smart contracts’ are often seen as perfect vehicles for the automation of interest rate swaps or other derivatives as the latter can be expressed in numbers and formulae.Footnote ²²² In this context, legal scholars and practitioners often debate the relationship between the code of the ‘smart contract’ and its accompanying legal agreement, if any.Footnote ²²³ The assumption is that in most circumstances ‘smart contracts’ cannot exist ‘on their own’ but require an underlying, traditional legal agreement that constitutes the source of obligations. In such an event, however, there is always a risk that the code of the ‘smart contract’ diverges from the original obligation, usually due to a failure to correctly convert natural language into code, be it due to the incompetence of the coder or due to the inherent difficulty of translating legal obligations into a series of if-then statements. In the event of such divergence, it becomes necessary to agree on which ‘version’ prevails. In most circumstances, the contracting parties would have negotiated an agreement in a natural language before translating it into code—not vice versa.

This does not, however, prevent blockchain enthusiasts from agreeing that the code comprises the entire agreement in a manner not unlike an ‘entire contracts clause’, as happened in the most infamous of ‘smart contracts’, the DAO (or Decentralised Autonomous Organisation). The DAO was set up as an investment fund on the ethereum blockchain in which investment decisions would be voted upon by investors rather than left to fund managers.Footnote ²²⁴ After attracting more than US$168m worth of crypto-asset, a bugFootnote ²²⁵ in its code allowed a ‘hacker’ to siphon off some US$50m worth of invested funds.Footnote ²²⁶ But if the ‘entire contracts clause’ found on the DAO websiteFootnote ²²⁷ is to be taken seriously, then it is arguable that the ‘hack’ was perfectly legal since it was permitted by its code and the code constituted the complete contract.Footnote ²²⁸ There are frequent references to the concept that ‘code is law’—a concept that has lost its original meaning (i.e. code regulates behaviour more effectively than legal rules)Footnote ²²⁹ and became a ‘suitcase expression’ carrying different connotations depending on the context. Exceptional circumstances apart, it is generally unreasonable to expect that parties would agree to be bound by code alone—especially if they cannot ‘read’ code and hence understand or predict how it will execute.

Thirdly, in order for a ‘smart contract’ to perform the contract, it must have access to the means of performance, ie, the asset to be transferred, when the contractual conditions are met. However, the only way to guarantee such performance at the time of contracting is to ensure that the ‘smart contract’ has access to such assets as are necessary for performance at the outset. Furthermore, ‘smart contracts’ can ensure performance only if such performance entails the transfer of on-chain assets. No blockchain can control assets or events existing off-chain and we have seen how the concept of a perfectly authoritative blockchain ledger is arguably more dystopian than utopian. Even if we buy into the rhetoric of the absolute authority of a blockchain ledger, ownership without enjoyment is futile. If I purchase a cup of coffee, I wish to drink it, not simply be recognised on some blockchain as its owner. Besides, even if we assume that off-chain assets can be tokenised, for this utopian ideal to work, we must effectively rid the world of credit. After all, to ensure perfect performance—all tokens must be ‘locked’ by the ‘smart contract’ upon formation and remain locked until payment. Logically, such a ‘solution’ seems unproductive as it excludes value from the system until the ‘smart contract’ executes.Footnote ²³⁰ Credit is neither good nor evil. Properly deployed, credit can help an economy to grow,Footnote ²³¹ but many within the crypto-community are obsessed with perfect performance at all costs, an unsurprising attitude given the origins of the blockchain. In macroeconomic terms, the price of guaranteed performance may be a radically contracted economy.

Fourthly, ‘smart contracts’ must have access to off-chain information to determine when to ‘self-enforce’ because blockchains cannot ‘see’, and hence validate, anything that happens off-chain. Whenever a payment is conditional upon off-chain events/performance, so-called ‘oracles’ are required to enable ‘smart contracts’ to function. Oracles are service providers who confirm—on the basis of external data sources—the occurrence of off-chain events.Footnote ²³² Upon their verification of such event, an oracle provides its digital signature on the relevant unlocking script that controls the tokens to be transferred. While oracles solve the technical problems stemming from the ‘insulated’ character of blockchains, they annihilate their ‘trustless’ and ‘decentralised’ character by delegating trust to external entities and information sources.Footnote ²³³ In effect, the contracting parties must not only trust the code of the ‘smart contract’ but also the code of the oracle and the authenticity of the data it uses to confirm performance.

Finally, blockchain enthusiasts underestimate the difficulties of contract drafting, especially if it is to be undertaken exclusively or extensively in code. Most contractual disputes arise out of either unforeseen events or disagreement over the meaning of open-ended terms. Both problems are, however, difficult to avoid. Coders share the same human fallibility as contracting parties and their legal advisers—they cannot predict the future. Even when risks can be foreseen, it is not easy to agree on how to allocate them without resorting to open-ended terms.Footnote ²³⁴ However, computer code does not accommodate such messy solutions. Such commonplace legal standards as ‘reasonable care’, ‘best efforts’ or ‘good faith’ are impossible to express in code and difficult to replace.Footnote ²³⁵ To the extent that they are replaceable, any loss in ambiguity would mean that greater precision is required. Greater precision, however, often comes at the price of greater complexity. In effect, the transaction costs may increase as more time will be spent negotiating every detail, drafting in precise terms, and converting the contract into computer code, which complexity also substantially increases the incidences of bugs.Footnote ²³⁶

The difficulties of coding are also severely underrated, especially given the number of novice coders with rudimentary technical skillsFootnote ²³⁷ that have been attracted by the blockchain's libertarian promises. The process of coding is highly exactingFootnote ²³⁸ as it entails formulating precise instructions that describe how to complete a particular task while anticipating all possible variations that might affect its operation. In coding, there is no officious bystander to add lines of code that go without sayingFootnote ²³⁹ or reinterpret code that must have gone awry.Footnote ²⁴⁰ Coding has been likened to ‘writing War and Peace – but with no typos’.Footnote ²⁴¹ Unfortunately, ‘[i]ndustry average experience is about 1–25 errors per 1000 lines of code for delivered software’.Footnote ²⁴² The industry average for ‘smart contracts’ on the ethereum network, the most popular blockchain hosting ‘smart contracts’, is dramatically worse at more than 100 bugs per 1000 lines of code.Footnote ²⁴³ Nor do bugs simply increase in number proportionally to the length of the code. Although it might be thought that code that is twice as large would contain twice as many bugs, in fact, ‘the density of defects – the number of defects per 1000 lines of codes – increases’.Footnote ²⁴⁴ Simply put, doubling the number of lines of code will likely more than double the number of bugs in the code.Footnote ²⁴⁵

Once the difficulties of expressing obligations in code and creating error-free code are properly understood, and the realities of commercial negotiation fully appreciated, the true impact of ‘smart contracts’ on the legal profession can be more firmly grasped. ‘Smart contracts’ will not solve many of the problems arising out of commercial contracts. They can only ‘solve’ some problems by creating others. Instead of promisees having to enforce promises against promisors, promisors will have to take action to try to reverse ‘self-executing’ performance triggered by bugs in the code or inaccurate information supplied by oracles. In most cases, ‘smart contracts’, if at all useful, are better utilised to automate certain aspects only (ie specific clauses or obligations) of a contract drafted properly in natural language. The sparing use of code will limit the number of bugs and the underlying legal contract can provide a safety net for the inevitable residual bugs. The expense involved in creating such ‘smart clauses’ also suggest that they will only be cost-effective where a standard form will eventually be used in scale, such as the automation of compensation for flight delays in order to save costs and grow the market for flight delay insurance,Footnote ²⁴⁶ rather than for bespoke contracts. Their repeated usage would test the code and the legal contract can then serve as the basis for coders to debug the ‘smart clause’ so that performance improves over time.Footnote ²⁴⁷ Errors in the meantime can be dealt with outside the ‘smart clause’ on the basis of the underlying legal agreement.