Liability

To turn robots into economic agents one needs a contract tool for this. Meet Liability - Robonomics pallet implementing
contracts between parachain accounts!

Dev Node

Please pay attention that this tutorial is demonstrated on a local instance of Robonomics Node. Set up yours with these instructions.

Theory Overview

Back on the Ethereum there was quite a complicated structure of liability interaction. You can get acquainted with it
here. Nowadays things are a bit easier with Kusama!

Negotiations

To sign a contract the two sides need to negotiate first. This may be done several ways, including
IPFS PubSub or Robonomics PubSub. A sample of Python code using Robonomics PubSub is
presented here.

Offer and demand are messages containing two main characteristics of a contract: job description and price. Message
format is to be designed by user for each specific application. It is not that important in the negotiations process to follow
a strict format rule. The possible flow is presented in the picture below.

PubSub

Note that PubSub is an open protocol, so no sensible data should be transferred. For this you should use other protocols.

Signatures

When negotiations are successfully over, each side needs to sign its so-called agreement named a signature. This is a
message containing job description and price in a specific format signed with a private key of the account. There is a
Python tool for that as well.

• Job description is called technics. This is a launch-like 32 bytes long string which may be an encoded IPFS CID.

• Price is called economics. This is an XRT decimal - Weiner. 1 Weiner = 10**-9 XRT.

  32 bytes

  One may obtain an IPFS CID formatted in a proper way with the Python library.
  When using the sign_liability function, no need to transform the hash, it will be done automatically.

Following the coffee example:

1. The task is a JSON

{"task": "make_espresso", "description": "Make one cup of espresso"}

2. Its IPFS CID is QmP17mWKtQtq2Gq6qZAggPRrho3sVjQGBpXZ8KZiQ57FDi
3. So the technics (transformed CID) is 0x09daaa8055722a6894951b1273e807f8a46628efeec46805f0228ace230bd5a9
4. Economics is 1.5 XRT.

When signed, it’s time to create a liability! This may be done by one of the sides (either promisee or promisor) or by a
3rd-party account of a so-called provider.

Create Liability

Preparations

As have been mentioned earlier, at least two sides are involved in the process. For this example, let’s use three and make
a separated provider for this. Assume that the negotiations took place somehow already.

1. Create three accounts and add funds to them

Here we have supplied the provider with 100 XRT to sign liability extrinsics, promisee was given 2 XRT to pay for the work.
Promisor wasn’t granted any funds (except for an existential deposit of at least 1 mXRT).

1. Navigate to Developer -> Extrinsics

2. Choose liability -> create from the dropdown list of possible extrinsics

Also choose an account you want to submit the extrinsic with. Fill in all the parameters.

3. Submit transaction

4. Review your liability in the events

For this, navigate to Network -> Explorer and find a list of events on the right. Click a triangle icon to expand.

5. Storage exploring

You may also explore some characteristics of the liabilities in storage module liability.

Reports

Image that a coffee has been made and now the coffee machine needs to report it somehow. That’s where liability reports
come into scene. As a proof of labour the account adds another IPFS CID as a report content when finalizing the existing
liability. This again requires a signature of the promisor.

Keeping with the coffee machine example:

1. Report is a JSON

{"report": "Coffee made! Time to execute - 80 seconds."}

2. Its IPFS CID is QmeXCrBuv6cw825JJfSWqNVv28AyjJZW9KReN9wcLQjfCm
3. So the payload (transformed CID) is 0xf06f2394f55537a5f37d63fd72bfbef50e9f60ea9e0e34224e455afae27a97a2
4. Index is 0 it’s the existing liability index.

1. Navigate to extrinsics, liability -> finalize(report)

Fill in the parameters and submit extrinsic. Again, this may be done by a 3rd-party account.

Existential deposit

Pay attention that the promisor account should not be “dead” - it should have the existential deposit of at least 1 mXRT.

Sign and submit the report. When done, you can explore it in the events.

2. Explore reports

You can also observe the report in the storage. Go to Developer -> Storage and choose liability from the dropdown list.

3. Check balances

On the picture it’s shown that now the promisor has got the “salary”. Economical relationship happened!