Come Tokenizzare un Business Model

Vedi tutti i miei articoli.

Introduzione

Questo articolo fornisce delle linee guida generali per aiutare imprenditori e tecnici ad orientarsi nel processo, ancora non completamente formalizzato, di tokenizzazione di un Business Model.

Esistono diversi approcci alla tokenizzazione, il più semplice prevede di tokenizzare alcuni aspetti di un Business Model al fine di decentralizzarne una parte (semi-decentralized), principalmente allo scopo di renderlo più accessibile, flessibile, trasparente ed economico (in seguito entreremo in dettaglio nei vantaggi della tokenizzazione). Questo è il caso di emissione di security token (STO), in cui si parcellizza il possesso del business, o di utility token (ICO/IEO e varianti) in cui si parcellizzano le risorse prodotte dal business. Nei casi più complessi invece si costruisce o si trasporta un business su un’infrastruttura completamente decentralizzata (fully-decentralized), in questo caso l’azienda o il gruppo promotore dell’iniziativa, si limita a possedere una quota dei token in circolazione che abilitano il business, ma tende a cedere nel tempo la governance esclusiva dell’iniziativa, a favore di un nuovo mercato di stakeholder, ottenendo quello che grossolanamente può essere assimilato ad una quotazione azionaria.

Come è organizzato l’articolo.

• Cos’e’ un Business Model: si fornisce uno strumento per indagare e rappresentare un business nei suoi aspetti qualitativi fondamentali, nelle relazioni fra questi aspetti e negli attributi principali.
• Cos’e’ un Token Model: si fornisce uno strumento per indagare e modellare qualitativamente gli aspetti principali dell’economia di un token.
• Quali sono i vantaggi della tokenizzazione: si esaminano i vantaggi fondamentali nella tokenizzazione di un Business Model.
• Quanto tokenizzare un Business Model: dei criteri per valutare se la tokenizzazione di un Business Model può fornire dei vantaggi effettivi.
• Come tokenizzare un Business Model: si forniscono delle linee guida sul processo di tokenizzazione di un business model esistente o la creazione di uno completamente nuovo.
• Oltre il Token Model: si introducono alcuni aspetti che vanno presi in considerazione per pianificare le strategie operative e progettare la piattaforma che ospiterà il Token Model.

Cos’è un Business Model

Un Business Model è la serie di strategie implementate da un’azienda per generare profitto, realizzando un prodotto o un servizio e vendendolo a specifiche tipologie di utenti. Questo prodotto / servizio è realizzato implementato una serie di attività, con risorse interne e grazie a partnership esterne. Queste attività mirano alla produzione ed erogazione verso l’esterno di prodotti o servizi che possono essere destinati ad utenti finali (B2C), ad altre aziende (B2B) o ad una combinazione di questi.

Un Business Model si basa sulla realizzazione di una o più Value Proposition, ossia la generazione di valore per i Clienti, tale valore viene realizzato attraverso la risoluzione di problemi o il soddisfacimento di necessità.

Un Business Model fa parte di un Business Plan, che contiene anche tutti i dettagli relativi alla all’analisi del mercato e dei competitor, la strategia complessiva come il la pianificazione temporale e finanziaria, la strategia di marketing e tutti gli altri aspetti rilevanti del progetto aziendale.

Il Business Model Canvas

Il Business Model Canvas è un template per la rappresentazione dei tratti essenziali di un Business Model ideato da Alexander Osterwalder, e risulta essere uno strumento molto efficace per costruire, validare o tracciare un Business Model.

Il Business Model Canvas è organizzato in 9 quadranti, divisi un due macro aree, il Front Stage costituito da tutti i quadranti sopra al Revenue Streams ed il Back Stage costituito da tutti i quadranti sopra al Cost Structure, la Value Propositions è inclusa in entrambe le macro aree.

Di seguito la lista dei quadranti elencati per ordine suggerito di compilazione:

1. Value Propositions: l’offerta di business in termini di prodotti o servizi che risolvono problemi o soddisfano necessità dei Customer.
2. Customer Segments: le tipologie di customer per cui le Value Propositions sono state identificate.
3. Channels: i canali con cui i prodotti o servizi vengono distribuiti ai Customer.
4. Customer Relationships: i canali che usano i Customer per comunicare con l’azienda ed ottenere feedback e supporto.
5. Revenue Streams: I metodi usati per monetizzare i prodotti o servizi offerti.
6. Key Activities: le attività che devono essere predisposte per realizzare le Value Propositions.
7. Key Resources: le risorse necessarie per realizzare le Key Activities.
8. Key Partners: i partner strategici per realizzare le Key Activities.
9. Cost Structure: tutte le voci di costo per realizzare le Key Activities.

Credits: Strategyzer

Per maggiori dettagli sull’utilizzo del Business Model Canvas si consiglia di consultare la guida ufficiale di Strategyzer.

Cos’è un Token Model

Un Token Model descrive le proprietà di un token, la natura degli utenti e dei servizi che interagiscono con tale token e le caratteristiche economiche di tali interazioni, di fatto rappresenta un intero ecosistema economico e tecnologico. Un Token Model definisce inoltre lo scopo del token, la sua utilità e la modalità di creazione, distribuzione ed eventuale distruzione (token lifecycle). Il Token Model è parte fondamentale di un Business Model tokenizzato.

Il Token Model è caratterizzato da due aspetti principali:

• Attributi: assia la piattaforma e la configurazione del token;
• Token Flow: ossia le interazioni che il Token compie con i Token Holder, gli Exchange ed il substrate, e che costituiscono la sua economia.

Attributi di un Token

In questa sezione riportiamo gli attributi più rilevanti per la definizione di un token e del suo modello operativo:

