Despite the resent downturn in the cryptocurrency market, the “crypto winter”, the use of smart contracts remains an important and growing area of technology. A smart contract is a self-executing contract with the terms of agreement written into code. They can be used to automate the performance of contracts and reduce the need for manual intervention, making them particularly useful in industries where transactions are frequent and repetitive.
One could imagine a farmer and an insurance company entering into a smart contract to automatically pay out a policy if the temperature in the farmer’s region reaches over 30C for more than two weeks. The insurance company uploads code that triggers the payment when the temperature threshold is reached, and the farmer agrees to the terms by transferring a premium payment.
Smart contracts have the potential to being significant efficiency and cost-saving benefits to a wide range of industries, including finance, insurance, real estate, supply chain management, and more. While the use of smart contracts is still in its early stages, it is likely to become increasingly prevalent as the Law Commission offers guidance and their use becomes more widely adopted.
Despite the potential benefits of smart contracts, there are also significant risks and challenges to be aware of. One key area of risk is related to the concept of offer and acceptance. In the case of smart contracts, the offer and acceptance may be implied or explicit, depending on the specific terms of the contract and the actions of the parties. This article will explore the risks and challenges related to offer and acceptance in the context of smart contracts, and discuss strategies for minimising those risks.
Current state of the law
On 25 November 2021, the Law Commission published its advice to the government, concluding that the UK’s legal regime is ‘clearly able to facilitate and support the use of smart legal contracts.’ Within this report, the Commission took the opinion that there were no issues relating to contract formation that emerged from smart contracts and specifically that ‘if […], a computer program can make an offer, we see no reason why a computer program cannot also accept an offer.’
To return to the farmer and temperature insurer, the code uploaded by the insurance company could be ambiguous and open to interpretation. For example, it may not specify whether the temperature threshold applies to the farmer’s specific location or to the region as a whole. Additionally, the code may not specify how the temperature will be measured or who will be responsible for providing the temperature data. However, the ‘contract’ would seem to be made – with automatic transactions from both parties and yet with a fundamental uncertainty about what the terms of the agreement actually existed.
Smart contracts could be anything from the automation of an offline written contract or exist as computer code by itself. In this sense, the concept could cover anything from blockchain automation of simple escrow agreements right up to complex autonomous programmes that can make independent decisions. Applying traditional contract law to agreements that are written and subsequently automated is relatively uncontroversial.
It is where agreements are ‘code only’ that the real powers, and risks, of blockchain technology arise. A recent example of this is the case of Quoine Pte Ltd v B2C2 Ltd [2020] SGCA(I) 02, where a cryptocurrency exchange platform had failed to implement certain necessary changes to its algorithmic program which led to disputed trades being executed at an exchange rate that deviated greatly from the market rate. This highlights the potential for unintended consequences and potential losses for parties involved in smart contract trades. For smart contracts, the parties’ code is uploaded and becomes immutable, meaning that it will automatically execute the agreed upon outcomes without the need for further human intervention. This can be an efficient process, but it also carries significant risk for the parties involved, particularly if the trade leads to adverse outcomes. Once started, smart contracts on the blockchain would be immutable, assuming there was no kill-switch, leaving their creators to watch on in horror.
Offer and Acceptance
To unpick these transactions, Courts have resorted to traditional conceptions of offer and acceptance. Indeed, the current approach in smart contracts, as proposed by the Law Commission and the majority of respondents, is based on three cases: Thornton v Shoelane Parking Ltd [1970] EWCA Civ 2, R (Software Solutions Partners Ltd) v R& C Commissioners [2007] EWHC 971 (Admin), and Quoine v B2C2. These cases suggest that computer programs, such as smart contracts, can be likened to vending machines or parking meters. When someone or something interacts with these programs, it is considered acceptance of the implicit offer.
Software Solutions expands on this idea by stating that this analysis applies to offers made by computer programs. Once the necessary data has been input into the electronic process, no further human intervention is needed for the formation of a binding contract between the parties. Quoine v B2C2 goes even further, suggesting that the whole process of offer and acceptance in smart contracts can be automated. In this case, the principles of formation did not prevent the formation of a contract when one algorithm made an offer that was accepted by the other.
On the face of it, this would appear to mirror the approach taken for algorithmic trading built on the principles outlined by multilateral contracting which stem from The Satanita [1897] AC 59. For traders, this means that by agreeing to engage in trading underpinned by ISDA agreements, contractual obligations emerge to each party. By comparison, in a smart contract transaction the terms of the agreement could be far less clear and much harder to define and accordingly to create clear obligations for each party. Rather than internationally agreed and recognised rules for trading, transactions take place on a system that prides itself on decentralisation. This could make it harder to define on whose terms parties are transacting.
Mitigating Risk – Construction of Contract
In mitigating these risks there are a number of things to be aware of. Perhaps the most crucial is ensuring that the smart contract is clearly written and unambiguous: parties should take care to ensure that the terms of the smart contract are clearly written and that there is no room for interpretation or misunderstanding. This would be simplest if code based smart contracts had a natural language counterpart to confirm what the terms parties were contracting on.
Equally though, comments embedded in the code could serve as an additional component of natural language to aid interpretation. In a smart contract, the terms and conditions are written into the code and are immutable and automatically enforced. Ensuring clarity at the first instance of agreement with a keen awareness of the broader terms and conditions that platforms use would both help to maximise the efficacy of smart contracts and minimise the potential risks.
These could also be minimised by using established legal frameworks, such as the Open Law project, to create and execute smart contracts. These frameworks provide a level of legal certainty and can help to reduce the risk of disputes or challenges to the validity of the contract. Similarly, parties can also minimise legal risk by using standardised templates and protocols for smart contracts, which can help to ensure that the contract is well-defined and consistent with industry standards.
Mitigating Risk – Disputes
Having robust dispute resolution mechanisms in place is crucial in the event of a dispute, as it can help to resolve issues efficiently and effectively. In the context of two algorithms contracting without human interaction, it can be challenging to agree on dispute resolution mechanisms as there is no direct communication or negotiation between the parties. However, there are still ways for the algorithms to establish dispute resolution mechanisms.
One approach is to include pre-determined dispute resolution protocols within the algorithm’s code. For instance, the algorithms can be programmed to automatically initiate arbitration or mediation with a neutral third-party algorithm in case of a dispute. This can be done through a smart contract that includes a provision for dispute resolution and specifies the algorithm to be used or uses smart oracles to resolve disputes. Smart oracles act as neutral third-party services that provide external data or information to the contract, and can be programmed to make a determination in case of a dispute.
Another way to mitigate risk in smart contracts is through the use of a kill switch. This feature allows the creator of the smart contract to disable or terminate the contract under certain circumstances. By including a kill switch in the smart contract, the creator can protect themselves from the risk of offer and acceptance by giving themselves the ability to terminate an offer before it is accepted or even stop the contract from being executed if something goes wrong.
In the context of the farmer and insurance company for example, a kill switch could be triggered under certain conditions. For example:
- Smart Oracles: If a dispute arises over the temperature data provided by the farmer, a smart oracle could be used to verify the data and make a determination. If the oracle determines that the data is inaccurate, it could trigger the kill switch to terminate the contract.
- A specific data or time: The kill switch can be activated if the contract reaches a specific date or time that is specified in the contract, for example, the end of the farming season.
- A threshold exceeded: The kill switch can be activated if a certain threshold, such as temperature or other environmental variable, is exceeded. For example, if the temperature exceeds a certain level for an extended period of time, the kill switch can be triggered to terminate the contract.
It is important for the parties to clearly define and agree on the conditions under which a kill switch can be triggered in order to minimise the risk of disputes and ensure that the contract can be stopped if necessary.
Conclusion
In conclusion, smart contracts have the potential to revolutionise the way we conduct business by automating contract performance and reducing the need for manual intervention. As the use of smart contracts becomes more prevalent, it is important to be aware of the risks and challenges associated with them, particularly related to the concept of offer and acceptance. The good news it that the Law Commission has already made it clear that the UK’s legal regime is able to support and facilitate the use of smart legal contracts.
However, it’s still important to ensure that the smart contract is clearly written and unambiguous. Parties should take care to ensure that the terms of the smart contract are clearly written and that there is no room for interpretation or misunderstanding. Robust dispute resolution mechanisms, smart oracles and kill switches can be used to mitigate risks and ensure that the contract can be stopped if necessary.
Jamie is currently studying at the Inns of Court College of Advocacy intending to practice at the Commercial Bar. He has previously built a website to notify and categorise justifications for self-defence and is interested in developing intersection between technology and law.
