Smart Social Contracts — How they work

This is a detailed explanation of how our Smart Social Contracts work. It is not intended to be a technical paper as it is addressed to a very broad public: our first objective is to bring on board companies and entrepreneurs.

First, have a look at what smart social contracts are.

There are 4 types of actors involved in a Smart Social Contract

• Companies
• Users
• Charities
• Us, with our Core Smart Social Contract

Image by StartupStockPhoto

The company Innoshoes makes some great shoes. On top of that, they promise that 10% of the price of their products goes to their favourite charity, Free Children, that protects children from forced labour. Because Innoshoes is fully committed to this cause, it wants to prove that they do what they say to add value to their shoes.

Innoshoes sets up a Smart Social Contract on the blockchain — our tool can help with that.
This contract can have many parameters, but at a minimum it requires:
1) The percentage of revenue it wants to redirect to a charity
2) The preferred charity

This contract is published on the blockchain, is public and can be read by anyone.
Because we want to empower traditional and new types of businesses, contracts can be as complex as someone can invent them. They can have specific logics, algorithms, secondary transactions. As long as those 2 parameters are present, anything else is left to the entrepreneurial freedom.

Bob is surfing on Innoshoes website and wants to buy a pair of shoes. He likes the shoes and he is also happy the company is devoting part of their revenues to a charity. The shoes now have even a bigger value for him and he is encouraged to recommend Innoshoes to his friends.

At checkout, he has his typical payment options, PayPal, Debit Card, ecc..
He can also see our plugin:

The plugin interface reads the promise directly from the Smart Social Contract of the merchant.

The verify link redirects directly to the Smart Social Contract of Innoshoes as a proof that the plugin is presenting reliable information.

Bob has finally a reason to use the cryptocurrency he holds. He can pay with 2 options:

• With our RSN, if he previously bought any
• Directly with Ethereum. The plugin will then automatically convert Ether in our RSN. This makes our plugin highly accessible by the vast majority of the crypto users (Ethereum is the 2nd cryptocurrency by market value — 50+ Billions USD, and the 3rd by daily transactions 1+ Billion; CoinMarketCap)

Bob can pay through its favourite crypto wallet. He confirms the transaction and the payment is processed.

The merchant (Innoshoes) can verify the payment via simple APIs that read the blockchain and confirm the transaction. Innoshoes then send their fantastic shoes. There are already many online services that support this steps of the supply chain.

In the background, the plugin transfers Bob’s payment along with the parameters of the product purchased to InnoShoes. This can happen directly or indirectly depending on whether Bob has paid with Ethereum or RSN.

flow 1: Bob’s Ethereum (metadata: price of product in $/ETH , productid product and company → Core SSC → Conversion → Transfer to Innoshoes
flow 2: Bob’s RSN (product id as metadata) → Innoshoes

RNS: the atypical coin, an Ethereum “expansion pack”.

Our Core Smart Social Contract has 2 main functions:

1. It can convert Ethereum into RSN— relationship of 1:1.
   The function called is convertToBuy(Origin, Destination, optional Product_price, optional Product_code). We are also considering the option of bonding RSN to DAI, a stablecoin that has always the value of 1$.
2. It transfers RSNs between wallets when requested. Function transferToFinal(Origin, product_price, product_code, Destination). This function, while being executed, looks for the parameters with the Destination’s Smart Social Contract (the company’s contract) to recognize and complete the promise.
   
   To make things straightforward, the transferToFinal function doesn’t have to understand the full Smart Social Contract, it just needs to identify the parameters. This allows for greater freedom to entrepreneurs to design their contracts, while at the same time guarantees the RSN mission.
   If for example a function within the company’s contract was saying:
   If 1 > 10 then divert 10% to charity
   Our Core Contract would just recognize the 2 parameters and ignore the other conditions.

No ICO needed.

Contrary to the current trend, we do not need an Initial Coin Offerings. The RSN are generated by an automatic conversion when Ethereum is sent to the central smart social contract, making the value of our token tied to Ether in a 1:1 relationship. When RSN are redeemed, the Ether is released and the RSN tokens burnt.

Why do we need a new coin then?

We actually didn’t want a new currency at all. We want to make the most user friendly tool to support our mission. A coin is just necessary for the whole process to work in a trustless way.

Here are the possible options and the reason they are not feasible:

• If the user was sending Ethereum directly to the company’s smart social contract, he/she would have to read every smart contract to make sure this diverts the promised amount to a charity
• A DAPP could potentially have a similar workflow. It would collect Ethereum from a user, read the company’s promise and send the payment to the company’s wallet minus the amount reserved for the charity.
  However, because the promise would be executed before reaching the company’s smart contract, the company would not know if the promise had been executed. Anybody could just pay them (less) directly.

The REASON protocol is necessary to guarantee the promise to the user, but also to the company.

Charities

Every actor using RSNs might have different types of interests regarding the charities.

• Companies want to be free to address any charity they prefer
• At the same time, we cannot know if an address chosen by a company will actually be the one of a charity rather than another account of the same company in case of fraudulent activity.
• Users want to know which charity an address belongs to. Rather than seeing a series of numbers and letters, they want to see “UNICEF”, “WWF”, ecc…

While we keep monitoring the evolution of Digital IDs on the blockchain, the best immediate solution will be to assign a central authority to compile and maintain a public list of identified charities and their corresponding wallet addresses, so that our Core Smart Social Contract can use that database as an official Oracle.

This authority will be independent, known and trustworthy.

REASON aims to be a protocol.

This means that different payment tools — credit cards, online plugin, digital wallets on phones — will be suitable for transacting to make the user experience as seamless as possible, not that they finally have a reason to use cryptocurrencies.

This is an ambitious project for a great cause.
If you want to contribute, or if you have any questions, please contact us or sign up for updates.