Come valutare un progetto Blockchain

  • di

In questo articolo fornisco dei metodi, utilizzabili anche da lettori non tecnici, per valutare in autonomia dei progetti blockchain, nello specifico si tratteranno solo progetti associati a blockchain pubbliche, liberamente accessibili e partecipabili (permissionless). Non saranno invece trattati criteri di valutazione per blockchain private. Di seguito faremo riferimento ad un metodo di valutazione generico per progetti di varia natura, siano essi:

Questi progetti potranno essere:

  • in fase di funding;
  • già operativi.

Per poter eseguire una valutazione efficace di un progetto blockchain sono richieste competenze interdisciplinari che combinano aspetti di business e tecnologia. Il mio consiglio è, compatibilmente con le vostre competenze, di non limitarvi a verificare lo score di un progetto sui siti di rating specializzati, ma di integrare queste ricerche con un approccio #DYOR (Do Your Own Research).

Vi fornirò gli strumenti base per essere indipendenti in una valutazione oggettiva.

Aspetti principali del progetto

I fattori principali da valutare per stimare la qualità di un progetto blockchain sono introdotti di seguito e saranno dettagliati nelle sezioni successive. Si consiglia sempre di affrontarli nell’ordine presentato.

  1. Vision: la visione di lungo termine del progetto, il tipo di impatto che costruirà nel suo mercato di riferimento.
  2. Product: il prodotto o servizio oggetto del progetto.
  3. Tech Stack: la piattaforma tecnologica su cui poggia il prodotto, quando applicabile.
  4. Team: il gruppo di persone che segue tutti gli aspetti di operatività del progetto.
  5. Advisors: il gruppo di persone che affianca il team nelle operazioni decisionali, di networking e scaling del progetto.
  6. Community: il gruppo allargato di individui e società che contribuisce direttamente o indirettamente al progetto.
  7. Business Plan: il piano di sviluppo del progetto.
  8. Market Cap: lo stato di capitalizzazione del progetto.

Il primo approccio per avere uno score quantitativo sulla qualità di un progetto può essere trovato nei principali siti di rating, magari confrontandolo con gli score pubblicati dallo stesso sito di rating per altri progetti che si conoscono in dettaglio, al fine di avere un raffronto di attendibilità.

Tuttavia i siti di scoring non coprono tutti le iniziative esistenti, inoltre possono favorire degli aspetti non sempre coerenti con i nostri criteri di valutazione.

Alcuni siti di valutazione ICO/STO.

Alcuni siti specializzati STO.

Per saperne di più sulle varie risorse disponibili su ICO/STO rating potete consultare questo articolo.

Vision

La vision definisce lo scope, gli obiettivi e gli aspetti ispirazionali di un progetto. In ambito blockchain la vision di un progetto dovrebbe rispondere in modo esaustivo alle seguenti domande.

  • Quale mercato il progetto va ad aggredire?
  • Quali problemi va a risolvere per questo mercato?
  • Come si pone rispetto agli incumbent e competitor esistenti su questo mercato?
  • Che tipo di benefici economici ci sono per l’utente occasionale?
  • Che tipo di benefici economici ci sono per i partecipanti (token holder) del progetto?
  • Come si pone il progetto in relazione con le altre tecnologie blockchain?
  • Come funziona il business nel suo complesso? Questa domanda sarà affrontata meglio nella sezione Business Model.

Tipologia di progetto

La prima cosa che bisogna capire è la natura del progetto che si sta esaminando, fare fatica già in questa fase dovrebbe accendere un campanello di allarme. I progetti blockchain si possono generalmente suddividere nelle seguenti categorie, a volte combinate tra loro.

  • Progetti di tokenizzazione: prevedono la tokenizzazione di un business model attraverso l’emissione di token utility (ICO) o security (STO). Di solito si concentrano sulla realizzazione di un prodotto o servizio principalmente digitale e usano una piattaforma blockchain esistente per l’automazione degli aspetti economici, con livelli di complessità che vanno dalla semplice emissione di un token a scenari di controllo avanzati implementati con gli Smart Contract.
  • Extension Layer: aggiungono delle funzionalità avanzate su una blockchain esistente, senza che questa ne sia affetta o ne sia consapevole. Questi progetti mirano per lo più a risolvere problemi di scalabilità di cui sono affette le piattaforme blockchain e a costruire servizi parzialmente o totalmente decentralizzati sulle stesse.
  • Blockchain network: sono i progetti più ambiziosi, che prevedono lo sviluppo di una nuova piattaforma blockchain, sono anche i più difficili da valutare negli aspetti di complessità tecnologica.

