Key Points

1. different token types for different purposes ( security, utility, loyalty incentives etc ) ( see Token Taxonomy Framework )
2. different jurisdictions have different legal definitions and regulations for different token types ( still evolving )
3. security token - has a defined claim against assets ( like stock ) and issued via ICO or secondary sale
4. utility token - used to incentivize participants on a platform, can be used to purchase goods on marketplace
5. currency - tokens that can be bought and sold on open marketplaces - may have fixed or variable value ( Ethereum vs Stable coin )
6. Fabric does not have a native token infrastructure yet in v2x

References

Key Concepts

Token Types for different use cases

Design process can determine the need for different token types in the disbursement solution

Token Taxonomy Initiative defines a Token Taxonomy Framework 

https://github.com/interwork-alliance/TokenTaxonomyFramework

https://github.com/token-taxonomy-initiative/TokenTaxonomyFramework

http://tokentaxonomy.org/wp-content/uploads/2019/11/TTF-Overview.pdf

Examples of tokens defined in version 1 specification 

Token Taxonomy Framework

https://github.com/interwork-alliance/TokenTaxonomyFramework

https://github.com/token-taxonomy-initiative/TokenTaxonomyFramework

token-taxonomy-framework-github.pdf

The taxonomy is comprised of artifacts that are categorized into 5 basic types:

• Base Types: the foundation of any token is its base token type.
• Behaviors: capabilities or restrictions that can apply to a token.
• Behavior Groups: a bundle of behaviors that are frequently used together.
• Property Sets: a defined property or set of properties that - when applied to a token - can support a value that can be queried.
• Token Templates: a composition of artifacts brought together to create a classification and detailed specification. There are 2 parts of a template, the formula and definition.

Hierarchy

Token behaviors

A behavior may also include things like a sequence diagram to clearly define how a behavior is invoked and how the behavior responds using the defined control message definitions.

Token formulas - token definition language

The formula uses brackets, braces and parentheses to combine the token parts and starts with the base token type:

Examples of formulas

A token formula uses the taxonomy symbols, which are references to artifacts, can be used to represent a token that is useful for tooling allowing grouping and structures to be represented. Some examples:

Token Types

https://invao.org/token-classes-explained-coin-vs-utility-token-vs-security-token/

But it’s actually quite simple: Coins are a currency, utility tokens offer a right to use a product or service, and security tokens represent an investment product.

1. Security token is an investment with a defined stake in assets ( eg company eps, fixed assets etc )
2. Coin token is a digital currency ( an alternative to fiat currency )
   1. coins bought and sold through exchanges for a fee
   2. coins can have fluctuating value ( value store ) like Ethereum, Stellar etc
   3. coins can have stable values ( value transfer ) like USD coin etc
3. Utilitiy tokens have specific value in a defined context ( eg buy a product or use a service in  online marketplace etc )
   1. To use a utility token outside the platform, it is normally redeemed for digital currency or fiat currency unless there is an ecosystem that accepts it
   2. Investors can buy these tokens and use them as a means of payment on the platform developed by the issuing company.
4. Single Use tokens
   
   1. issued by party A to party B for party B to execute a transaction on A's blockchain using a smart contract one time only

What are utlity tokens

https://blog.sfox.com/what-are-utility-tokens-and-how-will-they-be-regulated-89cfb6bb2a45

Using Utility Tokens

A Uber token, for example, could be used to pay for a ride with a Uber car. But not for anything else. If you wanted to use the Uber token to buy another product or service, you would first have to exchange it against either fiat money or a crypto-coin such as bitcoin.

Token Classifications

https://github.com/token-taxonomy-initiative/TokenTaxonomyFramework

The TTF classifies tokens using five characteristics they possess, allowing tokens that share the same characteristics to be classified together. These are foundational token concepts that can be applied to most tokens.

