Sydney University Law Society (3).gif

Adamant: Legal Constructs as Smart Contracts

Adamant: Legal Constructs as Smart Contracts

By Alex Connolly


Alex Connolly

Bachelor of Information Technology/Bachelor of Laws II

1  Introduction

The rise to prominence of blockchain cryptocurrencies such as Ethereum, NEO and Tezos has led to a surge of interest in cryptographically enforceable methods of dispute resolution.[1] “Decentralised applications” running on these platforms allow for the execution of particular commands in predefined scenarios, or as a reaction to user input. This has prompted significant research into their ability to be “smart contracts”—programs which seek to enhance or supersede traditional contracts by automating execution and enforcement processes. 

The prospect of a trustless system of enforcing arbitrary agreements between an unlimited number of parties has significant ramifications for both individuals and society more broadly. This article will provide a detailed introduction to smart contracts from a legal perspective and analyse the consequences of a more decentralised legal system, particularly for those who cannot currently access adequate legal representation. It proposes a framework for determining whether any particular legal construct is “adamant”, that is, whether it can be represented as a smart contract.                              

2  What is a smart contract?                                      

2.1 Definitions

“Smart contracts” are computer programs designed to replace or augment existing legal constructs. They have become strongly associated with blockchain cryptocurrency protocols, and particularly with Ethereum, an open software platform based on blockchain which allows users to construct “decentralised applications”. These applications are executed by a global network of computers (each referred to as a “node”), rather than by the parties alone, and therefore allow for trustless execution of predefined instructions in response to external interaction. They maintain a block of internal storage (their “state”) to which data can be saved for later retrieval.[2]


The “blockchain” underlying this and other protocols is an ordered list of “blocks” which group together “transactions” in a particular sequence.[3] These “transactions” can move value between parties, or function as messages to particular applications currently running on the chain. The order of blocks and transactions is determined by a consensus protocol (run by the computers in the network described above), a game-theory-compatible system of incentivising honest behaviour.[4] The properties of this protocol make such a blockchain a probabilistically accurate and immutable record of interactions, enabling the creation of the trustless applications described above.[5] This article, however, is concerned with the subset of these decentralised applications that seek to mimic the functionality provided by traditional legal constructs.


2.2 Comparison with Current Contracts

Even in cases where financially protective costs orders can be made,[6] the nature of the legal system often forces parties to expend significant time and energy to recover damages for breach of contract.[7] In addition, compensation provided by a court cannot always redress the opportunity cost endured by a party who might otherwise have entered into external arrangements.[8] This has a “chilling effect” on the economy more generally: parties are forced to assess the risk of unfulfilled promises in their business decisions, and cannot rely on transactions or contracts being completed at particular times. The existence of these structures is often characterised as necessary to support the achievement of just outcomes.[9] However, Australian courts have found considerations of duration and expense to be inextricably linked to concerns of justice,[10] to the extent that there is significant motivation for reducing this consumption of legal resources.


Smart contracts allow these harms to be mitigated by facilitating binding and cryptographically secured agreements between an unlimited number of parties. Parties are able to specify complex terms and scenarios, and the contract will be enforced automatically by the network. A common example of this is a contract which represents a bet over whether a party will be able to acquire a certain amount of money in a particular time period. Both parties store the potential payout within the contract, and then the payout is made to either party after the condition is evaluated. The automated nature of the evaluation and payout allows for a “trustless” interaction between the two parties. This is particularly significant for parties who are unable to access adequate legal representation, as the automatic enforcement mechanisms provided by these “contracts” may allow them to achieve adequate redress without resorting to the courts.

 However, there is also debate about the role of courts in resolving issues related to the function and consequences of smart contracts. Deployed smart contracts will always execute in a deterministic manner in a particular context, but the parties themselves may have misrepresented their actual intentions or made an error and created a vulnerability. The most famous example of this is the Dao Hack, where a bug in the source code of the contract used to create a global investment vehicle allowed an attacker to withdraw ether valued at $50 million (now worth more than a billion dollars).[11] It was later “recovered” in controversial circumstances through a “hard fork” of the chain, where a majority of nodes agreed on an alternate history of transactions which did not include the theft of the funds, essentially performing a “51% attack” on the network. This decision divided the Ethereum community into supporters of the intervention, and those who believed that smart contracts should not be subject to oversight by either the community or existing legal systems, and that external parties are free to interact with contracts in any way they wish, even in ways which were not anticipated by the contract’s authors (adherents to the “code is law” philosophy).[12] This conflict is likely to become the subject of repeated study and investigation as the legal system determines whether courts should intervene in these cases.

