Wiki
Search…
Rewards Engine
Rewards can be accrued when Data Aggregations are used as a part of a product or service for which data consumer is paying. The nature of those fees might varying and could encompass a subscription or a transaction fee model. A coalition member becomes eligible for rewards when they contribute their private data to the Aggregation Service for aggregation. The extent to which, or how an aggregation results in rewards, must be determined by CoApp business logic based on the coalition use case. In many cases the accrual of rewards will be linked to a transaction of some kind, including the sale of the data aggregation directly as a data product or the use of the data aggregation in a marketplace model to encourage derived transactions.

Rewards Eligible Events

During onboarding the host and its members must define the set of events for which rewards are eligible to accrue. There is no strict limit on the number of event however practicalities will likely limit this number to less than three to four.

Value Coefficients

The coalition must define the unit by which the value of an event ought to be measured. The value is known as the value coefficient. For example in terms of payload size or dollar value. It is the responsibility of the host to track the occurrences of events, the corresponding value coefficients, as well as the associated aggregation ID. It is possible that multiple aggregations contributed to a rewards event. In that case, the host may deliver to the Rewards Engine the array of Aggregation IDs and Responsibility Weights.

Rewards Inputs

The 180Protocol Rewards Engine requires the following inputs from coalition hosts in order to generate Aggregation Rewards. Inputs are tracked and considered on an event by event basis.
For each event the Rewards Engine requires the following fields:
Event ID (PK)
String
Assigned by host, unique
Event Description
String
User defined field
Value Coefficient
Double
Assigned by host
Aggregation ID (PK)
List of Strings
Assigned by 180Protocol
Responsibility Weight
Double
Weight between 0 and 1
Aggregation Value Coefficient
Double
VC * Responsibility Weight

Rewards Engine

The rewards engine is triggered each time the application host transmits that an event has occurred to the Rewards Engine. The output of the Rewards Engine is a Quality Score. A unique quality score will be assigned to each Data Provider that contributed data to the Aggregation that resulted in the Rewards Eligible Event.

Quality Score

The quality score is the basis of rewards accruals to members. 180Protocol calculates the quality score of each data contribution as a function of the Rewards Inputs from the host and information about provider contributions to the aggregation stored within the enclave or encrypted within the provider network. The Quality Score is designed to be a single digestible figure that user can use to easily understand the quality of a contribution, and, by extension the reason why rewards were what they were.
Coalitions have a predetermined functions that translate quality scores into reward credits. This function takes as its inputs the quality score of the aggregation as well as the aggregation value coefficient of the rewards event. In this sense the reward depends on both the meaningfulness of the event but also the quality of the data contribution, with both positively correlated. The exact rewards function can be tweaked by the coalition, however a default function per below is made available to cover all scenarios using unitless rewards.
Below follow two illustrative examples:
8.0
50
240.79
8.0
50,000,000
7433.61
3.0
50
33.86
3.0
50,000,000
1480.21
Rewards balances are a unitless figure analoglous to credits. These credit are entries on each Provider's Corda node and interact via an on-demand translation service to the Ethereum token economy. Please see Token Network Economy for greater detail.

Quality Score Factor Model

The Quality Score is defined a function of the follow Quality Factors:
Quantity ProvidedAssumption: Providing more data is better than less data.
Data Uniqueness - Assumption: Providing data that others haven’t provided is valuable.
Data CompletenessAssumption: Certain data is better than other data and thorough data is better than patchy data
Update Frequency - Assumption: Providing data more frequently is better than less frequently. Additionally, providing more recent data is better than providing stale data.
Quality Scores can be defined at the level of the individual member contributions as well as at the level of the aggregation. The Aggregation Quality Score is the simple average of the constituent quality scores. It is the belief a simple average will be sufficient given that the quality score itself is designed to capture and normalize the detailed factors underlying data quality.

Factor Weightings

