Non parlo dei processi di trading NPEX, non parlo dell'economia dei token, non parlo dell'architettura del layer esecutivo e non ripeto quelle parole chiave precedenti. Utilizzo un'angolazione più dettagliata: se Dusk vuole servire asset regolamentati, quali componenti di conformità operativa sono necessari sulla catena? Mancarne uno causerebbe blocchi.
La prima categoria è il sistema di identità e autorizzazioni. Gli asset regolamentati devono avere confini chiari su "chi può possedere, chi può scambiare, chi può ricevere"; non basta dire KYC, ma è necessario formare un giudizio di autorizzazione chiamabile sulla catena. Ad esempio, gli account devono poter essere classificati (al dettaglio, professionale, istituzionale), le autorizzazioni devono poter essere aggiornate in qualsiasi momento (tramite revisione, scadenza, ri-certificazione) e tutte le modifiche devono avere registrazioni tracciabili. Altrimenti, l'emittente e la piattaforma non possono provare di adempiere continuamente agli obblighi di conformità.
La seconda categoria è il motore per le restrizioni di trasferimento e di detenzione. Gli asset titoli spesso presentano regole come periodi di blocco per il trasferimento, limiti di detenzione, limiti di transazione singola, restrizioni geografiche e limitazioni sui beneficiari. La vera difficoltà non è scrivere queste regole, ma trasformarle in moduli configurabili, riutilizzabili e aggiornabili, garantendo al contempo che l'aggiornamento non rompa la logica di vincolo degli asset esistenti. Se Dusk vuole scalare e accettare asset, non può chiedere a ogni emittente di scrivere un sacco di contratti restrittivi, altrimenti i costi di audit esploderanno e sarà difficile rispondere a eventuali problemi.
La terza categoria è quella degli eventi di conformità e delle registrazioni dimostrabili. Nei sistemi regolamentati, la cosa più comune non è "transazione riuscita", ma "transazione rifiutata e devi spiegare perché". Sulla catena deve essere possibile registrare il motivo del rifiuto, le clausole delle regole che hanno scatenato il rifiuto, lo stato degli account correlati e il percorso di audit corrispondente.
La quarta categoria è la capacità di gestione delle emergenze. Nel mondo reale, un account può essere sanzionato, gli asset possono essere congelati dalla giustizia e un'emissione errata può necessitare di correzione. Se sulla catena non ci sono interfacce di gestione controllabili, si può solo sperare che il mercato si auto-ripari dopo un incidente, il che è inaccettabile per gli asset regolamentati. Qui la chiave non è "può congelare", ma le condizioni di attivazione per congelare, decongelare e correggere, i confini di autorizzazione e la chiarezza della auditabilità dell'intero processo.
