Publicada con documentos de Google
UTU Protocol Whitepaper V4
Actualizado automáticamente cada 5 minutos

UTU PROTOCOL

White Paper

V4

August 10, 2022

Note on Methodology

This whitepaper version reflects our understanding of the economics and technology at the time of its publication. Even in the context of existing blockchains and decentralised applications, our proposed system/application exhibits several new functional, network and economic qualities. We thus cannot claim to have it all figured out…yet.

For this reason, we are committed to test our assumptions in the form of different levels of simulations, and ultimately MVPs, and adapt our concepts, models and economic parameters where necessary from what we learn over time. We’re also committed to continuing research projects with our established research partners -- such as the Turing Institute, UKRI Trusted Autonomous Systems Hub, and the  Agents, Interaction and Complexity Research Group at the University of Southampton -- to improve the model, tokenomics, technology and other core properties such as the privacy of the proposed platform.

Introduction

Who do you trust?

We could never have predicted how far that question would drive us. We’ve asked thousands of people all over the world who they trust, and it turns out, as people, we all tend to trust the same. 90+% of people answer this way:

I TRUST MYSELF.

I TRUST MY FAMILY.

I TRUST MY FRIENDS...WELL SOME OF THEM, SOMETIMES, FOR SOME THINGS.

Relationships + Context - These are the core of human trust, yet our digital and sharing platforms ignore this reality of human nature when building their services. Instead they try to build trust around anonymous star ratings and reviews, yet none of the thousands of people we’ve ever asked about trust has ever mentioned anything about good star ratings from random folks on digital platforms as their north star of trust.

So we asked ourselves more questions?

And finally, what if we sparked a movement to do exactly this?

Origin Story and Where we Stand today

UTU is the Swahili word for “Humanity.”

Our story started as we tried to build and scale a mobility app in Kenya from 2015. We recognized that all existing mobility apps in the global marketplace ignored the key problem facing Kenyan consumers, namely trust.

Built in places like California and London, these platforms were built on the premise that drivers are commodities, to be replaced one by another, stripping them of their individuality and ignoring the human desire to work with people we trust. In fairness to these platforms, perhaps this is adequate in San Francisco and London. Then it hit us:

What about the several billion people that live in places nothing like San Francisco or London? What about Nairobi? What about the billions in cities that have more in common with Nairobi than London? What about the millions of marginalised people in almost every country for whom the world is not so open or safe. Can we build something for all of these communities?

At this moment we set about building a machine learning powered recommendations engine, modeled on the fundamentals of real interpersonal trust, to power the next generation of the sharing economy - a trust economy.

The results were transformational. Overwhelmingly people chose personally trusted service providers over others with higher star ratings, shorter wait times, and even lower prices, validating our core hypotheses around the massive desire for better trust in our digital platforms. Our trust engine proved its ability to drive all marketplace KPIs:

Our trust-powered approach to mobility struck a nerve around the world as messages came flooding in from entrepreneurs and platform operators, all saying the same thing, “Your trust-powered approach to mobility: that’s exactly how it works in my country too. Can we license your technology?”

After many requests from platform operators in every other sharing economy sector and massive demand from consumers for the ability to source trusted services, UTU set about opening up our trust infrastructure as an API, available across multiple sectors and geographies. We recognized that our ecosystem of users, our deep expertise in distributed multi-agent system and R&D capacity, and unswerving commitment to building a trust economy put us in a unique position to use this ecosystem as a nucleus to launch a blockchain protocol, built around human trust. Read the rest of the story here: https://utu.io/blog/utu-origins/.

The previously unpublished chapter of this story, outlined here,  which we will at some point write more about, includes:

These tools are part of a new ecosystem that changes the economics of trust, de-silos data to let users reclaim it for their own goals, ensures trust can’t be bought or manipulated, and leverages that data to help people make better decisions.

Vision - Decentralized Trust Infrastructure of the Internet

Starting with Web 3 was an obvious choice in hindsight. Web 3 comprises only five actions, five things a user can do, but each carries with it very specific fears that hold back mass adoption and often lead to huge losses for users, both to scams and honest mistakes. UTU was born to help people take these five actions: Connect, Send, Swap, Stake, & Borrow.

 

First Principles

Guiding our platform are our first principles of trust:

Privacy First.

Incentive Alignment. The core of UTU’s Token model treated below.

Trust as infrastructure - not product. It must be delivered as such. Any consumer-facing platform or directory you’ve ever used to discern trust, or the quality/reliability of an online service provider, whether Angie’s list, Yelp, TrustPilot or any other, has productized trust forcing you to their platform to identify the service provider you want to hire which you may ultimately do through another platform or app. This multi-step user journey creates a trust gap that ultimately constrains adoption of services that expose you, your family, your home, health, assets, or business to risk. This is why UTU’s core trust offerings are served up as infrastructure directly into platforms to inform their users’ decisions in real-time when they’re selecting from available service providers. This principle ultimately led us to also develop our blockchain protocol as basic infrastructure on top of which any platform can be built.

Trust is individual, relational, contextual, and evolving. It can’t be prescribed, only described - Most companies have taken a data-centric approach to modeling trust, framing it in terms of quantifiable scores, ratings, and confidence intervals - far from the human experience of trust - driven by personal relationships and environmental conditions. Where other trust companies evaluate an individual’s trustworthiness against a fixed, prescribed, monolithic standard, rather than evaluating every buyer and seller in relation to each other. Furthermore, they fail to adapt these models to reflect the complexity of the real world and the impact of external environmental factors on purchasing decisions in real-time. By evaluating trust first and foremost based on the presence/strength of our users/providers relationships, evaluating buyers and sellers in context of one another rather than in absolute terms, and adjusting for sector-relevant environmental factors, our trust engine models human trust better than any existing technology.

