In today’s Blockchain and DLT world, the term ‘Smart Contract’ carries an air of magic about it. It seems that every problem can be solved, that’s the nature of Smart Contracts. When something is too hard or when system designers cannot devise a solution, all is made well by reference to a smart contract. Like duct tape or all-purpose putty, what was broken is now fixed.
The approach at SETL, however, is to engineer solutions for financial infrastructure where there is no space for duct tape solutions. This week saw the SETL releasing v2 of its SETL Labs product which includes its contract builder – an easy to use smart contract system which challenges the complexity of its rivals. SETL argues that it has a system which more fully implements the vision of smart contracts by addressing the core needs of a contracting framework.
This article shows how SETL’s approach is closely tied to financial contracts and tries to demystify some of the other common approaches – showing where they fail to meet key needs in contracting and sacrifice the very essence of ‘smart contracting’ in favour of esoteric generality.
What Is A Legal Contract?
A contract is an agreement between parties which creates mutual legal obligations. That is to say, obligations which can be legally enforced. All valid legal contracts need the following elements to be enforceable:
· An offer (I will pay you $1,000 for 1,000 widgets);
· And acceptance of the offer presented with (Other person accepts $1,000 for 1,000 widgets);
· A promise to perform (Other person says they will perform);
· A valuable consideration ($1,000);
· A time or an event of when the performance must be made (1,000 widgets exactly 2 weeks from now);
· Terms and conditions for the performance (The widgets must be purple); and
· Performance (The 1,000 widgets are delivered and the person is paid $1,000).
A contract can be invalid if:
· Its purpose is illegal (say a contract to murder someone)
· There is no mutual understanding between the parties – i.e. they don’t understand each other, and there is no meeting of minds; or if there is no consideration.
Finally, in the real world, contracts can be breached. The whole of financial services is built on the risk of contracts being breached. Contracts are, in their very essence, instruments to mitigate and transfer risk.
What Makes A Good Smart Contract?
Nick Szabo is widely recognised as the inventor of the term ‘smart contract’. In his article ‘Smart Contracts: Building Blocks for Digital Markets’, he considers a smart contract to be a contract embedded in the world around us – like a vending machine. His vision is that the elements of constructing and operating a legal contract could be largely automated. He articulates several design principles;
Observability – the ability of the parties to observe each other’s performance of the obligations under the contract.
Verifiability – the ability of a party to prove to an arbiter, that they have fulfilled their obligations.
Privity – the principle that knowledge and control over the details of the contract should be distributed among parties only as much as is necessary for the performance of that contract
Enforceability and minimising the need for enforcements. Nick Szabo considers good observability and verifiability as reducing the need for enforcement. Further, reputation, built-in incentives and self-enforcing protocols as contributors to good enforceability
Of course, it is almost always the case that identity feeds into these principles. Reputation only works to enhance enforceability if the parties know each other’s identity. It is also interesting that he considered ‘self-enforcing’ protocols only as one element of smart contracts. In the world of DLT this particular principle has been emphasised – sometimes to a level of absurdity.
Is A Computer Program A Contract?
For the most part the answer is no. A program, whether it runs on a node, a laptop or a smartphone is a set of instructions passed to a processor interacting with inputs and outputs. This, of course, is immensely useful to allow us to communicate and entertain ourselves endlessly. But not everything is a contract. Checking off against the characteristics above, most computer activity could not be described as contracting.
Dive A Little Deeper – Code Vs Contract
There are any number of tutorials on building smart contracts using languages like Solidity. They typically start from a ‘Hello World’ example. This is a smart contract where you cause the Ethereum to return a string like ‘hello world’. Follow on tutorials will take the user into more complex examples such as constructing a to-do list. Whilst these are simple examples, they illustrate something fundamental – a program written for Ethereum is not written in the frame of a ‘contract’. It does not specifically assist parties in coming to an agreement, it does not coordinate an offer and acceptance nor must it have a consideration.
In short, Solidity programmes are not contracts. Let’s look at the most widely used ‘contract’ on Ethereum – known as ERC20. This is a standard set of six functions that can be called to implement a system of tokens. An ERC20 compliant programme will facilitate the issuance and transfer of tokens. None of those functions look at all like a legal contract nor do they meet the tests set out by Nick Szabo in his definition of a ‘smart contract’.
More experienced Ethereum coders have actually moved away from the term ‘smart contract’ and embrace the term DAPP – meaning ‘Distributed APPlication’. It is not that a contract could not be represented in Solidity – just that it rarely is. What’s more, it does not lend itself to the process of contracting (and financial contracting in particular) as well as other domain specific approaches do.
The Meeting Of Minds
This is crucial to the establishment of any kind of contract. If the final step of a contract is the fulfilment of a set of obligations, the beginning is a proposition that exists only in the mind of an individual.
This imagined desire can only start its journey to become a contract through communication to other individuals. The first step of a useful contracting framework is, therefore, a forum which provides for its members to find agreement. The best forums are the ones which are domain specific. A person looking to fix a leaky pipe will find no use in a marketplace for syndicated loans.
Identity Is Key
A contract has no meaning in the absence of enforceability. Enforceability derives from authority which itself derives from identity. Financial contracts in particular rely upon an ecosystem of identities and authorities which orchestrate to deliver contractual outcomes. Complex incentives drive this system including reputation backed by observation and verification. Identity and authority in financial services are multi-layered and
The Art Of The Getting To The Deal
The thrust of Nick Szabo’s thoughts on smart contracts was that they should be ubiquitous and inexpensive. That comes from intelligently reducing the dimensions of decision making. The financial services industry has long recognised the power of standardising. A contractual framework which deploys domain specific features to focus participants on key decisions is, by this definition, smarter than one which seeks generality.
The idea that ‘code is contract’ reduces the possibility of contracting to those that understand coding. That is because a valid contract requires the meeting of minds which requires an expression which the ‘minds’ understand. The way that a contract is presented, therefore, is essential to it being valid. In fact, the contract is strictly what is arguable in a dispute for resolution, take for example a vending machine. The contract is formed from the instructions and information written on the machine, not the complex inner mechanics that execute the transaction.
The Act Of Agreement
A contract comes into being when an offer is accepted. A good contracting framework requires an effective way of asserting an offer and for that offer to be accepted. The implementation needs to be observable by the parties and verifiable by both the parties and any arbiter.
Fulfilment Of Obligations
Key to the idea of smart contracts is that they should be ‘embedded in the world’. That is to say, their fulfilment should be a function of the system that hosts them. If one considers the ‘world’ as a particular political system, legal contracts exist in a jurisdiction. For financial transactions (with the world being ownership of assets and money) fulfilment can be assured if the contract is hosted on the ledger which determines ownership.
SETL’s Smart Contract
SETL’s approach, not surprisingly, comes from its deep financial markets heritage. Its OpenCSD software is still the only implemented financial market infrastructure with Blockchain at its heart. The key to SETL’s approach is in its intelligently designed layers. Each of these layers is fundamentally different in how it contributes to the process of negotiating, agreeing and fulfilling a contract.
The process starts with defining identity and authority. In particular, SETL built its framework around users not nodes. Tying authority and identity to a node, such as in the Corda model, was not just a technically inelegant solution but also does not reflect the complexity of how financial services work with multifaceted delegation and partitioned authority.
The second innovation was to recognise that the process of coming to a contract was a matter of communication and workflow which is a particular kind of computing that need not be tightly bound to a ledger. SETL logically separates this element recognising that the process can be highly bespoke. Instead, it provides a protocol to express the agreement – however it was reached. This means that SETL can easily interface with existing markets and processes and maintain the customs and privacy models that already prevail.
Finally, having arrived at an agreement, the terms of that agreement, using the SETL protocol, can be embedded in the ledger structure as a pure smart contract. Crucially, a contract is a data object that records mutual obligations and conditions which can, provided the obligations can be effected on the ledger, self-execute.
Summing up, the following table maps the different elements of smart contract creation and execution for a two other popular DLT protocols;
|Identity of Parties||SETL separates user identity from nodes implementing a comprehensive identity, authority and permissioning system.||An identity is a node. This is technically cumbersome and does not facilitate multifaceted permissioning.||No substantial identity framework. This removes one of the key pillars of enforceability.|
|Contract Formation Process||SETL implements a messaging system to allow communication between parties without imposing a rigid process. Presents an understandable protocol to express agreements from any source||Imposes a ‘flow’ paradigm where a transaction object is passed between nodes. Technically complex and hampered by node=identity structure||Negotiation is not imposed nor is there any tool to facilitate. The Web3 framework allows for external interactions to be reflected into the chain.|
|Contract Presentation and Readability||Contracts can be constructed and examined in SETL’s contract builder which clearly shows the mutual obligations, conditions and contract state||No integral contract visualisation or graphical builder. The transaction object can form the basis of some sort of understandable representation||Contracts are held in EVM Bytecode. They can be constructed in specialist computer languages like Solidity|
|Contract Representation on the Ledger||A contract is represented by its state (a json object) and not by computer code. The contract can be alleged into the ledger by any participant but must be signed to be agreed. The contract object expresses all of the obligations to be effected subject to conditions – such as the parties signing or agreeing data or documents.||A contract is represented by a complicated combination of a ‘contract’ (which is an object and constraint definition in Java or Scala) and a transaction – which is the flow described above.||A contract is a state structure and a collection of functions that change that state structure. Typically this is only understandable by those that can read the code. Most applications on Ethereum are not contracts at all – they are components of DAPPs|
|Contract Fulfilment||The ledger will automatically fulfil the contract when the conditions allow||A contract is fulfilled by the flow which includes passing it to a designated notary before it can be effected into the ledger||There is no framework of contractual fulfilment – just a language which can cause state changes.|
|Privacy||Only the parties see the contract representation on the ledger. The process of negotiation can be private, the terms can be private with only the minimum representation being on the ledger for execution||The contract participants must disclose the complete history of the asset they are transferring back to its original issuance.||Everyone sees everything|
SETL’s approach to smart contracts, not surprisingly, maps closely to the real world approach to contracts. It was modelled on how financial services work and have evolved over a long history.
At its base is a multifaceted approach to identity which is separate from the technical implementation of a ‘node’. SETL provides the tools for negotiation and contract formation but, more importantly, provides a receptacle for expressing the terms of a contract which is easily accessible to the many ways in which formation may occur. It does not impose any particular paradigm or complexity around its node structure.
Finally it publishes a contract to the ledger as an object which changes in state and can be easily represented graphically or in plain text. It does not expect parties to read esoteric code nor is it using its ledger as an execution platform for distributed apps which are, for the most part, nothing to do with contracts – smart or otherwise.
SETL’s implementation is close to the original vision of smart contracts expressed in Nick Szabo’s 1996 article and because SETL has implemented core financial infrastructures such as a CSD and fund transfer agent it has the ‘world’ into which it can embed such contracts.