• substrate: la piattaforma decentralizzata che ospita il token (es. Bitcoin, Ethereum);
• system: eventuale sotto sistema di gestione del token all’interno del substrato (es ERC20, ERC721), determinano inoltre aspetti come:
• fungibility: definisce l’equivalenza o meno dei singoli token e quindi possibilità di scambiare parità di volume a parità di prezzo, questo criterio è connesso al system;
• transferability: la possibilità di trasferire token da un indirizzo all’altro senza autorizzazioni;
• role: il ruolo funzionale del token. I ruoli funzionali possono essere attivo o passivo;
• passive token: un qualsiasi token che rappresenta un valore, può essere una currency (Bitcoin), una utility (Ethereum) o una security;
• active token: dei token che attivano delle funzionalità come l’accesso ad una smart property o delle funzionalità specifiche di servizio;
• payload: un token può essere associato ad un asset fisico o digitale esterno con un valore predefinito, ad esempio fiat currency, metalli preziosi, materie prime;
• supply: può essere limitata o illimitata, determina la politica monetaria del token e dipende dal Business Model che si va ad implementare, specifica quanti token verranno generati e secondo quale criterio, attraverso un algoritmo definito nello smart contract o tramite l’esercizio della governance dei token holder;
• flow: il token flow model descrive il lifecycle dei token, di solito si hanno i seguenti modelli:
• > straight line: il token viene creato, assegnato al destinatario, usato e distrutto;
• > chip model: viene usato con un servizio exchange per la conversione in altri token / fiat e viceversa;
• > circular: viene usato come una currency;
• divisibility: rappresenta la divisibilità del token, quando applicabile, ossia il numero di cifre dopo la virgola che devono essere supportate (es: 6 decimali), particolarmente importante che sia alta per i token con limited supply;
• source: ossia la disponibilità del codice sorgente dello Smart Contract che regola il token. Può essere open o closed, sebbene ci siano ancora dei progetti con token closed source, riteniamo che questa pratica contrasti con i concetti di auditability e trustless alla base di una token economy affidabile e quindi sia assolutamente da evitare.

Classificazione del Token

Altri gruppi di ricerca hanno definito dei validi framework di classificazione per i token, al fine di valutarne e validarne gli aspetti principali. Fra questi citiamo il Token Classification Framework di Untitled Inc, che rispetto al nostro metodo utilizza un numero ridotto dei parametri (dimensioni) di un token, fornendo una vista semplificata.

Credits: Token Classification Framework

Quali sono i vantaggi della tokenizzazione

Un Business Model può essere decentralizzato e quindi implementato su blockchain, attraverso tecniche di tokenizzazione, se almeno parte delle Key Activities che prevede, come vedremo meglio in seguito, sono eseguibili e verificabili con un protocollo digitale decentralizzabile.

La tokenizzazione di un Business Model consente di:

• Introdurre dei token che promuovano l’utilizzo del business e creino degli incentivi economici a sostegno;
• dividere le feature funzionali del business tra più entità preferibilmente ridondate e permissionless per per aumentare la reliability del progetto.

I vantaggi della tokenizzazione in asset riconducibili ad utility e security sono i seguenti:

• Liquidity
• > Velocizzazione (e potenzialmente utilizzabilità) delle operazioni.
• > Accesso ai mercati 24/7/365.
• > Accesso a un bacino di investitori borderless.
• > Fractionalisation: la tokenizzazione ed il mercato secondario abilitano scenari di micro-ownership con ricadute potenzialmente positive sul brand awareness.
• Efficiency
• > Maggiore valore percepito: maggiore liquidità significa minori costi di exit e quindi maggiore evaluation a parità di value proposition.
• > Riduzione dei costi di intermediazione.
• > Riduzione dei tempi di intermediazione.
• > Programmabilità dei token con attribuzione di reward a fronte di comportamenti virtuosi per gli stakeholder.
• Transparency
• > Possibilità per tutti gli stakeholder di effettuare auditing di tutti gli aspetti della piattaforma.

L’ecosistema dei Tokenized Asset

Le opportunità di business con l’avvento della tokenizzazione impatteranno soprattutto i servizi finanziari tradizionali, cambiandone completamente il paradigma. Affinchè però tutto questo sia realizzabile, sono necessari una serie di layer incrementali come:

1. un layer tecnologico blockchain, in grado di fornire scalabilità ed economicità delle operazioni, pur mantenendo un ragionevole livello di decentralizzazione;
2. un layer regolatorio preferibilmente internazionale in grado di fornire armonizzazione giuridica e garanzie;
3. un layer fiscale e legale basato sul precedente in grado di operare senza frizioni ed incertezze;
4. un layer di garanzia che renda sicuro l’utilizzo di una tecnologia che supporta transazioni irreversibili e possibilmente operatori anonimi.

Credits: Finoa

Valutare se un Business Model può essere tokenizzato

Non tutti i Business Model si prestano ad essere tokenizzati, dei metodi per valutare la tokenizzabilità di un business sono in corso di studio. Al momento si puó fare affidamento su una serie di domande, come le seguenti.

• Il tuo BM può essere / è stato già realizzato senza Blockchain?
• Le Key Activities che caratterizzano la tua Value Proposition possono essere decentralizzate, almeno parzialmente?
• La tokenizzazione del tuo Business Model ha dei vantaggi reali intermini di adoption e market size?
• Hai bisogno di condividere uno stato consistente tra entità differenti?
• È possibile trovare un incentivo economico per consentire a queste entità di collaborare?
• L’incentivo economico è valido anche per partecipanti anonimi?
• Hai bisogno di verificabilità legale?
• Hai bisogno di requisiti stringenti di performance o di privacy?

Per un’analisi delle risposte ed una trattazione più estesa dell’argomento si suggerisce di consultare questo articolo.

Quando tokenizzare un Business Model

Ho bisogno di tokenizzare?

Il fatto che che un Business Model sia tokenizzabile non significa che sia conveniente. Alcune considerazioni rispetto ai vantaggi della tokenizzazione:

• lo scopo della tokenizzazione è accedere ad un mercato globale e fornire ai propri stakeholder liquidità sul mercato secondario. Se una di queste due condizioni fosse stata scartata in fase di definizione del progetto, verrebbe meno l’utilità della tokenizzazione;
• Il processo di tokenizzazione ha un costo, in alcune giurisdizioni al momento ottenere le licenze necessarie può costare fino a ~1M USD, va quindi valutato il rapporto costi/benefici.