In a trust economy, consumers and providers give way to a third key actor in each transaction, that of endorsers that give both buyer and seller confidence to execute a transaction together. Traditionally these middlemen have been either denigrated or compensated surreptitiously by the seller to drive him/her business. By openly and transparently valuing these endorsements for the security they deliver within a trust economy, we encourage the expansion of trusted endorsements to unlock the true scale and potential of sharing platforms globally whether traditional, centralized platforms or decentralized apps. By building the system around our interconnectedness we create optimal conditions for participants to behave honestly and strong disincentives and mitigation mechanism to fight the fraud, abuse, and manipulation that has plagued review platforms and star rating systems.

UTU Trust AI  - Use Cases

In any online marketplace, establishing trust between parties who would like to engage in business with each other is a prerequisite for that business to actually happen. But the currently widely used trust and reputation mechanisms such as often anonymous star ratings and reviews are flawed and easily fakeable. Consider, for instance, the fake restaurant that reached #1 on TripAdvisor London and  widespread review fraud on Amazon.

This issue is even more prevalent in the developing world, such as in Kenya where our story began  and where we indeed came to realise the importance of this issue in the course of operating our first venture, a taxi app. For example, while most Uber users in New York City perceive Uber drivers as a commodity to go from a point A to a point B and therefore are willing to take any one of them because they trust Uber drivers in general, this is not generally true in African localities, where users traditionally even store the phone numbers of their known and trustworthy drivers.

Researching further into this area, we discovered that people often don’t care very much about ratings of people they don’t know.  We asked thousands of people who they trust and who might influence their decision regarding choosing one service from another, and some 92% answered:

I trust myself,

my family,

and (most of) my friends.

So people generally trust people whom they know very well. That is why we founded UTU, to offer a different, social-relationship based approach to establishing trust, rather than scores, aggregated reviews and ratings in order to transform the sharing economy into a trust economy.

Concretely, UTU’s AI-powered Trusted Recommendation Service will operate as follows:

The latter approach enables UTU to provide useful recommendations to users even without knowing a lot of their data,  and we believe that even if they are reluctant to provide more data at first, after a while they will see the value of having a relationship-based recommendation system and therefore accept to do so.

Moreover, UTU has the huge advantage of having its own channel to market – MARAMOJA, the aforementioned taxi app with tens of thousands of users across Africa – that is  helping us  tackling the data acquisition challenge. Indeed, having our own mobility app allows us to test and improve our AI infrastructure on MARAMOJA, and therefore come up with a high quality operational recommendation system to other platforms in various sectors. As for its users, we have a high potential to leverage existing data from the MARAMOJA app -- subject to users’ consent, which we will seek -- which helps to mitigate this bootstrapping problem.

Trust is relational, but also contextual and it is constantly evolving. Its value is also positively correlated with risk: the riskier a transaction, the more valuable is trust in the transaction’s other parties.

That is why we believe that UTU is particularly relevant in any transaction that is exposing the user’s business, assets, home, family or health, and more generally that is exposing him to some sort of risk :

 UTU’s potential market is therefore huge, and this list is not even exhaustive (see next section). We are constantly approached by entrepreneurs and companies with novel use cases that we would have never considered, such as a trust power dating app or reducing fake news.

But we are also fully aware of the fact that operating in various sectors comes along with different stakes and risks that requires UTU to constantly adapt.

That is why, to maximise our chances of success, we are prioritising partnerships with platforms regarding several factors, such as:

For the MARAMOJA app, we have already shown that an early version of our recommendation service leads to 20% more conversion when a recommendation from a social relationship exists, 20% better satisfaction and higher retention. We believe that these metrics will increase as our AI system improves.

UTU Trust AI  - DeFi Use Case

Another major use case for UTU is Decentralized Finance (DeFi). For a long time, credit offering institutions such as banks have evaluated the creditworthiness of consumers based on traditional credit scoring methods that rely on an individual’s or business’s financial history. Factors such as how regularly one settles bills, how many credit accounts they have open, history of delinquency, and the length of a person’s credit history, are reduced to a single score that determines not only whether you get credit, but also dictates the terms of that credit. However, the lack of these data points in Decentralized Finance burdens borrowers significantly with high collateral amounts and interest rates. This not only requires large collateral amounts to access the loans, it also locks up liquidity for the borrower.

The collateral requirements take away access to finance for those that need finance the most. In most of the developing world, traditional banks have left out huge swaths of people and businesses because of limited financial history. These banks rely on traditional credit scoring systems that are too rigid. DeFi has encountered a similar issue with overcollaterization.

To alleviate these issues, UTU’s trusted recommendation mechanism and creditworthiness methods built on top of this can help in three distinct ways:

Currently UTU’s DeFi credit scoring and trust recommendation mechanisms are being implemented in the following use cases:

UTU Trusted Recommendation Service and Protocol

In previous sections, we outlined the need for trust in open economic systems, and our high-level vision of how to approach this challenge. In this section, we describe the basic properties of the system that we propose to implement to concretely tackle the trust issue.

On the highest level, this system is a composition of two main components:

  1. our social feedback and recommendation  service, a classic (proprietary) web service, and
  2. a decentralised and blockchain-based protocol to provide transparency and verifiability of  feedback, and to incentivise data provision.

In the following sections, we explain these two components, their basic functional requirements, and how they will work together.

Trusted Recommendation Service

As explained, “trust" in our understanding is mostly based on personal relationships where human actors are concerned (but can have additional transactional components) as well as on the type of interaction (e.g. requesting a certain kind of service) and its context.

UTU’s main goal therefore is to establish ourselves as a secure and decentralised platform to  facilitate the analysis of personal relationships and other relevant data in order to provide a “trusted recommendation mechanism”, which can be used by mediators (e.g. a taxi app) or directly by individuals (e.g. taxi clients) to get trusted recommendations for peers to do business with (e.g. taxi drivers).

