La necessità di interoperabilità nei protocolli dei token di sicurezza – Thought Leaders

Una breve storia dei token

È passato più di 10 anni da quando Bitcoin ha introdotto per la prima volta la tecnologia blockchain al mondo. In questo periodo, l’elenco dei potenziali casi d’uso per i registri distribuiti è cresciuto rapidamente, dalle valute digitali alle catene di approvvigionamento, alla gestione dell’identità. Tuttavia, alla base, molti di questi casi d’uso condividono una struttura simile: consentono agli utenti di detenere e trasferire asset digitali in modalità peer-to-peer. In parole semplici, ora possiamo scambiare e tracciare asset digitali senza la necessità di un’autorità centrale di fiducia che gestisca il processo.

Questa evoluzione dello spazio ha naturalmente portato all’invenzione dei “token” – asset digitali su una blockchain che sono possedibili e trasferibili tra individui. I token sono suddivisi in due categorie principali: quelli che rappresentano un asset nativamente digitale e quelli che rappresentano un asset reale sottostante. Sfruttando questo nuovo paradigma, centinaia di migliaia di token diversi sono già stati creati solo su Ethereum, con una capitalizzazione di mercato combinata di oltre 15 miliardi di dollari al momento della scrittura.

Una delle applicazioni più promettenti dei token è la rappresentazione di titoli del mondo reale on-chain, che consente di frazionare e trasferire asset tradizionalmente illiquidi, come gli immobili commerciali, in modalità peer-to-peer. Questo processo, noto come “tokenizzazione”, ha guadagnato notevole attenzione sia da parte delle istituzioni tradizionali sia delle start‑up emergenti, grazie al suo potenziale di alleviare molti dei problemi esistenti nei mercati dei capitali.

Conformità normativa

Sebbene la blockchain possa semplificare il trasferimento della proprietà in senso tecnico, i token di sicurezza sono comunque soggetti alle stesse leggi e regolamentazioni dei titoli tradizionali. Garantire che i token di sicurezza siano conformi alla normativa è quindi fondamentale per qualsiasi potenziale tokenizzazione, e finora è stato un ostacolo all’adozione. Come mostrato nel grafico sottostante, l’incertezza normativa è ampiamente considerata la più grande barriera all’adozione della blockchain.

Numerosi progetti sono emersi nello spazio blockchain, ciascuno progettando un protocollo che tenta di semplificare e standardizzare come i token di sicurezza siano regolamentati, scambiati e gestiti. Guardando solo a Ethereum, i progetti che hanno pubblicato standard per affrontare questo problema includono Securitize, Harbor, Polymath e altri. Tuttavia, in ultima analisi, senza modifiche al modo in cui questi protocolli sono attualmente progettati, investitori ed exchange continueranno a sperimentare attriti significativi quando comprano e vendono titoli tokenizzati. Perché? Interoperabilità.

L’interoperabilità è fondamentale

L’interoperabilità è uno dei vantaggi più significativi della tokenizzazione. Consente a un intero ecosistema di applicazioni e prodotti dei mercati dei capitali di integrarsi tra loro perché condividono standard software comuni. Tuttavia, per abilitare l’interoperabilità a livello di applicazione e prodotto, è necessario partire dal livello più basso, ovvero i token stessi. Nel settore dei token di sicurezza, l’interoperabilità è essenziale per due parti chiave: exchange e investitori.

Come exchange, vuoi poter autorizzare gli investitori all’acquisto di qualsiasi token di sicurezza per il quale siano idonei – indipendentemente dalla società che ha creato il token. Questo significa non dover realizzare un’integrazione su misura per ogni token di sicurezza, ma una semplice integrazione generica uniforme per tutti i token di sicurezza.