Limitazioni giuridiche

Il panorama regolatorio internazionale si sta evolvendo rapidamente ma è difficile fare previsioni. I punti principali sono la possibilità legale di attivare un mercato primario (vendita al pubblico di securities) e la possibilità di attivare un mercato secondario (ossia disponibilità di operatori/exchange abilitati alla detenzione di securities conto terzi). Mentre molte giurisdizioni autorizzano già il mercato primario senza particolari riserve, per il secondario al momento mancano le autorizzazioni per gli operatori in molti mercati internazionali, che come soluzione alternativa stanno sperimentando l’utilizzo di decentralized exchange (DEX) combinato spesso con l’uso di un payload per il token che rappresenta delle partecipazioni al portatore garantite da una banca, piuttosto che direttamente securities.

Nella prossima sezione viene descritto il processo che può essere utilizzato sia per la costruzione di un Business Model tokenizzato, sia per la sua valutazione/verifica.

Come tokenizzare un Business Model

Il metodo che viene suggerito per la tokenizzazione di un Business Model richiede di partire dall’analisi del Business Model Canvas associato. Il Business Model di partenza può essere:

• convenzionale: ossia è possibile implementarlo senza tokenizzazione ma con la tokenizzazione si amplificano le possibilità;
• token nativo: ossia può essere implementabile esclusivamente con un modello tokenizzato.

A partire dal Business Model Canvas, i passaggi per la costruzione del Token Model sono dettagliati nelle sezioni seguenti.

1. Definizione della Token Economy

> a. Costruzione del Business Model Canvas

> b. Identificazione degli aspetti di decentralizzazione e tokenizzazione nel Business Model Canvas

> c. Costruzione del Token Economy Canvas

2. Definizione della Token Mechanics

> a. Identificazione degli attori e dei flussi del token

3. Token Legal Review

4. Il Token Valuation Canvas

The tokenization and evaluation flow

1. Definizione della Token Economy

Il primo passo per costruire la Token Economy richiede di partire dal Business Model Canvas del progetto in oggetto, se non esiste va ricavato.

Una buona guida per la costruzione di un Business Model Canvas può essere trovata nella sezione guides di Strategyzer.

1.a Il Business Model Canvas

Una volta disponibile il Business Model Canvas, iniziamo a ragionare sugli aspetti di decentralizzazione e tokenizzazione applicabili su di esso. In particolare valutiamo il livello di decentrabilità del modello ed eventuali criticità.

1.b Identificazione degli aspetti di decentralizzazione e tokenizzazione nel Business Model Canvas

Casella per casella, verifichiamo le condizioni riportate di seguito, preferibilmente nell’ordine specificato, che poi coincide con l’ordine di compilazione del BMC.

Value Propositions

Le Value Propositions sono le feature che il nostro progetto si pone di offrire a specifici Customer Segments e che abbiamo individuato, dopo analisi e validazioni, e che sono riconosciute come generatori di valore per le attività dei Customer.

Per migrare le Value Proposition su blockchain queste devono essere tokenizzabili, ossia devono essere virtualizzabili e quanto più possibile decentralizzabili, in funzione di questi vincoli si possono avere diversi livelli di attendibilità del modello e della tipologia di token utilizzabile. In particolare i token possono essere associati a beni puramente digitali, oppure a degli asset fisici (asset-backed tokens). In tal caso il livello di decentralizzazione è limitato.

Inoltre le Value Proposition aiutano a stabilire se il Token Model poggia su una blockchain esistente o necessita di una nuova, tipicamente specializzata, e se questa seconda blockchain e collegata ad una esistente. Ipotizzare lo sviluppo di una nuova blockchain è un’opzione molto costosa, si consiglia quindi di evitare tale assunzione a meno che non si siano escluse tutte le alternative esistenti.

Domande applicabili in questa fase.

• Le Value Propositions possono essere digitalizzate?
• > Le Value Propositions possono essere asset backed?
• È possibile appoggiarsi ad una blockchain esistente o è necessario crearne una nuova?
• > Quali sono i limiti delle blockchain esistenti che richiedono lo sviluppo di una blockchain dedicata?

Customer Segments

I customer segments sono le tipologie di utenti che abbiamo identificato come interessati alle nostre value proposition.

Tra i customer segment ci aspettiamo di trovare diverse tipologie di futuri token holders e ed eventuali network supporter (ossia coloro che supportano una eventuale rete mettendo a disposizione risorse HW).

Domande:

• Quali sono i benefici che ottiene ogni customer segment nel poter accedere ad una value proposition tokenizzata? Vale la pena per loro?
• I customer segment individuati nel BMC sono compatibili con la figura di token holder?
• > Sono sufficientemente digitalizzati?
• > Come si collocano nel grado di adoption di nuove tecnologie?

Channels

I Channel sono le vie di accesso delle Value Propositions verso i Customer Segments. Attraverso la tokenizzazione, i Channel con cui le Value Propositions possono raggiungere i Customers Segments aumentano. Infatti adesso i Customer Segments possono partecipare al Business Model attraverso la partecipazione attiva (network support), attraverso i token exchange, attraverso meccanismi di airdrop legati al possesso di altri token.

Domande:

• Su quali exchange posso quotare i miei token?
• Come fanno gli utenti a partecipare al network e a guadagnare token?
• È possibile ipotizzare degli airdrop che poggiano sul possesso di altri token?

Customer Relationships

Le Customer Relationships sono i canali attraverso i quali i Customer comunicano con il business. In ottica relationships i token model hanno introdotto meccanismi estremamente interessanti di governance decentralizzata, basata ad esempio sul voto pesato esercitato dagli stakeholder.

Domande:

• I Customer Segments sono interessati alla governance del Token Model?
• > Che tipo di diritti possono essere interessati ad esercitare?

Revenue Streams