To provide good quality recommendations, this service needs to know who is related to whom but also who trusts whom to give recommendations for what kind of interaction/service and in what context. To learn this, it needs feedback data answering questions such as:

Therefore our trusted recommendation service (TR) can be formalised as a function

with

Assuming that we can in principle obtain enough data constituting the sets , and , we can run AI algorithms (such as deep learning, reinforcement learning, or other ML and clustering techniques) on it to improve the quality of our recommendation service.

For this purpose, we are working closely together with the first of the 3rd-party platforms to use our recommendation service to facilitate retrieving enough such feedback data from them to enable our recommendation engine to start learning the clients’ recommendation preferences.

However, when we grow the number of other 3rd-party services using our service, we expect to not always be able to integrate with them this closely. Another way to obtain this data is from the clients directly. However, we expect clients to likely not always provide us with this data voluntarily and freely. Therefore, apart from the prospect of getting better future recommendations, we think it is necessary to create additional incentives for clients to provide feedback data directly. For this and other purposes, the next section introduces the Decentralised UTU Trust Protocol.

Decentralised UTU Trust Protocol

In this section, we describe the high level requirements for a decentralised protocol which supports the previously described recommendation service by:

Incentives

In order to incentivise clients to provide data which is usable for our trusted recommendation service, but potentially also to other services on the platform, we devise a non-transferable token to be built on a blockchain platform. We call this the UTU Trust Token, UTT  or just “token” in the following.

This token will be rewarded to clients who actively engage in the system in two ways:

  1. Clients will be able to not only endorse entities such as service providers, but to put a stake of tokens on it. Successful endorsements, i.e. such ones which lead to a recommendation being shown to clients subsequently requesting the same service and who then in turn endorse the same provider themselves, shall be rewarded depending on the staked amounts.
  2. Any other data provision shall be rewarded with tokens based on their usefulness to our recommendation service as well as other services:
  1. For data in known formats, for which automatic verification is possible, some amount of tokens shall be rewarded directly as a consequence of the provision.
  2. Otherwise, provided data is rewarded based on consumption by services and their giving feedback about the validity and usefulness of the data.

Note that as a consequence of the first point, the total amount of UTT staked on a provider constitutes a measure of reputation for the provider.

On the other hand, a user’s UTT balance measures a mix of their contribution to the protocol and making successful endorsements. Therefore, when considering another user’s endorsement of a provider, a user might consider the other user’s UTT balance — in addition to their personal relationship and opinion of them — as an indication of the trustability of the endorsement. In other words, a user’s UTT balance can also be seen as a measure of their reputation as endorsement or feedback providers.

Apart from that, UTU Trust Tokens will be of value for clients in three more ways:

  1. Earning UTU Trust Token additionally rewards a user some amount of UTU Coin ($UTU), a second token on our platform which is monetary in its nature, i.e. it is a fungible token which is freely tradable on cryptocurrency exchanges. The corresponding $UTUs are given out from a pool.
  2. Participating in UTU governance will require holding of both UTU Trust Token and UTU Coin.
  3. Some services, including UTU’s recommendation service, might require holding a certain amount of tokens in order to be consumed.

The motivation for the UTU Trust Token to be non-transferrable, and therefore not tradable on exchanges, is that we want to prevent people from “buying their way” into the system. Rather, we want them to take part properly, i.e. providing feedback data, endorse others etc.

On the other hand, we want truthful feedback and endorsements, and therefore a penalty mechanism shall be instated for unsuccessful endorsements, i.e. those endorsements which lead to a recommendation being shown to clients subsequently requesting the same service, but who then disapprove of the provider.

Therefore, truthful behaviour is incentivised on three levels:

  1. It increases the client’s UTT holdings.
  2. As a consequence of point 1., it earns them more $UTU.
  3. Since the client’s name might be shown when showing a recommendation based on their endorsement to another client, a “bad” endorsements might worsen the latter’s opinion about  the former.

Given that the $UTU rewards are paid out from a pool, the amount of $UTU rewarded for earning some amount of UTT might need to be adjusted dynamically or by governance depending on the protocol state, to prevent depleting the pool completely.

Identity

Additionally to all of the above, a dual concern to trust is that of identity, posing challenges such as:

The UTU Protocol mechanisms will need to provide means to address these concerns.

Data Storage and Access Management

Another question is how can we enable people to securely store their data and make it useful for private or public services? Data may in principle be stored:

However we don’t want anyone to own or just get unrestricted access to another individual’s data. In fact, we want users to be able to fully control who gets to access their data when, for what reason, in what context etc. They should be able to choose to do this fully or semi-automatically, controlled by smart contracts but also with the possibility to be notified or asked back. This could be implemented via oracles or interactive oracles (whereby we mean that an oracle requires some interactive confirmation from the user), respectively.

Another aspect of the data-provision is that users should be able to provide only minimal data required for each task. In some cases, it might be possible to employ technologies like zero-knowledge proofs or ring signatures for certain services to function adequately. Our platform shall therefore enable the use of such technologies.

UX

Lastly, all of the above constitutes some rather complicated economic system, whose rules might not be immediately understandable to the average user. We therefore need to develop front-end software with a user experience (UX) that enables novice users to easily start taking part in the system, making some pre-selections and decisions on behalf of them which are beneficial. But at the same time such software should allow expert users to control the system as detailed as they like.

UTU Protocol Additional Tools

Outside of the two main components of UTU Protocol, there are a series of tools that have been developed by UTU to give users the ability to integrate UTU’s recommendation and feedback features to a variety of applications. UTU’s SDK Toolkit allows businesses to integrate UTU’s recommendation and feedback infrastructure into their applications. The toolkit makes it relatively simple to integrate the recommendations while minimising the technical modifications that need to be made in order for the integration to complete. UTU’s Web Browser plugin can be downloaded easily and will allow users to truly build their digital reputation. The browser extension will allow you to view feedback and endorsements on UTU Protocol right from the sites and D-apps, right as you are about to interact with them. Moreover, it also gives you a mini interface where you can provide feedback and make endorsements yourself.