Come investitore, desideri che il processo di onboarding sia il più semplice e privo di attriti possibile. Attualmente, quando un investitore vuole acquistare azioni da più fonti, deve fornire le proprie informazioni personali più volte in un processo chiamato Know Your Customer “KYC”. La blockchain ha il potenziale di trasformare questo processo memorizzando tali informazioni in modo immutabile on-chain, dove possono poi essere richiamate da tutti i token di sicurezza. Ciò significherebbe non dover fornire ripetutamente le stesse informazioni personali ogni volta che si desidera acquistare un nuovo token, ma solo informazioni supplementari o aggiornate dopo la registrazione iniziale. Tuttavia, questo processo sarà possibile solo se l’interoperabilità tra token di sicurezza è incorporata negli standard che governano il sistema.

I protocolli

Tre dei principali protocolli di token di sicurezza su Ethereum sono stati pubblicati da Securitize, Harbor e Polymath. Tutti e tre questi protocolli si basano sullo standard ERC-20 di Ethereum, che poi estendono per imporre la conformità nel trading del token di sicurezza. Questo è ottenuto interrogando un secondo contratto sulla legalità di ogni scambio al momento in cui avviene.

Sebbene denominati diversamente nei protocolli, l’uso di un secondo contratto è coerente in tutti e tre, ottenendo lo stesso risultato: impedire scambi non conformi. Questo secondo contratto “Regolatore” è aggiornato con le informazioni KYC e di accreditamento degli utenti da servizi off-chain autorizzati – ad esempio un exchange o l’emittente del token.

Anche se questi tre componenti possono sembrare tutto ciò di cui hai bisogno per regolare un token di sicurezza (e nella forma più semplice lo sono), è il modo in cui i componenti sono programmati che determina realmente l’interoperabilità. Purtroppo, i protocolli mancano di interoperabilità in due aree chiave, il che continuerà a causare attriti e a rallentare l’adozione di questa tecnologia:

1. Come aggiornano le parti autorizzate le informazioni on-chain sugli utenti?

Harbor

Harbor dichiara nel proprio whitepaper che sarà l’unica parte autorizzata ad aggiornare le informazioni degli utenti on-chain per il momento. La centralizzazione di questo ruolo significa che gli exchange non aggiornerebbero alcun dato a cui fa riferimento il Regolatore. Di conseguenza non potranno approvare nuovi destinatari del token, impedendo che i token vengano scambiati facilmente al di fuori della piattaforma Harbor.

Securitize

Securitize ha già implementato un sistema in cui più parti possono essere autorizzate, il che significa che gli investitori possono registrare le proprie informazioni di conformità in più luoghi e non sono tenuti a passare attraverso Securitize direttamente. I dati on-chain sono quindi aggiornati direttamente dalla parte autorizzata e possono essere visualizzati da tutti i token di Securitize. Inoltre, per evitare che gli investitori debbano fornire le informazioni più volte, Securitize ha progettato un’API che consente alle parti autorizzate di accedere alle informazioni private sugli investitori memorizzate off-chain, permettendo loro di determinare facilmente se un individuo è conforme o se sono necessarie ulteriori informazioni.

Polymath

Polymath ha un token digitale di utilità nativo chiamato POLY che è richiesto in tutta la loro piattaforma per svolgere varie attività, incluso far aggiornare i dati on-chain da una parte autorizzata. Perché un individuo possa fare il KYC, deve prima acquistare token POLY, i quali non hanno un mercato fiat‑POLY liquido. Invece, l’individuo deve acquistare un’altra criptovaluta come l’“ether” (ETH) di Ethereum usando fiat, per poi scambiarla con POLY. I token possono quindi essere usati sul marketplace KYC di Polymath per fare un’offerta a un fornitore KYC. Se il fornitore KYC approva l’offerta, viene pagato in token POLY per effettuare il controllo KYC per l’individuo. Questo processo rappresenta chiaramente un notevole attrito di onboarding sulla piattaforma Polymath, rendendo il processo più complesso del necessario.

2. Come queste informazioni sugli utenti vengono poi archiviate e accessibili on-chain?