Le Revenue Streams in un business model tokenizzato includono, oltre alla possibilità (opzionale) di guadagnare token supportando il network, quella della rivalutazione del token in funzione dell’aumento della user base, e quella del risparmio portato dall’utilizzo del servizio associato al token.

Domande:

• Posso garantire un modello di revenue basato sul network support? (Dipende dalla decentrabilità delle Value Proposition).
• L’aumento della adoption causa un effettivo aumento del valore del token?

Key Activities

Sono le attività principali che svolge il business per implementare le Value Propositions, quanto sono più digitalizzabili e decentralizzabili tanto più il business può essere efficace.

Domande:

• Le Key Activities sono digitalizzabili?
• Le Key Activities sono decentralizzabili?
• Come massimizziamo la trasparenza di eventuali Key Activities che non possiamo decentralizzare?

Key Partners

I Key Partners sono le aziende / privati che forniscono servizi strategici all’esecuzione delle Key Activities. In ottica di tokenizzazione i Key Partners sono le varie tipologie di utenti che forniscono network support.

Domande:

• I Key Partners sono delle tipologie di utenti o degli utenti specifici?
• È possibile identificare una tipologia generica di user che fornisce network support?

Key Resources

Le Key Resources sono le risorse indispensabili all’esecuzione delle Key Activities. In una tokenizzazione queste risorse dovrebbero essere il più possibile fungibili in modo da avere una totale decentralizzazione.

Domande:

• Ho bisogno di risorse specifiche per implementare il BM?
• Tali risorse sono fungibili?

Cost Structure

Rappresenta la strutturazione dei costi da sostenere per eseguire le Key Activities.

Domande:

• Come mi aiuta la token economy per sostenere i costi di esecuzione?

1.c Costruzione del Token Economy Canvas

Affinché un Business Model sia portabile su blockchain è necessario che le Value Propositions siano almeno in parte decentralizzabili, ossia distribuibili in no modo bilanciato tra più nodi.

Di seguito le principali domande da porsi quando si tokenizza un BM.

• Qual’e’ il livello di decentralizzazione raggiungibile dalle Value Propositions?
• > Quante funzionalità sono decentralizzabili (e quindi affidabili ad utenti/entità intercambiabile) e quante sono necessariamente centralizzate (quindi possono essere svolte da utenti/entità ben definite)?
• > > Le funzionalità decentralizzabili possono essere espresse come un algoritmo completamente on chain ed assegnate ad entità/sistemi intercambiabili;
• > > Le funzionalità centralizzabili vengono gestite da entità specifiche, e rappresentanto un punto di concentrazione del trust oltre ad un single point of failure.
• Qual’e’ il livello di verificabilita’ delle Key Activities previste dal BM? Questo è importante per gli aspetti di
• > auditing: tutti i partecipanti e gli osservatori possono verificare indipendentemente che ogni attore sta operando in modo onesto;
• > reward: il calcolo della contribuzione al network e quindi del reward può essere automatizzato, oppure deve essere delegato a entità.
• Funzionalità del token. Le sfide principali che deve risolvere il/i token sono:
• > come tokenizzare le revenue stream dei partecipanti: ossia come distribuire l’incentivo economico fra i partecipanti;
• > come tokenizzare i costi di operatività dei partecipanti: questo aspetto è opzionale, di solito i costi sono gestiti in fiat, tuttavia non va esclusa la possibilità di configurare la token economy anche per coprire i costi operativi.

Uno strumento che rivela estremamente efficace nell’identificazione di strategie di tokenizzazione è il Token Economy Canvas. Questo template, simile come approccio al Business Model Canvas, identifica 9 quadranti che vanno compilati secondo una sequenza consigliata (riportata nello schema in basso a sinistra), per aiutare l’utilizzatore a valutare tutti gli aspetti nella definizione un token model.

1. Iniziamo con il quadrante Problem, dove identifichiamo i maggiori problemi che il token risolve o le maggiori opportunità che costruisce.

> a. Identifichiamo poi le alternative esistenti (Existing Alternatives) e per quali motivi il loro utilizzo nel Business Model non è applicabile.

2. Passiamo poi al quadrante Economy e descriviamo quali sono le funzioni principali che l’economia del token fornisce.

> a. Chiediamoci anche perchè per lo sviluppo di questo specifico modello è necessaria una blockchain e quali sono i vantaggi che introduce.

3. Andiamo ora ad identificare i Participants, ossia la le tipologie di utilizzatori della piattaforma. Per ogni tipologia di utilizzatori è opportuno identificare un incentivo economico di lungo temine che crei un rapporto fra gli utilizzatori e la piattaforma. Gli incentivi possono essere divisi in tre grandi categorie: incentivo all’acquisto, incentivo alla conservazione (hodling), incentivo all’uso. Ricordiamoci che fra gli user ci sono combinazioni di:

> a. User: coloro che usano la piattaforma

> b. Token Holder: coloro che si limitano ad investire acquistando i token;

> c. Service Provider: coloro che supportano l’infrastruttura tecnologica della piattaforma.

4. Indaghiamo poi la relazione fra Participants ed Economy, attraverso la compilazione del quadrante Governance, definendo quindi che tipo di influenza esercitano i Participant sull’Economy.

5. Analizziamo ora la relazione inversa fra Economy e Participants, nel quadrante Outside Economy. Come attori e tecnologie esterne all’ecosistema in analisi si rapportano con la nostra economia.

6. Token Usage: identifichiamo in questo quadrante come i token sono usati per attivare e sostenere l’economia.

7. Nel quadrante Scale & Growth identifichiamo il rapporto tra Problem ed Economy e tutti gli aspetti che devono essere considerati perché l’economia possa scalare e crescere.

8. Nel quadrante Health identifichiamo il rapporto tra Economy e Problem e tutti gli indicatori che consentano di verificare che l’economia sia funzionale al problema.

9. Nel quadrante Token Distribution & Value identifichiamo i criteri di distribuzione iniziale del token e quali sono i parametri che fanno aumentare o cambiare il valore del token (Tokenomics).

Credits: TokenCanvas