The Quality Score is determined as a function of the Quality Factors. The factor weights are determined for each rewards events via multivariate regression, looking at how the Quality Factors of historic aggregations correlate with their associated Value Coefficients within coalitions. The purpose is to ensure we dynamically assign quality scores on the basis of the contribution quality factors contributing the most value to data consumers and application hosts. We assume that this multivariate regression is always run over the entire historic sample of Events, however the is scope to limit this to more recent Events, for example. Ideally this regression is rerun after each event to remain up to date, however less frequent refreshes are acceptable.
Please see the section Reward Factor Model for more information.

Quality Factors

The four quality factors are Quantity Provided, Data Uniqueness, Data Completeness, and Update Frequency. Conceptually, the factors are designed to account for different attributes of a data contribution. Naturally, there will be some correlation and overlap between them. For example Data Completeness in many cases may be positively correlated to Quantity Provided. This is acceptable as the Factor Weighting algorithm will promote or demote each factor’s importance based on their observed impact within each use case.
For each aggregation, each aggregation rewards factor will be assigned score:
The explanations of the factor score derivations below rely on the following syntax:
Update Frequency
The update frequency score is derived as a function of how the average of a member’s most recent four contributions relate to the distribution of total coalition contribution frequencies.
Data Completeness
The completeness factor encourages providers to offer thorough and robust data sets covering a representative sample of the population distribution. The completeness factor is calculated within a particular aggregation. During onboarding and during determination of input data structures, certain fields can be assigned as Data Fields of Interest. The Data Field of Interest must be a descriptive label. The completeness score can be calculated as follows:
  1. 1.
    Get the count of distinct values supplied by all providers to the aggregation. Let this be Count_Values_Total
  2. 2.
    For each provider, get the count of distinct values they provided to the aggregation. Let this be Count_Values_Provider
  3. 3.
    For each provider, the completeness score for each field will then be calculated per below. If there are multiple fields specified, that can be handled within the distinct function and the logic remains the same.
Data Uniqueness
The uniqueness factor encourages data providers to offer unique sets of data. The uniqueness factor is calculated within a particular aggregation. Data uniqueness refers to descriptive, not numerical fields. For example, data labels. During onboarding and during determination of input data structures, certain fields can be assigned as Data Fields of Interest. The Data Field of Interest for the Uniqueness factor is distinct from that of the Completeness, though it is fine if they are the same. These are the fields that will be relevant for the Uniqueness score. The algorithm that determines uniqueness will be defined as follows. Data Fields of Interest may encapsulate multiple fields, for example (age range, gender, education level). In the case of multiple fields, the algorithm considers the combinations holistically.
For all contributions to an aggregation, determine the list of distinct values and occurrences.
18-25, Male, High School
25
25-45, Male, Bachelors
18
18-25, Female, Bachelors
12
25-45, Female, High School
8
45-65, Male, High School
5
65+, Male, High School
3
Assign values incrementally starting with the most popular value, if a tie assign the same value and increment beyond at the next step.
18-25, M, High School
25
1
25-45, M, Bachelors
18
2
18-25, F, Bachelors
12
3
25-45, F, High School
8
4
45-65, M, High School
5
5
65+, M, High School
3
6
For each provider, calculate the sumproduct of the value and their count per label. In this example, we assume three providers:
1
18
5
10
2
1
0
36
71
2
5
10
1
3
1
0
20
45
3
2
3
1
3
3
3
15
56
For each provider, calculate the average by dividing by the number of count, or SP / Count.
1
1.97
2
2.25
3
3.73
Normalize into acceptable range (0-10) by multiplying the scarcity score by 10 / MAX(Assigned Value).
1
3.28
2
3.75
3
6.2
Quantity Provided
The quantity provided score is derived as a function of how the member’s contributions relates to the distribution of coalition-wide contribution amounts. The coalition host and the founding coalition members must define the unit by which the quantity of data (or value) provided if measures (bytes, dollars, etc)

Rewards function

This function must be selected at launch by the coalition host and the coalition members. The default function listed above in the Quality Score section is made available if customization is not desired or required. This function transforms unitless rewards into the rewards unit sought by the coalition. This is configurable and may be in the form of fiat currencies, cryptocurrencies, or unitless credits.
Copy link