Managing Trust and Risk in Fragments

Data is the most valuable asset companies have. There are strict requirements about who can access the data and this means they must establish binding agreements with the workers. Given the nature of Fragments’ platform, we have designed our agreements to comply with these needs, especially for companies who currently use in-house employees and are considering migrating and outsourcing their tasks to scale better.

Agreements will be created by requesters (companies). Workers will have to sign them in order to be able to work on more sensitive tasks. One of the most prominent examples of an agreement is an NDA (non-disclosure agreement). Other agreements might include proof of passing tutorials, where workers will pass competency tests before beginning the actual work on micro-tasks.

These agreements are crucial for data protection and quality management, so they must be binding. This is why we implement them on the blockchain to facilitate trust, binding an agreement to a worker’s ethereum address, which will in turn be connected to the worker’s identity using blockchain ID services. This system (in combination with a blacklist) will ensure that those who violate any agreement will not be able to participate in the platform any more.

This is a proof-of-concept approach, where we demonstrate the way we want to tackle this problem — we aim to minimize the gas costs for agreements and investigate other options, such as companies who might cover these costs. We are open-sourcing our demo on GitHub and are keen to receive community feedback.

Two sides of the agreement

What will both parties usually need to agree on? At Fragments, we divide agreements into three distinct components:

The first component is the informative documents which are shared. These will usually contain information about the requester, the purpose of the tasks, and any other general information or requirements. You can imagine this component as the body of a real-world legal contract. (Metadata, such as identity of parties involved, will be handled by other components and/or by Ethereum itself.)

The second component we call ‘conditional validity’. Here, you can specify things such as expiration terms of the agreement, or any other logic needed for the micro-tasks. In situations where you don’t need additional conditions, you can use a dummy (unconditional) component instead.

The third and final component is the logic needed for the agreement signingitself. Above all else, it is important to note that signing of the agreement will be realized as Ethereum’s transaction to the agreement smart contract.

Use cases

Let’s illustrate some non-obvious situations that we aim to support with our modular architecture.

In a situation where many workers are expected, we aim to limit Ethereum gas consumption for contract deployment(s). Requesters can create a single “asymmetric” agreement that can be signed by multiple workers (instead of having a separate agreement with each of the workers). In this case we want to be able to check that the treaty is valid for each worker independently.

Another example could be multi-step signing. Imagine a semi-private task repository aimed at image classification of very rare herbs that can be reliably classified only by postgraduate students of biology. In such a case, the chosen universities could be required to co-sign the agreement between requester and worker to verify the worker’s proficiency.

One last example of signing logic could be an agreement which is signed only when passed through a blacklist or whitelist.

Task requester’s point of view

Let’s take a look at the steps a requester will need to carry out in order to create an agreement.

In Fragments, we will provide many templates for Ethereum contracts that can be composed into an agreement. Task requesters will need to decide on (or discuss) requirements for an agreement and then select from the provided templates, or write a new Solidity contract that fulfills the needs of the generic agreement’s interface. Besides contract templates, we will also provide the user interface for generating an agreement. A prototype of this interface can be seen in the following video: https://www.youtube.com/watch?v=OfKlLzEWIqA