Sviluppo di piattaforme per la tokenizzazione degli asset

Quando conviene sviluppare una piattaforma di tokenizzazione da zero?

Lo sviluppo ex novo è opportuno quando la struttura dell’asset, i requisiti di conformità o la logica commerciale non possono essere rappresentati accuratamente da una piattaforma esistente o da uno standard di token. Ciò si verifica solitamente quando l’asset presenta meccanismi di proprietà non standard, la piattaforma deve supportare più tipi di asset o emittenti nel corso del tempo, oppure quando l’emittente richiede il pieno controllo sulla logica del contratto.

Come garantite la conformità normativa on-chain?

Le regole di conformità sono integrate nella logica di trasferimento dello smart contract, pertanto ogni transazione viene verificata rispetto alle condizioni applicabili prima della sua esecuzione. In altre parole, il contratto verifica l’indirizzo di destinazione confrontandolo con una whitelist verificata tramite KYC, conferma il livello assegnato all’investitore, verifica i limiti di detenzione specifici per giurisdizione e applica eventuali requisiti di lock-up o di approvazione come parte integrante della richiesta di trasferimento stessa. Se una qualsiasi condizione non viene soddisfatta, la transazione viene annullata.

Come vengono verificati i dati e gli eventi provenienti dall’esterno?

I dati esterni vengono inseriti nello smart contract tramite un oracolo, che funge da ponte di dati verificato tra le fonti off-chain e lo stato on-chain. L’architettura dell’oracolo è progettata per soddisfare i requisiti specifici di ciascuna classe di asset. I dati vengono firmati crittograficamente alla fonte e convalidati dal contratto prima di influire sull’offerta di token, sui calcoli di distribuzione o sulle condizioni di idoneità. Se sono necessarie più fonti di dati, la progettazione può incorporare logiche di aggregazione e risoluzione dei conflitti, in modo che il contratto non dipenda da un singolo punto di errore nel flusso di dati.

La piattaforma può supportare mercati secondari e meccanismi di liquidità?

Sì, la funzionalità del mercato secondario è integrata nell’architettura della piattaforma sin dall’inizio. La logica di trasferimento applica tutte le restrizioni applicabili a ogni transazione secondaria. I periodi di lock-up, i controlli sull’idoneità delle controparti, i flussi di lavoro per l’approvazione dei trasferimenti e i limiti specifici per giurisdizione si applicano a livello di contratto, indipendentemente dalla sede in cui ha origine la transazione. La piattaforma può essere configurata per supportare trasferimenti peer-to-peer, un libro degli ordini integrato o l’integrazione con un mercato secondario autorizzato gestito dall’emittente o da un ATS regolamentato. Per gli asset per i quali la liquidità DeFi è appropriata, il contratto può essere progettato con hook conformi che consentono l’interazione con protocolli esterni, mantenendo al contempo l’applicazione della whitelist in ogni punto di integrazione.

In che modo gli audit e le verifiche di sicurezza si inseriscono nel processo di sviluppo?

La revisione della sicurezza inizia con la modellazione delle minacce durante la fase di progettazione dell'architettura, in cui vengono identificate le superfici di attacco prima ancora che venga scritto il codice del contratto. Durante tutto il processo di sviluppo, manteniamo dei test invarianti parallelamente al codice del contratto e li eseguiamo continuamente come parte della suite di test. Prima di qualsiasi implementazione, viene condotta una verifica indipendente da parte di terzi sul codice finale del contratto e sulle relative specifiche.

Quali sono i costi di sviluppo di una piattaforma di tokenizzazione?

I costi di sviluppo possono variare al rialzo o al ribasso a seconda della complessità della struttura degli asset, del modello di conformità, del numero di tipologie di asset che la piattaforma deve supportare e della portata delle integrazioni richieste. Pertanto, non è realistico fornire cifre precise. Una piattaforma dedicata a una singola classe di asset ben definita, con una struttura giuridica semplice, avrà un costo notevolmente inferiore rispetto a una realizzata per supportare più tipologie di asset in diverse giurisdizioni, dotata di un mercato secondario completo e di un livello API istituzionale. Gli esperti di Innowise saranno lieti di fornirvi una valutazione diretta basata sulle vostre specifiche esigenze.