Harbor

Dallo studio del whitepaper e dei contratti intelligenti su GitHub, è tecnicamente possibile che molti dei token di Harbor condividano un unico contratto Regolatore comune e una fonte comune di dati utente, tuttavia ciò è improbabile a causa delle differenze normative tra i vari token. L’assenza di token Harbor live su Ethereum non ha chiarito se fosse loro intenzione che ciò avvenga, o se ogni token verrà distribuito con il proprio Regolatore.

Securitize

Il protocollo di Securitize è progettato in modo che il loro contratto Regolatore interroghi un terzo contratto intelligente che memorizza le informazioni degli utenti. Questo consente a ciascun token di avere normative uniche codificate nel proprio Regolatore, pur condividendo una fonte comune di dati utente nel terzo contratto, il che significa che quando un utente effettua il KYC per un token Securitize le sue informazioni sono memorizzate pronte per l’acquisto di token futuri.

Polymath

Il whitepaper non specifica esplicitamente se Polymath abbia una fonte centrale di dati di conformità memorizzata on-chain a cui ogni Regolatore interagisca, o se i token abbiano una propria fonte locale di informazioni. Tuttavia, basandosi sui contratti di esempio di Polymath, sembra che ogni token utilizzi una fonte locale di informazioni, non condivisa tra token diversi. Sebbene ciò possa avere vantaggi, questa configurazione rischia ridondanza e incoerenze nei dati.

Consideriamo il seguente esempio: Bob ha mostrato interesse per due token di sicurezza Polymath, ABC e DEF, ed è stato approvato come investitore per entrambi. Queste informazioni sono inviate al contratto Regolatore di ciascun token. Un mese dopo, Bob tenta di acquistare ulteriori token DEF ma si scopre che non è più accreditato. Questa informazione è inviata al Regolatore di DEF per aggiornare lo stato di Bob a non accreditato. Ora, on-chain, ci sono informazioni contrastanti: ABC pensa che Bob sia un investitore verificato, mentre DEF non è d’accordo. È facile vedere che una fonte centrale di informazioni eviterebbe tali discrepanze.

Interoperabilità dei protocolli

Come discusso in precedenza, ci sono due parti principali coinvolte nell’emissione e nello scambio di token di sicurezza per le quali l’interoperabilità sarà di grande importanza: exchange e investitori. Entrambe queste parti desiderano un’esperienza fluida quando interagiscono con token di sicurezza diversi. Quindi, se si utilizzano i protocolli così come sono, diamo un’occhiata a come gli exchange e gli utenti saranno influenzati.

Exchange

Come exchange, integrare questi protocolli per scopi di trasferimento è semplice: tutti i token utilizzano lo standard ERC-20, fornendo un’interfaccia uniforme per invocare trasferimenti, approvazioni e controlli di saldo. Tuttavia, l’integrazione più approfondita con l’aspetto di conformità di ogni protocollo diventa molto più complessa. Ricorderai che attualmente non è possibile per una parte fidata diventare autorizzata sul protocollo di Harbor – dovrà invece indirizzare gli utenti a Harbor per fare il KYC. Per integrare il protocollo di Securitize, la parte fidata deve essere autorizzata da Securitize, il che le consentirà di accedere ai dati KYC degli investitori tramite l’API off-chain e di aggiornare le informazioni on-chain memorizzate nel data store on-chain.

Integrare il protocollo di Polymath è probabilmente il più complesso. La parte fidata deve registrarsi come fornitore KYC sul marketplace KYC di Polymath e configurarsi per ricevere offerte in token POLY in cambio dei servizi KYC. Fornendo servizi KYC agli investitori, la parte fidata deve poi organizzare un modo per garantire che i dati on-chain duplicati memorizzati su ciascun Regolatore del token non diventino incoerenti.

