OriginTrail: A Look into Network Mechanisms, Incentives and Market Forces

Published in

OriginTrail

16 min readJun 28, 2018

OriginTrail is a purpose-built protocol, based on blockchain, for trusted supply chain data sharing and the utilization of global standards to ensure data interoperability.

The peer-to-peer decentralized network operates as serverless supply chain data storage, validating and serving the network with built in fault-tolerance, DDoS resistance, and tamper-proof resistance. It is self-sustaining based on the incentive system explained in this document. The incentive tool utilized within the protocol is the Trace token (TRAC).

OriginTrail is launching a beta version (testnet) of its decentralized network on June 29, 2018 and the mainet in Q3.

The intention of this paper is to present the existing incentive model, bidding mechanism, and staking system in the test network, for public node holders who will participate in the testnet.

1. Network Entities and Classification

In order to better understand the OriginTrail P2P network structure and the incentive mechanisms within the protocol, we have to understand all the different roles within the context of the system.

The main premise is that the nodes have different interests, given their roles. In order to provide fair play on the network — and a fair market — we have to understand the different entities, aims, needs and relationships operating within it. Above all, we have to understand the potential for collusion among the entities, and their possible motives, and therefore construct incentives in order to mitigate them.

It is important to state that all the nodes are operated by the same software, but their function in the context of observed data determines how the nodes are perceived: one node can have different roles within different agreements. Below is a list of different entities and their roles in the system. The complete picture of interaction between participants in the OriginTrail system is presented in a data flow diagram (Figure 1).

*Figure 1: Data Flow in the OriginTrail Decentralized Network (ODN)*

1.1 Data Provider (DP)

The Data Provider (DP) is an entity that publishes supply chain data to the network. A typical scenario would be a company that would like to publish and share its data from their ERP system about products that are part of their supply chain. Data Providers can also be consumers interacting with the network through applications, or devices, such as sensors that provide information about significant events in the supply chain.

The interest of the Data Provider is to be able to safely store data on the network, as well as to be able to connect it and cross-check with the data of other DPs within the network. Depending on the use case, providing data to the network can be incentivised with the Trace token.

1.2 Data Creator Node (DC)

The Data Creator node (DC) is an entity representing a node that will be responsible for importing the data provided by the DP, making sure that all the criteria of DP are met (e.g. the availability of the data on the network for a desired time or a factor of replication). While we typically expect that Data Providers will run their own Data Creator nodes, it is not a requirement. Third party DC nodes may provide the service for one or several Data Providers. The DC node is an entry point for information to the network and the relationship between the DPs and the DCs is not regulated by the protocol.

The responsibility of the DC node is to negotiate, establish and maintain the service requested by the DP in relationship with its associated Data Holder (DH) nodes. Furthermore, DC nodes are responsible to check if data is available on the network during the time of service and initiate the litigation process in case of any disputes.

1.3 Data Holder Node (DH)

The Data Holder (DH) is a node that has committed itself to storing the data provided by a DC node for a requested period of time and making it available for the interested parties (which could also be the DC node itself). For this service, the Data Holder will be compensated in TRAC tokens. The DH node has the responsibility to preserve the data intact in its unaltered, original form, as well as to provide high availability of the data in terms of bandwidth and uptime.

It is important to note that the DH node can be a DC node at the same time, in the context of the data that it has introduced to the network. As noted, the same software runs on all the nodes in the network, providing for symmetrical relations and thus not limiting scalability.

The Data Holder may also wish to find data that is not directly delivered by DCs but is popular, and offer it to interested parties. Therefore, it is probable that Data Holders will listen to the network, search for data that is frequently requested, and replicate it from other Data Holders to also store, process and offer it to the Data Viewers. However, since such Data Holders are not bound by the smart contract to provide the service, there is a certain risk that these Data Holders may offer false data or tamper with the data, or even pretend to have data that they don’t have.

