Last year saw a shift to real, use-case blockchain technology proof-of-concept projects in various markets, including shipping, insurance, logistics, mining, energy, and fine art.
Most of the current projects under testing are platform-based, and use private or permissioned blockchain or similar distributed ledger technology. We consider this to be “blockchain-light” technology, and we envision that the first movers will develop and rapidly expand this technology as it continues to mature and as systems become proven (albeit in some cases proven not viable), revised, and scaled.
Current blockchain platforms tend to focus on the administration—or back-office plumbing—of relationships, where blockchain can offer real efficiency savings. Growth in the use of coded smart contracts, which automate all or part of a natural language contract, is also likely to occur. Widespread adoption can only be via platform relationships at this stage. As the technology matures, allowing interoperability between different networks in particular, more ad hoc solutions may become possible.
Tokenization will likely play a large part in many platforms. The recording of ownership of assets in digital form, tokenization (distinct from crypto assets and currencies as units of value or measures of exchange) will provide the ability to promote fractional ownership of assets, and to recognize small value sets, which offers a way to scale new projects.
As more industries adapt to using blockchain technology, there is an increasing need to understand the risks. Blockchain is one type of decentralized ledger technology (DLT). The key theme for these technologies is that they allow common and simultaneous access to information. Smart contracts utilizing such common access can then be overlaid on this network/platform. Thus the issue of risk needs to be assessed on two overlapping levels:
1. The governance of the platform or network.
2. The transaction layered on top of the network.
Governance Levels
Blockchain networks use differing internal arrangements that can be equated to governance structures. At one end of the scale, you have the public permission-less systems:
• The original Bitcoin blockchain, based on proof-of-work and essentially governed by its users on a majority basis via a decentralized autonomous organization (DAO), and thus anonymous.
• Ethereum, which also uses a DAO but is now considering moving from a proof-of-work to a proof-of-stake model.
A DAO is essentially the name given to the coded rules of the network. On Ethereum and the Bitcoin blockchain, all the decisions on how the network operates (e.g. whether to accept a transaction as valid) are made via reaching a consensus amongst the holders of the tokens (the users). This extends to any changes in the code required to deal with unexpected bugs or problems, or simply to adapt to surrounding circumstances.
Conversely, private or permissioned systems do not need to use such a governance structure because they are established by their users, who can program the systems as required. However, even private-permissioned systems may rely on existing technology. Only as the technology and its uses mature will the picture become clearer. For example, the Corda Protocol, which is an enterprise-level system (and which is neither proof-of-work nor proof-of-stake) has recently established Corda Network, operating via a unique Dutch “Stichting” organizational model (like a trust in the U.S. or UK) that will act as a kind of executive-oversight foundation whose members will determine the future shape of the technology. It proposes a parliamentary system of a board of directors voting on governance issues, elected by participants on a one-identity, one-vote basis.
Likewise, the Hyperledger fabric, which is open-source software, allows its development and functionality to be managed by its participants (with varying degrees of authority and influence) via its Linux foundation.
These issues may seem, on the one hand, fantastical and, on the other hand, remote and irrelevant to users. First, regarding the “fantastical” element, fundamentally there is nothing different in the rules of association of these platforms compared to those that trade guilds or associations established in earlier centuries: loose groupings of commercial men and women seeking to establish a framework for doing business.
Second, on whether such concerns are too remote and irrelevant to users—in many private-permissioned systems, they may be, but an example of how they can become relevant is shown by the DAO “attack” in 2016. A hacker took advantage of a recursive-call bug to drain the DAO of more than 3.6 million Ethereum coins, (valued at approximately $55 million). The problem, caused by a bug in the DAO application and not a problem on Ethereum, was rectified by a controversial “fork” of the Ethereum network, which ring-fenced the lost value.
Equally, the Quadriga debacle of 2019 saw $145 million of bitcoin and other digital assets become inaccessible when the founder died. This showed the weaknesses of tokenized systems when appropriate governance is not in place.
These considerations give rise to a number of questions that, to some extent, can be resolved by good governance of the networks:
• Do participants in a DAO, or other network management institution/framework, have a duty of care, and, if so, to whom?
• Do the advisers to a DAO have any such liability?
• What is the legal status of DAOs as entities—where the entity is essentially self-governing software engaging in or facilitating commerce, what legal status will attach to DAOs? Are they simple corporations or something else?
• What, if any, is the liability of DAOs and their creators? Who or what is claimed against in the case of a legal dispute?
• When building a permissioned system based on any such platform, who can be insured against such liability?
• When advising clients on their commercial use of such platforms, do advisers have to be aware of the governance structure and understand the implications?
• What is the true classification of an attacker’s conduct in such circumstances?
More broadly, as the technologies become more widely used, legislators, regulators, and courts will have to turn their minds to these issues and provide a proper legal framework within which blockchain can be utilized. This necessitates further clarity as to jurisdictional and applicable law issues. Where servers are decentralized and can be spread around the world, pinpointing where a breach or failure occurred (and taking the appropriate cross-border action) may be complicated.
Transaction Level
Smart contracts are coded instructions that execute on the occurrence of an event, often using a blockchain or other related technology to record and enact the instructions. Their implementation and impact can be far reaching. For example, smart contracts allow for insurance monies to be transferred virtually immediately when an event occurs, such as travel insurance paying out following a flight delay. Additionally, smart contracts allow ship owners to monitor their cargo continuously and update insurance contracts in real time as conditions change.
There is, unsurprisingly, no case law concerning this area. However, in many ways, it is analogous to a situation with liability for systems using AI, when that AI proves to be flawed. For example, consider the Therac-25 case, in which a flaw in the code of a radiology machine caused deaths. Who is responsible?
The potential to use blockchain as a platform for uploading and storing smart contracts is as empowering as it is limiting. There is an inherent expectation in smart contracts that once the self-executing code is properly recorded onto the blockchain, it cannot be altered. Immutability, in this sense, is propounded as one of the integral features of blockchain.
This presents a significant limitation as it does not account for events that may occur outside the scope of the pre-coded contracting language that would potentially render contracts unenforceable in the legal sense. An example of this is where fraud is discovered in the underlying negotiations or related transaction, and one of the parties wishes to unwind or void the contract, as it may be entitled to do with a traditional contract.
Another example would be where the contract becomes impossible to perform for unforeseen reasons outside of the parties’ control, such as war or an act of God—an event that would usually be caught under a force majeure clause in a traditional contract.
Finally, an event occurring after the contract is formed might strike at the root of the contract and, through no fault of the parties, make performance illegal or make it radically different from that contemplated by the parties at the time of the contract. This would result in frustration of the traditional contract.
From the development work we have undertaken, we consider it very difficult to write certain events or fact sets into the code in such a way as to govern how the contract would execute and respond in any given circumstance. It may be possible to expressly define in the code the events what would constitute instances of force majeure, but how do you link these to an external “oracle” or data source that does not require external control?
This might be done by creating a simple command for the contract to respond by suspending any obligations or removing the non-performing party’s liability for non-performance or delay while the force majeure event continues, or otherwise creating a right to terminate the agreement altogether where, for example, performance becomes commercially unfeasible for the parties even after the force majeure event has ceased. But we query whether this delivers improvements over a traditional non-smart contract.
Alternatively, it may just be a matter of regularly updating the software to address any errors or gaps in the code, and programming it to respond to new pieces of information. Smart contracts, much like any software, could be maintained and updated in the same way, provided there is a process and pre-agreed rules in place to govern how such changes can be made. This, however, militates the usefulness of smart contracts if you need to have in place surrounding contractual arrangements and understandings.
Ultimately, this would likely come down to a question of control and proprietorship of the software code and the ability of blockchain to accommodate alternative structures of accounting and ownership. Given the difficulties in anticipating what may constitute force majeure, frustration, or fraud, however, we consider that it may be extremely difficult to articulate such pre-agreed scenarios at the onset.
At this stage, most projects utilize a smart contract as an execution tool with an appropriate contractual “wrapper.” We encourage clients to keep such a wrapper in a short-form nature if possible. However, a criticism often made of smart contracts is that they are merely the execution arm of a contract. While this may be true at present, as the technology matures, we believe that the need for parallel contractual arrangements will, in many circumstances, wither. After all, no party enters into a contract for the sake of doing so; the parties want to transact. Thus, if smart contracts execute that transaction and can do so in a platform or network environment that has dealt with many of the uncertainties surrounding traditional contracts, then merely being the execution tool can, with sufficient imagination, be seen as a strength.
While it is certainly important that they are addressed, the core legal considerations for smart contracts remain on the periphery. We see these core considerations as:
• Clarity as to the agreement.
• Responsibility for the code—writing and maintenance.
• Clarity as to any input data (quality, accuracy, and reliability).
• Understanding of the outputs. For example, are they to be fully automated, or will they have an in-built pause or review mechanism.
• Agreement as to applicable law and jurisdiction in the event of a dispute or change in circumstance.
• Compliance with the regulatory framework.
Blockchain technology and the use of smart contracts are delivering important benefits, but there are still risks and challenges to consider. It is important to understand the legal implications involved as blockchain innovation continues and we adapt to new technologies. With the increased use of tokenization comes a new set of risks, which we are watching closely as this world of blockchain evolves.