Smart Contracts vs. Ricardian Contracts

Smart Contracts are all the rage right now

… the problem is that very few people full understand what a Smart Contract is.

The reason is because that they: (i) are rather complicated by their very nature, in that they combine two sophisticated professions: Law and Technology; and (ii) they’ve suffered from shifting definitions, in the sense that there are competing definitions out there.

Smart Contracts — Nick Szabo

Well let’s make sure first of all that we understand the term — for this, we need a history lesson.

Let’s rewind back to 1996, to a paper published by Nick Szabo: Smart Contracts: Building Blocks for Digital Markets

Smart contract: A set of promises, including protocols within which the parties perform on the other promises. The protocols are usually implemented with programs on a computer network, or in other forms of digital electronics, thus these contracts are “smarter” than their paper-based ancestors. No use of artificial intelligence is implied.

And there it is: the coining of the term, way before its inception was to be feasible in the real world. We can break it down into two parts: (i) promises; and (ii) protocols. The former being akin to the paper contracts we all know and love (some love less than others); the latter being another terms for what is commonly understood to be automation — i.e. hands off processing of data and/or actions.

Smart Contracts — Ethereum

Fast forward to 2014; where Vitalik Buterin tours the world promoting a new “Smart Contract” blockchain.

Ethereum, it turns out, is a runtime environment for a scripting language that uses a blockchain as its running environment. It achieves this by minting its own cryptocurrency and establishing an incentive structure for “miners” (which are nodes in the network that process the scripts and its transactions).

Despite this occurrence being very popular and being the first time that the public had its first large scale promotion of the term Smart Contract, it brought little resemble to Szabo’s definition.

Although it must be mentioned in fairness that Ethereum could be used for processing contracts — it was not designed for legal contracts. More precisely, “Smart Contracts” in Ethereum are more accurately described as DApps (Decentralized Applications). In the way that a software running on your desktop is not necessarily processing contractual obligations — an Ethereum “Smart Contract” is not necessarily processing contractual obligations either. The main difference between locally running scripts and “Smart Contracts” on Ethereum are its running environment: the blockchain.

This is where we saw the first main diversion of the term “Smart Contract” away from its original intention… but it was not the last.

During several controversies during Ethereum’s reign as the leading “Smart Contracts” platform, it was besieged by the DAO hack, which is too long of a story to rehash here. One important principle that was laid bare during the fiasco was that:

Code is Law

Any lawyer immediately recognizes that this cannot be so in the eyes of any Court. However, Ethereum was not built for lawyers — rather the opposite, as a challenge to the established legal frameworks (or at the very least, ignoring established legal principles).

Smart Contracts — EOS

In 2018, we see the launch of EOS — which not only improves upon scalability issues present in Ethereum, but improves it also in its approach to Law.

Intent of Code is Law

EOS introduced in its Smart Contract structure Ricardian Terms, which are essentially non-machine interpretable words that describe the intention of the parties to the contract.

This brings things back to Szabo’s definition when we consider that describing the intention of the parties is akin to describing the promises made to each other — which is one would expect if you’re describing the intention in a contract.

Taking this a step further, EOS established an arbitration forum and a “senate” of sorts: its 21 Block Producers… essentially modeling it as a government with a Constitution, voted by its coin holders.

Ricardian Contracts

Having now seen a sneak peek of what Ricardian Terms are in EOS, we have to once again rewind to the 90’s — 1996 in fact, where Ian Grigg coins the term Ricardian Contract:

A Ricardian contract can be defined as a single document that is a) a contract offered by an issuer to holders, b) for a valuable right held by holders, and managed by the issuer, c) easily readable (like a contract on paper), d) readable by programs (parsable like a database), e) digitally signed, f) carrying the keys and server information, and g) allied with a unique and secure identifier.

The gist of this definition in plain language is that it is a contract for a commercial purpose that is readable both by humans (for mutual understanding) and machines (for processing), and is cryptographically verifiable.

Furthermore, the specifications of the Ricardian Contract calls for three components: code, parameters, prose (i.e. legalese). Setting aside the parameters for now, we see that the two parts now compare closely to Szabo’s original definition of Smart Contract, as it defines the promises (legalese) and the protocol (code). Lastly, the parameters are there to fill in the blanks if the contract is originally drafted as a template — which is usually the case, even in the case of a paper contract. The parameters are a good design technique to separate what changes often from what doesn’t.

Synthesis

Under their original definitions, Smart Contracts and Ricardian Contracts are quite similar. Ricardian Contracts being a specialized form of Smart Contract. Szabo’s definition is a general definition that makes no technical assumptions; whilst Grigg’s definition prescribes a design pattern.

Ethereum’s use of the terms Smart Contract is not exactly in step with Szabo’s; as such, the term DApp platform is more appropriate for Ethereum. EOS as a Smart Contract platform is not as bad in this regard as it found a way to bridge a DApp with Smart Contracts/Ricardian Contracts with the use of Ricardian Terms, a governance structure and legal means of enforcement.

As of yet, we are still waiting to see a real proper Smart Contract platform, as per Szabo’s original definition. That said, it is not the intent of current platforms to specifically tackle legal contracts. A layer on top of DApps might be able to achieve Szabo’s vision.