Bisogna poi valutare i fattori di hype (quanta risonanza mediatica sta producendo), rischio (quanto è tecnologicamente complesso realizzare il business model) e potenziale (qual è la dimensione del mercato raggiungibile) del progetto, analizzando alcuni aspetti come:

  • comunicazione e impression: come si presenta il website e tutto il materiale informativo e divulgativo del progetto, livello e qualità della comunicazione e della grafica;
  • external reviews: il livello di gradimento che si registra fra gli utenti delle community di riferimento, un livello elevato di discussione è molto importante per garantire visibilità e attenzione degli investitori;
  • partners: il livello di prestigio dei partner che partecipano al progetto, soprattutto se inerenti all’ambito del business.

Approfondiamo alcuni aspetti per le varie tipologie di progetto.

Progetto di tokenizzazione

I progetti di tokenizzazione sono fra i più comuni e facili da valutare, bisogna assicurarsi innanzitutto che il business plan sia consistente e che l’uso del token sia sensato.

Esempi di tokenizzazione sono i progetti basati su ERC-20 (per le ICO) e ST-20 (per STO).

Alcune domande da porsi e possibili considerazioni sulle risposte.

  • Il token è indispensabile al funzionamento del progetto o è solo uno strumento di fundraising?
  • > Indispensabile: il valore del token crescerà al crescere del valore del progetto.
  • > Non indispensabile: il valore del token potrebbe scendere anche al crescere del valore del progetto.
  • Come si integra il token model con il business model?
  • Il progetto prevede l’interazione con beni digitali o fisici?
  • > L’interazione con beni digitali è una premessa necessaria per poter automatizzare e quindi decentralizzare il business model potenzialmente del tutto, l’interazione con beni fisici invece impedisce la decentralizzazione totale.
  • > In caso ci siano aspetti necessariamente centralizzati è interessante verificare come il progetto garantisce la tracciabilità del revenue stream (che visibilità garantisce ai token holder sui guadagni) e la possibilità di automatizzare le revenue per tutti gli holder.
  • Il token è legato all’utilizzo del prodotto/piattaforma, ovvero fornisce all’utente l’accesso esclusivo o fornisce diritti di interazione con il prodotto?
  • Il token è l’esclusiva unità di pagamento per l’uso del prodotto/piattaforma, o ce ne sono altre?
  • Il token garantisce la proprietà di risorse?
  • Il token genera reward monetizzabili basate su azioni degli utenti del prodotto/piattaforma?
  • I reward eventualmente generate sono distribuiti automaticamente dal codice on-chain o passano per una governance umana?
  • Quali sono gli incentivi per i token holder?
  • Quali incentivi ci sono per i clienti, per i partner e per i fornitori del progetto ad acquistare il token?
  • Il token concede diritti di governance?
  • > Molti progetti interessanti garantiscono diritti di governance ai token holder, va comunque verificato quali sono gli aspetti fondamentali del progetto che non possono essere modificati nemmeno dal quorum.
  • Il token abilita interazioni tra utenti?

Extension Layer

Un Extension Layer aggiunge una funzionalità specifica ad una blockchain, come una soluzione di scalabilità. Affinchè tali progetti funzionino correttamente di solito definiscono un’economia basata su un token di utilizzo o su una fee sul token della blockchain principale, ponendosi quindi con una value proposition simile ai progetti di tokenizzazione di asset digitali.

Se il progetto non prevede un modello di tokenizzazione / revenue, allora non supporta neanche un’economia in grado di incentivarlo e quindi perde di rilevanza in termini di potenziale di investimento.

Un Extension Layer infine è tanto robusto quanto lo è la blockchain sottostante.

Esempi di progetti Second Layer sono le varie Sidechain costruite su blockchain principale oltre a varie soluzioni di scalabilità come Lightning Network, un layer su stack Bitcoin che supporta micro transazioni con micro fee istantanee.

Progetto Blockchain