• Token Type: Fungible or Non-Fungible. The difference between the two is clarified later in this document
• Token Unit: Fractional, Whole or Singleton indicates if a token can be subdivided into smaller fractions, usually represented as decimals, or if there can be a quantity greater than 1. For example, a $1 bill can sub-divided to 2 decimal places and can be broken into four .25¢ coins (or a number of different variation of coins) and is thus Fractional. Whole means no subdivision allowed - just whole numbers quantities - and a Singleton has a quantity of 1 with no subdivision.
• Value Type: Intrinsic or Reference indicates if the token itself is a value, like a crypto currency, or if it references a value elsewhere, like a property title.
• Representation Type: Common or Unique. Common tokens share a single set of properties, are not distinct from one another, and balances are recorded in a central place. These tokens are simply represented as a balance or quantity attributed to an owner’s address where all the balances are recorded on the same balance sheet. A unique token has its own identity, can have unique properties, and be individually traced. Common tokens are like money in a bank account and Unique tokens are like money in your pocket.
• Template Type: Single or Hybrid, covered later, but is an indication of any parent/child relationships or dependencies between tokens.

Taxonomy Artifacts, Categories, and Templates

The taxonomy is comprised of artifacts that are categorized into 5 basic types:

• Base Types: the foundation of any token is its base token type.
• Behaviors: capabilities or restrictions that can apply to a token.
• Behavior Groups: a bundle of behaviors that are frequently used together.
• Property Sets: a defined property or set of properties that - when applied to a token - can support a value that can be queried.
• Token Templates: a composition of artifacts brought together to create a classification and detailed specification. There are 2 parts of a template, the formula and definition.

Token transfer requests

https://github.com/token-taxonomy-initiative/TokenTaxonomyFramework/blob/master/images/txfer-response.png

Base Token Types

Fungible

Physical cash or a crypto currency is a good example of a fungible token. These tokens have interchangeable value with one another, where any quantity of them has the same value as another equal quantity if they are in the same class or series. A fungible token is identified by τ_F symbol.

Non-fungible

A non-fungible token is unique. Hence a non-fungible token is not interchangeable with other tokens of the same type as they typically have different values. A property title is a good example of a non-fungible token where the title to a broken-down shack is not of the same value as as the title to a mansion.

A fungible token is identified by τ_N.

Representation Type

Tokens can have either a common representation, sometimes called account or balance tokens, or unique representation, or UTXO (unspent transaction output). This distinction might seem subtle but is important when considering how tokens can be traced and if they can have isolated and unique properties.

Common tokens share a single set of properties, are not distinct from one another, and balances are recorded in a central place. These tokens are simply represented as a balance or quantity attributed to an owner address where all the balances are recorded on the same balance sheet. This balance sheet is distributed, not centralized, and rather simplified. Common tokens have the advantage of easily sharing a value like a "SKU" where the change in the value is immediately reflected for all tokens. Common tokens cannot be individually traced, only their balances between accounts can.

Bank accounts are an example of a common fungible token.

Unique tokens have their own identities and can be individually traced. Each unique token can carry unique properties that cannot be changed in one place and cascade to all and their balances must be summed. Bank notes and paper bills are interchangeable but have unique properties like a serial number and are therefore examples of unique fungible tokens.

A unique token is identified by ‘ following the type symbol, i.e. τ_F'.

Hybrids

Hybrid tokens combine a parent token and one or more child token(s) to model different use cases. Hybrids can get nested where a child token is also a parent for more complex scenarios. Here are some examples.

Shared Non-fungible Parent with Fungible classes

These tokens have a non-fungible parent or base token and can have multiple classes of child tokens. An example of this hybrid is a rock concert, where the parent token represents the specific date or showing of the concert with a fungible child for general admission and a non-fungible child for "reserved" section seating. Represented as τ_N(τ_F, τ_N).

The owner of an instance of this token will possess the child token that pulls along the parent and is presented at the concert gate for admission. If the parent token date matches the current date the token is valid for admission. If the child token that is owned is in the reserved seating section, the owner has the right to sit in the seat indicated by the token.

Fungible Parent class owns or has many non-fungible Children