Therefore, when the resolution of a legal dispute may be expedited through cryptography, it not only enhances economic efficiency but also allows for traditionally disadvantaged parties to achieve justice more effectively. In most cases, the adaptation of the legal system to incorporate smart contracts will simply consist of an application of traditional principles of contract to the present circumstances. However, the law must nevertheless formulate a coherent approach to engaging with the significant challenges sparked by this innovation and its consequences.


2.3 Analysing Smart Contracts

Szabo conceptualised cryptographic “smart contracts” as devices through which parties could automatically enforce particular obligations.[13] He outlined four objectives of smart contract design:                                                     

  1. Observability: parties should be able to supervise performance
  2. Verifiability: parties should be able to prove their performance
  3. Privity: parties should only be able to view or modify information which concerns them
  4. Enforceability: parties should be able to compel performance                                                                                                                                                             

These objectives determine the utility of a particular smart contract, but do not provide a mechanism for determining the categories of traditional constructs which are capable of translation. In order to facilitate targeted and productive investment in the development of smart contracts, it is necessary to reduce the ambiguity regarding the possibility of replacing any particular legal construct with a smart contract.[14] The remainder of this article is therefore concerned with the development of general principles for the identification of legal constructs that can be converted into smart contracts.


3  Adamant: Translating Legal Constructs

A construct is representable if it can be translated into a smart contract. Therefore, existing contracts and constructs are either:                                                           

  1. unrepresentable;
  2. partially representable; or
  3. fully representable.                      

Constructs which are partially representable are composed of at least two divisible elements, with at least one of those elements being unrepresentable. In general terms, fully representable contracts do not rely on the processes or threat of the traditional court system for execution and enforcement. This lack of reliance is desirable, not only because it allows for the efficient resolution of breaches, but also because it is often impossible for the court to compel performance (as the parties would need to have included such a mechanism in the original contract), and so the only available mechanism of redress is damages. However, there may still be value in the translation of a partially representable contract, depending on the portion of a contract which is representable.

The determination of whether a contract is representable in a particular smart-contracting paradigm involves the consideration of several factors, including the limitations of the virtual machine and the availability and cost of particular operations.[15] However, in a generic smart-contracting context, a representable contract must be “adamant”, meeting the following requirements.                                  


3.1 Accessible                               

Szabo’s principle of privity is not directly correspondent with the traditional legal doctrine of privity, which limits the ability of third parties to enforce contracts,[16] and is more analogous to a general concept of contractual privacy, where the ability to observe the current state of the contract is restricted to the parties alone. However, in order for the network to verify the validity of each alteration of the contract’s “state”, contracts stored on the blockchain must publicly expose certain details of their function[17], necessarily precluding this restriction.

Zcash, a relatively new cryptocurrency, employs zero-knowledge proofs to “shield” the identities of participants in a transaction.[18] Future smart-contracting paradigms (or updated versions of current paradigms) may be able to conceal more information from the network nodes using similar methods[19], but current contracts necessarily expose at least some of their functionality and all of their storage on the public blockchain. There have been other attempts at constructing privacy-preserving contracts through obfuscation, but all current mechanisms are infeasible for general usage.[20]            