Per Blockchain si intendono tutte le quelle tecnologie che consentono di realizzare ledger decentralizzati, ed includono le tecnologie blockchain che costituiscono il primo approccio. Realizzare uno nuovo network Blockchain partendo da zero è un’operazione che richiede un enorme dispendio di risorse ed un alto rischio di realizzazione. Una parte significativa dei costi sta nella costruzione di una community di riferimento che vada a sostenere e contribuire al nuovo network.

Va valutato quindi se questa network ha un’opportuna copertura economica e effettiva traction da parte di un ecosistema. Ci vuole un investimento iniziale stimabile nell’ordine dei milioni di Euro per realizzare tutti gli aspetti indispensabili di una Blockchain funzionante con una community di qualche migliaio di utilizzatori e qualche centinaio di nodi.

Può risultare più efficace costruire una soluzione specializzata realizzata come Extension Layer su una blockchain consolidata con una community già esistente, piuttosto che creare una infrastruttura general purpose.

Una strategia efficace e già testata in diversi progetti per sviluppare una Blockchain è l’emissione di token per la capitalizzazione del progetto in crowdfunding, appoggiandosi ad una piattaforma già esistente, dalla quale si ereditano la traction e magari parte della community, per poi migrare con fasi ben definite su una piattaforma completamente indipendente (strategia seguita ad esempio da EOS, che ha capitalizzato con una ICO su Ethereum).

Valutare l’efficacia e l’utilità di un nuovo progetto Blockchain risulta molto complesso, fra le domande da porsi e le possibili risposte ci sono le seguenti.

  • Risolve un problema specifico (ad esempio file storage) o generico (ad esempio esecuzione di Smart Contract), come si pone nei confronti di progetti simili?
  • Quali sono gli incentivi per i token holder?
  • > Accesso all’infrastruttura.
  • > Accesso ai profitti.
  • > Accesso alla governance dell’infrastruttura.
  • Quali sono gli incentivi per i nodi (tutti coloro che forniscono infrastruttura)? Che tipo di relazioni ci sono fra le diverse tipologie di nodo?
  • > Generano dei nuovi token (minting), guadagnano dalle fee di transazione.
  • Qual’è il rapporto fra nodo e nodo, quale fra nodo e token holder?
  • Che modello di consensus propone?
  • > Basato su mining Proof of Work (PoW), Proof of Stake (PoS), su reputation (PoA), altro.
  • Che tipo di governance garantisce? È sufficientemente decentralizzata?
  • Quanto è attiva la sua community? Quanti sono gli di sviluppatori che seguono questo progetto? Quanti sotto-progetti dipendono da questo?
  • Quali partnership ha definito il progetto?
  • Che market cap vuole raggiungere o ha raggiunto il progetto?

Tech Stack

Un progetto blockchain poggia su due aspetti, il business model e la tecnologia di decentralizzazione. In questa sezione forniamo gli strumenti base per valutare la seconda. La tecnologia sottostante ad un progetto blockchain è di solito descritta in uno o piu’ paper tecnici, per avere un metodo di lettura di un white paper tecnico si può consultare questo articolo.

Alcuni aspetti fondamentali da considerare nella valutazione tecnica di un progetto blockchain sono relativi alle limitazioni della piattaforma utilizzata o realizzata, di seguito riportiamo le principali.

Transazioni

  • Qual è il limite di transazioni al secondo che la piattaforma supporta?
  • La scalabilità della piattaforma blockchain impatta direttamente la scalabilità del business model, bisogna quindi essere consapevole dei limiti.
  • Qual è la latenza media per la finalizzazione di una transazione?
  • > In funzione dello use case il progetto potrebbe avere la necessità di finalizzare una transazione nel tempo di 20/30 secondi al fine di non compromettere la user experience.
  • Le transazioni supportano meccanismi di programmabilità come gli Smart Contract? Gli Smart Contract possono eseguire compiti di complessità arbitraria (Turing completeness)?
  • > L’infrastruttura deve poter eseguire quanto più possibile on-chain gli use case previsti dalla value proposition, altrimenti ci potrebbero essere problemi di centralizzazione.
  • Il progetto usa un framework per Smart Contract basato su una tecnologia esistente (tipo Ethereum Virtual Machine)?
  • > Usare una piattaforma per Smart Contract costruita ad-hoc significa sottoporsi a rischi tecnologici, mancanza di competenze e di soluzioni off-the-shelf, mancanza di supporto e traction da parte della community di riferimento.

