tip-0034.md

TIP: 0034
Title: TIP-34 Sentiment Token Standard
Authors: Douglas Horn
Status: Draft
Type: Protocol
Created: 2019-03-10

Abstract

The following standard describes a novel token implementation of a standard API for tokens within smart contracts. This standard provides basic functionality to issue tokens and transfer them under the control of the issuer, not the third-party account where they are recorded.

Sentiment tokens are more fully described in the paper: Like, Trust and Respect: Tokenizing Sentiment and Opinion on the Telos Blockchain.

Motivation

The development of a new form of blockchain token that can be used to record persistent sentiment or opinion about another account creates many new technical possibilities for integrating sentiment, opinion, ratings, certifications, and social media into blockchain technology.

Rationale

Sentiment or opinion about another account can be a powerful and important force within a blockchain network or community like Telos. By having a standard token that may be applied to another account like a badge, either from a single issuer, such as a ratings organization, or from multiple issuers, where measuring aggregate commmunity sentiment increases meaning, accounts may gain persistent but maleable reputations reflecting the sentiment of others. Such sentiment measurements could serve many purposes, such as warning users away from untrustworthy customers or suppliers, designating an account user to be a widely respected authority on a topic, or serving as an community poll about the actions of a company on their actions or offerings.

Specification

The TIP-34 Sentiment Token Standard defines an interface that allows third-party support for token contracts that implement sentiment tokens. The interface is defined as follows:

Tables

The following tables store information such as token balances and global token settings.

• typedef multi_index< N(balances), balance> balances_table

  The balances table will hold all accounts and their respective token balances. The table is indexed by account_name.

• typedef eosio::singleton<N(singleton), setting> settings_singleton

  The settings singleton holds all token related information such as max supply, circulating supply, and a human-readable name.

Structs

The following structs and their members are stored in tables and referenced by their primary keys.

• setting

  Issuer refers to the account authorized to mint new tokens. This may be a single account or, if blank, then any account may issue tokens which are further scoped by their account name.

  Max Supply holds the maximum supply of tokens to be allowed in circulation. If blank, the token has no maximum supply.

  Supply stores the total tokens currently in circulation.

  Minting Period defines the minimum about of time that must pass since the last minting before new tokens can be minted.

  Minting Amount defines a fixed amount of tokens that will be minted each time new minting occurs.

  Name holds the human-readable name of the token.

  Name Anti holds the human-readable name of the anti-token or opposite opinion form of the sentiment token, when used. If blank, the token does not employ an anti-token.

  Maximum Balance Per Account holds the maximum value of either tokens or anti-tokens that any recipient account may hold from any single issuer account. If blank then there is no maximum.

• balance

  Owner refers to the account where the tokens reside (although this account cannot transfer these tokens).

  Tokens holds the balance of tokens owned by the owner.

ABI Actions

The following function signatures define how users can interact with the token contract.

• void mint(account_name issuer, asset tokens, account_name mintbank)

  Mints new tokens into the circulating supply, associated with issuer, and sends them to the mintbank account. Tokens may be minted either only by the account publishing the contract, when Issuer is defined in the Setting Struct, or by any account, when Issuer is blank in the Setting Struct. Any time a token that has an anti-token is minted, the anti-token is also minted in the same amount (and vice versa).

• void transfer(account_name sender, account_name recipient, asset tokens)

  Transfers tokens from the sender account to the recipient account. Only the issuer has the authority to transfer tokens. Tokens may only be transferred either from or to the mintbank. Tokens may not be transferred to issuer. When a transferring a token that has an anti-token, the balance of the anti-token must be zero before the token can be transferred. When an anti-token balance exists and a positive token balance is transferred to that account by the same issuer account, the anti-token must be reduced (transferred to the mintbank). The reverse is also true when transferring an anti-token to an account with a token balance from the same issuer account.

Discussion

• Q: Why can only issuers transfer tokens, not owners?

  A: Sentiment tokens reflect the opinions of others regarding an account. Allowing owners to acquire or remove them defeats the purpose.

• Q: What is the mintbank and why is it used?

  A: The mintbank holds sentiment tokens not currently assigned to another account. Once minted, tokens must reside somewhere. The mintbank is a common account to hold all the unassigned sentiment tokens and their anti-tokens from any given sentiment token account. One mintbank could hold the tokens of many different types of sentiment tokens or even all sentiment tokens on the network. Tokens and anti-tokens can only be transferred to or from the mintbank and never from one account directly to another.

• Q: What is an anti-token and how is it used?

  A: For sentiment tokens that employ a balanced opposite sentiment such as RESPECT and DISRESPECT, the Anti-token is this opposite form (If the token is RESPECT, then the anti-token is DISRESPECT). Since tokens cannot express negative values, but opinion often does, an anti-token is required. When no anti-token is specified, then the token is unidirectional, such as a ratings system that may only be positive values. When transferring tokens, it is necessary to ensure that, First: any anti-token balance is reduced and has reached zero before any positive token balance is applied (and vice versa for anti-token balances), and Second: that the token balance does not exceed the maximum_balance_per_account of either the token or the anti-token.

• Q: Are the same tokens from different issuers fungible?

  A: No. Sentiment tokens are semi-fungible in that any RESPECT token from the issuer account (accountname1) is fungible with any other RESPECT token from the issuer account (accountname1), but not with RESPECT tokens from any other issuer account.

Copyright

Open Source under GNU GPLv3 License.