Therefore, contracts in which the parties are not willing to reveal the state and conditions of the contract are not representable on a public blockchain. This is particularly limiting for private business-to-business transactions, as sensitive data and business logic must be concealed, and it is therefore likely that significant research will occur in this area.             


3.2 Demonstrable   

In order to facilitate enforcement, each promise in a contract must be demonstrable: there must be a predefined mechanism for evaluating whether it has been performed at a particular time. A term is demonstrable in the following circumstances:


1) Performance can be observed from the state of the contract

For some contracts, all that is required to determine whether a term has been satisfied is an inspection of the internal “state” of the contract. For example, consider a contract that requires the payment of a deposit before a secondary action can be performed. When attempting to perform the secondary action, the contract is always capable of verifying whether the deposit has been paid by querying its internal storage.


2) Performance explicitly relies on one party’s subjective discretion

If one party is totally at liberty to reject or accept the offered performance, it will be incumbent on the other to demonstrate that performance has taken place. In this case, the contract is not particularly “smart”, and serves only as a vehicle for exchanging messages. However, such a term may still be useful for reasons of transparency, convenience, or as part of a larger whole.


3) Performance is judged with reference to a third party or decentralised “oracle”

Before the contract begins, it is possible to define an external method of evaluating whether performance has taken place. For instance, a contract which outlines the conditions of a bet about whether it will be sunny tomorrow could defer to an external and trusted weather provider by means of an "oracle”, another contract which communicates with an external API.[21]

Decentralised prediction markets, such as Gnosis[22] and Augur[23], also provide a mechanism for receiving external information. These markets incentivise the provision of accurate information in a similar fashion to the game-theory consensus discussed earlier: allowing applications to determine performance according to decentralised observations about external affairs. However, this approach is unsuitable for contracts involving private information.


4) One party is able to produce a “proof of performance”

It may also be possible for one party to construct some “proof of performance”, a mathematical proof through which they could demonstrate to the other parties that they have completed some operation or know a particular secret, without revealing the content of the secret itself.[24] The ability to construct such a proof could be interpreted by the contract as proof of the party having almost certainly performed the particular term. However, such generalised proofs are currently infeasible on most major platforms.

As a counter-example, where this condition is not met: consider a contract which stipulates a “reasonable price” for a particular service. This cannot be determined by any of the mechanisms above; the decentralised market approach does not reflect the legal construct of reasonableness, and thus must be decided by the courts, making any such construct unrepresentable.                      


3.3 Accountable

Legal contracts often do not stipulate explicit mechanisms for holding other parties accountable for particular breaches, leaving conflicts either to the determination of the court or to agreement between parties based on the threat of legal action. If such mechanisms are not provided in a smart contract, the contract will be unable to respond to breaches and the parties must either rely on negotiation (necessarily favouring the party who has not yet performed) or the court system. These mechanisms must explicitly cover all cases of breach, although they may be very general—each breach of a term might incur a fixed penalty, for example, regardless of the gravity of the breach. They might also give rise to an enforcement right, giving some control over the progression of the contract to the aggrieved party. Such accountability is necessary in order to give the contract a deterministic mechanism for responding to breaches of its terms. The absence of these mechanisms will therefore preclude the representation of a traditional contract as a smart contract.                                                                      

3.4 Modular

Where a contract is partially representable, the elements which are unrepresentable must be sufficiently divisible from the representable elements to allow the contract to be translated. Such contracts can be described as modular in that they are composed of independent groups elements. For example, consider a contract where one of the terms is not demonstrable. If the parties are unwilling to be bound by the contract in the absence of this term, then the contract is clearly unrepresentable. However, if the parties are willing and able to divide the contract, then they have in effect established two new constructs: a representable set of terms and one term which must be interpreted by the courts. In this case, the representable portion of a partially representable construct is still able to be translated. The degree to which a contract is modular is therefore crucial to determining whether or not it is representable.