A token can be the parent of any number of tokens to represent the compound value of the child tokens. For example, a τ_F(τ_N) is a fungible token parent that is the owner of one or more non-fungible tokens. An owner of an instance of this parent would own a percentage of the pool of non-fungible child tokens. A mortgage-backed security is a good example of this type of hybrid token.

Token properties

Token Behaviors

Token Taxonomy Framework pdf from githun

https://drive.google.com/open?id=1CjNlFeoTMG9jH78Fgp5fcY8DXXipR3Aw

Sequence diagram shows process to mint token

Token usage models

Reward systems

Reputation systems

Custom Tokens on HLF example 1 - for ERC20 wallet

https://medium.com/deqode/erc20-tokens-on-hyperledger-b82399b4b969

Sample token framework example for HLF and ERC20 wallets

Github links

https://github.com/grepruby/ERC20-Token-On-Hyperledger/tree/v1.0/chaincode/token_chaincode/node
https://github.com/grepruby/ERC20-Token-On-Hyperledger/tree/v1.0/chaincode/token_chaincode/node/tokens

it sets up a token network based on Fabric and shows the use of a smart contract for using ERC20 token (still a token and principles/functions of using it still apply etc...)

Issue custom tokens on the Stellar Network for use in HLF solutions

https://www.lumenauts.com/guides/how-to-issue-a-token-or-ico-on-stellar

tokens-lumenauts.com-How to Issue a Token or ICO on Stellar.pdf

Using custom tokens on HLF network solutions 

setup for the tokens

The custom tokens should be standard ERC20 tokens for wallets

Create users, identities, ERC20 wallets.

Using the tokens

Then distribute the tokens in the HLF app: sell or donate to users as rewards

Users can buy, sell, donate on the network using tokens

Burn the tokens - buy back the tokens from users at a fixed price or ??

Interwork Token Architecture

https://interwork.org/

The value exchange layered protocol for Interwork opens many doors 

https://www.forbes.com/sites/vipinbharathan/2020/06/07/digital-assets-ecosystem-will-be-powered-by-end-to-end-standards/#1b13be873fd8

Monetize and Tokenize Data

Ocean Protocol Network

https://blog.oceanprotocol.com/how-to-monetize-tokenize-data-8f860e405773

four building blocks needed to make this vision of open data sharing a reality. This open system allows every data provider to monetize and tokenize their data, so that data itself could be a sustainable business model. Once I explain how data can be used more openly, can we then apply the tools of finance to it?

Ocean architecture

https://docs.oceanprotocol.com/concepts/architecture/

• Components

  • Tier 3 - Application Layer
  • Tier 2 - Protocol Layer
  • Tier 1 - Decentralized VM Layer
• Interactions

https://docs.oceanprotocol.com/concepts/secret-store/

Ocean Software components

https://docs.oceanprotocol.com/concepts/components/

Keeper

A computer running an EVM-compatible blockchain client (such as Parity Ethereum) where the associated blockchain network is running the Ocean Protocol keeper-contracts (smart contracts).

Secret Store

A Parity Secret Store: software for distributed key pair generation, distributed key storage, and threshold retrieval. It’s used to store asset access-control keys.

Acquarius item metadata manager

Marketplaces run Aquarius to store and manage metadata about the assets available in their marketplace. It provides an HTTP API for interacting with an off-chain database (sometimes called “OceanDB”).

Ocean DB Drivers

Aquarius supports several options for the off-chain database (OceanDB), including Elasticsearch and MongoDB. One can add support for another off-chain database by creating a new driver similar to the existing OceanDB drivers.

Birzio to manage access to market assets

Publishers run Brizo to manage interactions with marketplaces and consumers. It interacts with the publisher’s cloud and/or on-premise infrastructure.

The most basic scenario for a publisher is to provide access to the assets the publisher owns or manages, but Brizo can do much more.

Events Handler

Brizo communicates with the Events Handler to deal with Keeper Contracts events.

The Events Handler monitors Service Execution Agreement (SEA) events and acts as a provider agent to grant access and release rewards for the publisher/provider. This is a critical part in the process of consuming data sets in the Ocean Protocol network.