To mitigate this risk, a node will be required to deposit a stake for executing an agreement. This stake will be stored in case it is proven that the Data Holder tried to sell altered data while Data Viewers will have a mechanism to check if all the chunks of data are valid and initiate a litigation procedure in case of any inconsistencies.

The amount of stake is set per agreement within each node. The DC node may require a minimum amount of stake to form an agreement with DH nodes, informing them of these amounts by publishing this information when they create an “Offer” on the blockchain. The stake settings can be setup either directly in the node configuration files or through a UI application (Houston).

Data Holders will be able to provide a larger stake if they want to demonstrate their quality of the service to Data Viewers. However, the amount of tokens staked is not the only criteria for node selection, there are other factors that determine which node will have a chance to execute the service, as we will explain in the remainder of this paper. The system is designed to provide great service to its users and relies heavily on the nodes’ reputation (past success and reliability of executing the deals) and other factors.

1.4 Data Viewer

The Data Viewer (DV) is an entity that requests data from any network node able to provide that data. The Data Viewer will be able to send two types of queries to the network. The first type is a request for listing data on the network for a specific set of batch identifiers of the product supply chain they are interested in, where they will be able to retrieve the all connected data of the product trail. The second type is a retrieval query for the specific data set from the listed one in the first request. In both cases, the Data Viewer will receive the offers from all the nodes that have the data, together with their compensation requests for retrieving of the data that will be sent. The Data Viewer can decide which offers it will accept and deposit the requested compensation funds on the escrow smart contract. The providing node then sends the encrypted data in order for the Data Viewer to test the validity of the data. Once the validity of the data is confirmed, the Data Viewer will get the key to decrypt the data while the smart contract will unlock the funds for the party that provided the data.

The interest of the Data Viewer is to get the data for as affordable as possible, but also to be sure that the provided data is genuine. Therefore, the Data Viewer also has an opportunity to initiate the litigation procedure in case the data received is not valid. If that happens, and it is proven that Data Viewer received false data, the stake of the corresponding DH node is lost.

2. Service Initiation Process: The Bidding Mechanism

One of the main building blocks of the OriginTrail Decentralized Network (ODN) is the bidding mechanism by which nodes in the network are able to form agreements and bid on providing services to each other.

To get data onto the OriginTrail network, the Data Provider sends tokens and data to a chosen DC node. The Data Creator sends tokens to the smart contract with tailored escrow functionalities and broadcasts a data holding request (Offer) with the required terms of cooperation. All interested DH node candidates then automatically respond with their bids to the smart contract, which will include the price for the service per data unit, the stake amount and minimum time for providing the service.

The minimum factor of replication is 2N+1, where the minimum value for N is is the amount of stakeholders involved in the supply chain observation, while the actual factor may be larger. To mitigate the possibility for fixing the results of the public offering, the smart contract will close the application procedure only after a certain number of Data Holders — greater than the replication factor — answer the call. Once the application procedure is finished, the smart contract selects the required number of Data Holders based on the parameters in the DH bids. The selection process operates on the principle of the closest data hash address, preferring DH nodes which have IDs that are ‘closer’ to the replicated data hash address, so a potential malicious Data Creator, who may own several DH nodes, can’t influence the process and pick its own nodes.

The Data Creator will deposit the compensations in tokens for the Data Holders on an escrow smart contract that Data Holders will be able to progressively withdraw from as time passes, and up to the full amount once the period of service is successfully finished. The smart contract will take care that funds are unlocked incrementally. It is up to the Data Holder to decide how often it will withdraw the funds for the part of the service that is already delivered, as each withdrawal is a transaction on the blockchain. Ideally, the DH node will withdraw their funds at the end of successfully providing the service to minimize transaction costs.

In order to participate in the service, the Data Holder will also have to deposit a stake in the amount proportional to the amount of the job value. This stake is necessary as a measure of security, ensuring that data will not be deleted or tampered in any way, and that it will be provided to third parties according to the requirements. The stake is set via a “stake factor” which presents a multiplier of the bid value (i.e. a stake factor of 1 means that the staked amount is equal to the amount of tokens agreed for the service).