From the perspective of an external assessor, this process is somewhat analogous to the doctrine of severance in traditional contracts, which allows the court to set aside invalid terms in order to preserve the integrity of the contract.[25] While partial “severance” of a term is permissible, the relative importance of the remaining terms is left entirely to the subjective determination of the parties, and this determination must be made before the contract has commenced.

3.5 Allocatable

All representable contracts must be allocatable, in that all parties are able to allocate the required resources for the contract’s execution before its commencement. As punitive measures can only be enforced within the local storage of the contract (or in a pre-defined communication with an external contract), all enforcement mechanisms which rely on the availability of certain resources must preemptively bind those resources to the contract.

A contract for a loan, for example, is not representable unless the borrower is able to allocate the entire value of the loan or provide equivalent collateral, as is the case in existing blockchain loan platforms.[26] Without such a deposit, the lender has no mechanism for compelling performance of the contract. However, many of the benefits of a loan-based economy explicitly rely on the borrower not requiring the entirety of the principal to be instantly available. Therefore, any contract where any party is required to allocate resources outside their available possession for the performance of a term or for the purposes of enforcement is not representable.                        

3.6 Non-interchangeable   

Contracts which are predicated on the establishment of a new contract or a total re-negotiation of terms are unrepresentable. This primarily applies to preliminary agreements, where the parties enter into an “agreement to agree”, which generally takes one of the following forms[27]:


  1. The parties are bound immediately, but intend to restate the terms in a more formal contract with the same effect


Such a contract is unrepresentable to the extent that it countenances the addition of contractual terms. Smart contracts are not able to facilitate the addition of terms after their inception, although it is possible for existing terms to be re-negotiated, or even removed, provided that such mechanisms were established in the original contract.


2. The parties intend to be bound immediately, but performance of terms is suspended until their intention is formalised


In general, contracts of this nature will be unrepresentable, unless a complex mechanism for establishing this formal expression is embedded into the contract. 


3. The parties do not intend to be bound immediately, but only when a formal contract is signed


This category of contracts is representable, as the process of signature initiation is trivially implementable.


4. The parties intend to be immediately bound by the terms agreed upon and expect to create a further contract as a replacement for the initial contract which will contain additional terms (if agreed upon).[28]


This category is distinguishable from the three categories described in Masters v Cameron, as it contemplates a substantial alteration of the effect of the contract. All contracts of this nature are unrepresentable to the degree that they expect additional terms to be included.

This does not exclude contracts being formed for a time, and then rescinded in the establishment of a new contract. However, the initial contract must include an explicit transition mechanism, to ensure that any “state” maintained by the first contract is able to be preserved in the second.                                                                                                                              

3.7 Terminable

Traditional contracts are subject to termination through a variety of methods which may not be anticipated by the parties. Smart contracts, which cannot be deleted or be modified except through predefined interfaces, are not able to be terminated through these means. Therefore, legal constructs which do not have natural termination points, or pre-agreed termination cases, should not be translated into smart contracts. These termination mechanisms will closely resemble the termination clauses included in traditional contracts, although they must also provide for situations which would normally be the domain of the common law.[29]  Without an explicit termination mechanism, the contract will continue running on the blockchain indefinitely, exposing companies and users to serious risk of non-performance if the contract is partially representable.

Therefore, while it is possible to translate an interminable contract, the resulting smart contract could expose the participants to significant liability. If the parties are unwilling to formalise a termination mechanism, the contract should be considered unrepresentable.                                             

4  Conclusion

Current systems of enforcing contracts significantly disadvantage those without access to legal resources. Blockchain-based “smart contracts” will enable parties to enter into binding agreements more readily, more efficiently and with a more reliable standard of protection.


This article has outlined a set of criteria for determining whether a legal construct is representable as a smart contract. However, even if a contract is “adamant”, whether any particular construct should be converted will depend on the severity of its concerns, the situation of the parties and the degree to which its component elements are representable.


