Smart contracts: how to deal with ambiguity?

Smart contract

Smart contracts are contracts represented in code and executed by computers. They are said to revolutionise the way transactions are carried out, reduce transaction costs, remedy many of the problems that traditional contracts suffer from and even obviate the need for lawyers, notaries and other intermediaries.

It is widely believed that the use of programming languages with strictly defined syntax and automated execution will increase clarity and provide a greater level of certainty. Computer code does not permit ambiguity: something either does or does not happen as a result of code execution. While smart contacts do reduce the risk of subjective interpretation, it is questionable whether a complete elimination of contractual discretion is always desirable.

The use of ambiguous language in contracts is not inherently bad. Contracts are frequently written is broad terms to ensure a certain degree of flexibility and to allow parties to adapt to changing circumstances without the need to renegotiate the agreement. In contrast, the use of precise language may make a contract rigid and inflexible.

Another question is how to convert traditional contracts into computer code. Smart contracts are unlikely to be “written” by lawyers but by specialized programmers who will translate legal language into code. The parties to the contract and their lawyers will not be able to check whether the code correctly reflects the desired functionality. Potential errors may not become evident until the phase of implementation, i.e. when the contract is executed. As there is a huge gap of abstraction between legal and programming language, there is a risk of miscommunication and potential for discrepancies between what was agreed and what was implemented. Not all legal language is capable of a reduction into an algorithm and omitting a single word in legal documents may give rise to unintended legal consequences and prolonged disputes. Some contracts rely on abstract concepts, such as “reasonable steps” or “good faith”, that do not lend themselves to encoding as they involve value judgments and are a question of degree. As words are ambiguous and capable of multiple interpretations, they may be incorrectly interpreted by those converting a particular obligation into code.

To remedy the problem of translating legal language into executable code, lawyers should draft agreements with encoding in mind. They should write contractual terms in a way that enables their subsequent translation into code by using logical, clear and unambiguous language that the programmers can understand. It is also recommendable to supplement the use of smart contracts with a written natural language-contract that would resolve liability issues in case the smart contract does not perform as it should. Another possibility is to opt for the split contracting model where non-human performance in represented in computer code, and general contractual obligations are contained in a traditional written contract.