A major part of UTU’s ability to provide curated recommendations is its ability to incentivize data collection. UTU’s Social Media Connectors allow users to login or create accounts with their various social media. This is critical information that allows us to map a user’s network and truly provide trusted recommendations.

Other tools are being developed to further capture relevant information. Next projects include developing plugins for centralised ecosystems such as WooCommerce and Shopify.

Summary

Taking all the above into consideration, we can summarise the requirements for our trusted and decentralised platform :

Note that UTU’s recommendation service then is a special case of a service which might be consumed by other services (i.e. as part of a composed service) or directly by clients. It would reward the provision of feedback data (to facilitate ML and other AI algorithms to improve the trust/recommendation model), and payment of tokens for providing recommendations.

Having outlined our platform’s general requirements, the next section looks into the economics of such a system in more detail, and determines the system’s parameters which allow to implement the required incentives more concretely.

Token Economics

Overview

UTU COIN

UTU Trust Token

Nature

Monetary coin with limited supply

Utility token slightly inflationary

Supply

1 billion

Infinite

Acquisition

Purchasable on exchanges

 

Conversion from UTU Trust Token

Rewards for data provision, successful endorsements, interest on staked tokens, ecosystem service provision/consumption

Usage

Conversion into fiat and other tokens

 

Payment for ecosystem services (consumers)

 

Payment for trust engine (platforms)

 

Payment to access users’ data (platform, third parties)

Endorsing (stake tokens) on trusted service providers

 

Endorsing negatively on untrusted service providers

 

Earn UTU Coin rewards

Conversion

Convertible back-and-forth between its incarnations on Ethereum and various bridged chains.

Convertible to other crypto/fiat on Ethereum and bridged chains (centralised and decentralised) exchanges

Not convertible

Stakeholder analysis

STAKEHOLDER

WHAT VALUE THEY MIGHT PROVIDE

WHAT THEY MIGHT GET

Buyers

Their data, seller endorsements, network effect, demand for currency

Access to trusted services, tokens for sharing data, clout-increasing recommendations, coin/token

Service providers

Their data, buyer endorsements, network effect, outlet for currency

Access to trusted consumers, increased brand value around trustworthiness

Platforms

Buyer/Seller Data at scale, 10% of each transaction, outlet for currency

Better KPIs, Better user trust, more brand goodwill

Connectors & Endorsers

Their data, buyer/seller endorsements, network effect

Tokens, social capital

Investors

Cash, Connections to Other Platforms, Partners, Franchises

Return on Investment as coin appreciates

UTU & CO

System Development, Trust Analysis, Ecosystem growth

Transaction Fees

Partners

Beneficial components in our ecosystem, Channel partnerships

UTU Coin, Access to market

UTU Coin

UTU Coin ($UTU) will be accepted as a form of payment within the UTU ecosystem of applications, by third party platforms and DAPPS. It will be required to use our trusted recommendation service, and to pay users who demand it for accessing their data.

Therefore, the reward scheme for UTU Trust Tokens and their rewards in $UTU has some similarities to a traditional coin mining process for the users: instead of running a Proof of Work algorithm, users can monetise their active participation in the system.

UTU’s own services accept service usage fee payment in $UTU. For decentralised client platforms, using our service via oracles requires them to hold a minimum amount of $UTU, and payments are accepted exclusively in $UTU.

Client platforms may choose to pass on $UTU charges to their own clients (users), or they might choose to pay all $UTU fees for their users.

$UTU has been launched with a max. total supply of 1 billion $UTUs. It is freely tradable, so its value is determined by the market, which ultimately depends on uptake and usage of the platform.

The rewards of $UTU for earning UTT is provided for by an $UTU pool, which will be replenished from service fees paid in $UTU for our own and later other services on the platform. So tokens are not minted for this purpose, but service consumers will need to acquire more $UTU over time, while users who were rewarded $UTU for earning  UTT can sell. This establishes a cycle of usage of $UTU.

One might obtain $UTU in these ways:

  1. by actively taking part by providing data and endorse services, thereby earning UTU Trust Token (UTT, see below), which will be rewarded with a certain amount of $UTU (see following sections),
  2. selling access to one’s data to UTU’s recommendation as well as other interested parties, like 3rd-party services on the platform,  
  3. taking part in token generation/distribution events and
  4. by trading on exchanges for other coins, tokens, or fiat money.

The $UTUs rewarded in point 1. will be credited to the user in a smart contract (either in the ecosystem growth pool itself, or an integrated contract), and a user might then claim them (and possibly bridge them to other chains, for which UTU might offer convenient and cost-effective methods) at their convenience.

The amount of rewarded $UTU is linear to the rewarded UTT according to the following definition.

Let

Then we define the reward in $UTU as

It might happen that the pool does not have enough balance for all existing claims. In this case, UTU governance should consider lowering DUTT, increasing protocol fees, and/or buying $UTUs to manually replenish the pool.

Note that this setup creates a cycle of $UTU for users of $UTU because they

This is in line with The Web3 Sustainability Loop described by Trent McConaghy of Ocean Protocol, which describes a general economic system for sustainable growth of web3 projects. For details please refer to the linked blog post, but the general form of it for a single token protocol looks like this:

Adapted to UTU’s two-token system, we get this:

Note that while introduces an additional cycle of $UTU via the $UTU rewards, the main cycle through UTU governance remains intact.

UTU Trust Token

Remember that the UTU Trust Token’s (UTT) purpose is to model participation in the platform with endorsements, and shall not be freely tradable.

Therefore UTU Trust Token cannot be implemented as an ERC20-like token, but rather will have a custom smart contract implementation.