Fee di transazione

  • Sono previste delle fee per eseguire transazioni?
  • > Se gli use case prevedono transazioni di basso valore economico bisogna capire quanto il costo medio di transazione diventa rilevante nel costo di utilizzo degli utenti.
  • Le fee sono fisse o variabili?
  • > Costi di transazione variabili rendono imprevedibili e quindi ad alto rischio alcuni use case.
  • Quali fattori influenzano il costo delle fee?

In generale l’uso di una piattaforma con delle fee, soprattutto se variabili può limitare la scalabilità del progetto: che succede quando il numero di utenti aumenta esponenzialmente? Impatta anche la usability: che succede quando nella piattaforma sottostante le fee aumentano repentinamente?

Consensus

L’algoritmo di consenso usato dalla piattaforma è il principale indicatore di sicurezza e di decentralizzazione. Considerate sempre che le tecnologie blockchain devono trovare un compromesso tra decentralizzazione e latenza: maggiore decentralizzazione significa maggiore latenza.

Il primo aspetto da considerare nella valutazione del Consensus è come il progetto si pone nei confronti del Blockchain Trilemma.

The Scalability Trilemma — source: https://medium.com/logos-network/everything-you-know-about-the-scalability-trilemma-is-probably-wrong-bc4f4b7a7ef

Il Blockchain Trilemma infatti definisce il limite logico che si ha in una blockchain quando si cerca un compromesso in termini di:

  • security: ossia quanto la blockchain è robusta ad attacchi dall’esterno e nella consistenza delle operazioni su di essa eseguite;
  • scalability: ossia quante operazioni supporta nell’unità di tempo, e quindi quanti utenti riesce a soddisfare contemporaneamente, introducendo quindi anche un indice dei costi dell’esecuzione delle transazioni;
  • decentralisation: ossia quanto il potere decisionale si distribuito omogeneamente fra tutti i sostenitori attivi della rete (miners, full nodes, validators etc).

Il Blockchain Trilemma è un corollario del CAP Theorem, dove si definiscono i limiti di scalabilità dei DB distribuiti, e dichiara che è possibile avere solo due fra le tre proprietà sopra elencate di una blockchain. Un articolo che spiega come si collegano CAP Theorem e Blockchain Trilemma può essere trovato qui.

Dato che nessuno, fino ad adesso, ha voluto rinunciare agli aspetti di sicurezza, sono emerse varie soluzioni che affrontano con diversi compromessi il rapporto scalability vs decentralisation.

Altro aspetto legato al Consensus è la relazione fra bandwidth (quantità media di transazioni al secondo supportate dal protocollo) e adoption (quantità di nodi che partecipa al network): maggiore bandwidth significa maggior numero di transazioni al secondo supportate, ma significa anche blocchi più grandi (per le DLT a blocchi) che comporta requisiti HW più costosi per i nodi partecipanti e quindi minore adoption.

Relazione fra bandwidth e adoption

Va considerata inoltre la relazione decentralisation (quantità di nodi del network che partecipa al Consensus sul totale dei nodi partecipanti al network o Adoption) e latency (tempo medio di attesa per la finalizzazione di una transazione): maggiore decentralizzazione garantisce maggiore consistenza e maggiore sicurezza ma comporta anche maggiore latenza nella finalizzazione delle transazioni.

Relazione fra decentralisation e latency

Per aggirare i problemi di bandwidth sono state introdotte diverse soluzioni di Consensus, che possono essere divise in due grandi tipologie.

  • Consensus distribuito: come Bitcoin, tutti i nodi partecipanti al network hanno lo stesso peso nel verificare ed indicare la validità delle transazioni.
  • Consensus gerarchico: come EOS, esistono delle sotto network il cui consenso è gestito in maniera peculiare, queste sottoreti sono supervisionate tuttavia da un network di primo livello che garantisce uniformità.

Piattaforma

Per piattaforma si intende lo stack tecnologico su cui poggia il progetto blockchain in esame. Il progetto può’ poggiare su una piattaforma esistente o costruirne una nuova, in entrambi i casi è possibile valutare l’attendibilità tecnologica dello stesso in base agli use case proposti dal business model sottostante.

