We use cookies to enhance your browsing experience and analyze our traffic. By clicking "Accept All", you consent to our use of cookies.. View our Privacy Policy for more information.
Your browser (Internet Explorer) is out of date. Please download one of these up-to-date, free and excellent browsers:
For more security speed and comfort.
The download is safe from the vendor's official website.


Decentralization and HUMAN Protocol

Crypto & Blockchain
Charlie Child
Mar 12, 2021

Decentralization and HUMAN Protocol

2 min read

In part one of this series, we will outline the current degree of decentralization in HUMAN Protocol, and explore the next steps the Foundation wishes to take to further decentralize the network.

First up is the Exchange. Decentralizing the Exchange is perhaps the most critical in the Foundation’s vision, for only by creating a distributed network of applications running on HUMAN Protocol can it deliver a revolutionary solution to data-labelling.

The more kinds of tasks made available by applications, the greater the capacity for the Exchange system to cooperate to solve more complicated jobs.


Decentralization is best thought of as the distributing of the power of a network, which is often associated with expansion, in which the original creators relinquish various forms of control relating to the overall functioning of the network. ‘Power’ can take on various forms, but generally speaking, for the purpose of this series, it is best to think of it as how, where, and by who the system is run.

The first part of HUMAN Protocol to be decentralized was the payments system. Currently, all payments are tracked on the Ethereum testnet, as can be viewed on our job factory and HMT token contract on Etherscan.

The Exchange

The Exchange system entails the interactions between humans, machines, and the blockchain. On one side, it takes data from the smart contract relating to the job manifest, and distributes it to Exchange Oracles, which are the ‘locations’ where work occurs, such as a website utilizing a captcha system.

There are three primary ways in which the Exchange system can be decentralized.

  1. By operator
  2. Geographically
  3. By code base

The Exchange is already decentralized in the first two categories. Firstly, there are captcha pools run by separate operators — HUMAN Protocol and Intuition Machines. Secondly, whichever the operator, the pools are running on different cloud servers across every continent, except Antarctica.

The next step is to decentralize by code base. That means to decentralize the Exchange by the applications running on top of it. Because we have moved from a library to a RESTful API, it is easy to plug multiple code bases into HUMAN Protocol (there will be an article on the RESTful transition soon).

HUMAN Protocol is already welcoming CVAT and Inception labelling interfaces, which signals the vital next step in bringing value to the application of the Protocol.

Decentralization is value

Metcalfe’s law expresses how the addition of a single user to a communication network increases the value of that network exponentially, by virtue of the increase in individual communication lines. To demonstrate:

  • A network of two users has two possibilities for the transfer of data: A-B, B-A.
  • The addition of a third user has six such possibilities: A-B. A-C. B-A. B-C. C-A. C-B.

A 50% increase in users has a 200% increase in communication possibilities. In a network like this, communication is value.

The more kinds of tasks made available by applications, the greater the capacity for the Exchange system to cooperate to solve more complicated jobs.

A diverse mixture of applications can combine to solve increasingly sophisticated tasks. A document may contain hand written text (requires captcha), complex sentence structure (requires Inception), an image of a car (requires CVAT) and so on. Not only that, but each system can mix together to answer questions within a specific media — in a photograph, for example, one person could draw a bounding box around a tree, another could identify there’s a monkey on it, and a third could identify that it’s all happening in a zoo.


The overall benefit of increased decentralization of the Exchange, particularly by code base, must be brought into context with the overall vision of HUMAN Protocol Foundation. A valuable side-effect of this kind of decentralization is an increased resilience to attack. The more programmes that run through the Protocol, the less likely that a single programmer’s bug could actually damage the system.

The trade-off to this kind of decentralization is a loss of agility. This is not a problem once the network is established, yet it is worth bearing in mind as part of a mature and responsible view of how we plan to decentralize; while it is important for the Protocol to remain agile in the early stages of its deployment, it will remain agile. As and when the Protocol develops a robustness through experience, we will look to decentralize other parts of the network, the plan for which we will outline in the next article of this series.

For the latest updates on HUMAN Protocol, follow us on Twitter or join our community Telegram channel.

Legal Disclaimer

The HUMAN Protocol Foundation makes no representation, warranty, or undertaking, express or implied, as to the accuracy, reliability, completeness, or reasonableness of the information contained here. Any assumptions, opinions, and estimations expressed constitute the HUMAN Protocol Foundation’s judgment as of the time of publishing and are subject to change without notice. Any projection contained within the information presented here is based on a number of assumptions, and there can be no guarantee that any projected outcomes will be achieved.

Guest post