Particularly, it will have no ERC20-like transfer functions (transfer, approve, transferFrom), although restricted versions of those might be added in a future version to facilitate transfers between different accounts of the same user (which also requires safe, privacy-preserving and user friendly-enough methods of identifying individual users or organisations; Kleros’ Proof of Humanity or Worldcoin’s Proof of Personhood might be options for this) .

In this regard, it is more similar to a soulbound token (SBT) than an ERC20. Though there are also differences, as the typical envisioned form of SBT seems to be soulbound NFTs, while UTT represents a balance measuring a kind of reputation (see section “Incentives” above).

As explained elsewhere, the total amount  of UTU Trust Token will be unbounded over all time . This is because the token is awarded (and generated at the same time) for staked successful service endorsements, as explained in the next section, and therefore models clients’ active participation in the system, which hopefully only grows over time and indefinitely.  

However, as is detailed  in the following sections, the amount of tokens awarded depends on some system-defined rates, which will be used to control the increase (or decrease) of existing tokens in the system in a way that leads to favourable overall system behaviour. We will run simulations to determine suitable initial rates and their update functions based on objective system criteria such the current total amount of tokens, the number of available services and clients etc.

Endorsement rewards are for now the only events when UTU Trust Token are generated, but more might be added later, should more rewardable action be made available in the platform.

UTU Trust Token might also be destroyed, e.g. in the case of system services charging fees, though these fees still need to be determined.

Endorsements

Providing trusted recommendations for services or peers is one of the main purposes of the platform. Therefore, users should be incentivised to share their true belief in which services they recommend for specific purposes.

The platform will enable this by providing an endorsement smart contract that users can invoke to make a staked endorsement of services. When other users are then recommended (via UTU’s personal relationship-based trusted recommendation service) those services later on and on their part use and endorse them, the previously-endorsing clients whose recommendation was shown will be rewarded.

A user can make repeated endorsements for the same service, where each newly staked amount is added to the existing stake. However we might introduce a minimum time period between each such endorsement, likely dependent on the overall service consumption rate.

They can also withdraw any amount of stake at any time as long as the resulting staked amount is >= 0. An endorsement with 0 staked amount may also be removed completely.

Note that when we speak of “services” in this context, we mean both on-chain services realised and smart contracts, or hybrid services which have on-chain components (smart contracts, wallets) and off-chain components (such as REST or SOAP interfaces). In the latter case, the off-chain interfaces of the services can also be utilised from smart contracts via Oracles and vice-versa. In all cases, services have on-chain addresses which can be used to pay fees in the form UTU Trust Token to.

In order for the smart contract to link service endorsements to previous endorsements and recommendations, and also to avoid ‘blind’ endorsements, clients have to provide “service receipts” to make endorsements. These receipts are returned by platform-conformant services as part of their response, and must be signed with the private key of the service’s operator. A corresponding public key must have been previously registered with the endorsement smart contract.

An application of this endorsement protocol with two clients is approximately depicted in the following figure, without giving all details (e.g. service fee payment):

Rewards

When a client c is offered some options for a requested service or product, UTU’s recommendation service might show ksp >= 0 recommendations (or more generally, feedback)  for each service provider sp. If the client then chooses sp, the originators — via their endorsements — of the shown recommendations  for sp, also called first-level previous endorsers,  shall be rewarded according to their respective stakes.  We denote the set of previous endorsers as Ec,sp.

But to incentivise successful endorsements — i.e. those that lead to many follow-up endorsements — even more, we also reward the originators successful endorsements that led the clients in Ec,sp to endorse sp in the first place. We call these second-level previous endorsers.  I.e. for each e in Ec,sp, there is a set Ee,sp of second-level previous endorsers for e (which might be empty). Rewards for second-level previous endorsements are to be smaller than rewards for first-level previous endorsers.

We now define the exact amount of the reward of UTT for each first and second-level previous endorser p as a function of

Then,

Note that in the smart contract, the whole computation will be done with integers only, i.e. decimal values will get lost.

Therein, the first fraction represents the max. total reward for the previous endorser p, given their stake and Dlvl(p). Note that this implies that the reward is always lesser or equal to the previous endorser’s own stake, and which also implies that  no rewards can be earned for endorsement with 0 stake. Requiring Dlvl(p) >= 0 ensures that the divisor is never 0.

The second fraction approaches 1 as the new stake  sn gets greater. It thereby determines how much of the max. total reward is realised. For greater Dn the reward curve, when plotted against increasing new stake sn, rises less steeply. This diminishes the influence of additionally staked UTT for greater amounts of UTT. We again ensure that  the divisor is never 0 by requiring Dn > On  >= 0.

The last fraction lowers the whole reward curve depending on other pre-existing stakes. The greater so, the lower the curve. Again, we ensure that  the divisor is never 0 by requiring  Do  > 0.

All capitalised parameters (On, Dn, Dp, Dlvl(p) and Do ) are made writable in  the smart contract (at first by the contract admin address).

The tokens for this reward will be added to the previous endorsers’ addresses, according to their share as defined above, in the form of newly generated tokens.

For an initial round of public testing on testnet, we set

As might be seen from the example below, these provide reasonable reward curves for stakes greater than just a few UTT. For smaller stakes, the reward will often be just 0 because of the integer-only computation.

We shall then tune the parameter values by running public tests on testnet further analysis and running simulations of the platform, applying the token engineering approach.

Later, as an intermediate step, we might set the contract admin address to a multi-signature wallet. In the final stage, the admin address shall be changed to a governance contract, which will implement automatic implementation of proposals which have been voted on successfully by $UTU and UTT holders.

We might also consider making  Dlvl(p) further dependent on the endorsed service’s fee (which would likely require an oracle).

Let’s consider an example with parameter values as given above, with one first-level previous endorser A who had staked sp =200, and with the amount of all other previous endorsements = 5, i.e. stotal  = 5 + 2 + new stake sn.