Il principio guida che consiglio per valutare una Piattaforma è capire con che frequenza si usa il token. Infatti uno degli aspetti fondamentali che determinerà l’efficacia di un progetto è la scalabilità della Piattaforma rispetto al suo business model. Se la piattaforma prevede che l’utente esegua diverse decine di transazioni al giorno, questa piattaforma non può essere realizzata su blockchain con costo di transazione superiore a pochi centesimi e con throughput limitato a poche decine di transazioni al secondo.

Se il business model richiede che le transazioni siano istantanee, anche in questo caso è necessario usare una soluzione scalabile.

Un business model che prevede che gli utenti eseguano numerose transazioni al giorno, anche se all’inizio può presentare performance sostenibili, non è in grado di resistere alla crescita della base utenti portando al fallimento del progetto.

Molte piattaforme Blockchain privilegiano la decentralizzazione alla scalabilità, (Bitcoin), altre la scalabilità alla decentralizzazione (EOS), infine alcune stanno cercando un giusto compromesso tecnologico fra scalabilità e decentralizzazione (Ethereum), trovi maggiori dettagli nella sezione Consensus.

Roadmap

Un altro aspetto fondamentale per valutare gli aspetti tecnologici di un progetto blockchain è la roadmap di sviluppo. La roadmap è il piano temporale di rilascio delle funzionalità, indicate come milestone, e riporta quali funzioni saranno realizzate, con che priorità e distribuzione temporale.

Se il progetto è in corso è estremamente importante verificare se la milestone passate sono state rispettate o meno. Una indicazione del rispetto della roadmap ci permette di valutare il livello di efficacia del team operativo e magari l’evidenza di possibili carenze di budget.

Nel caso in cui il progetto preveda lo sviluppo di un Extension Layer o comunque di un’infrastruttura che si basa su una blockchain esistente, è importante capire il livello di integrazione con questa ed il livello di sicurezza di tale integrazione.

Team

Uno degli aspetti più rilevanti per lo valutare la qualità di un progetto è il team. L’analisi del team è un indicatore fondamentale per comprendere la capacità di execution dello stesso. Gli aspetti principali da valutare sono:

  • esperienza e casi di successo: alcuni membri del team hanno esperienza e magari casi di successo nell’ambito operativo del progetto;
  • integrità: i membri del team non hanno trascorsi discutibili, posizioni o conflitti di interesse che possano pregiudicare la loro efficacia;
  • network: i membri del team hanno un network consistente alla loro mission.

Il modo più efficace per condurre un’analisi qualitativa di un team è la consultazione dei profili Linkedin, investigando in particolare sulle precedenti attività lavorative, sulle connessioni sociali, articoli pubblicati, slide etc.

Advisors

Ad affiancare i membri del team nelle decisioni strategiche ci sono gli advisor, che pur non ricoprendo un ruolo operativo forniscono insight e mettono a disposizione il proprio network professionale. È fondamentale che gli advisor abbiano un network rilevante, siano noti nel settore di competenza del progetto e che abbiano delle success stories interessanti.

Community

Una community è un insieme di privati ed aziende che per motivi economici o ideologici infondono effort nello sviluppo di un progetto, tipicamente open source.

Una community blockchain aggiunge all’open-source una componente economica diretta, introducendo nuove tipologie di attori come gli stakeholder, i miner ed i service provider (sviluppatori di wallet, explorer ed altri servizi).

La dimensione e l’attività di una community è indispensabile per valutare lo stato di adozione e di salute di un progetto blockchain, infatti la dimensione e l’effort profuso da una community consentono di misurare:

  • il livello di adozione;
  • il livello di maturazione;
  • la velocità di evoluzione.

La prima cosa da verificare in una community blockchain, nel caso in cui il progetto sia già operativo, è verificare il numero di nodi partecipanti, recuperando un po di statistiche sul numero di utenti / wallet stimatinumero medio di transazioni giornaliere, volumi medi spostati sugli exchange per eventuali token associati.

Segue poi un’analisi sul volume e sulla velocità delle attività di sviluppo. Uno dei modi più efficaci per misurare il livello di attività di una community è quello di esaminare il repository della codebase di riferimento. Il repository è uno strumento che coordina l’effort di creazione e maintenance del codice sorgente di un progetto.

