Imagine you visit a website, an exchange quite possibly, which turns out to be a Rug-Pull (fraudulent) one. They have the smart contract mechanism in place, laced with website content that says send 3 ETH to our exchange, and we will repay in millions. You take the bait as you have read about smart contracts — which are written in a machine-readable language, but given the buzz around it, you become sure that it must be legitimate.

Unfortunately, it will not take long for you to realize that you just dumped your precious ETH into a scammer’s wallet. You forget the incident, labelling it as a norm in the crypto world, and then you come across a P2P crypto-run marketplace involving smart contracts that get immediately executed when you purchase a physical asset over it; sounds futuristic?

Wait until you get to know that the person selling that asset does not actually own it.

What is the solution?

Ricardian Contracts; but before they came into the picture, people floated the idea of having an application read the code in smart contracts and display the meaning in the human-readable form to the user dashboard so that users will at least get a first-hand understanding of what is going to happen on the distributed ledger.

All was going well except for the following two issues:

• The app associated with the platform may show false data to the user for undisclosed monetary gains from the platform
• Even decentralized apps were not smart enough to read the actual transactions happening on the blockchain.

So the issues lingered on, and everyone who once thought that smart contracts are poised to make data collaboration between various agencies easier and faster took a backseat. Also, establishing the provenance of a product in the supply chain industry using smart contracts was debated for a while, without ever being introduced to the real world.

The uninitiated beings in the smart contract space can take it as an agreement happening between two or more parties that executes the given set of instructions. E.g., your access card to office premises or key card for the hotel room, wherein they are pre-defined by a set of code linked to a database; the only difference is that the data this time would get stored in an immutable fashion on a blockchain (Distributed Ledger Technology).

The data will remain accessible for an eternity and will perform some pre-defined tasks as per the set of conditions. E.g., imagine a person selling an NFT artwork on a marketplace and mentioning 3% as the royalty fees, which they will automatically receive whenever the artwork gets resold, all thanks to the smart contract.

Smart contracts can implement a complex set of instructions in an immutable, autonomous, and automatic fashion. Although they offer a great value proposition, they still lack one crucial aspect of any contract, i.e., a legal framework, since it is an agreement that has been written as a code but not the actual agreement.

Now, what would happen if there was a way to store an actual legal contract over the blockchain, which can be read by the people before falling into the traps of fake ICOs and Ponzi schemes? That’s where the Ricardian contract comes into the picture!

Ricardian Contracts: A Brief Introduction

Essentially, a Ricardian Contract is a legally binding contract that both humans and machines can read. This means that it is a legal contract written & deployed by a lawyer and can be produced in front of a judge when a dispute arises.

One of the frontrunners in the crypto world, Ian Grigg, in 1995 proposed Ricardian contracts with cryptographic signatures to bind individually contracting parties in a legal fashion. Each part of the Ricardian contract can be hashed and stored on the blockchain so that altering them without the knowledge of the parties involved becomes impossible, making them arguably secure.

The contract follows Ricardo architecture laid down by Systemics Inc., which derives its name from the British economist David Ricardo.

Ricardian Contracts: How do they Work?

Let us take the example of a smart contract involved in a real estate exchange. If a person decides to sell a house — the ownership will get automatically transferred to the buyer once the seller receives the funds. Now, let us see how a Ricardian contract would make it happen.

Firstly an Oracle (Verifying entity, in this case, government office) will check whether the person is the current legal owner of the real estate or not.

If that’s true, then the next step would be to find if any debt is associated with the real estate or not?

If it is a yes again, then that debt will get paid automatically to the bank or the lending entity.

Once done, ownership transfer of the asset will happen while following the due process of the law, resulting as the conclusion for the entirety of the interaction.

A major example of a platform using a Ricardian Contract was OpenBazaar (A P2P marketplace that recently got shut down as they ran out of donations), wherein they have named Ricardian Contracts as “Trade Receipts” to safeguard the interests of sellers, buyers, and the platform concerning legal framework.

Quite recently, EOS blockchain, developed by Block.one, has launched a Ricardian Contract that looks promising as Ian Grigg himself is a partner in Block.one. Also, the EOS network actively promotes Ricardian contracts for agreements made on the EOS blockchain.

EOS offers a Ricardian contract, built using two modules:

• Ricardian Contract Specifications
• Ricardian Template Toolkit

The Ricardian Contract Specifications is a common set of specifications that help the developers prepare the contract while conforming to the guidelines, which using the Ricardian template toolkit, validating user-agents can validate.

All the resources associated with the contract should get hashed using the SHA-256 algorithm so that the validating user agent can check whether the content of the agreement at the original URL is original or not.

The contract is written using the English language with the JSON template for adding metadata, the formatting gets done via a subset of CommonMark/Markdown, and variable substitution gets carried out with the aid of Handlebars.

With that, you can rest assured that you are sending your tokens to the right entity, an app is not misleading you in any sense, and no one can defraud you with fake ICOs, phishing attacks, and Ponzi schemes.

Before Ricardian Contracts, users were at the mercy of authenticators (wallets) or apps to determine what the smart contract actually means and what will happen on the blockchain once it gets executed. Thankfully, it will not be the case anymore.

So now, smart contract developers can create and test easily understandable Ricardian contracts that the users can read and agree to, and the authenticator developers can render the contracts.

E.g., Ricardian Contract Specifications can get considered analogous to HTML specification, whereas the Ricardian Template Toolkit works like the browser that renders those documents that conform to HTML specification.

So, the data collaboration and legal compliances that we missed with smart contracts form the pillar of Ricardian Contracts, providing a great sense of relief. Even more so, they are a lifesaver in decentralized apps (dapps).

Additional Features of the Ricardian Contract:

• Reference to the Hash

Once the contract gets signed cryptographically, it starts referring to the hash. E.g., if there is any financial activity involved, it will have to be applied to the hash of the contract with the consent of the paying parties.

• Hidden Signature

The contract gets signed using private keys, and the hash of the same gets utilized to attach the hidden signature to the agreement.

Ricardian Contracts: The Road Ahead

The Ricardian contract is still in its development phase, and the awareness related to the role of the issuer and arbiter has to be shared more often than not on the public platforms. (E.g., who do we go to in case of fallout?)

Still, as far as the definition of pre-agreed and pre-defined agreements goes, they suffice the original intent of being adequately legally binding to be invoked in the court of law.

However, let us see who comes up with the possible ways to customize the contract to follow the laws of every state in consideration.

Meanwhile, we can help you with most of your projects (if not all) related to cryptocurrency, blockchain, hash graphs, and whatnot. Do not forget to give us a holler. Call +1.844.3539.746 or shoot an email to info@flexsin.com