Per maggiori informazioni sul Token Economy Canvas si suggerisce di consultare http://tokencanvas.it.

Esempio — Storage Token

Per maggiore chiarezza proviamo a declinare il metodo su un esempio: eseguiamo l’analisi di un generico token per il data storage decentralizzato come quelli proposti in progetti come FileCoin e StoreJ.

Problem

si vuole avere un’infrastruttura decentralizzata per il file storage attivata da uno utility token che fornisca i seguenti vantaggi:

• non censurabile;
• resiliente;
• a basso costo.

Existing Alternatives

Sistemi di cloud storage centralizzati controllati dai big player IT.

Costose soluzioni private di storage replicato secondo criteri di disaster recovery.

Economy

Si definisce un’architettura decentralizzata P2P basata su uno storage token che consente di memorizzare una quantità specifica di dati nell’infrastruttura per un periodo di tempo definito.

Why Blockchain

Perché fornisce una soluzione resiliente e non censurabile, perché consente, tramite un meccanismo di permissionless participation, di abbattere i costi di servizio.

Participants

Storage Provider, coloro che offrono storage.

Data Producer, che si dividono in sotto categorie:

• privati che vogliono usufruire di un servizio resiliente, non censurabile e a basso costo;
• aziende che vogliono usufruire di un servizio resiliente, non censurabile e a basso costo.

Token Holder: speculatori che vogliono semplicemente contribuire al progetto e guadagnare in maniera passiva acquistando significative quantità di token puntando su un riprezzamento.

Incentives

• Storage Provider: possibilità di monetizzare con commodity HW.
• Data Producer: non censurabilità dell’infrastruttura, basso costo.
• Token Holder: diversificazione di investimento.

Governance

Gli stakeholder possono esercitare diritti di voto pesato per modificare i parametri del network, come ad esempio il tempo di persistenza del dato.

Outside Economy

Gli incumbent nel cloud storage potrebbero usare il servizio per abbattere i loro costi interni o contribuire al servizio per monetizzare.

Token Usage

I Data Producer acquistano gli storage token e lo usano per retribuire gli Storage Provider a volume. Gli Storage Provider rivendono il token tramite exchange per liquidare le loro attività ai Data Producer.

Scale & Growth

Che succede se finiscono i token: i token detenuti dagli Storage Provider vengono rimessi in commercio per finanziare i costi operativi, maggiore è l’offerta di dati dai Data Producer, maggiore il prezzo del token sull’exchange, maggiore è la volonta’ di tokenholder e Storage Provider di venderli.

Che succede quando aumentano gli utenti: gli utenti fanno aumentare il prezzo del token e quindi il circolo economico.

Health

Il sistema può considerarsi in salute se la crescita della base utenti non comporta una crescita della token velocity a discapito del market cap che, come discusso nella sezione Considerazioni sulla Token Velocity, deve essere contrastata o bilanciata da un aumento del valore del token.

Approfondimenti

Evaluating Blockchain Projects With Token Economy Canvas

1.1 Token user profile

Come anche trattato nell’articolo Understanding Token User Profiles concordiamo nel ritenere che la corretta e completa identificazione delle Personas coinvolte nel Token Model (nel Token Economy Canvas al passo 3) sia uno dei passi più delicati nella compilazione del quadrante esterno, ossia quello che tratta la relazione tra la token economy e i suoi partecipanti. Interessante comprendere per ogni Personas, il suo quadrante di appartenenza (Token Investor, Token Adopter, Token Atheist, Token Instant User).

In particolar modo bisogna assicurarsi che il problema e l’economia vadano ad attrarre principalmente Token Investor e Token Adopter, che sono quelli che garantiscono un sano supporto al progetto.

2 Token Mechanics

La Token Mechanics è la descrizione dei flussi di creazione, movimentazione, scambio e potenzialmente distruzione (burn) di uno o più token. Spiegano come i token si relazionano con le tipologie di utenti che le gestiscono e con i servizi interni ed esterni al BM.

Nella figura sotto uno scenario classico di emissione di token tramite mercato primario e successiva attivazione di un mercato secondario su exchange.

Basic mechanics example

Un’altra analisi estremamente utile per modellare la Token Mechanics consiste nella realizzazione di un interaction diagram fra tutte le parti interessati al Business Model.

Come esempio, nella figura sotto, si riportano i principali attori che partecipano al Business Model centralizzato di Uber (Passengers, Drivers e Future Passengers) e relative interazioni.

Uber Business Model Interaction Diagram — credits: boardofinnovation.com

Per avere altri esempi di interaction diagram di Business Model di aziende note, potete visitare https://www.boardofinnovation.com/guides/50-business-model-examples.

In generale un interaction diagram di un Business Model centralizzato è un oggetto come quello in figura seguente, in cui abbiamo in posizione centrale la Company che implementa il business, e una serie di attori (aziende e consumatori) che interagiscono con la Company e tra di loro, attraverso una relazione di fornitura di prodotti / servizi (provides) in cambio di rewards di varia natura (generalmente economici).

Generic Centralized Business — Interaction Diagram

A partire da un interaction diagram come questo è possibile formalizzare delle feature che il / i token possono andare a realizzare nella versione decentralizzata. È importante notare che nella versione decentralizzata esistono relazioni anche tra i peer che costituiscono la piattaforma del business (semi) decentralizzato.

Nel prossimo diagramma vediamo come evolve lo scenario della figura precedente, in un approccio decentralizzato: in questo caso i vari attori non si relazionano più con la Company (o almeno solo con essa), ma si relazionano soprattutto con un network di peer che costruisce il decentralized business. Interessante notare che ora sono definiti anche degli incentivi che operano nel rapporto fra nodi.

Generic Decentralized Business — Interaction Diagram

Nel caso in cui la Company rimanga presente, fornendo delle feature anche parziali alla piattaforma allora abbiamo una semi-decentralized solution, nel caso sia possibile implementare una piattaforma in cui la Company scompare completamente si parla di fully decentralized solution.