Il repository di solito viene mantenuto da un dev team che ha le autorizzazioni per apportare modifiche al codice, questo team è affiancato da una serie di sviluppatori esterni che possono proporre delle modifiche che devono essere accettate dai membri del dev team.

Le principali community open source usano ormai la stesso strumento di coordinamento, GitHub, una soluzione cloud per il repository di codice Git.

Dall’analisi di una pagina di progetto su GitHub si possono estrarre molti indicatori utili:

  • il numero di stars aiuta a valutare il livello di popolarità del progetto;
  • il numero di fork o cloni, che indica l’interesse nel riutilizzare o modificare il progetto;
  • il numero di developer e di contributor totali indica la potenza complessiva della community in termini di velocità di sviluppo;
  • Il numero di pull request / numero di merged pull request, che indica l’interesse della community, esterna al team di sviluppo, nel proporre nuove funzionalità o migliorare le esistenti;
  • Il numero di issues e active issues, che indicano il numero di problemi riscontrati dalla community e la velocità con cui il team dev risolve tali problemi;
  • la frequenza e quantità di commit, che indicano la velocità complessiva della community.

Business Plan

Passiamo finalmente alla valutazione del business plan del progetto, ci sono vari aspetti che possono essere presi in considerazione, ho riportato di seguito quelli a mio avviso più rilevanti.

  • Value proposition: definisce l’obiettivo di alto livello del progetto, il prodotto ne è la prima rappresentazione, ci deve essere uno stretto legame fra value proposition ed il progetto in esame. La Value Proposition e tutte le condizioni a contorno sono definite nel Business Model. Ci si aspetta che sia consistente ed interessante.
  • Token model: descrive i parametri principali dei/dei token emessi dal progetto, quantità e modalità di emissione, distribuzione e diritti concessi ai token holder. Ci si aspetta che sia coerente con la value proposition.
  • Financial plan e market size: fornisce delle stime quantitative sui volumi generabili dal progetto in funzione anche del market size potenziale. Ci si aspetta che sia proporzionata all’effort previsto dalla value proposition.
  • Stage: definisce lo stato di maturazione e quindi di rischio del progetto.

Il token model è strettamente legato al business model, se vuoi approfondire trovi qui un articolo sulle modalità di tokenizzazione di un business model.

Value Proposition

La value proposition definisce le caratteristiche che un prodotto o un servizio, in questo caso decentralizzato, che viene fornito ad una tipologia di utenti, e costituisce l’elemento centrale di ogni business model.

Un business model descrive la logica di come un’organizzazione crea, fornisce e acquisisce valore in contesti economici, sociali e culturali. Il processo di costruzione e modifica del business model è anche chiamato innovazione del business e fa parte della strategia aziendale. Un business model si evolve attraverso delle fasi iterative ed incrementali che vanno dall’ideazione all’espansione di un progetto.

Nella validazione del business model di un progetto blockchain è opportuno accertarsi che tutte le fasi di crescita del progetto siano state considerate opportunamente sotto gli aspetti di scalabilità e di equilibrio fra i vari attori del token model.

Token Model

Il Token Model definisce la tipologia di token associati al progetto, come i token vengono emessi, come vengono distribuiti tra gli stakeholder, che tipo di diritti garantiscono e come si relazionano al business model.

Il Token Model deve rimanere consistente con il Business Model in tutte le fasi di sviluppo di quest’ultimo, quindi deve essere chiaro quali siano le funzioni operative di un token dalla fase di funding alla fase di lancio di un progetto e per tutte le fasi di espansione.

Dettagli specifici su come si costruisce e quindi come comprendere un Token Model possono essere trovati nell’articolo Come costruire una ICO/STO.

Tokenomics

L’aspetto principale del Token Model è il sistema economico che definisce. Come per l’economia classica si definiscono aspetti di micro e macro economia, per i token si possono identificare delle caratteristiche di micro e macro tokenomics. Gli aspetti di microtokenomics definiscono le proprietà individuali del token e i flussi economici che dipendono direttamente dalle regole di generazione e utilizzo dei token, gli aspetti di macrotokenomics descrivono le proprietà complessive del network ed i flussi economici che dipendono dai token holder e dai partecipanti al network.

Perchè un progetto blockchain sia sano è necessario che gli aspetti di micro e macro tokenomics siano stati considerati e descritti per tutti i player in gioco.

