When Contracts aren't Smart Contracts

We're constantly talking about documents, and some of these documents might be agreements, or "contracts." The word "contract" is also used in the context of DLT, more specifically when we talk about "smart contracts." We need to make sure that we don't confuse one with the other.

The concept of smart contracts was introduced by Nick Szabo in the nineties. Originally, the concept wasn't related to DLT in any way. Today, there's no longer a uniform understanding of the term "smart contract." Some consider a smart contract as computer code that is executed on a distributed ledger –e.g. in the case of Ethereum, the code runs on the Ethereum Virtual Machines (EVMs)—, others consider it to be a legally binding contract that is coded in a programming language –e.g. in the case of Corda, contracts can be executed on a Java Virtual Machine (JVM).

In the context of registering documents in the blockchain, smart contracts can be used to determine whether and how a document can be registered in the blockchain, at which time they were registered, and possibly at what cost, but that's outside the scope of this ref card. We'll focus on storing with the hash of a document in a record, (optionally) along with some metadata. This document may or may not contain a smart contract.

This is a completely different use of DLT than the way blockchain is used in the context of Bitcoin, Ethereum, or other applications that use DLT as a kind of large computer that is distributed over the whole world. We'll use DLT more in the sense of a distributed database, where the id of a document is on one hand the primary key, and on the other hand one of the main triggers for events to be performed by an external service. such as a CRM, ERP, or DMS system.

There are advantages of storing "the contract" in a document outside the blockchain. The contract itself isn't distributed, and can therefore remain a secret. Also, storing complete documents in the blockchain would cause huge problems in terms of storage and bandwidth. The disadvantage of storing "the contract" in a document outside the blockchain, is that the contract isn't distributed, and that an additional system has to be put in place to distribute the document, or to give access to it. We can counter that problem by storing one of more links to the document in the ledger record.

If the contract is stored in the blockchain as a smart contract, there is agreement on how the contract needs to be interpreted and executed. This isn't the case in the approach we have chosen:

• The contract could be a traditional agreement, in which case a mutual understanding on how to interpret the contract is needed between any two parties that are involved. Most likely, these contracts are written by human beings, and there is often room for interpretation. This may be a desired effect, as not all contracts can be programmed. Think of an employment or a contractor agreement where the job to be done or the work at hand can't be described up-front in an ironclad way, or

• We could work with human-readable documents that also contain machine-readable information allowing automated processing of the document. The ZUGFeRD standard, for example, offers a way to create invoices that can either be read by human beings in the form of an PDF/A-3 document, or processed by machines because of the XML attachment that complies with Cross Industry Invoice (CII) standard, or

• If the document does consist of code, and code only, all parties involved should be in agreement on the way the code is executed. We may chose this option in cases where we don't want to expose the code to the other clients of the blockchain we are using. This example is out of scope in the context of this ref card as none of the use cases we'll cover requires the document to consist of code.

The mechanisms outlined in our patents don't primarily rely on smart contracts stored in the blockchain. This was a deliberate choice to cater for use cases where the contract needs to remain private in the context of an environment with parties that can't always be trusted.