How to Tokenize a Business Model
All my articles by topic.
Introduction
This article provides general guidelines to help entrepreneurs and engineers to direct themselves in the process, not yet fully formalized, of the tokenization of a Business Model.
There are different approaches to tokenization, the simplest one consists in tokenizing some aspects of a Business Model in order to decentralize a part of it (semi-decentralization), mainly in order to make it more accessible, flexible, transparent and economical (later we will go into details in the advantages of tokenization). This is the case of issuing a security token (STO), in which the ownership of the business is parceled out, or of utility tokens (ICO and variants) in which the resources produced by the business are parceled out. In more complex cases, on the other hand, a business is built or transported on a fully decentralized infrastructure, in this case the company or the group promoting the initiative limits itself to owning a share of the tokens in circulation that enable business, but tends to yield over time the exclusive governance of the initiative, in favor of a new stakeholder market, obtaining what can roughly be assimilated to a stock listing.
How the article is organized.
- What is a Business Model: a tool is provided to investigate and represent a business in its fundamental qualitative aspects, the relations between these aspects and the main attributes.
- What is a Token Model: it provides a tool to qualitatively investigate and model the main aspects of a token economy.
- What are the advantages of tokenization: we’re going to examine the fundamental advantages in the tokenization of a Business Model.
- When to tokenize a Business Model: the criteria for evaluating whether the tokenization of a Business Model can provide real advantages.
- How to tokenize a Business Model: guidelines are provided on the process of tokenization of an existing business model or the creation of a completely new one.
- Beyond the Token Model: we’re going to introduce some aspects that must be taken into consideration when planning operational strategies and designing the platform that will host the Token Model.
What is a Business Model
A Business Model is a series of strategies implemented by a company to generate profit, creating a product or service and selling it to specific types of users. This product / service is implemented with a series of activities, internal resources and external partnerships. These activities are aimed at producing and delivering products or services to the outside that can be destined for end users (B2C), other companies (B2B) or a combination of these.
A Business Model is based on the achievement of one or more Value Propositions, that is the generation of value for the Customers, this value is realized through the resolution of problems or the satisfaction of necessity.
A Business Model is part of a Business Plan, which also contains all the details relating to the analysis of the market and competitors, the overall strategy such as time and financial planning, marketing strategy and all other relevant aspects of the project company.
The Business Model Canvas
The Business Model Canvas is a template for the representation of the essential features of a Business Model conceived by Alexander Osterwalder, and is a very effective tool for building, validating or tracking a Business Model.
The Business Model Canvas is organized in 9 quadrants, divided into two macro areas: the Front Stage consisting of all the quadrants above the Revenue Streams and the Back Stage consisting of all the quadrants above the Cost Structure. The Value Propositions is included in both macro areas.
Below is the list of the quadrants listed by suggested order form:
- Value Propositions: the business offer in terms of products or services that solve problems or satisfy the needs of the Customers.
- Customer Segments: the types of customers for which the Value Propositions have been identified.
- Channels: the channels with which the products or services are distributed to the Customers.
- Customer Relationships: the channels that use the Customers to communicate with the company and obtain feedback and support.
- Revenue Streams: The methods used to monetize the products or services offered.
- Key Activities: the activities that must be prepared to carry out the Value Propositions.
- Key Resources: the resources needed to carry out the Key Activities.
- Key Partners: strategic partners to carry out the Key Activities.
- Cost Structure: all the cost items to carry out the Key Activities.
For more details on using the Business Model Canvas we recommend consulting the Strategyzer official guide.
What is a Token Model
A Token Model describes the properties of a token, the nature of the users and services that interact with that token and the economic characteristics of such interactions, in fact represents an entire economic and technological ecosystem. A Token Model also defines the purpose of the token, its usefulness and the mode of creation, distribution and possible destruction (token lifecycle). The Token Model is a fundamental part of a tokenized Business Model.
The Token Model is characterized by two main aspects:
- Attributes: it assists the token platform and configuration;
- Token Flow: the interactions that the Token performs with the Token Holder, the Exchange and the substrate, and which constitute its economy.
Attributes of a Token
In this section we report the most relevant attributes for the definition of a token and its operating model:
- substrate: the decentralized platform that hosts the token (eg Bitcoin, Ethereum);
- system: eventual management system of the token inside the substrate (eg ERC20, ERC721), also determine aspects such as:
- fungibility: it defines the equivalence or not of the individual tokens and therefore the possibility of exchanging parity of volume at the same price, this criterion is connected to the system;
- transferability: the ability to transfer tokens from one address to another without authorization;
- role: the functional role of the token. Functional roles can be active or passive;
- passive token: any token that represents a value can be a currency (Bitcoin), a utility (Ethereum) or a security;
- active token: tokens that activate features such as access to a smart property or specific service features;
- payload: a token can be associated with an external physical or digital asset with a predefined value, for example fiat currency, precious metals, raw materials;
- supply: it can be limited or unlimited, it determines the monetary policy of the token and depends on the Business Model that is being implemented, specifies how many tokens will be generated and according to which criterion, through an algorithm defined in the smart contract or through the governance of the token holder;
- divisibility: represents the divisibility of the token, when applicable, ie the number of digits after the comma that must be supported (ex: 6 decimals), particularly important that it is high for limited supply tokens;
- source: ie the availability of the Smart Contract source code that regulates the token. It can be open or closed, although there are still projects with closed source tokens, we believe that this practice contrasts with the concepts of auditability and trustless at the base of a reliable economy token and therefore is absolutely to be avoided.
Token Flow
The token flow model describes the token lifecycle, usually with the following models:
- straight line: the token is created, assigned to the recipient, used and destroyed;
- chip model: it is used with an exchange service for conversion to other tokens / fiat and vice versa;
- circular: it is used as a currency.
Token classification
Other research groups have defined valid classification frameworks for tokens, in order to evaluate and validate their main aspects. Among these we mention the Token Classification Framework by Untitled Inc, which compared to our method uses a reduced number of parameters (dimensions) of a token, providing a simplified view.
What are the advantages of tokenization
A Business Model can be decentralized and therefore implemented on blockchain, through tokenization techniques, if at least part of the Key Activities that it foresees, as we will see later, are executable and verifiable with a protocol digital decentralizable.
The tokenization of a business model allows to:
- introduce tokens that promote the use of the business and create economic incentives to support;
- divide the functional features of the business among more entities preferably redundant and permissionless to increase the reliability of the project.
The advantages of tokenization in assets attributable to utilities and security are the following:
Liquidity
- Speed up (and potentially usability) of transactions.
- Access to the markets 24/7/365.
- Access to a pool of borderless investors.
- Fractionalisation: tokenization and the secondary market enable micro-ownership scenarios with potentially positive effects on brand awareness.
Efficiency
- Higher perceived value: greater liquidity means lower exit costs and therefore greater evaluation with the same value proposition.
- Reduction of brokerage costs.
- Reduction of intermediation times.
- Programmability of tokens with attribution of rewards for virtuous behaviour for stakeholders.
Transparency
- Possibility for all stakeholders to perform auditing of all aspects of the platform.
The Tokenized Asset Ecosystem
Business opportunities with the advent of tokenization will especially impact traditional financial services, completely changing the paradigm. However, in order for all this to be achievable, a series of incremental layers are still needed to be improved and developed, such as:
- a tech layer, capable of providing scalability and cost-effectiveness of operations, while maintaining a reasonable level of decentralization;
- a regulatory layer, preferably international, capable of providing legal harmonization and guarantees;
- a taxation and legal layer based on the precedent able to operate without friction and uncertainty;
- an insurance layer that makes safe the use of a technology that supports irreversible transactions and possibly anonymous operators.
Evaluate if a Business Model can be tokenized
Not all Business Models lend themselves to being tokenized, methods to assess the tokenisation of a business are being studied. At the moment we can rely on a series of questions, such as the following.
- Can your BM be / has already been realized without Blockchain?
- Can the Key Activities that characterize your Value Proposition be decentralized, at least partially?
- Does the tokenization of your business model have real advantages in terms of adoption and market size?
- Do you need to share a consistent state between different entities?
- Is it possible to find an economic incentive to allow these entities to collaborate?
- Is the economic incentive also valid for anonymous participants?
- Do you need legal verifiability?
- Do you need stringent performance or privacy requirements?
For an analysis of the answers and a more extensive discussion of the subject, we suggest you consult this article.
When to tokenize a Business Model
Do I need to tokenize?
The fact that a Business Model is tokenizable does not mean that it is convenient. Some considerations with respect to the advantages of tokenization:
- the purpose of tokenization is to access a global market and provide its stakeholders with liquidity on the secondary market. If one of these two conditions had been discarded in the project definition phase, the usefulness of tokenization would be lost;
- The process of tokenization has a cost, in some jurisdictions at the moment (mid 2019) obtaining the necessary licenses can cost up to ~ 1M USD, therefore the cost / benefit ratio must be evaluated.
Legal limitations
The international regulatory landscape is evolving rapidly but it is difficult to make forecasts. The main points are the legal possibility of activating a primary market (sale of securities to the public) and the possibility of activating a secondary market (ie availability of operators / exchanges authorized to hold securities for third parties). While many jurisdictions already authorize the primary market without particular reservations, for the secondary one currently lack the authorizations for operators in many international markets, which as an alternative solution are experimenting with the use of decentralized exchange (DEX) often combined with the use of a payload for the token that represents bearer holdings guaranteed by a bank, rather than directly securities.
The next section describes the process that can be used both for the construction of a tokenized Business Model and for its evaluation / verification.
How to Tokenize a Business Model
The method suggested for the tokenization of a Business Model requires starting from the analysis of the associated Business Model Canvas. The starting Business Model can be:
- conventional: it is possible to implement it without tokenization but with tokenization the possibilities are amplified;
- token native: it can be implemented only with a tokenized model.
Starting with the Business Model Canvas, the steps for building the Token Model are detailed in the following sections.
- Definition of the Token Economy
1.a Construction of the Business Model Canvas
1.b Identification of the aspects of decentralization and tokenization in the Business Model Canvas
1.c Construction of the Token Economy Canvas
2. Definition of the Token Mechanics
2.a Identification of the actors and token flows
3. Token Legal Review
4. The Token Valuation Canvas
1. Definition of the Token Economy
The first step to build the Token Economy requires starting from the Business Model Canvas of the project in question, if it does not exist, it must be obtained. A good guide for building a Business Model Canvas can be found in the guides section of Strategyzer.
1.a The Business Model Canvas
Once the Business Model Canvas (BMC) is available, let’s start thinking about the aspects of decentralization and tokenization applicable to it. In particular we evaluate the degree of decentralization of the model and any critical issues.
1.b Identification of the aspects of decentralization and tokenization in the Business Model Canvas
Box by box, we verify the conditions listed below, preferably in the order specified, which then coincides with the order of compilation of the BMC.
Value Propositions
The Value Propositions are the features that our project aims to offer to specific Customer Segments and that we have identified, after analysis and validations, and that are recognized as value generators for Customer activities.
To migrate the Value Propositions to blockchain these must be tokenizable, which means they must be virtualizable and as much as possible decentralized, depending on these constraints you can have different levels of reliability of the model and the type of usable token. In particular, tokens can be associated with purely digital assets, or with physical assets (asset-backed tokens). In this case the level of decentralization is limited.
Furthermore, the Value Propositions help to establish if the Token Model is based on an existing blockchain or needs a new one, typically specialized, and if this second blockchain is connected to an existing one. Assuming the development of a new blockchain is a very expensive option, it is therefore advisable to avoid such option unless all existing alternatives are excluded.
Questions applicable at this stage.
- Can Value Propositions be Digitized?
- Can Value Propositions be asset backed?
- Is it possible to rely on an existing blockchain or is it necessary to create a new one?
- What are the limits of existing blockchains that require the development of a dedicated blockchain?
Customer Segments
Customer segments are the types of users we have identified as interested in our value propositions.
Among the customer segments we expect to find different types of future token holders and eventual network supporters (ie those who support a possible network by making available HW resources).
Questions
- What are the benefits that each customer segment gets in being able to access a tokenized value proposition? Is it worth it for them?
- Are the customer segments identified in the BMC compatible with the token holder figure?
- Are they sufficiently digitized?
- How do they fit into the adoption of new technologies?
Channels
Channels are the access routes of Value Propositions to Customer Segments. Through tokenization, the channels with which Value Propositions can reach the Customers Segments increase. In fact, now the Customer Segments can participate in the Business Model through active participation (network support), through token exchange, through airdrop mechanisms linked to the possession of other tokens.
Questions
- On what exchanges can I list my tokens?
- How do users participate in the network and earn tokens?
- Is it possible to assume airdrops based on the possession of other tokens?
Customer Relationships
Customer Relationships are the channels through which Customers communicate with the business. With a view to relationships, token models have introduced extremely interesting decentralized governance mechanisms, based for example on the weighted vote exercised by stakeholders.
Questions
- Are Customer Segments interested in Token Model governance?
- What kind of rights can they be interested in exercising?
Revenue Streams
Revenue Streams in a tokenized business model include, in addition to the possibility (optional) of gaining tokens supporting the network, that of the revaluation of the token according to the increase of the user base, and that of the savings brought by the use of the associated service to the token.
Questions
- Can I guarantee a revenue support model based on network support? (It depends on the decentralization of the Value Proposition).
- Does the increase in adoption cause an actual increase in the value of the token?
Key Activities
These are the main activities that the business carries out to implement Value Propositions, how much they can be digitized and can be decentralized the more the business can be effective.
Questions
- Are Key Activities digitizable?
- Are Key Activities decentralized?
- How do we maximize the transparency of any Key Activities that we cannot decentralize?
Key Partners
Key Partners are companies / individuals that provide strategic services for the execution of Key Activities. With a view to tokenization, the Key Partners are the various types of users that provide network support.
Questions:
- Are the Key Partners specific user or user types?
- Is it possible to identify a generic type of user that provides network support?
Key Resources
Key Resources are the resources essential to the execution of Key Activities. In a tokenization these resources should be as fungible as possible so as to have total decentralization.
Questions
- Do I need specific resources to implement the WB?
- Are these resources fungible?
Cost Structure
Represents the structuring of the costs to be incurred to perform the Key Activities.
Questions
- How does the token economy help me to support the costs of execution?
1.c Construction of the Economy Token Canvas
In order for a Business Model to be portable on a blockchain it is necessary that the Value Propositions are at least partly decentralized, that is to say that they can be distributed in a balanced way between multiple nodes.
The following are the main questions to ask yourself when tokenizing a BM.
- What is the level of decentralization achievable by Value Propositions?
- How many features can be decentralized (and therefore reliable to users / interchangeable entities) and how many are necessarily centralised (so they can be performed by well-defined users / entities)?
- Decentralized functionalities can be expressed as a completely on-chain algorithm and assigned to interchangeable entities / systems;
- The centralised functionalities are managed by specific entities, representing a concentration point of the trust in addition to a single point of failure.
- What is the level of verifiability of the Key Activities envisaged by the BM? This is important for the following aspects:
- > auditing: all participants and observers can independently verify that each actor is operating honestly;
- > reward: the calculation of the contribution to the network and therefore of the reward can be automated, or it must be delegated to entities.
- Token functionality. The main challenges that the token (s) must solve are:
- > how to tokenize the revenue streams of the participants: ie how to distribute the economic incentive among the participants;
- > how to tokenize the operating costs of the participants: this aspect is optional, usually the costs are managed in fiat, however it should not be excluded the possibility to configure the token economy also to cover operating costs.
A tool that proves extremely effective in identifying tokenization strategies is the Token Economy Canvas. This template, similar in approach to the Business Model Canvas, identifies 9 quadrants that must be compiled according to a recommended sequence (shown in the diagram below at the bottom left), to help the user to evaluate all aspects in defining a token model.
- Let’s start with the Problem quadrant, where we identify the major problems that the token solves or the major opportunities it builds.
1.a We then identify the existing alternatives (Existing Alternatives) and for what reasons their use in the Business Model is not applicable.
2. We then move on to the Economy quadrant and describe what are the main functions that the economy of the token provides.
2.a Let ask ourselves why a blockchain is needed for the development of this specific model and what are the advantages it introduces.
3. We are now going to identify the Participants, that is the types of users of the platform. For each type of user it is advisable to identify a long-term economic incentive that creates a relationship between users and the platform. The incentives can be divided into three main categories: incentive to purchase, incentive to conservation (hodling), incentive to use. Let us remember that among the users there are combinations of:
3.a User: those who use the platform
3.b Token Holder: those who simply invest by buying tokens;
3.c Service Provider: those who support the technological infrastructure of the platform.
4. We then investigate the relationship between Participants and the Economy, through the compilation of the Governance quadrant, thus defining what kind of influence the Participants exercise on the Economy.
5. Let us now analyze the inverse relationship between Economy and Participants, in the Outside Economy quadrant. As actors and technologies outside the ecosystem in analysis they relate to our economy.
6. Token Usage: we identify in this quadrant how tokens are used to activate and sustain the economy.
7. In the Scale & Growth quadrant we identify the relationship between Problem and Economy and all the aspects that must be considered in order for the economy to scale and grow.
8. In theHealth quadrant we identify the relationship between Economy and Problem and all the indicators that allow us to verify that the economy is functional to the problem.
9. In the Token Distribution & Value quadrant we identify the initial distribution criteria of the token and what are the parameters that make the token value (Tokenomics) increase or change.
For more information on the Token Economy Canvas it is suggested to refer http://tokencanvas.it.
Example — Storage Token
For greater clarity we try to decline the method on an example: we perform the analysis of a generic token for decentralized data storage like those proposed in projects like FileCoin and StoreJ.
Problem
wants to have a decentralized infrastructure for file storage activated by a token utility that provides the following advantages:
- non censurable
- resilient
- low cost.
Existing Alternatives
Centralized cloud storage systems controlled by the big IT players.
Costly private storage solutions replicated according to disaster recovery criteria.
Economy
A decentralized P2P architecture is defined based on a storage token that allows a specific amount of data to be stored in the infrastructure for a defined period of time.
Why Blockchain
Because it provides a resilient and non-reprehensible solution, because it allows, through a permissionless participation mechanism, to reduce service costs.
Participants
Storage Providers, those who offer storage.
Data Producer, which are divided into subcategories:
- individuals who want to take advantage of a resilient, non-reprehensible and low-cost service;
- companies that want to enjoy a resilient, non-reprehensible and low-cost service.
Token Holder: speculators who simply want to contribute to the project and earn in a passive manner by purchasing significant amounts of tokens by betting on a re-pricing.
Incentives
- Storage Provider: possibility to monetize with HW commodities.
- Data Producer: non-censorship of the infrastructure, low cost.
- Token Holder: investment diversification.
Governance
Stakeholders can exercise weighted voting rights to change network parameters, such as the persistence time of the data.
Outside Economy
Incumbents in cloud storage could use the service to reduce their internal costs or contribute to the service to monetize.
Token Usage
Data Producers purchase storage tokens and use them to pay Volume Provider Storage. Storage Providers resell the token via exchange to liquidate their assets to Data Producers.
Scale & Growth
What happens if tokens run out: tokens held by Storage Providers are put back on the market to finance operating costs, the greater the data offer from Data Producers, the higher the price of the exchange token, the greater the willingness of token holders and storage providers to sell them.
What happens when users increase: users increase the price of the token and therefore the economic circle.
Health
The system can be considered healthy if the growth of the user base does not lead to a growth of the token velocity at the expense of the market cap which, as discussed in the section Tokens on Velocity Token, must be contrasted or balanced by an increase in the value of the token.
Further readings
Evaluating Blockchain Projects With Token Economy Canvas
1.1 Token user profile
As discussed in Understanding Token User Profiles, we agree that the correct and complete identification of the Personas involved in the Token Model (in the Token Economy Canvas in step 3) is one of the most delicate steps in compiling the external quadrant, that is, the one dealing with the relationship between the token economy and its participants. Interesting to understand for each Personas, its quadrant of belonging (Token Investor, Token Adopter, Token Atheist, Token Instant User).
In particular it is necessary to make sure that the problem and the economy go to attract mainly Token Investor and Token Adopter, which are those that guarantee a healthy support to the project.
2 Token Mechanics
The Token Mechanics is the description of the creation, handling, exchange and potentially destruction (burn) flows of one or more tokens. They explain how tokens relate to the types of users who manage them and with internal and external BM services.
In the figure below, a classic scenario of issuing tokens through the primary market and subsequent activation of a secondary market on exchange.
Another extremely useful analysis to model the Token Mechanics consists in the realization of an interaction diagram between all the parts interested in the Business Model.
As an example, in the figure below, the main actors participating in the centralized Business Model of Uber (Passengers, Drivers and Future Passengers) and related interactions are reported.
For more examples of business model interaction diagrams of known companies, you can visit https://www.boardofinnovation.com/guides/50-business-model-examples.
In general, an interaction diagram of a centralized Business Model is an object like the one in the following figure, in which we have in a central position the Company that implements the business, and a series of actors (companies and consumers) that interact with the Company and between them, through a relationship of supply of products / services (provides) in exchange for rewards of various nature (generally economic).
Starting from an interaction diagram like this it is possible to formalize some features that the token (s) can implement in the decentralized version. It is important to note that in the decentralized version there are also relationships between the peers that constitute the platform of the (semi) decentralized business.
In the next diagram we see how the scenario of the previous figure evolves, in a decentralized approach: in this case the various actors no longer relate to the Company (or at least only with it), but relate above all to a network of peers that builds the decentralized business. It is interesting to note that incentives are now defined that operate in the relationship between nodes.
In the event that the Company remains present, providing even partial features to the platform then we have a semi-decentralized solution, if it is possible to implement a platform in which the Company completely disappears we speak of fully decentralized solution.
Taking up the figure Uber Business Model Interaction Diagram, in the decentralized and tokenized version of a hypothetical UberChain, the trips and commissions could be modeled with a stablecoin, the vouchers could be tokenized and made freely interchangeable between users, the trust could also be tokenized and reputation could be modeled with tokens.
Token Sales Anatomy
Token Sales defines all strategies for placing a token on the market through direct sales or exchanges. The direct sale made by the Company constitutes the primary market, the subsequent sales transactions made by the stakeholders constitute the so-called secondary market.
In this step, the actual funding plan is drawn up. The main inputs to plan the campaign are the soft and hard cap, ie the minimum and maximum collection target. The minimum objective must always be specified in order to stand out as a reliable initiative, the maximum objective can also be avoided, but incremental milestones should be described in terms of product functionality. Finally, the management policy for unsold tokens at the end of token issuance is declared, which for utility tokens generally provides for destruction, while for security, subsequent sales are expected.
The token sales policy is then decided. The simplest token sales mechanism includes fixed exchange sales, discounted prices are set for private sales (investors) and pre-sales (by invitation) and a standard price for the public. Then, bands of price increases can be introduced at set times to generate a sense of urgency.
Other more complex mechanics instead provide the auction mechanisms of the fiat world with some famous variants like Dutch Auction (reverse Dutch auction), where it starts from a cap expressed in fiat and the number of tokens issued depends on the total duration of the sales token. It opens with a base price that drops as new blocks are mined in the token reference chain (substrate), while the price falls meets the target costs of the various buyers until the total capital is reached.
An alternative to the Dutch Auction is the Vickrey Auction, which makes secret bids for a batch of tokens and assigns the batch to the highest bidder at the second highest price. An interesting discussion of which sales token technique to use depending on the type of investor you want to reach can be found in this interesting article by Reuben Bramanathan: The perfect token sale structure.
In addition, in the article Economic Dynamics of an ICO, the relationship between market value and issuance strategy of token utilities is analyzed.
To conclude, it can often be useful to retrieve sales token information concluded for auditing, evaluations and projections of us scenarios. A technical article showing how to retrieve this information can be found here. This article describes the use of the bloxy.info web tool, which allows you to analyze transactions towards a Smart Contract issuing an arbitrary token.
3 Token Legal Review
The first thing to check in the legal review is the type of token. A token can be classified as (crypto) currency, utility or security or a combination of these.
- Currency: they are the most well-known and widespread tokens, the main example being Bitcoins, they carry an intrinsic value that is established by the market.
- Utility: these are tokens that enable owners to use the services provided by a (semi) decentralized platform. An example is Ethereum, which in addition to being a cryptocurrency is also a token utility that allows access to the decentralized computing service of the eponymous network.
- Security: are tokens that guarantee annuity rights (and governance in the case of equity) on the proceeds of a (semi) decentralized business.
Utility vs Security
2017 was characterized by the ICO capitalization boom, however many tokens distributed as utilities behaved like security, whose issuance is strongly regulated and requires licenses for marketing, going to break the regulatory policies of many countries in which they were distributed.
In order to verify the correct nature of the token being issued, a simple verification tool called Howey Test is used.
The Howey Test was introduced by the SEC (USA), but the criterion can be considered valid also in other jurisdictions. It is used to verify that our token issue is an ICO (issuance utility token) or an STO (security token issue).
The test is divided into the following questions:
- Are we making an investment of money?
- Is our investment in a joint venture?
- Do we have profit expectations?
- Is this profit generated by the effort of others?
If we get to the fourth question with an affirmative answer, we are dealing with a security tool.
GDPR compliance
Many experts consider GDPR and blockchain as deeply incompatible issues, since the former wants to provide a legal guarantee framework for the processing and storage of sensitive data, related to natural persons, in particular on aspects of the right to rectification and cancellation , while the second focuses on the immutability of the data itself.
I personally believe that with the right approach, GDPR and blockchain can co-exist profitably. The only care that must be used in the use of public DLT technologies (and therefore immutable) for the storage of sensitive data, consists in avoiding storing raw data containing sensitive information on blockchain. Sensitive data should be persisted on centralized storage, on blockchain only cryptographic signatures corresponding to such sensitive data should be deposited. In this way the information remains however immutable, timestamped and verifiable, but only after access (controlled) to the original data, which can in this case be rectified or eliminated, even if in this case the ability to verify through the corresponding signature is invalidated on blockchain.
4 The Token Valuation Canvas
A Token Valuation Canvas is a tool to perform the evaluation of an existing token or a design (self-assessment). There are several evaluation canvases, below there is a sufficiently complete one, which despite being designed for ICOs can easily be applied also to STOs.
The canvas leads us to validate the basic aspects of the token as type, role and supply, then the legal status (see previous section), the activity of the developer community, the evaluation of the overall team. The same canvas then leads us to examine / validate the network effect that the token is able to develop, for all the token cases (currency, utility, to be included in the evaluation also security).
Some non-functional aspects such as safety and resilience are then investigated. Finally, various considerations related to market analysis, validation of the development roadmap, expected traffic hypotheses and the analysis of dissemination contents such as the whitepaper are suggested.
Beyond the Token Model Token
Considerations on Token Velocity
The enthusiasm that involves those approaching the world of tokenization for the first time, both as an investor and as a business proposer, it often leads to neglecting aspects of performance on the Business Model linked to the token velocity, that is to the number of times that in the unit of time a token passes from the owner (and therefore is bought, sold, used ). This aspect, however, is not lost on professional investors, who are usually asked for an account.
Indeed, velocity entails risks for all those token economies which provide for the issuance of a single token as a medium of exchange for a single generally limited resource, since it introduces a misalignment in incentives.
In general, at least in the first phase of building a tokenized project, it is important to introduce incentives to ensure that the token velocity remains low.
In particular, many experts agree that the Token Economy is governed by the following equation, adapted from the reformulation of the known exchange equation of classical macroeconomics:
MV = PQ
where
M = size of the basic token (or market cap)
V = token velocity, number of times that a token is used
P = price of the unitary digital resource (in fiat)
Q = quantity of unitary resource produced (computation, storage, etc.)
The product PQ can also be expressed as the total value of the volume of transactions made, or TotalTransactionVolume (generally in fiat), while M is interpreted as the total value of the network or NetworkValue.
So
V = PQ / M = TotalTransactionVolume / NetworkValue
for which
NetworkValue = TotalTransactionVolume / V
So the NetworkValue grows, assuming the invariance of TotalTransactionVolume, in inversely proportional way to the speed V of the token.
So to avoid a decrease of the NetworkValue there are the following options:
- avoiding the growth of V and therefore encouraging the immobility of the token, the Proof of Stake or reward on immobilized stakes are very useful in this regard, however this solution is not always implementable especially in cases of success and therefore increase in the user base of the token;
- make a counterbalance by introducing mechanisms that increase the TotalTransactionVolume and therefore the product PQ, thus increasing the value of the token (P) or the amount of resources associated with the circulating tokens (Q).
Insights
https://hackernoon.com/token-velocity-a455173d69e3
Curation Markets
Curation Markets are token models designed to reduce information asymmetry in a market by allowing token holders to bet on certain options. This approach facilitates the formation of collaborative groups and their coordination, aimed at creating value around a shared resource, building a profit mechanism around a set of common objectives.
These markets work by attributing value to an idea, a concept, an initiative, and can be extremely effective for the tokenization of non-profit models or open source models.
The Curation Market can in turn use advanced tokenization techniques such as Continuous Token Models and Dynamic Bounding Curves.
Application examples of Curation Market
- Monetization of Open Source models, allowing participants to focus on the development of the next features and provide / develop this implementation.
- Data / Content Curation: allowing actors to bet on a certain topic to be enriched and paying the contributors according to their effort.
- Attention Market: allowing publisher actors to focus on a sponsored topic and guaranteeing a reward to distributors and consumers of this content.
Insights
Introducing Curation Markets
More about Curation Markets and Curved Bounding
https://medium.com / @ simondlr / curation-markets-curved-bonding-update-02-april-2018–87c593d629c2
Continuous Multi-Party Decentralized Issuance Tokenized Funding
Dynamic Token Bonding Curves
https://tokeneconomy.co/dynamic-token-bonding-curves-41d36e43befa
Token Engineering
As well introduced by the article Towards a Practice of Token Engineering the design of a token and a supporting ecosystem involves different orthogonal disciplines: from economics to game theory to linear optimization.
This article discusses the use of formal methods for an engineering approach in the construction of a Token Model. We start from the analysis of the incentives among the participants using the Game Theory, to then arrive at the identification of the mechanics of the tokenized system with the relative identification of functional constraints. Finally, optimization techniques are used (Optimization Design) to arrive at the identification of practices and tools that can be used both during the validation of the requirements and in the implementation of the models.
FOSS and Blockchain
The creation of Business Models on open source projects have already been successfully explored, although I believe that the real potential for innovation in the combination of these two disciplines has not yet reached its maximum.
FOSS (Free Open Source Software) is the classic Business Model set that accompanies companies involved in the development of Open Source platforms (OS). In the FOSS Business Models a relationship is created between companies, which cooperate in the development of complex common Open Source platforms, while remaining in many cases in competition with customers. Usually the various companies then develop a closed proprietary layer on the core OS and on this base their own differentiation and competitive capacity.
The FOSS model lends itself very well to implementing the Permissionless Blockchain Business Model (PBBM), in this model the boundaries between private, companies, customers and investors become completely liquid, moreover the cooperation between companies is not limited to the development of the technological platform, but it can also lead to the coordination of financial strategies, aimed at increasing the value of the underlying tokens. In fact in a PBBM model the contributor companies are also stakeholders, and can therefore exercise the (programmatic) voting right to modify aspects of the economy of the platform token, such as the minting rate.
The following table shows the main players and tasks compared between the classic FOSS model and the innovative PBBM model.
Application Modules
The implementation of the Key Activities of a business model enabled by blockchain will lead to the development of an application, partially or totally decentralized, which will allow interaction with the business itself. This application will consist of several functional modules, some off-chain, existing on centralised servers, others on-chain, able to run on a decentralized network.
Examples of off-chain modules:
- Explorer module: a module that lets you see assets and related metadata at a higher level (ie with a simplified UX) than you could do with a standard Blockchain Explorer.
- Payment module: crypto / fiat payment module for the purchase of tokens at the primary sale stage.
- Stats module: production module for sales / pricing / token exchange statistics.
- User module: module for managing the user’s private profile, with possible custodian features, management of decentralized governance.
- Admin module: administrative module for checking token status and managing campaign parameters, centralised governance.
Examples of on-chain modules:
- Various Smart Contracts for token management.
- Dapp: web app distributed on decentralized storage that uses the substrate as a backend.
Today, various off-the-shelf solutions are available, both commercial and Open Source, which already provide the main on-chain and off-chain modules necessary for the implementation of a decentralized project, which only require the development of the token model or which provide some token model that implement predefined strategies.
An example among all the Open Source platforms, among the most complete and modular for the realization of distributed organizations that is worth mentioning is certainly Aragon. Instead, to have an example of a specialized proprietary platform for accessing alternative financing by issuing tokens, you can look at Harbor or Polymath.
In general, to simplify the development of some of these aspects, a tokenization stack can be used.
The tokenization stack
The tokenization stack represents the technological substrate supporting a tokenization. The correct selection of the substrate is an indispensable step for the operation of the tokenized Business Model. The main aspects to consider when selecting a stack are:
- Safety: the substrate is sufficiently secure for the type of token to be implemented;
- Expressiveness: the substrate allows to implement all the functionalities necessary for the Business Model, guaranteeing the right level of decentralization (on-chain).
- Scalability: the substrate is sufficiently scalable to support the activities of the user base, considering the growth projections of this base, also keeping the transaction costs under control.
In particular in considering scalability there are the following aspects to consider:
- Fee Cost: how the transaction fees impact and how they can be mitigated;
- Transaction Confirmation Time: how the confirmation times impact the UX and the Business Model;
- Transaction Throughput: how the bandwidth of the network impacts the scalability of the Business Model.
A tokenization stack, in addition to the token attributes discussed in the previous section, can also include the following layers:
- Compliance Platform: provides all aspects of compliance (AML / KYC) to speed up and make investments safer.
- Exchange Protocol: defines a standard for the secondary market.
- Exchange Platform: provides an engine and a user experience for the secondary market.
Thanks!
If you’ve made it this far, you’ve probably enjoyed my article. Why don’t you leave me feedback, like a comment or applause? If you’re new to Medium, you probably won’t know that a click on the applause button is only worth 1/50 of the top grade.
Further readings
How to Build an ICO / STO
https://medium.com/@hardest/come-costruire-una-ico-sto-ff6fb36c5f43
TokenWork: Introducing the Token Utility Canvas
https://media.consensys.net / tokenwork-introducing-the-token-utility-canvas-tuc-9a1f32979dc0
What is an Asset-Backed Token? A Complete Guide to Security Token Assets
Mapping business opportunities in The Era of Tokenization
Meet the first companies tokenizing their equity on Blockchain
Exchanges for Security Tokens: Which STO Exchanges do Already Exist? Which Follow Soon?