Every provider in the network must run some sort of an events handler to be able to fulfill the access condition of an Access service in a Service Execution Agreement.

Osmosis Drivers

Brizo supports several options for file storage, including Azure Storage, Amazon S3 and on-premise storage. One can add support for another file storage option by creating a new driver similar to one of the existing Osmosis drivers.

Squid Libraries

Client libraries used by applications (such as Pleuston or Jupyter notebooks) to interact with Ocean components, including Keepers, Aquarius nodes, Brizo nodes, etc.

Commons Marketplace

An online example marketplace/publisher for consumers to explore, download, and publish open data sets in the Pacific Network. Implemented using React and squid-js.

For more information, see the blog post about Commons Marketplace.

Pleuston example marketplace publisher

An example marketplace/publisher front-end for developers to explore, download, and publish assets in an Ocean Protocol network. Implemented using React and squid-js.

Ocean Tutorials

https://docs.oceanprotocol.com/tutorials/introduction/

Potential Value Opportunities

Potential Challenges

Candidate Solutions

Stellar Digital Asset Token Platform

Stellar Concepts & Terms

https://developers.stellar.org/docs/glossary

Account​

A central Stellar data structure to hold balances, sign transactions, and issue assets.

See the Accounts section to learn more.

Account ID​

The public key used to create an account. This key persists across different key assignments.

Anchor​

The on and off-ramps on the Stellar network that facilitate one-to-one conversion of off-chain representations to and from tokenized assets, for example, digital tokens representing bank deposits.

Application (app)​

A software program designed for users to carry out a specific task (other than operating the computer itself).

Balance​

The amount of a given asset an account holds. Each asset has its own balance and these balances are stored in trustlines for every asset except XLM, which is held directly by the account.

Base fee​

The fee the network charges per operation in a transaction. When the network is in surge pricing mode, the base fee varies based on an auction mechanism. When it's not, the base fee defaults to the network minimum currently at 100 stroops per operation.

Learn more in our Fees, Surge Pricing, and Fee Strategies Encyclopedia Entry

Base reserve​

A unit of measurement used to calculate an account’s minimum balance. One base reserve is currently 0.5 XLM.

Learn more in our Lumens section.

Keypair​

A combined public and private key used to secure transactions. You can use any Stellar wallet, SDK, or the Stellar Laboratory to generate a valid keypair.

Keystore​

An encrypted store or file that serves as a repository of private keys, certificates, and public keys.

Ledger​

A representation of the state of the Stellar universe at a given point in time, shared across all network nodes.

LedgerKey​

LedgerKey holds information to identify a specific ledgerEntry. It is a union that can be any one of the LedgerEntryTypes (ACCOUNT, TRUSTLINE, OFFER, DATA, or CLAIMABLE_BALANCE).

Liability​

A buying or selling obligation, required to satisfy (selling) or accommodate (buying) transactions.

Orderbook​

A record of outstanding orders on the Stellar network.

Passive order​

An order that does not execute against a marketable counter order with the same price; filled only if the prices are not equal.

Pathfinding​

The process of determining the best path of a payment, evaluating the current orderbooks, and finding the series of conversions to achieve the best rate.

Payment channel​

Allows two parties who frequently transact with one another to move the bulk of their activity off-chain, while still recording opening balances and final settlement on-chain.

Price​

The ratio of the quote asset and the base asset in an order.

Rate-limiting​

Horizon rate limits on a per-IP-address basis. By default, a client is limited to 3,600 requests per hour, or one request per second on average.

Sequence number​

Used to identify and verify the order of transactions with the source account.

Secret (private) key​

The private key is part of a keypair, which is associated with an account. Do not share your secret key with anyone.

Signer​

Refers to the master key or to any other signing keys added later. A signer is defined as the pair: public key + weight. Signers can be set with the Set Options operation.

See our Signature and Multisignature Encyclopedia Entry for more information.

Source account​

The account that originates a transaction. This account also provides the fee and sequence number for the transaction.

Starlight​