[1] Julie Maupin, ‘Mapping the Global Legal Landscape of Blockchain and other Distributed Ledger Technologies’ (2017) 149 Centre for International Governance Innovation Papers, 1.

[2] Gavin Wood, Ethereum: A Secure Decentralised Generalised Transaction Ledger (2014), 1.

[3] Satoshi Nakamoto, Bitcoin: A Decentralized Transaction Ledger (2008), 2.

[4] Juan Garay, Aggelos Kiayias, and Nikos Leonardos, ‘The Bitcoin Backbone Protocol: Analysis and Applications’ (2014) 2014/765 Cryptology ePrint Archive, 5.

[5] Vitalik Buterin, A Next Generation Smart Contract & Decentralized Application Platform, (2014), 1.

[6] Fire Containment P/L v Peter Robins & Ors [2011] NSWSC 444.

[7] Community Law Australia, Unaffordable and Out of Reach: the Problem of Access to the Australian Legal System (2012).

[8] Scott Elbert Dobbs, Common Law Recognition of Opportunity Costs (2003) University of Wollongong, 195.

[9] Queensland v JL Holdings (1997) 189 CLR 146.

[10] Aon Risk Services v Australian National University (2009) 239 CLR 175.

[11] Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli, ‘A Survey of Attacks on Ethereum Smart Contracts’ (2016) 2016/1007 Cryptology ePrint Archive.

[12] Quinn DuPont, ‘Experiments in Algorithmic Governance: A History and Ethnography of “The DAO,” a Failed Decentralized Autonomous Organization’ (2017) Bitcoin and Beyond: Cryptocurrencies, Blockchains and Global Governance, 5.

[13] Nick Szabo, ‘Formalizing and Securing Relationships on Public Networks’ (1997) 2(9) First Monday.

[14] Christopher Clack, Vikram Bakshi, Lee Braine, Smart Contract Templates: Foundations, Design Landscape and Research Directions (2016) CoRR abs/1608.0071.

[15] Gavin Wood, Ethereum Yellow Paper EIP-150 Revision (2017), 7.

[16] Peter Kincaid, ‘Privity and the Essence of Contract’ (1989) 12(1) University of New South Wales Law Journal, 75.

[17] Vitalik Buterin, A Next Generation Smart Contract & Decentralized Application Platform, (2014), 13.

[18] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, Madars Virza, ‘Zerocash: Decentralized Anonymous Payments from Bitcoin’ (2014), 2014 IEEE Symposium on Security and Privacy (SP), 459.

[19] Christian Reitwießner, ‘zkSNARKs in a nutshell’ on Ethereum Foundation, Ethereum Blog, December 5 2016, <>.

[20] Vitalik Buterin, ‘Privacy on the Blockchain’ on Ethereum Foundation, Ethereum Blog, January 15 2016, <>.

[21] Steve Ellis, Ari Juels, and Sergey Nazarov, ChainLink: A Decentralized Oracle Network (2017).

[22] Gnosis, Gnosis: Crowdsourced Wisdom (2017).

[23] Jack Peterson, Joseph Krug, ‘Augur: a Decentralized, Open-Source Platform for Prediction Markets’ (2015) 1501.01042 arXiv preprint arXiv.

[24] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer and Madars Virza, Succinct Non-Interactive Zero Knowledge for a von Neumann Architecture (2014) USENIX Security 2014, 2.

[25] Fitzgerald v Masters (1956) 95 CLR 420.

[26] Salt Lending, SALT: Blockchain Backed Loans (2017), 3.

[27] Masters v Cameron (1954) 91 CLR 353.

[28] Baulkham Hills Private Hospital Pty Ltd v GR Securities Pty Ltd (1986) 40 NSWLR 622.

[29] JW Carter, ‘Drafting Termination Clauses’ (2017) Vol. 31, No. 1 Commercial Law Quarterly: The Journal of the Commercial Law Association of Australia, 22.