The following plot then depicts A’s reward as a function of the new stake sn for a few different values for so, denoted  “s_o” in the plot:

Note that over time, a successful service will accumulate more and more endorsements by different clients, which means that so will grow over time, and therefore the rewards for existing endorsements will diminish on average. This means that we reward initial discovery higher than loyalty and commerce, which makes sense because the stated main purpose of our system is discovery of trusted service providers. This can be countered to some extent by clients by increasing their stake at times.

However, the division by the total amount of tokens, including the newly staked ones, leads to diminishing returns for higher token amounts. This serves two purposes:

  1. We want to incentivise clients to endorse new, now well known services, rather than profiting only from “safe bets” on already well-known and endorsed services.
  2. While users with large amounts of tokens (“token whales”) should of course benefit from their wealth, the playing field should not be too unlevelled for new users.

But using this mechanism with diminishing returns is not safe against Sybil attacks, where an attacker might e.g. create multiple virtual clients to split their endorsements between them, rather than making one larger endorsement. However, since an endorser is only rewarded if their recommendation of the service was shown to another client and which then lead to the service’s consumption (including paying the fee for it), only one of the attacker’s virtual clients would be rewarded at any one following service endorsement. Additionally, the non-genuine virtual clients would not be known by other clients, except the attacker invests some serious effort into making them look legitimate, including creating social connections etc. Therefore, this strategy is very unlikely to be profitable for the attacker. Even so, we’re going to investigate this more formally in future versions of this paper.

Finally, note that the bounding by Rmax is necessary to prevent making endorsement rewards more worthwhile than it costs to consume a service with some margin. Otherwise it would be profitable to collude with another client to endorse “useless” services, profiting purely on the rewarded endorsements.

However, note that the staked token amounts are not modified when receiving rewards, therefore future endorsements of the same service might be rewarded again accordingly. We do not bound the total reward that a client might thus receive over time, meaning that highly influential endorsers will keep being compensated for their efforts.

Penalties

But clients may not only profit for endorsements, but might also be punished by them, if other clients deem the service not recommendable. I.e. similar to endorsing a service, clients may disapprove of services.

This is to enable them to let their acquaintances know of particular problems with a service (provider), and therefore will require them to provide a narrative.

Therefore, UTU’s recommendation service will take disapprovals — particularly those of socially related people — into account when showing recommendations, which therefore might also be negative, i.e. warnings.

Instead of a stake, the “disapprove” function of the endorsement smart contract just takes a fee, which has a minimum amount but can otherwise be chosen by the disapproving client.

This is to allow only “one-off” disapprovals, rather than staked disapprovals over time. Disapprovals therefore do not generate any profit for the disapproving client, and in fact are costly because of the fee, which cannot be refunded. This disincentivises the use of disapprovals to “sabotage” services maliciously.

The fee could be in $UTU or UTT, or both. They both have drawbacks:

  1. Paying in $UTU would mean rich folks (whales) can basically downvote without being hurt.
  2. Paying in UTT would mean the user loses some of their own standing/reputation.

We’re going with 2., because disapproving is after all supposed to hurt anybody just a bit, and it will hurt more reputable people (more UTT) comparatively less. Which is probably good. It’s also a model which has been live for years on Stackoverflow/Stackexchange, where one needs to “pay” a bit of reputation in order to downvote, and it seemingly seems to work quite well.

If only the minimum fee is paid, this has no effect on the previously endorsing clients, but the disapproval is persisted in the system and might be used for determining service recommendations.

However, if more than the minimum fee is paid, then the client previously endorsing the service and whose recommendation was shown will be penalised. This is implemented through a penalty which is subtracted from the previously endorsing client’s stake as long as the remaining stake stays >= 0. Note that a smaller stake might reduce the chance of a recommendation being shown to subsequent requesters.

OTOH, we want to limit the impact of penalties:

For these reasons,  the penalty for any given paid disapproval fee should always be less than the reward that would have been paid out to the previous endorser for an equivalent staked endorsement.

We thus define the penalty for each first- and second-level previous endorser as a fraction of the equivalent reward, with an additional minimum requirement on the paid fee. With

we define

Similarly to the system-wide defined values in the reward section, the exact values for Dmin and Dd shall be determined by the governance mechanism .

We propose to initially set Dmin to 50 and Dd to 2.  

Data Provision

As described earlier, UTU’s trust recommendation service uses data on personal relationship, user profile, and other context data to serve meaningful recommendations. And we expect that also other services in the system will benefit from clients providing such data. On the other hand, we want clients to fully own their own data, i.e. give them full access control. We discuss access control in detail in the Technology section.

Currently, the UTT contract rewards users for connecting some of their social media accounts, such as Telegram and Twitter. More will be added. Such connections are currently rewarding a constant amount of UTT, and only one account of each social network can be linked to an address.

For the more general purpose of arbitrary data provision, we will provide smart contracts or integrations with other systems for clients to specify

Interested consumers of this data, may they be UTU, other platform or service providers, or other entities might then query the smart contract to check whether they’re allowed to access a particular set of data, and if so, request the facilitation to and pay for access.

The smart contract would then reward the client according to the service’s feedback. Why would a service provider want to make the mentioned callback and provide feedback on the data?

This mechanism ensures that clients are incentivised to provide useful data for services because they make a profit from this. Service providers who need this data to improve the quality and therefore profitability of their services will find this mechanism useful as long as their increased utility (however they measure it) exceeds any fees they need to pay for being a part of the platform.

Additionally to this per-use reward scheme, we will consider rewarding provision of certain standardised data sets directly, such as uploads of data exports from social media platforms — which are now almost universally available to users thanks to GDPR and similar regulations. But without additional validation mechanisms, this would enable users to be rewarded for uploading useless or fake data. We will therefore explore using such mechanisms, possibly something similar to Ocean Protocol’s data curation.

We further envision allowing clients to give data access right according to their trusted relationships. For example, a client might want to give a service access to its data if their good friend also gave them access. We shall investigate whether a client trusted by their friends in this way shall be additionally rewarded, and how. This would likely further incentivise reasonable data-sharing behaviour by clients.

Monetary Policy

We believe that $UTUs and tokens designed as described above will provide the best token economics system for UTU technology for the following reasons:

Incentive Compatibility

We have not formally analysed our mechanism to see whether it is incentive compatible, but we have reasons to believe that it is or can be made so with reasonable effort:

Stability

The supply of $UTUs is capped at 1 billion.

40% of $UTUs will be available through a planned Token Generating Event (details to be announced soon). These tokens vest 40% at TGE, 30% after 3 months, and the final 30% after 6 months.

10% of the $UTU will be held by the advisors. These tokens will be locked for 12 months after TGE and then released monthly for 24 months.

20% of $UTU will be held by the Team. Team tokens are locked for 12 months after the UTT/Condorsement contract launch and then released monthly thereafter for 24 months.

Another 30% are reserved for the future growth of the ecosystem by constituting a Coin pool for the conversion of Tokens into Coins.

The number of coins that can be exchanged from tokens on a daily basis will be constraint regarding this formula:

 

with X a system wide defined constant, Oeco the pool of coin, Tt the total amount of UTU Trust Token (UTT) in the UTU ecosystem, and Nu the number of registered user in UTU.

Since Tt and Nu will increase as the ecosystem grows, and Oeco naturally diminishes as more and more tokens are exchanges against coins, Emax is therefore naturally diminishing and will limit more and more the exchange from tokens.

There are incentives to hold and use $UTU. Users will have the possibility to pay service providers with it, and third parties that wants to access user’s data will have to pay for this and the user in $UTU, and in the long run all platforms will have to pay transaction fees in coin. The fees will also be used to replenish the UTU pool that is available for UTT -> UTU conversion.

On a high (macro-economic) level (without considering concrete reference values or units), the value of an asset is defined as the ratio of total demand and supply:

where

The demand Dt can be further broken down to

where

On the offer side, we have

where

Therefore, initially in each conversion time frame,

 

Since Du, Dp, Dd, and Do will generally increase as the ecosystem grows, the only variable that could harm the coin’s value over time is a great drop of Dc  that outweighs the growth of all the other partial demands.

Technology

Building on EVM

Given that numerous blockchains now support the EVM as a smart contract platform, including highly scablable and low-fee ones, the UTU Coin and UTU Trust Token contracts are written in Solidity.

$UTU is available on Ethereum and bridged to BSC; it will soon be bridged to Polygon, and to other chains.

A first version of UTT is currently deployed on Polygon Mumbai testnet, and will soon be deployed on Polygon mainnet. In the future, it might be deployed on other chains as well, or in the form of “UTT satellites” which enable users to make endorsements directly on supported chains, and which will sync to the UTT contract via oracle.

Numerous oracle technologies are available for EVM-compatible chains, both centralised and decentralised. Currently, the existing UTT contract employs a Chainlink oracle.

User Interfaces

  1. UTU API /SDK Clients. We are building an API and SDKs to let sharing economy platforms serve their users with our trust recommendations, directly in their apps. This is the primary revenue stream for UTU Technologies.  
  2. Browser and mobile keyboard plugins. These will be the main User Interfaces for consumers using our ecosystem from web or mobile. The user will manage their privacy and their $UTUs and Tokens from here. These apps will regularly feed data into the user’s encrypted data store on-chain and earn the user UTU Trust Tokens as they transact on traditional platforms. These consumer-facing products both help us acquire user data to improve our trust modelling capabilities but also demonstrated demand for our services to the major sharing platforms, which in turn drives the value of our ecosystem. Since our trust infrastructure is highly dependent on our ability to securely acquire and store user data, it is essential for us to avoid any business model that would compromise this priority.

Architecture

The UTU platform will consist of the following layers:

Smart Contracts

In this section we describe how we’re planning to implement the $UTU as well as the UTU Trust Token, such that it fulfils it purposes as outlined in other parts of this paper. To summarise what we want UTU Trust Token to do:

  1. Be rewarded for successful staked endorsements of services or peers.
  2. Be paid for disapprovals of services or peers.
  3. Be convertible to $UTU using a dutch auction mechanism.
  4. Be rewarded for successful data provision to service platforms/providers/others.

In the following sections, we outline how each of these features shall be implemented in the blockchain platform.

The UTU Coin Contracts

UTU Coin ($UTU) currently exists on the Ethereum and BSC blockchains, and more, such as Polygon, in the future. It is implemented as a smart contract according to the ERC20 standard.

Users are able to swap it back-and-forth between these two chains via the Meter Passport bridge.

The UTU Trust Token Contract

The UTU Trust Token smart contract will provide functions and state management to facilitate the following:

  1. Manage the token account balances of all participating peers.
  2. Add or remove token stakes to/from endorsements. When an endorsement’s stake is increased (including staking an initial amount on a new endorsement), the contract will initiate a query to the UTU Oracle (see below) to determine previous relevant endorsers, and reward them according to the mechanism described in section “Rewards” above.
  3. Make disapprovals. The contract will initiate a query to the UTU Oracle (see below) to determine previous relevant endorsers, and penalise them according to the mechanism described in section “Penalties” above.
  4. Reward provision of data, such as connecting social networks to UTU.
  5. Give feedback about data usage, and if positive, reward the providing peer according to the mechanism described in section “Data Provision” above.
  6. Manage the ecosystem growth pool, from which $UTU rewards are paid out.

Additionally, there will be “UTT satellite” contracts on other chains. As described in “Building on EVM”, these enable users to make endorsements directly on supported chains, and will sync to the UTT contract via oracle.

