Towards Measuring Smart Contract Automation

Blockchains are an interesting new technology emerging into large scale commercial deployments for a variety of different applications. While cryptocurrencies were the initial application, the development of smart contracts has enabled a broader variety of transactions on blockchains. Financial transactions using blockchain smart contracts have become a significant element of broader transformations in the financial service industry. “FINTECH” refers generally to the broader transformation of financial services by technology solutions. “DeFi” refers to a more specific, though perhaps less widely supported transformation towards Decentralized Financial services using permissionless (or public) blockchains.

Smart contracts automate transactions of cryptocurrencies and other tokenized digital assets between account holders. Smart contracts execute on the blockchain; and use the block to maintain transaction state information. Some smart contracts may also use oracles to interact with cyber-physical resources, off chain computing resources or other information sources. Not every smart contract is required to have legal significance, but generally this is required for financial transactions above a certain size so that legal recognition and enforcement of the financial transaction can be available.

The scope of a legal contract is a fundamental factor in any legal contractual dispute. Generally, disputes over contract scope center around whether the contract is completely contained in a single document, or whether there are additional contractual terms captured elsewhere. An analogous problem exists in the context of smart contracts as to the scope of the agreement. The academic literature has recognized a continuum of solutions between two extremes (a) the code is the contract vs (b) the code is an implementation of a separate legal document. In practice, not all the terms and clauses of a typical legal contract are executable by a smart contract, hence intermediate solutions are desirable. Intermediate solutions include (i) the annotation of code with legal terms that are not executable by the smart contract, or (ii) the annotation of traditional contractual language to identify terms that might be computable by a smart contract. It may be easier to think of these intermediate solutions as targeting different types of users. Type (i) smart contracts might be of particular interested to software developers operating in a relatively fixed legal environment. Type (ii) smart contracts might be considered of particular relevance to lawyers and other non- software developers that are interested in focusing on the terms and clauses without being so concerned about the software implementation mechanics. Templated legal contracts have previously been used for contract automation, and this approach also applies for type (ii) smart contracts.

Given the dissonance in practical implementations between the scope of the legal contract and the corresponding executable smart contracts, it becomes interesting to consider how to measure the gap between these entities. Clack (2018) considered comparing the semantic differences, but legal prose and computer source code are recorded with vastly different levels of precision, making this approach difficult.  The ISDA (2018) whitepaper, in considering the automation of derivates contracts via smart contracts, distinguishes between the contract terms that should or could be automated within the overall scope of terms in derivative contracts. Templated contracts provide a mechanism to identify the specific elements of the contract which are computationally significant.  Some comparison of the quantity of computable terms within a contract compared to the size of the overall contract may therefore provide a useful perspective on the degree of automation of the contract.

There are a number of tools and methods for capturing templated contracts. Similarly, a variety of languages exist for encoding the corresponding smart contract.  Several of these are even available, to varying degrees, in open source, thus enabling easier access for study. Project Accord[1], hosted by the Linux Foundation, is one such open source project providing tools and templates for smart legal contracts. In particular, this project provides[2] (as of 9/1/2020) a repository with 51 examples of contract text with corresponding data structures for the data fields that are computable within the smart contracts.  The figure below provides plots of various measures of the size of the legal clause or contract (# words, # sentences, # paragraphs, # clauses) vs counts of the number of data fields that were templated with a linear trendline for reference. These plots show an increasing trend of number of templated terms with the size of the contract.  But the number of data fields templated as rather low in comparison to the size of the contracts with (on average) <5 per legal clause, <2.5 per paragraph, < 1.5 per sentence, and overall <10% of words were templated as data fields.

This corpus may be rather small; a larger corpus may provide for more statistical rigor. This corpus is also intended as exemplary; it is an aid to illustrate the operation, and feasibility, of the smart contract functionality provided by accord. In that sense, it may not be representative of commercial smart contracts in operation on various blockchains.

If we consider the templated data fields as being the terms that should be automated in ISDA’s parlance, having only 10% of the words in this category would seem to indicate that a relatively low degree of automation at present. This may be indicative of the current state of the technology, where the easier use cases are automated first.  It would be interesting to better understand the limits of the contract terms that could be automated via smart contracts. Some grammatical constructs of natural language (e.g., “the”, “of” may have no 1:1 semantic equivalent in computation. Some typical legal clauses (e.g., choice of law, choice of venue) may require action by parties off the blockchain that are difficult to automate in a smart contract. Hence, the limits of how many words in a legal contract may have computational significance in a smart contract may be less than 100%.   

References

Clack, C. D. (2018). Smart Contract Templates: legal semantics and code validation. Journal of Digital Banking2(4), 338-352.

ISDA, (2018) White paper: Smart Derivatives contracts: from Concept to Construction.


[1] https://accordproject.org/

[2] https://templates.accordproject.org/