Riprendendo la figura Uber Business Model Interaction Diagram, nella versione decentralizzata e tokenizzata di una ipotetica UberChain, i trip e le commission potrebbero essere modellate con uno stablecoin, i voucher potrebbero essere tokenizzati e resi scambiabili liberamente fra utenti, anche il trust potrebbe essere tokenizzato e la reputation potrebbero essere modellati con dei token.

Token Sales Anatomy

La Token Sales definisce tutte le strategie per la collocazione di un token sul mercato attraverso vendita diretta o exchange. La vendita diretta operata dalla Company costituisce il primary market, le successive operazioni di vendita operate dagli stakeholder costituiscono il cosiddetto secondary market.

In questo passaggio si disegna il piano di funding vero e proprio. Gli input principali per pianificare la campagna sono il soft e all’hard cap, ossia l’obiettivo minimo e massimo di raccolta. L’obiettivo minimo va sempre specificato per distinguersi come un’iniziativa affidabile, l’obiettivo massimo invece può anche essere evitato, andrebbe però descritte delle milestone incrementali in termini di funzionalità del prodotto. Si dichiara infine la policy di gestione dei token invenduti a fine emissione token, che per utility token generalmente prevede la distruzione, mentre per i security si prevedono sales successive.

Viene poi decisa la politica di vendita dei token. La più semplice meccanica di token sales prevede la vendita a cambio fisso, si fissano dei prezzi scontati per il private sales (investitori) e per il pre-sales (ad invito) e un prezzo standard per il pubblico. Poi si possono introdurre degli scaglioni di aumento dei prezzi a tempi prefissati per generare una sensazione di urgenza.

Altre meccaniche più complesse invece prevedono i meccanismi ad asta proprie del mondo fiat con alcune varianti famose come Dutch Auction (asta olandese inversa), dove si parte da un cap espresso in fiat ed il numero di token emessi dipende dalla durata totale del token sales. Si apre con un prezzo base che scende man mano che vengono minati nuovi blocchi nella chain di riferimento del token (substrate), mentre il prezzo scende incontra i costi obiettivo dei vari compratori fino al raggiungimento del capitale totale.

Un’alternativa alla Dutch Auction è la Vickrey Auction, in cui si fanno offerte segrete per un batch di token e si assegna il batch a maggior offerente al secondo prezzo più alto. Una interessante disquisizione di quale tecnica di token sales utilizzare in funzione della tipologia di investitori che si vuole raggiungere può essere trovata in questo interessante articolo di Reuben Bramanathan: The perfect token sale structure.

In aggiunta, nell’articolo Dinamiche economiche di una ICO, si analizza la relazione fra valore di mercato e strategia di emissione di utility token.

Per concludere, spesso può essere utile recuperare informazioni di token sales conclusi per auditing, valutazioni e proiezioni ci scenari di utilizzo. Un articolo tecnico che mostra come recuperare tali informazioni può essere trovato qui. Questo articolo descrive l’uso del web tool bloxy.info, che consente di analizzare le transazioni verso uno Smart Contract di emissione di un token arbitrario.

3 Token Legal Review

La prima cosa da verificare nella legal review è la tipologia di token. Un token può essere classificato come (crypto) currency, utility o security o come combinazione di questi.

• Currency: sono i token più noti e diffusi, esempio principale è Bitcoin, portano un valore intrinseco che viene stabilito dal mercato.
• Utility: sono dei token che abilitano i possessori all’utilizzo dei servizi forniti da una piattaforma (semi) decentralizzata. Un esempio è Ethereum, che oltre ad essere una cryptocurrency è anche un utility token che consente di accedere al servizio di computazione decentralizzato del network omonimo.
• Security: sono token che garantiscono diritti di rendita (e di governance in caso di equity) sui proventi di un business (semi) decentralizzato.

Utility vs Security

Il 2017 è stato caratterizzato dal boom di capitalizzazione delle ICO, tuttavia molti token distribuiti come utility si comportavano come security, la cui emissione è fortemente normata e richiede delle licenze per la commercializzazione, andando ad infrangere le policy regolatorie di molti paesi in cui sono stati distribuiti.

Per poter verificare la corretta natura del token che si sta emettendo è si utilizza un semplice strumento di verifica chiamato Howey Test.

L’Howey Test è stato introdotto dalla SEC (USA), ma il criterio può essere considerato valido anche in altre giurisdizioni. Viene utilizzato per verificare che la nostra emissione di token è un ICO (emissione di utility token) o una STO (emissione di security token).

Il test è articolato nelle seguenti domande:

1. Stiamo facendo un investimento di denaro?
2. Il nostro investimento è in un’impresa comune?
3. Abbiamo aspettative sui profitti?
4. Questo profitto è generato dallo sforzo degli altri?

Se arriviamo alla quarta domanda con una risposta affermativa, abbiamo a che fare con uno strumento security.

GDPR compliance

Molti esperti considerano GDPR e blockchain delle tematiche profondamente incompatibili, in quanto la prima vuole fornire un quadro giuridico di garanzia per il trattamento e la conservazione di dati sensibili, legati a persone fisiche, in particolare sugli aspetti del diritto alla rettifica e alla cancellazione, mentre la seconda verte sull’immutabilità del dato stesso.

Personalmente ritengo che con il giusto approccio GDPR e blockchain possano coesistere proficuamente. L’unica accortezza che deve essere usata nell’impiego di tecnologie DLT pubbliche (e quindi immutabili) per la custodia di dati sensibili, consiste nell’evitare di memorizzare su blockchain dati raw contenenti informazioni sensibili. I dati sensibili dovrebbero essere persistiti su uno storage centralizzato, su blockchain dovrebbero essere depositate solo le firme crittografiche corrispondenti a tali dati sensibili. In questo modo l’informazione rimane comunque immutabile, timestamped e verificabile, ma solo previo accesso (controllato) al dato originale, che può essere in questo caso rettificato o eliminato, anche se in questo caso viene invalidata la capacità di verifica attraverso la corrispettiva signature su blockchain.

4 Il Token Valuation Canvas