The Data Provision Contract

The UTU Trust Token smart contract will provide integrations or interoperability with suitable data storage and access management systems, to provide feedback about data consumptions as described in previous sections, and to pay our according rewards.

Supporting external protocols for data management gives the user the option of choosing a service they trust to hold their data while UTU mediates the larger data provisioning process without having access to the data. When supporting an external protocol we have the following considerations:

  1. Interface with the UTU design: The protocol must be able to incorporate interactions with the UTU smart contracts on supported blockchains.
  2. Interface with the UTU philosophy: The protocol must respect user privacy -- the service must never have access to user data unless authorised explicitly -- and aim to give users as much flexibility as possible with their trust options. For instance, we would prefer that the external protocol be open-source, and allow individual users to host their own data management services if they so wish.

In the table below we detail the external protocols that we are considering to integrate with the UTU data provisioning protocol:

Summary

Design

Philosophy

Ocean Protocol

Ocean Protocol offers a protocol for a data marketplace, as well as a frontend app to use it. The protocol includes fine-grained access control methods and thus seems suitable for UTU’s purposes. It is also already deployed and working on mainnet of Ethereum, Polygon and other blockchains.

Users can publish datasets or algorithms on datasets, and create “data NFTs” and “data tokens” for them. These define the modes of access.

Data tokens can be put up in DeFi-style pools, where they can be freely traded. Therefore, users might earn either by providing datasets/algorithms themselves, by providing liquidity, or simply by trading data tokens.

  1. Very flexible definition of access modes and terms.
  2. Open source, code is on Github.
  3. Foundation/DAO-managed.

DEDIS Calypso

(Paper)

Academic project from the DEDIS lab at EPFL. Calypso uses distributed trust and cryptography to mediate data access on the blockchain. The system allows for flexible access policies and secure distribution of user data. Data accesses are logged on the blockchain (by a distributed access authority) for auditability.

  1. Calypso manages data using two distributed co-thority entities, one for access control and one for secret management. The access control co-thority can be implemented using a smart contract as in the UTU design. The secret management co-thority is off-chain and could potentially be hosted by the user*.
  2. Calypso is native to the Byzcoin blockchain. There have been attempts to port it to Ethereum, which however are not complete yet.
  1. Calypso allows for flexible access control and off-chain secret management. The user could manage their own data if they so wish*.
  2. The code is available at the linked GitHub repository.

Recheck

Update: ReCheck might have pivoted to other products, so might not be a viable option anymore.

Fellow Aeternity start-up aiming to provide secure data access via the blockchain. Recheck facilitates data access while using end-to-end encryption for user privacy. Data accesses are mediated by centralized servers running a data facilitation service. Data accesses are logged on the blockchain by the facilitation service.

  1.  Recheck uses centralized servers to facilitate data access. However these servers operate under end-to-end encryption and cannot access any of the data they handle. Groups of users^ or Recheck clients could license the facilitation service to reassign trust.
  2. The Recheck facilitation service implementation uses smart contracts on Aeternity.
  1. Recheck provides a UI for flexible access management but secret data management is done by the facilitation service.
  2. The code is available at the linked GitHub repository but the facilitation service code itself is proprietary -- only accessible to Recheck partners.

Other candidate systems (from Calypso Related Work in paper and extended version)

Enigma (extended ver.) - decentralized data management. Centralized storage provider.

CHURP (eprint ver.) - efficient re-sharing of secrets, alternative to long-term secrets.

We further envision allowing clients to give specialised data access right according to their trusted relationships. For example, a client might want to give a service access to its data if their good friend also gave them access. However, for this case we need to devise a way for those services to get the necessary credentials to access the respective URL. One way to make this work is to have the client provide a proxy, which is fully controlled by the client and can access their data provision URLs with the client’s own keys, and which the service might access instead of accessing the data directly. Another way is to somehow interface this functionality with the data access protocols. We will work out more details of this approach in a future version of this paper.

The UTU Ecosystem

Governance

As a protocol built around trust, we believe that trust starts with us. To this end, we commit to radically transparent governance both in terms of product development and use of funds. In a crypto ecosystem fraught with scams, we believe this to be a fundamental first step to restoring and building trust for the next generation of economic transactions.  

It is essential to note that governance is very much a human problem that most likely cannot be "solved" purely by technical means. We therefore will adapt user friendly voting and delegation mechanisms and apps that make it easy for users to take part in governance, be it voting or making proposals themselves.

The full scope of this will be a fully automated, DAO-type governance protocol implemented by smart contracts. It will automatically execute passed proposals. It will support delegated voting as in Liquid Democracy, weighted by the amount of tokens (UTT)  and coins (UTU) the account holds. The exact parameters will be subject to voting themselves.

Our idea for this is to let trust ecosystem participants -- measured by UTT -- weigh in higher here, but also to give some voting power to UTU holders. There are a few motivations for this:

At $UTU launch, when not UTT holders exist yet, we will bootstrap the governance protocol with a simplified version. This version will be implemented by using existing on-chain voting tools and apps, and it will be used to determine the initial system parameters (as discussed in the Rewards and Penalties sections for the UTU Trust Token in the Token Economics section). A multi-signature wallet will be used to authorise the execution of successful proposals, i.e. to set the voted values on the UTT smart contract. The multi-signature wallet will be owned by at least 5 people, some of which non-team community members, and require at least 3 signatures.

We shall use this initial governance protocol also for determining details for the design and implementation of the full-fledged version.

We will also use multi-signature wallets to hold and oversee the use of on-chain funds which have been raised for the project.

Development Plans                                                                                           

UTU Protocol core software                                                

Management & analytics of UTU Protocol network        

Marketplace template software (to be open-sourced for others)

Software & support to support the ecosystem and catalyze the community

Hooks into other platforms, protocols, and networks                

Enable and grow the two-sided marketplace