Rappresentazione stilizzata di 2 individui che azzionanao 2 ruote dentate di un meccanismo, a simboleggiare la blockchain

COME TOKENIZZARE UN BUSINESS MODEL – Parte 2

Con la seconda parte dell’articolo “COME TOKENIZZARE UN BUSINESS MODEL” concludiamo l’approfondita analisi.

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 è 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).

 

Il Token Economy Canvas

Credits: TokenCanvas

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.

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.

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 Business Model.

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

Rappresentazione di emissione di token tramite mercato primario

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.

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.

Rappresentazione del Business Model centralizzato di Uber

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).

Rappresentazione di un Interaction diagram di un Business Model

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.

Rappresentazione di un network di peer

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.

Per concludere, spesso può essere utile recuperare informazioni di token sales conclusi per auditing, valutazioni e proiezioni ci scenari di utilizzo.

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

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.

Token Evaluation Canvas

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).

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.

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.

Rappresentazione del design di un ecosistema tokenizzato

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.

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.

Tabella di confronto tra modello FOSS e modello 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.

Rappresentazione grafica di un Security Token Stack

Credits: oceanprotocol.com

GRAZIE!

Se sei arrivato fin qui probabilmente hai apprezzato questo articolo, perché non lasci un feedback, come un commento?

LETTURE DI APPROFONDIMENTO

COME COSTRUIRE UNA ICO/STO

https://medium.com/@hardest/come-costruire-una-ico-sto-ff6fb36c5f43

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

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