Un Token Valuation Canvas è uno strumento per eseguire la valutazione di un token esistente o in fase di progettazione (autovalutazione). Esistono diversi evaluation canvas, di sotto ne riporto uno sufficientemente completo, che nonostante sia stato progettato per le ICO può essere facilmente applicato anche alle STO.

Il canvas ci porta a validare gli aspetti basilari del token come type, role e supply, poi lo stato legale (vedasi sezione precedente), l’attività della community di sviluppatori, la valutazione del team complessivo. Lo stesso canvas ci porta poi ad esaminare / validare il network effect che il token riesce a sviluppare, per tutte le casistiche di token (currency, utility, da includere nella valutazione anche security).

Vengono poi indagati alcuni aspetti non funzionali come la sicurezza e la resilienza. si suggeriscono infine varie considerazioni relative alla market analysis, la validazione della roadmap di sviluppo, ipotesi di traffico atteso e l’analisi dei contenuti di dissemination come il whitepaper.

Credits: BlockchainHub

Oltre il Token Model

Considerazioni sulla Token Velocity

L’entusiasmo che coinvolge chi si avvicina al mondo della tokenizzazione per la prima volta, sia come investitore, sia come propositore di business, porta spesso a trascurare aspetti di performance sul Business Model legati alla token velocity, ossia al numero di volte che nell’unità di tempo un token passa di proprietario (e quindi viene comprato, venduto, utilizzato). Questo aspetto però non sfugge agli investitori professionali, di cui di solito chiedono conto.

La velocity comporta infatti dei rischi per tutte quelle token economy che prevedono l’emissione di un singolo token come mezzo di scambio per una singola risorsa generalmente limitata, poiché introduce un disallineamento negli incentivi.

In generale, almeno nella prima fase di costruzione di un progetto tokenizzato, è importante introdurre degli incentivi per assicurarsi che la token velocity rimanga bassa.

In particolare molti esperti concordano sul fatto che la Token Economy sia governata dalla seguente equazione, adattata dalla riformulazione della nota equazione di scambio della macroeconomia classica:

MV = PQ

dove

M = dimensione della token base (o marketcap)

V = token velocity, numero di volte che un token viene usato

P = prezzo della risorsa digitale unitaria (in fiat)

Q = quantità di risorsa unitaria prodotta (computation, storage, etc)

Il prodotto PQ può essere espresso anche come il valore totale del volume di transazioni effettuate, o TotalTransactionVolume (generalmente in fiat), mentre M viene interpretato come il valore complessivo del network o NetworkValue.

Quindi

V = PQ / M = TotalTransactionVolume / NetworkValue

per cui

NetworkValue = TotalTransactionVolume / V

Per cui il NetworkValue cresce, a parità di TotalTransactionVolume in maniera inversamente proporzionale alla velocità V del token.

Quindi per evitare una decrescita del NetworkValue ci sono le seguenti opzioni:

• evitare il crescere di V e quindi incentivare l’immobilità del token, il Proof of Stake o reward su stake immobilizzati sono molto utili a riguardo, tuttavia questa soluzione non è è sempre implementabile specie nei casi di successo e quindi di aumento della user base del token;
• operare un controbilanciamento introducendo dei meccanismi che aumentino il TotalTransactionVolume e quindi il prodotto PQ, aumentando quindi il valore del token (P) o la quantità di risorse associata ai token circolanti (Q).

Approfondimenti

https://hackernoon.com/token-velocity-a455173d69e3

Curation Markets

I Curation Market sono dei token model pensati per ridurre l’asimmetria informativa in un mercato consentendo ai token holder di scommettere su determinate opzioni. Questo approccio facilita la formazione di gruppi di collaborazione laschi ed il loro coordinamento, teso a creare valore intorno ad una risorsa condivisa, costruendo un meccanismo di guadagno intorno ad un insieme di obiettivi comuni.

Questi mercati funzionano attribuendo valore intorno ad un’idea, un concept, un’iniziativa, e possono risultare estremamente efficaci per la tokenizzazione di modelli no profit o di modelli open source.

I Curation Market possono a loro volta utilizzare tecniche di tokenizzazione avanzate come i Continuous Token Models e le Dynamic Bounding Curves.

Esempi applicativi di Curation Market

• Monetizzazione di modelli Open Source, consentendo ai partecipanti di puntare sullo sviluppo delle prossime feature e fornire / sviluppare tale implementazione.
• Data/Content Curation: consentendo ad attori di puntare su un certo argomento da arricchire e retribuendo i contributor in funzione del loro effort.
• Attention Market: consentendo ad attori publisher di puntare su un argomento sponsorizzato e garantendo ai distributori e consumer di tale contenuto un reward.

Approfondimenti

Introducing Curation Markets

https://medium.com/@simondlr/introducing-curation-markets-trade-popularity-of-memes-information-with-code-70bf6fed9881

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

https://medium.com/@simondlr/the-arcade-bazaar-continuous-multi-party-tokenized-funding-without-central-issuance-2cbac86ab5c

Dynamic Token Bonding Curves

https://tokeneconomy.co/dynamic-token-bonding-curves-41d36e43befa

Token Engineering

Come ben introdotto dall’articolo Towards a Practice of Token Engineering la progettazione di un token e di un ecosistema a sostegno, coinvolge diverse discipline ortogonali: dall’economia, alla teoria dei giochi arrivando all’ottimizzazione lineare.

Credits: oceanprotocol.com

In tale articolo si discute dell’utilizzo di metodi formali per un approccio ingegneristico nella costruzione di un Token Model. Si parte dall’analisi degli incentivi tra i partecipanti utilizzando la Game Theory, per poi arrivare all’individuazione della meccanica del sistema tokenizzato con la relativa individuazione dei constraint funzionali. Infine si ricorre all’impiego di tecniche di ottimizzazione (Optimization Design) per arrivare all’individuazione di pratiche e tool che possono essere usati sia in fase di validazione dei requirement, sia in fase di attuazione dei modelli.

FOSS e Blockchain