Stellar’s layer 2 protocol that allows for bi-directional payment channels.

Stellar​

A decentralized, federated peer-to-peer network that allows people to send payments in any asset anywhere in the world instantaneously, and with minimal fees.

Stellar Consensus Protocol (SCP)​

Provides a way to reach consensus without relying on a closed system to accurately record financial transactions.

Stellar Core​

A replicated state machine that maintains a local copy of a cryptographic ledger and processes transactions against it, in consensus with a set of peers; also, the reference implementation for the peer-to-peer agent that manages the Stellar network.

Stellar.toml​

A formatted configuration file containing published information about a node and an organization. For more, see the Stellar Info File spec (SEP-0001`)

Transaction​

A group of 1 to 100 operations that modify the ledger state.

Read more in the Operations and Transactions section.

Transaction envelope​

A wrapper for a transaction that carries signatures.

Transaction fee​

Stellar requires a small fee for all transactions to prevent ledger spam and prioritize transactions during surge pricing.

Trustline​

An explicit opt-in for an account to hold a particular asset that tracks liabilities, the balance of the asset, and can also limit the amount of an asset that an account can hold.

Learn more in our Accounts section.

Validator​

A basic validator keeps track of the ledger and submits transactions for possible inclusion. It ensures reliable access to the network and sign-off on transactions. A full validator performs the functions of a basic validator, but also publishes a history archive containing snapshots of the ledger, including all network transactions and their results.

XLM (lumens)​

The native currency of the Stellar network.

Wallet​

An interface that gives a user access to an account stored on the ledger; that access is controlled by the account’s secret key. The wallet allows users to store and manage their assets.

XDR - External Data Representation format ( Binary )

https://developers.stellar.org/docs/encyclopedia/xdr

Stellar stores and communicates ledger data, transactions, results, history, and messages in a binary format called External Data Representation (XDR). XDR is optimized for network performance but not human readable. Horizon and the Stellar SDKs convert XDRs into friendlier formats.

XDR is specified in RFC 4506 and is similar to tools like Protocol Buffers or Thrift. XDR provides a few important features:

• It is very compact, so it can be transmitted quickly and stored with minimal disk space.
• Data encoded in XDR is reliably and predictably stored. Fields are always in the same order, which makes cryptographically signing and verifying XDR messages simple.
• XDR definitions include rich descriptions of data types and structures, which is not possible in simpler formats like JSON, TOML, or YAML.

Parsing XDR

Since XDR is a binary format and not as widely known as simpler formats like JSON, the Stellar SDKs all include tools for parsing XDR and will do so automatically when retrieving data.

In addition, the Horizon API server generally exposes the most important parts of the XDR data in JSON, so they are easier to parse if you are not using an SDK. The XDR data is still included (encoded as a base64 string) inside the JSON in case you need direct access to it. .X files

Data structures in XDR are specified in an interface definition file (IDL). The IDL files used for the Stellar Network are available on GitHub.

Stellar Federation Protocol - address users, accounts, orgs

https://developers.stellar.org/docs/encyclopedia/federation

The Stellar federation protocol maps Stellar addresses to an email-like identifier that provides more information about a given user. It’s a way for Stellar client software to resolve email-like addresses such as name*yourdomain.com into account IDs like: GCCVPYFOHY7ZB7557JKENAX62LUAPLMGIWNZJAFV2MITK6T32V37KEJU. Federated addresses provide an easy way for users to share payment details by using a syntax that interoperates across different domains and providers.

Federated addresses​

Stellar federated addresses are divided into two parts separated by : the username and the domain. For example: `jedstellar.org:`

• jed is the username
• stellar.org is the domain

Note that the @ symbol is allowed in the username. This means you can use email addresses in the username of a federated address. For example: maria@gmail.com*stellar.org.

Transaction Base and Surge fees & management

https://developers.stellar.org/docs/encyclopedia/fees-surge-pricing-fee-strategies

API Security Standards for Stellar Net

https://developers.stellar.org/docs/encyclopedia/securing-web-based-projects

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles