The second article in our Blockchain and the Law series
While the idea of "smart contracts" as a means of executing peer-to-peer transactions is not new, the advancement of blockchain technology as a public platform for recording and executing transactions may finally provide the basis for bringing smart contracts into commercial use.
The commercial utility of smart contracts stems from the ability to automatically self-execute transactions in accordance with pre-coded instructions. While this has the potential to reduce the contracting, enforcement and compliance costs associated with related transactions, it also comes with a multitude of risks and challenges, which have yet to be adequately addressed. The very term "smart contract" is of questionable utility when used in isolation.
Legal challenges presented: Fraud, Force Majeure and Frustration
The potential to use blockchain as a platform for uploading and storing smart contracts is as empowering as it is limiting, for 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 would present 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.
As discussed in our previous article, this leads to a number of legal issues surrounding the ownership and liability of "Decentralised Autonomous Organisations" (DAOs), the entities made up of and operating through a series of smart contracts. To ignore these issues would be to ignore the possibility of the software code containing errors and being susceptible to such events or circumstances that may not have been contemplated.
One way forward would be 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, provided these may be adequately articulated in technical format. For instance, to take one of our examples, it may be possible to expressly define in the code the events that would constitute instances of force majeure. 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.
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.
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 it may be extremely difficult to articulate such pre-agreed scenarios at the onset.
A Practical Solution
It is our view that certain contractual terms may not be fully expressed in code or executed – for instance, those making reference to legal terms and concepts that require human interpretation or subjective judgment. As discussed above, this arises from the difficulty in articulating an explicit list of constituting events and the common practice of draftsmen to include sweep-up language to ensure that any list of events is not treated as an exhaustive list.
To use the example of force majeure again, a sweep-up phrase to include "any other cause outside the Seller's reasonable control" or reference to "events which the Seller should have foreseen" may be virtually impossible to execute, as it would involve an element of predicting how a contract should perform.
In such situations and certainly before the onset of AI, it may be appropriate depending on the nature of the transaction to form a type of Master Supply Agreement to govern over all smart contracts in the linked DAO. Alternatively, a joint agreement that links the smart contract to the traditional contract could be used. In this structure, a traditional contract would consist of the main terms and conditions, while the linked smart contract would act as an execution method.
Questions of enforceability, and the role, responsibility and status of the DAO, could then be properly addressed to a court of law or a specialised arbitral tribunal designed to deal with such matters in accordance with the dispute resolution clause written into the traditional contract. In our next article we consider the potential benefits of resolving disputes arising under such a joint agreement in arbitration.
In regards to the legal status of the DAO itself it may be possible for the contributing parties to simply adopt a free-to-use platform operating on open-source software with a legal charter to govern how the code can be modified and what the process involved would be.
An example of this is the Ethereum platform, which is a public blockchain platform for decentralised applications, smart contracts and DAOs, administered by a central manager ("Owner") and governed by a code ("Constitution") which determines how members can participate in the generation of contract source code and the execution of transactions.
While the legal ramifications of this platform still remain largely unclear and untested, Ethereum presents a meaningful and practical outline for how legal and technical code might exist side by side.
The Way Forward
While the technology of smart contracts is still in early stages, and many legal questions still remain unanswered, smart contracts undoubtedly offer a practical alternative to traditional commercial and financial agreements with the potential to significantly disrupt the legal and business sectors.
Providing a clear legal framework under which both legal and technical code can exist and interact is an important step both in ensuring the structured development and widespread adoption of smart contracts and blockchain at the level of industry.
Please click here to read the first article in the series.
"Smart Contracts": Where Law Meets Technology
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
