In Aggiornamento  della Community Migration Committee #3.2 – Attivazione post Lancio

In Aggiornamento  della Community Migration Committee #3.2 - Attivazione post Lancio

Comunicazione Pubblica: Catapult Migration (3.2) – Procedura di Attivazione post Lancio

Questo è un messaggio congiunto per la nostra comunità a nome del gruppo Migration Catapult, composto da NEM Foundation, NEM Studios, NEM Ventures e Tech Bureau Holdings.

Esiste anche un post di domande frequenti come riferimento: Migration Committee Community Update #3 (Revised Recommendation) 3

Procedura di Attivazione post Lancio

Post launcher (dopo il lancio) opt-in (abbonamento), per i possessori di token NIS1 (attuale Mainnet pubblica), se gli utenti, per qualsiasi motivo, decidono di non distribuire token, gli aggiornamenti del software Catapult il primo giorno e decidono rinviare questo processo (per qualsiasi motivo) fino all’avvio (avvio) dell’aggiornamento del software Catapult NIS2. Come parte di questo processo di opt-in (abbonamento) o opt-out (rifiuto), ci sarà una certa proporzione di token che vengono creati durante l’avvio di un aggiornamento del software Catapult, ma non possono essere assegnati al titolare del token (per qualsiasi motivo). Quindi cosa accadrà a questi token non rivendicati?

La raccomandazione originale del Migration Committee era che tutti i token non richiesti saranno presi sotto il controllo del custode dell’organizzazione (SPV) – l’entità legale che dovrebbe essere responsabile della gestione e della conservazione dei token non richiesti dell’aggiornamento del software Catapult fino alla scadenza del reclamo (durata che sarà di almeno 5-6 anni), quindi il processo di masterizzazione di token non riscossi verrà eseguito alla fine del periodo di conservazione. Questo processo può essere implementato in processi di masterizzazione di token sia manuali che automatizzati. Questo custode dell’organizzazione (SPV) avrà documenti completamente trasparenti, statuti fiduciari e anche un team di gestione con esperienza che sarà legalmente responsabile della gestione dei token non richiesti dell’aggiornamento del software Catapult, in conformità con la politica interna fornita Organizzazione depositaria (SPV).

Dopo aver ricevuto feedback dai proprietari verificati di Supernode in merito alla creazione di un’organizzazione depositaria (SPV) e hanno espresso la loro opinione che la creazione di un’organizzazione depositaria non è l’opzione giusta e preferita, pertanto la soluzione migliore per i token non riscossi sarà una soluzione basata sul monitoraggio e sulla gestione, come sulla rete NIS1 o creando una soluzione di gestione che sarebbe controllata dai proprietari di Supernode. Vorrei sottolineare che questa decisione non è definitiva, quindi vorremmo ricevere feedback dalla comunità NEM.

Sono necessarie ulteriori analisi riguardanti:

  1. Le opzioni tecniche per l’estensione della soluzione di monitoraggio del supernodo per garantire che sia effettivamente praticabile
  2. Analisi giuridica per accertare se uno / tutti / alcuni dei detentori di supernodi incorrerebbero in responsabilità legale se dovessero gestire i token non reclamati e, in tal caso, che le parti coinvolte accettino tale responsabilità in modo trasparente.
  3. Allo stesso modo la posizione legale di qualcuno che cambia il monitor Supernode e lo ospita per svolgere questo ruolo.

Un passaggio all’Op-Out (dall’Op-In) offre l’opportunità di includere l’accettazione di qualsiasi soluzione utilizzata per il processo di Opt In post lancio come parte della Ux, firmando effettivamente un contratto per i loro token gestiti dal processo concordato .

Il precedente approccio Opt In avrebbe assegnato tutte le monete non riscosse di default da gestire dopo il lancio, senza interazione da parte dei titolari. La rinuncia esplicita richiede interazione e quindi decisione / autorizzazione esplicite.

Questo potrebbe cambiare la posizione filosofica di alcune persone sul modo in cui i token non rivendicati sono gestiti al meglio, oppure no. È importante che qualsiasi gruppo intraprenda la gestione dei token non richiesti per conto dell’ecosistema sia pienamente consapevole e accettando la responsabilità legale che potrebbe derivare dal farlo in caso di problemi.

Siamo interessati a tutte le idee, i commenti, le domande ecc. Su questo argomento, in quanto è una cosa di cui la comunità deve essere d’accordo e che ci sono vantaggi / svantaggi in tutte le opzioni.