La creazione di Business Model su progetti open source sono state già esplorate con successo, anche se ritengo che il vero potenziale di innovazione nella combinazione di queste due discipline non ha ancora raggiunto il suo massimo.

FOSS (Free Open Source Software) è l’insieme di Business Model classici che accompagna le aziende coinvolte nello sviluppo di piattaforme Open Source (OS). Nei Business Model FOSS si crea un rapporto tra aziende, che cooperano nello sviluppo di complesse piattaforme Open Source comuni, rimanendo comunque in molti casi in competizione sui customer. Di solito le varie aziende sviluppano poi un layer proprietario chiuso sul core OS e su questo basano la propria differenziazione e capacità competitiva.

Il modello FOSS si presta molto bene per implementare Permissionless Blockchain Business Model (PBBM), in questo modello i confini fra privati, aziende, customer e investitori diventano completamente liquidi, inoltre la cooperazione fra le aziende non si limita solo allo sviluppo della piattaforma tecnologica, ma puó arrivare anche al coordinamento di strategie finanziarie, volte ad aumentare il valore dei token sottostanti. Infatti in un modello PBBM le aziende contributor sono anche stakeholder, e possono quindi esercitare diritto (programmatico) di voto per modificare aspetti dell’economia del/dei token della piattaforma, come il minting rate.

Nella tabella seguente sono riportati i principali attori e task a confronto fra il modello classico FOSS ed il modello innovativo PBBM.

Application Modules

L’implementazione delle Key Activities di un Business Model abilitato da blockchain condurrà allo sviluppo di un’applicazione, parzialmente o totalmente decentralizzata, che consentirà di interagire con il business stesso. Questa applicazione sarà costituita da diversi moduli funzionali, alcuni off-chain, esistenti su server centralizzati, altri on-chain, in grado di eseguire su un network decentralizzato.

Esempi di moduli off-chain:

• Explorer module: un modulo che consente di vedere di navigare gli asset e relativi metadati ad un livello più alto (ossia con una UX semplificata) rispetto a quanto si potrebbe fare con un Blockchain Explorer standard.
• Payment module: modulo per il pagamento crypto / fiat per l’acquisto di token in fase di vendita primaria.
• Stats module: modulo per la produzione le statistiche di vendita / pricing / scambio del token.
• User module: modulo per la gestione del profilo privato dell’utente, con possibili funzionalità custodian, gestione della governance decentralizzata.
• Admin module: modulo amministrativo per la verifica dello stato del token e la gestione dei parametri di campagna, governance centralizzata.

Esempi di moduli on-chain:

• Smart Contracts vari per la gestione dei token.
• Dapp: web app distribuita su storage decentralizzato che usa il substrate come backend.

Oggi sono disponibili diverse soluzioni off-the-shelf sia commerciali che Open Source che forniscono già i principali moduli on-chain e off-chain necessari alla realizzazione di un progetto decentralizzato, che richiedono solo lo sviluppo del token model o che forniscono alcuni token model che implementano strategie predefinite.

Un esempio fra tutte le piattaforme Open Source, tra le piú complete e modulari per la realizzazione di distributed organizations che vale la pena citare è sicuramente Aragon. Per avere invece un esempio di piattaforma proprietaria specializzata per l’accesso a finanziamento alternativo tramite emissione di token si puó guardare Harbor o Polymath.

In generale per semplificare lo sviluppo di alcuni di questi aspetti si puó ricorrere all’utilizzo di uno stack di tokenizzazione.

Lo stack di tokenizzazione

Lo stack di tokenizzazione rappresenta il substrato tecnologico a sostegno di una tokenizzazione. La corretta selezione del substrato è uno step indispensabile per il funzionamento del Business Model tokenizzato. Gli aspetti principali da considerare quando si seleziona uno stack sono:

• Safety: il substrate è sufficientemente sicuro per la tipologia di token che si va ad implementare;
• Expressiveness: il substrate consente di implementare tutte le funzionalità necessarie al Business Model, garantendo il giusto livello di decentralizzazione (on-chain).
• Scalability: il substrate è sufficientemente scalabile per supportare le attività della base utenti, considerando le proiezioni d i crescita di tale base, tenendo inoltre sotto controllo il costo delle transazioni.

In particolare nel considerare la scalability ci sono i seguenti aspetti da considerare:

• Fee Cost: come impattano le fee di transazione e come possono essere mitigate;
• Transaction Confirmation Time: come i tempi di conferma impattano la UX ed il Business Model;
• Transaction Throughput: come la bandwidth del network impatta la scalabilità del Business Model.

Uno stack di tokenizzazione, oltre agli attributi del token discussi nella sezione precedente, può includere anche i seguenti layer:

• Compliance Platform: fornisce tutti gli aspetti di compliance (AML/KYC) per velocizzare e rendere più sicuri gli investimenti.
• Exchange Protocol: definisce uno standard per il mercato secondario.
• Exchange Platform: fornisce un engine e una user experience per il mercato secondario.

Credits: Harbor

Grazie!

Se sei arrivato fin qui probabilmente hai apprezzato il mio articolo. Perchè non mi lasci un feedback, come un commento o degli applausi? Se sei nuovo su Medium probabilmente non saprai che un click sul bottone applausi vale solo 1 / 50 del voto massimo.

Letture di approfondimento

Come costruire una 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

https://thetokenizer.io/2019/02/22/what-is-an-asset-backed-token-a-complete-guide-to-security-token-assets

Mapping business opportunities in The Era of Tokenization

https://hackernoon.com/mapping-business-opportunities-in-the-era-of-tokenization-a-24trn-game-9c0c8c03c236

Meet the first companies tokenizing their equity on Blockchain

https://blog.neufund.org/meet-the-first-companies-tokenizing-their-equity-on-blockchain-8dd2a9c4091f

Exchanges for Security Tokens: Which STO Exchanges do Already Exist? Which Follow Soon?

https://medium.com/altcoin-magazine/exchanges-for-security-tokens-which-sto-exchanges-do-already-exist-which-follow-soon-4ddff2be55bf