The implementation of the bidding system is based on an Ethereum smart contract. In the bidding system, an Ethereum smart contract handles the creation of Offers by DC nodes. DC nodes receive Bids from DH nodes should an Offer become interesting to one or more DH nodes.

Simply put, DC nodes form agreements with DH nodes to operate on and store data (D) on a particular observed supply chain (S). For the specific data set D, a set of agreements is made between the DC of the data provider, and several DH nodes, among which are both independent nodes within the network, as well as the associated partner nodes of the data provider entities. In that regard, it is important to understand how a node agreement is formed.

To form the set of agreements (A) associated with one data set D, the DC node of the data provider creates an initial offer (O). This offer contains the parameters set by the DC node such as:

The maximum amount of tokens the DC node is willing to provide as reimbursement per data unit for DH nodes;
The minimum amount of required stake for the agreement to happen;
The amount of time the agreement will last;
A minimum reputation requirement for the DH nodes.

The probability of the mechanism selecting a DH node is determined by the smart contract function which calculates it by the distance function used to rank all DH candidates, which incorporates all the necessary parameters of the offer, as well as the address space distance of the node address from the address of the data content hash.

3. TRAC Token as the Glue of the ODN: Token Economics & the Token Demand Model

OriginTrail ecosystem is enabled by the tokenization of data exchange and supply chain processing functionalities. The system consists of a network of machines (nodes) that are all running OriginTrail software clients. Their supply is met by the demand of users of the protocol (supply chain data providers and consumers) who wish to share supply chain data using OriginTrail. The Trace token is the means of compensation between supply chain data producers and data consumers on one side and the OriginTrail node holders on the other. It provides the incentive to the nodes in the peer-to-peer network to perform system functionalities. Maintaining and operating the P2P network takes resources: time, electricity, computing power, storage space and communication bandwidth.

Therefore, OriginTrail nodes are incentivised to do two groups of tasks:

Data processing: Supply chain consensus checks, data quality and replication checks;
Storing, managing and delivering the data in graph form.

As a decentralized peer-to-peer network, OriginTrail uses an ERC20 token, Trace ($TRAC), to manage relations between users and nodes that make up the network. The main aim of the network is not to impose technical limitations that would require arbitrary decisions of the technical architects, but rather to have market forces achieve equilibrium within the network and be self-adjusting, ensuring the required longevity.

Two characteristics of ODN that are especially important for understanding how demand for Trace tokens is built, are the replication factor and staking.

Market Forces of the ODN and Key Assumptions

There are two market forces in place within the ODN ecosystem. They are:

Demand is represented exclusively by the total need for ODN’s functionality on the side of stakeholders (companies) who want to use the protocol. This demand is represented in the model by the amount of fiat currency pressure (F) companies create for the TRAC token that is in turn used to compensate the nodes of the system.
Supply is represented by the TRAC token supply. As mentioned, TRAC represents a means of compensating the nodes in the network and, in turn, accessing the functionalities of the ODN. The model treats total available TRAC in circulation as the supply side of the graph, assuming there will be sufficient amount of nodes that are willing to offer services (storage and processing power) for TRAC compensation. The supply curve in the model is perfectly inelastic and we are assuming that the entire supply is being used for the protocol level utility.

Dynamics of the ODN

The final dynamics of the ecosystem will be determined by both the market forces and characteristics of the network. Let’s look at these dynamics step-by-step as the network experiences an increase in demand.

Step 1: Initial Equilibrium

In the initial phase, we have a given demand for the network’s functionality D0 and a total available circulating supply of S0. The equilibrium is established at the intersection of both (S0, D0) and price of P0. The available amount of tokens in this state is Q0.

Step 2: A Triple Effect

For the next step, let’s analyse the movements when a demand pressure of F enters the ecosystem, creating a triple effect.

The first effect that the new demand pressure F creates is moving the demand curve upward, whereas the total available supply remain the same. The new equilibrium is established at P’.