Per maggiori informazioni consigliamo la lettura di questo articolo.

Legal

Altro aspetto rilevante è il supporto legale per il Token Model. Bisogna innanzitutto assicurarsi che il/i token emessi dal progetto siano effettivamente ciò che dichiarano di essere (molto spesso dei security token vengono dichiarati come utility), e poi bisogna assicurarsi che i diritti associati ai token siano opportunamente formalizzati a livello legale per la giurisdizione di riferimento.

Governance

Ultimo aspetto da considerare è la governance, ossia la capacità decisionale che viene riconosciuta ai token holder. A partire dal 2018 gli aspetti di governance sono risultati sempre più determinanti nel successo di un progetto blockchain, infatti diventa sempre più sentita da parte degli utenti la possibilità di controllare l’erogazione dei fondi (vedasi DAICO) e pesare nel processo decisionale.

Financial plan e Market Size

Il Financial Plan definisce quantitativamente l’efficacia attesa del progetto, anche se nessun financial plan si avvera realmente la sua assenza è un segnale preoccupante. Il Financial Plan tiene anche conto del market size, stima infatti il mercato potenziale raggiungibile dal prodotto, di solito per progetti blockchain si ragiona sempre in ambito worldwide, e quindi il volume di affari potenzialmente raggiungibile.

Bisogna assicurarsi che il financial plan sia dimensionato opportunamente per sostenere la realizzazione del progetto.

Market Cap

Altro aspetto per valutare l’efficacia di un progetto blockchain, nel caso abbia già superato la fase di funding, è il market cap, ossia il valore complessivo dei token in circolazione e quanto di questo capitale è in mano all’azienda che promuove il progetto.

Per recuperare rapidamente informazioni sulla capitalizzazione di un progetto Blockchain, sia esso una currency, una utility o una security si possono consultare diversi siti.

https://coinmarketcap.com

https://token.security/listing

Interessante anche osservare l’andamento temporale del valore del token nel tempo, in particolare come sta affrontando il crypto winter partito dal gennaio 2018 anche in relazione al comportamento con altri crypto asset.

L’operazione di capitalizzazione può accettare cryptocurrency, fiat o un misto. Al termine dell’operazione di capitalizzazione si procede tenendo/acquistando una riserva in cryptocurrency e tenendo/convertendo la restante parte in fiat per il finanziamento delle operazioni previste nel business plan.

Mediamente si convertono in fiat i fondi necessari per coprire il primo rilascio del prodotto. Per capire lo stato di salute di un progetto va quindi valutato se la raccolta è stata sufficiente a coprire i costi operativi per realizzare almeno il primo rilascio.

Nel valutare l’efficacia del market cap risulta poi indispensabile considerare lo stato di maturazione del progetto, se partiamo da un concept il market cap deve poter sostenere lo sviluppo (ed i rischi tecnologici connessi) della prima milestone operativa e la costruzione della community, così come dovrebbe essere previsto nel Financial Plan, se invece partiamo da un prototipo già funzionante i fondi raccolti possono essere concentrati nelle operazioni di consolidamento e dissemination.

Stage

Per stage intendiamo lo fase di sviluppo del progetto, di solito si individuano le seguenti fasi:

1. Fase concettuale: abbiamo solo lo sviluppo della value proposition

1.1. Fase prototipale: abbiamo già’ qualcosa funzionante, alcuni progetti sviluppano dei prototipi prima del funding, ma non è la regola.

2. Fase first funding: abbiamo ottenuto un finanziamento attraverso uno strumento ICO (e presto STO).

3. Fase di sviluppo: la piattaforma è finanziata ma non ha ancora rilasciato una prima release operativa.

4. Prima release operativa: abbiamo la prima release.

5. Successive release: abbiamo già successive release.

Inutile dire che più siamo avanti nello stage maggiore è la probabilità di sopravvivenza di un progetto. Inoltre più avanti è un progetto maggiore è la possibilità di verificare la risposta del mercato (potenziali utilizzatori) e della community (supporter, integratori e sviluppatori) allo stesso.

Ecco un libro che vi consiglio per approfondire l’argomento
https://www.amazon.it/Mastering-Blockchain-Distributed-technology-decentralization/dp/1788839048/?tag=niobium09-21