Non solo i protocolli hanno interfacce diverse che la parte fidata deve integrare, ma ciascun protocollo ha anche un metodo diverso per fornire report di errore all’exchange. Quando si costruisce un’interfaccia è importante poter tradurre eventuali errori in qualcosa di comprensibile per gli utenti. Per esempio, se un utente non può acquistare un token questo può dipendere da una varietà di ragioni: il titolo potrebbe avere un periodo di detenzione non ancora soddisfatto, oppure potrebbe limitare il numero massimo di detentori consentiti. Per comunicare questi messaggi agli utenti, l’exchange dovrebbe integrare un metodo di report di errore diverso per ciascun protocollo.

Investitori

I diversi metodi con cui l’onboarding degli investitori è attualmente progettato nei protocolli significano che gli investitori probabilmente dovranno fornire informazioni personali molte volte a piattaforme diverse e in modi differenti. Questo è causato dal fatto che Harbor non ha autorizzato altre parti, e Polymath richiede agli investitori di fare offerte per i processi KYC usando token POLY. L’attrito causato dall’applicazione di questi metodi di conformità può rendere gli investitori riluttanti o incapaci di acquistare titoli che altrimenti acquisterebbero.

La portata di questo attrito indotto dal protocollo sugli investitori potrebbe essere in parte alleviata dal modo in cui gli exchange integrano ciascuno dei protocolli. Per esempio, se un investitore sceglie di fare il KYC su un exchange per acquistare un token Polymath, quell’exchange, se autorizzato, potrebbe scegliere di aggiornare contemporaneamente lo storage dati di Securitize. Ciò significherebbe che le informazioni dell’investitore sono on-chain nel caso fossero necessarie in futuro. Tuttavia, se non vengono apportate modifiche ai design attuali dei protocolli, il processo di registrazione e acquisto di titoli rimarrà arduo.

Soluzioni

La soluzione a questo problema non deve essere complessa. Infatti, è possibile introdurre certe soluzioni senza modificare alcun token già attivo su Ethereum. Una soluzione ideale che comporti minima frizione sia per gli exchange sia per gli investitori, e che prevenga incoerenze nei dati causate da molteplici fonti di dati di conformità, assomiglierebbe molto al data store centralizzato on-chain di Securitize; tuttavia, una tale configurazione dovrebbe essere adottata su scala industriale.

Avendo una fonte centrale di informazioni on-chain, i rischi di incoerenze nei dati vengono eliminati e gli investitori possono acquistare diversi titoli attraverso una sola verifica di conformità. Questo contratto centrale eseguirebbe la verifica che il trasferimento sia conforme per tutti i token di sicurezza, e il trasferimento continuerebbe o verrebbe annullato. L’API off-chain accessibile a tutti gli exchange autorizzati permette di comunicare le informazioni di conformità degli investitori agli exchange, riducendo il numero di volte in cui gli investitori devono fornire dati. Questi aspetti insieme riducono notevolmente il lavoro di integrazione richiesto dagli exchange.

L’introduzione di un nuovo sistema come questo comporta chiaramente alcune complicazioni, e diversi problemi dovrebbero ancora essere risolti. Per esempio, nella progettazione di come ogni exchange diventa autorizzato: chi prende la decisione che un exchange debba essere considerato affidabile? È necessario dedicare tempo alla progettazione di un sistema che consenta di raggiungere un consenso.

Conclusione

La tokenizzazione dei titoli è ancora un’area in fase di sviluppo e adozione precoce, in parte a causa delle complessità della conformità normativa. Sebbene la pubblicazione dei protocolli semplifichi la conformità a molte di queste normative consentendo di farle rispettare nell’esecuzione di ogni trasferimento, c’è ancora molta strada da fare prima che questo sia un processo senza soluzione di continuità. Finché non avremo un accordo tra i protocolli su come le informazioni degli investitori siano archiviate e aggiornate sia on-chain sia off-chain, rimarrà un significativo attrito nei processi di registrazione e investimento per tutte le parti coinvolte.