The second effect a pressure of F creates is an increase in demand by the average factor of staking factor (Sf), used in the contracts created by the DCs, multiplied by F. On the graph, this is shown by the demand curve making another move upward from D’ to D’’, pushing the equilibrium price from P’ to P’’.

The third effect is another consequence of Sf. Once TRAC tokens are staked in the smart contracts, they have effectively been removed from the circulating supply until the agreements have concluded. This means that the total available supply falls from S0 to S’’’ showing the last effect of the demand F entering the ecosystem. The move from S0 to S’’’ changes the price from P’’ to P’’’.

Step 3: The New Equilibrium

The new equilibrium therefore gets established at P’’’ as an effect of demand pressure F, demand for the required stake depending on the S0, and the lowering of supply as the tokens get staked in the smart contract.

The move from equilibrium point of E0 in time t-1 to E’’’ in t, is described by the equations below.

D(t) = F(t)P(t-1)

P(0) = $0.1

Q(0) = 500 000 000 TRAC

Q(t) = Q(t-1) — D(t)⋅Sf

Token Demand Model

In addition to the dynamics, we have produced a simplified model that can give you a rough estimation as to how much demand for the TRAC token (in USD) a certain level of adoption can bring. All figures have been factored in for minimal values (i.e. theoretical minimum of 2n+1).The model is available here and has the following variables as inputs:

S — Observed supply chains are a (relatively) constant group of partners that are involved in a supply chain of particular products that you wish to create estimations on;

M — Average number of months that data will be stored on the ODN;

D — Average size of data size per DC import;

Pw — Average price of data stored per kb per month in $;

n — Average number of stakeholders per observed supply chain (S);

Pr — Average price per data read;

V — Monthly velocity (repetitions) for the observed batch;

Sf — Average stake factor;

F — Estimated fiat demand for the token based on the assumptions;

TD — Estimated total fiat demand, including staking.

The variables have a linear correlation that approximately follow this equation:

F(t) = S x N x M x D x V x (2N x Pw + (N-3) x Pr)

TD = F + F * Sf

Let’s look at it one part at a time:

General variables — All general variables influence the model as a whole. Increasing their values means increasing the entire value by that same factor. With a number of observed chains (S) you are able to describe the group of supply chains you would like to observe within the model. It can be linked to a company, a region, an industry, a country or other estimations. The second variable is the average number of stakeholders (N) within the observed supply chain. The next is the number of months (M), representing the average time that data has to be stored based on your estimation and the use case. Data size (D) is what the estimate would be for average input per stakeholder in the observed supply chains for one batch (in kBs). Velocity (V) represents the frequency (repetitions) of a particular observed product supply chain within a month. This number greatly depends on the type of product/service.
Write (storage) variables — The next group of variables is linked to writing data to the protocol. The premise of the 2N x Pw x N is to describe the number of inputs to the network based on the key characteristics described above. 2N is the number of replications every actor has to perform to reach the integrity minimum (it is 2N instead of (2N+1) because one replication is the DC node itself). Pw is the price of storing 1kB of data per month and is the established price between DCs and DHs achieved through the bidding mechanism.
Read variables — The third group of variables are related to reading from the network. The premise is that every stakeholder will at least want to read the data from other stakeholders. Because the protocol automatically replicates data one-step-back and one-step-forward, N is lowered by 3. Pr is the price of reading 1kB of data.
Staking — The last variable is the stake factor (Sf), which is determined within the created agreement. It increases the total demand by F x Sf.

OriginTrail created an online token demand model calculator, which is available here.

User Interface Layer Houston and Automation

An OriginTrail node is created to run as a daemon (a background process on the computer), and can be fully setup without a user interface. Because setting up a node in this way requires an advanced level of technical knowledge, the OriginTrail team is working on the development of a user friendly interface towards the node daemon, called Houston.

Houston is a cross-platform application that can be downloaded separately and used to interact with the nodes. It provides a friendly UI for setting up all the necessary parameters and monitoring of the agreements the node is involved in. As it is still in beta stage, please let us know if you find out troubles through our support channels.

Trace on!