Written by Louis Lau (Associate Author) | Mentored by Josh Lee | Reviewed by Lim How Khang
LawTech.Asia is proud to conclude the first run of its Inaugural Associate Author Programme by publishing the works of its Associate Authors. The aim of the Associate Authorship Programme was to develop the knowledge and exposure of student writers in the domains of law and technology, while providing them with mentorship from LawTech.Asia’s writers and tailored guidance from a well-respected industry mentor.
This first run of the Associate Author Programme was a partnership between LawTech.Asia and Singapore Management University’s Legal Innovation and Technology Club. After a thorough selection process, two students were selected as Associate Authors, where they worked on thought pieces with a mentor from LawTech.Asia. Their pieces were each industry-reviewed by a respected thought leader from the legal technology industry.
This piece by Louis Lau, reviewed by industry reviewer Lim How Khang (Assistant Professor at the Singapore Management University), marks the first thought piece in this series, and provides an analysis on the legal validity of smart contracts in Singapore.
Introduction
Much has been said about the dawn of smart contracts, with many vouching for its potential to replace the traditional pen-and-paper contracts.[1] Some have even proclaimed that smart contracts would remove the need for the adjudication of contractual disputes in courts, since its ability to automate contractual performance means that parties would no longer need recourse to the courts to enforce contracts.[2]
While much has been written about the benefits of smart contracts, care must be taken not to treat smart contracts as the universal panacea for the resolution of business agreements. While smart contracts can automate performance, the reality is that there are many other ways in which agreements can go wrong, thus fueling disputes amongst contracting parties (which cannot be solved with the use of smart contracts). For example, defective goods or failure to meet the other party’s reasonable expectations are some of many ways in which contractual arrangements can go wrong. In these cases, judicial recourse is often the only way to resolve issues.
In turn, these scenarios raise questions about the legal recognition of smart contracts. This article seeks to provide a brief explanation on how smart contracts work, and thereafter, analyse whether smart contracts would be legally recognisable and enforceable in Singapore.
How smart contracts work
The “smart” aspect of smart contracts
The traditional understanding of a contract is an agreement that contains rights and obligations of contracting parties (usually expressed in natural language). What makes a contract “smart”, however, is the effective integration of computer codes to facilitate automated performance. Hence, smart contracts may be defined as a set of legally enforceable rights and obligations between parties that have been formalised, interpreted and encoded into software for automatic execution.[3]
Smart contracts usually operate within a software system known as “Distributed Ledger Technology” (“DLT”). DLTs maintain digital records synchronised between various computers (or “nodes”) in a computer network. In a DLT, each node holds identical digital records locally. These records are structured in the form of data packet blocks (hence the term “blockchain”), with each block containing all prior recorded transactions as well as the current transaction’s record.
When a transaction is made, it is acknowledged (or “signed”) using a pair of digital passcodes known as a private key and public key. The signature created from the private-public key pairing is unique to every transaction and can only be produced by someone with knowledge of the private key. Therefore, a digital signature is proof of the intention of the sender to authorise the transaction, as the transaction cannot be modified by anyone after it has been signed.[4] For the purposes of this article, it is not necessary to examine technically how transactions operate within a DLT network.[5] One need only understand that there are multiple levels of encryption in DLTs to ensure the certainty,[6] authenticity[7] and exclusivity[8] of transactions.
The three models for basing a smart contract on blockchain
For transactions to occur on a blockchain, a “virtual machine protocol” (also known as the “governing system rule”) is needed to govern the conditions for transactions to occur. The parties’ agreed contractual terms would be encoded into the governing system rule, which determines when a transaction will be executed. The extent to which contractual terms are encoded within a blockchain, however, depends on the model of smart contract employed. There are generally three different models:[9]
- “Solely Code Model”. In this model, the contract is essentially present within the blockchain as written codes that execute the transaction. There is no external written agreement in natural language.
- “Internal Model”. In this model, parties agree to the contractual terms set out in natural language. Some or all of the operative contractual terms, however, are expressed in programming language. [10] The software used to automate the contractual clauses may then be used to conclude, perform, and/or enforce the contract. In the Internal Model, the contractual terms are usually encoded before the formation of the agreement.
- “External Model”. In this model, the smart contract is drafted in natural language. The contract, however, contains an agreement to use a specific software to perform, enforce or conclude the contract.
Given the above, it would be apparent that smart contracts employed via the External Model would not be subject to issues of enforceability (as the contract is drafted in natural language). Hence, the rest of this article will only focus on smart contracts encoded using the Solely Code Model and the Internal Model.
The legal implications of smart contracts
The validity of smart contracts as enforceable agreements
Under the common law system, the key prerequisites of enforceability for contracts comprises: (a) the exchange of promises and/or actions made with the intention to create legal relations; (b) the transaction is supported by consideration; and (c) in some cases, the fulfilment of formality requirements.
As smart contracts generally do not raise issues with regard to consideration or the intention to create legal relations,[11]this article will its analysis on the fulfilment of the formality requirements of a contract.
While it is often assumed the contracts must be written and signed to have legal effect, it is trite that there are generally no requirements of formality for a contract to be legally enforceable and binding.[12] Written and signed contractual documents, however, play two roles. One, a written contract is important for evidentiary purposes – it provides documentary proof of the agreement and the rights and obligations which parties have conferred upon themselves within the contract.[13] Two, in certain cases, the law imposes formality requirements for contracts to be held legally enforceable (such as contracts for the transfer of ships[14] and contracts for hire purchases).[15] Some contracts are also legally required to be evidenced in writing and signed. These cases are provided for under section 6 of Singapore’s Civil Law Act (“CLA”).[16] Under section 6 CLA, the failure to adhere to statutory formalities will result in a legally unenforceable contract.
Enforceability of smart contracts encoded via the Internal Model
For smart contracts encoded via the Internal Model, given that the rights and obligations of parties are still out within a document written (and signed) in natural language, such a contract would be able to satisfy the requirements of section 6 CLA, as well as act as documentary proof of the parties’ agreement.
While one may argue that the programme codes for the contract are encoded into the blockchain (and thus may not satisfy the requirement of a written and signed document), it may be countered that these codes pertain largely to the operative aspects of the contract facilitating the fulfilling of the agreement and do not detract from the validity of the parties agreement.
Enforceability of smart contracts encoded via the Solely Code Model
The contentious aspect, however, lies smart contracts encoded via the Solely Code Model. In such contracts, the agreement is likely to be concluded orally, with the terms encoded within the blockchain.
The first issue relates to the evidentiary capabilities of such contract. As there is no written document to evince the parties’ intentions, contractual disputes that arise from the agreement would be difficult to deal with. While documentary evidence of the code can be provided, this would not shed much light on the substantive agreement between the parties. Faced with the difficulties of understanding the parameters and substance of the agreement, courts may find themselves in the unenviable position of re-writing the agreement (at the expense of the parties’ original intentions).
The second issue relates to contracts on which formality requirements are imposed under section 6 CLA. At first blush, Solely Code Model smart contracts would appear to be unenforceable, as there is no document “in writing” or a valid signature. However, an argument may be made that the programme codes governing the conditions of the transaction may be able to fulfill the requirement of writing under section 6 CLA.
Requirement for writing under section 6 CLA
The first key challenge for programme codes regarding the writing requirement under section 6 CLA lies in their difference in characteristic compared to natural languages. Relative to programme codes, natural languages are conventional and arbitrary. While natural languages obey linguistic rules, the use of words in natural languages to denote particular objects or concepts are relatively arbitrary.[17] Natural language words embody spoken, manual or written symbols used by humans to express themselves.[18] On the other hand, programme codes, are a set of logical instructions enabling humans to interact with computers. While also a form of communication, programme codes are morphologically different, [19] given the strict and formal rules they have to abide by, and the lack of an emotive aspect.[20] Thus, simply put, programme codes are not a conventional form of communication. One might not be faulted for not immediately recognising their ability to set out an agreement between parties, much less fulfill the writing requirement under section 6 CLA.
An examination of the Electronic Transactions Act (“ETA”)[21] may nonetheless be instructive. Section 7 ETA provides that where a rule of law requires information to be written or provides for certain consequences if it was not, an electronic record would satisfy that rule of law if the information contained therein is accessible to allow for subsequence reference.[22] An electronic record is defined under the ETA as a record generated, communicated, received or stored by electronic means in an information system or for transmission from one information system to another.[23] Read together, these provisions enable most electronically stored documents to be treated as writing for the purposes of section 6 CLA.[24]Arguably, programme codes as sets of commands or instructions expressed in syntax stored in the blockchain as information governing the parties’ agreement might be seen as a form of electronic record. Thus far, however, section 7 ETA has only been discussed in relation to the recognition of content in e-mails as a valid and legally enforceable contract,[25] or in recognising that electronic contracts may be formed in the context of internet transactions.[26] It remains undecided if the ETA’s definition of electronic records can be extended to encompass smart contract programme codes.
An argument might be made by borrowing the judicial reasoning used thus far for recognising e-mail contents using the ETA. In Joseph Mathew v Singh Chiranjeev (“Joseph Mathew”), the Singapore Court of Appeal was faced with the issue of whether the requirements of section 6(d) CLA was satisfied in a contract to grant an option for the purchase of real property, given that part of the transaction’s negotiations were concluded via e-mail. Even though section 4(1) ETA[27]read together with the First Schedule of the ETA[28] appeared to exclude the operation of the ETA from transactions relating to the sale or disposition of immovable property (i.e. transactions under section 6(d) CLA), the Court of Appeal nonetheless held that given the underlying purpose of section 6(d) CLA, e-mails could be considered to satisfy the writing requirement in section 6(d) CLA.[29] In particular, the court agreed with and upheld Justice Prakash’s observations in SM Integrated Transware Pte Ltd v Schenker Singapore (Pte) Ltd that e-mail correspondences would fulfil the writing requirements of section 6(d) CLA, quoting Justice Prakash’s words as follows: [30]
“I am pleased to be able to come to this conclusion which I think is dictated by both justice and common sense since so much business is now negotiated by electronic means rather than by letters written on paper and, in the future, the proportion of business done electronically will only increase. I think that the ordinary man in the street, who not only conducts business via computer but who is being encouraged to use technology in all areas of life and to become more and more technologically proficient, would be amazed to find that the law would not recognise a contract he had made electronically even though all the terms of the contract had been agreed and the parties were perfectly ad idem.”
Judith prakash j, SM Integrated transware pte ltd v schenker singapore (PTE) ltd [2005] 2 SLR(R) 651, at [85]
The same policy argument could be made for smart contracts encoded via the Solely Code Model. With smart contracts potentially becoming a key (if not primary) source of transactions in the future, the day may come where it would not be practical for a court to deny validity to the contract on the basis that it has not been recognised before. This is particular germane when smart contracts are already seeing increasing use[31] in property[32] and e-commerce transactions.[33]
Nonetheless, without judicial or legislative pronouncements, it remains to be seen whether the the meaning of electronic records can be extended to encompass purely programme codes under Singapore law. After all, email contents are expressed in natural language (as opposed to programme codes). Thus, it is uncertain whether electronic records as defined in the ETA can truly be extended to include programme codes, which fulfils the writing requirements under section 6 CLA.
Signature requirement under section 6 CLA
The second challenge lies in whether the smart contracts encoded in the Solely Contract Model can fulfill the signature requirement under section 6 CLA. It must be noted that this relates to the validity, and not the security, of the contract. As the English Law Commission recently noted, “… whether an electronic signature is secure or reliable is a different matter from whether that signature is valid in law”.[34] Notwithstanding the security provided by the private-public key combination in DLTs, the question remains whether such digital signatures are valid.
In Singapore, the signature requirement has been interpreted relatively loosely. As observed in Joseph Mathew, a signature may appear on any part of the document, and may take any form, as long as it is capable of identifying the person in question and also evincing the parties’ intention to be bound to the agreement.[35] As for electronic signatures, the Singapore courts have also recognised these as valid within e-mails, whether in the form of an automatic insertion of the sender’s name or an e-mail address in the email header, to fulfill the requirements under section 6(d) CLA.[36]
However, an e-mail signature differs from a signature generated by a private key used to sign a transaction in a blockchain. The difference is that an electronic signature is an acknowledgment provided in an electronic format that demonstrates acceptance by and authenticate a party involved. Conversely, a digital signature is a type of electronic signature adding a layer of security layer through the use of cryptographic encryption. Simply put, a digital signature is an encrypted electronic signature.[37]
Nevertheless, the ETA recognises both electronic and digital signatures. Under section 18 ETA,[38] a digital signature is treated as electronic signature if: (a) it is unique to its user; (b) capable of identification of its user; (c) created through means under the sole control of its user; and (d) linked to the electronic record in a manner that invalidates the signature, should the record be changed.[39] The legal effect is that it triggers the presumption under section 19(2) ETA,[40] which presumes that the digital signature is: (a) the signature of its user; and (b) the digital signature was produced with the intention of approving the electronic record.
When a digital signature is generated by a private key in a blockchain, it arguably fulfills the requirements laid out under section 18 ETA.[41] Given that a private key is unique and under the sole control of its owner, in that: (a) any private key can be linked only to one owner; (b) it can be generated by a compatible programme that may be written by its user external to the DLT system or by the system itself under the user; and (c) it enables any transaction involving its user as the recipient to be decrypted, such digital signatures would also be recognised as electronic signatures under the provision. Consequently, this means that smart contracts encoded in the Solely Code Mode would arguably fulfill the requirements of a signature under section 6 CLA (and reading together sections 18 and 19(2) ETA).
Notwithstanding the above, it appears that contracting parties using a smart contract may be better advised to do so using the Internal Model. This is because the presence of a written and signed document in natural language would avoid the issues raised by smart contracts encoded in the Solely Code Model.
Conclusion
While smart contracts can help increase commercial certainty, issues of legal validity remain the Achilles’ heel of certain types of smart contracts, especially for smart contracts encoded in the Solely Code Model. Thus, until there are further clarifications regarding the validity of smart contracts, contracting parties would be well-advised to remain cautious of issues of legal validity when employing smart contracts.
[1] Wesley Egbertsen, Gerdinand Hardeman, Maarten van den Hoven, Gert van der Kolk and Arthur van Rijsewijk, Replacing Paper Contracts With Ethereum Smart Contracts: Contract Innovation with Ethereum (2016) <https://allquantor.at/blockchainbib/pdf/egbertsen2016replacing.pdf> (accessed 26 June 2019).
[2] Joshua A.T. Fairfield, Smart Contracts, Bitcoin Bots and Consumer Protection (2014) 71 Washington and Lee Law Review Online 35, 37-38.
[3] See Kelvin Low and Eliza Mik, “Pause the Blockchain Legal Revolution” (2019) International & Comparative Law Quarterly Review(Forthcoming) (“Low and Mik”) <https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3439918> (accessed 2 September 2019), 24-25. The code will likely be written in high-level code such as JavaScript or Solidity or in a domain-specific language, for example the “Ergo” domain-specific coding language or the “Digital Asset Modelling Language”.
[4] Bisade Asolo, “Blockchain Public Key & Private Key: A Detailed Guide”, Mycryptopedia (28 March 2019) <https://www.mycryptopedia.com/public-key-private-key-explained/> (accessed 3 July 2019).
[5] However, interested readers may have a look at these articles to further understand the technicalities behind DLTs: Goh Eng Han, Blockchain: the Promise of Smart Contracts, [2016-17] Singapore Law Review Juris Illuminae 1; Timur Badretdinov, “How to generate your very own Bitcoin private key”, freeCodeCamp (28 June 2018) <https://www.freecodecamp.org/news/how-to-generate-your-very-own-bitcoin-private-key-7ad0f4936e6c/> (accessed 5 July 2019); Chris Coverdale, “A Beginner’s Guide: Private and Public Key Cryptography Deciphered”, Medium (26 February 2018) <https://medium.com/coinmonks/private-and-public-key-cryptography-explained-simply-4c374d371736> (accessed 5 June 2019).
[6] Henning Diedrich, Ethereum: blockchains, digital assets, smart contracts, decentralized autonomous organizations (Wildfire Publishing, 2016), 94: Certainty is derived from the decentralised nature of DLT networks, where there is no central authority managing the network. This increases the security and resilience of the system is increased as a whole and makes the network and rules which it operates on “immutable” and “unmodifiable” once created. This prevents the digital record from being re-used (“double-spending”) and the records are capable of exclusive control by an individual.
[7] Authenticity, which stems from the fact that a transaction can only commence upon being validated in the network. Validation ensures that all recipients know that the data is not counterfeit and prevents the same data from being transferred more than once.
[8] Exclusivity refers to the “hashing” or encrypting of the transaction, such that only the intended user can decrypt the transaction message and obtain payment.
[9] UK Jurisdiction Taskforce of the Lawtech Delivery Panel, Public consultation: The status of cryptoassets, distributed ledger technology and smart contracts under English private law (May 2019) (“Lawtech Delivery Panel, Public Consultation”), 31 and 32; C.f. Clifford Chance and European Bank for Reconstruction and Development, Smart Contracts: Legal Framework and Proposed Guidelines for Lawmakers (October 2018) (“Clifford Chance, Smart Contracts”), 12 and 13. While 3 different models have been identified by the UK Lawtech Delivery Panel (i.e. (1) the “Solely Code Model” where the entire contract is worded in code with no usage of natural language in its framework; (2) the “Internal Model” where the contract is written in a document and comprises both natural language and code; and (3) the “External Model” where the contract is used entirely in natural language and there is an agreement for certain portions of the contract to be automatically performed using a program), it would appear that the “Solely Code Model” and “Internal Model” can be classified as part of the “Integrated Model” where some or all of the parties’ rights and obligations are expressed in a programming language rather than a natural language. On the other hand, the “External Model” has been termed as the “Non-Integrated Model”. For clarity’s sake, therefore, this article shall focus its examination on the models proffered by the Lawtech Delivery Panel.
[10] It has been noted by the Lawtech Delivery Panel that there are some debates as to whether the “Solely Code Model” is capable of existing apart from the “Internal Model”.
[11] Low and Mik, 26.
[12] The Law of Contract in Singapore (Andrew Phang gen ed) (Academy Publishing, 2012) (Andrew Phang, The Law of Contract in Singapore), 08-001.
[13] Andrew Phang, The Law of Contract in Singapore at para 08.002.
[14] Merchant Shipping Act (Cap 179, 1996 Rev Ed), s 18.
[15] Hire-Purchase Act (Cap 125, 1999 Rev Ed), s 3.
[16] Civil Law Act (Cap 43, 1999 Rev Ed) (“CLA”).
[17] C M Millward & Mary Hayes, A Biography of the English Language, (Cengage learning, 3rd Ed, 2011).
[18] See Ana v Harris, Human languages vs. Programming languages, Medium (1st November 2018) <https://medium.com/@anaharris/human-languages-vs-programming-languages-c89410f13252> (accessed 7 July 2019) (“Ana Harris, Human Languages”).
[19] Ana Harris, Human Languages. Morphology is the study of words, their formation, their relationship with other words in the same language, as well as the ways context can change a word’s pronunciation and meaning. See also Mark Aronoff and Kirsten Fudeman, What is Morphology, (Blackwell Publishing, 1st Ed, 2004), 1 to 3.
[20] Ana Harris, Human Languages.
[21] Electronic Transactions Act (Cap 88, 2011 Rev Ed) (“ETA”).
[22] ETA, s 7.
[23] ETA, s 2(1).
[24] Andrew Phang, The Law of Contract in Singapore at para 08.050. However, under the First Schedule of the Electronic Transactions Act 2010, it was held that any contract for the sale or other disposition of immovable property, or any interest in such property, would be excluded from the ETA.
[25] SM Integrated Transware Pte Ltd v Schenker Singapore (Pte) Ltd [2005] 2 SLR(R) 651 (“SM Integrated”), which was affirmed by the Singapore Court of Appeal in Joseph Mathew v Singh Chiranjeev [2010] 1 SLR 338 (“Joseph Mathew”).
[26] See Chwee Kin Keong and others v Digilandmall.com Pte Ltd [2004] 2 SLR(R) 594.
[27] ETA, s 4(1).
[28] ETA, First Schedule.
[29] Joseph Mathew at [38].
[30] Joseph Mathew at [38], citing SM Integrated at [80] and [85].
[31] “Smart Contracts Market is estimated to grow at a CAGR of 32% by Forecast to 2023”, Reuters (16 April 2018) <https://www.reuters.com/brandfeatures/venture-capital/article?id=33313> (accessed 23rd June 2019).
[32] Rachel Wolfson, “Global Real Estate Platform Completes Sale Of $1M California Home Using Blockchain Technology”, Forbes (7th February 2019) <https://www.forbes.com/sites/rachelwolfson/2019/02/07/global-real-estate-platform-completes-sale-of-1m-california-home-using-blockchain-technology/#1dc10afd3a92> (accessed 22nd June 2019).
[33] “How Blockchain will Improve E-Commerce”, Medium (27 July 2018) <https://medium.com/ethereum-dapp-builder/how-blockchain-will-improve-e-commerce-773a17837f13> (accessed 22 June 2019).
[34] Law Commission Consultation Paper No 237, Electronic Execution of Documents (21 August 2018), 20.
[35] Joseph Mathew at [29], referring to Cheshire, Fifoot and Furmston’s Law of Contract, (Oxford University Press, 15th Ed, 2007), 273.
[36] SM Integrated at [91] and [92].
[37] The Electronic Transactions Act, Startup Decisions <https://www.startupdecisions.com.sg/singapore/business-laws/electronic-transactions-act/> (accessed 3 July 2019).
[38] ETA, s 18.
[39] ETA, s 18.
[40] ETA, s 19(2).
[41] ETA, s 18.
This piece was written as part of LawTech.Asia’s Associate Authorship Programme.