Este es un mensaje conjunto para nuestra comunidad en nombre del Symbol Migration Group, compuesto por The NEM Foundation, NEM Studios, NEM Ventures y Tech Bureau Holdings.
Tokenomics
Recientemente, las discusiones de NIS1 han ocupado un lugar destacado en la agenda del Comité de Migración. Hemos ilustrado en el pasado (en respuesta al sentimiento de la comunidad) que avanzaríamos con el desarrollo de Symbol sin olvidarnos de la red NEM que lo inició todo. Las conversaciones actuales y la planificación giran en torno a 4 temas principales:
Programa supernodo futuro en NIS1
Plan de garantía de nodo más amplio implementado
Revisión de Tokenomics
Comunidad y soporte para desarrolladores
Ingeniería
Servidor
Se realizó un lanzamiento del parche en el servidor para la versión 0.9.3.2. Este pequeño parche cubre una actualización de la versión rocksDb con un aumento a v6.6.4. Se han publicado imágenes de lanzamiento y se han actualizado las referencias de imágenes relacionadas en la herramienta de arranque testnet.
El equipo está trabajando para completar la próxima actualización importante, actualmente destinada a ser la versión 0.9.4.1. Esta actualización traerá un gran cambio en las comunicaciones entre pares / servidor que se cambiarán para aprovechar el estándar TLS 1.3.
Opt-In
Se sigue avanzando en las herramientas para impulsar el proceso de suscripción. El último esfuerzo de trabajo se ha centrado en la actualización para admitir los cambios introducidos en la versión 0.9.3.x del servidor, específicamente la actualización para dejar de admitir la compatibilidad con versiones anteriores de las claves NIS1. Las actualizaciones 0.9.3.x se completarán pronto con un esfuerzo de trabajo y luego se centrará en finalizar los flujos y la funcionalidad de UI / UX tanto para el complemento de billetera nano como para una aplicación de suscripción móvil dirigida. Una vez listo, el equipo intentará lanzar una versión NIS1 testnet para las pruebas finales previas al lanzamiento y recopilar comentarios del público.
Móvil
La billetera móvil está a punto de completarse y está lista para pruebas externas. Para aquellos que se han inscrito para participar, gracias por hacerlo y ser pacientes. El equipo apunta a la función beta completa esta semana. A partir de ese momento, los pasos finales serán la aplicación de actualizaciones de marca, similares a las actualizaciones de marca recientes aplicadas a la billetera de escritorio, luego la configuración y el uso compartido para probadores externos.
Pruebas
Las pruebas generales de los diversos componentes continúan. Un nuevo esfuerzo que comenzará esta semana es una campaña de prueba pública en la plataforma HackerOne. Para aquellos interesados en participar, regístrese allí (https://hackerone.com). La campaña se lanzará esta semana.
Este documento tiene como objetivo proporcionar un estándar para la emisión y gestión de tokens de seguridad en Symbol. Este estándar se estructurará de tal manera que las interfaces estándar se definirán para facilitar las operaciones e interrogatorios relacionados con los tokens de seguridad.
Motivación
Facilitar y acelerar los procesos de emisión y gestión de tokens de seguridad en Symbol.
Para emitir y administrar valores en Symbol, este estándar aprovechará varias características de Symbol. Los detalles de implementación se describirán en un documento conjuntamente con esta definición estándar.
Requisitos
Los estándares de token de seguridad que se describirán en este documento se basarán en las funciones disponibles con las redes Symbol. Además, para cada estándar, definiremos los requisitos que se aplicarán a la clase de activo subyacente.
DEBE tener una interfaz estándar para consultar la viabilidad de una transferencia y devolver un motivo de fallas.
DEBE poder realizar transferencias forzadas para acciones legales o recuperación de fondos.
DEBE definir notificaciones estándar para los procesos de emisión y reembolso.
DEBE poder adjuntar metadatos a un subconjunto del saldo del titular del token.
DEBE poder modificar los metadatos en el momento de la transferencia en función de los datos fuera de la cadena, los datos dentro de la cadena y los parámetros de la transferencia.
DEBE admitir consultas y suscribirse a actualizaciones en cualquier documentación relevante para la seguridad.
PUEDE requerir que los datos firmados se pasen a una transacción de transferencia para validarlos en la cadena.
NO DEBE restringir el rango de clases de activos en las jurisdicciones que pueden representarse.
La siguiente tabla de características se utilizará para definir las características obligatorias del paquete de software publicado:
Característica
Motivación
Emisión
La emisión de tokens de seguridad se gestiona a través del propietario
Delegación de poder del emisor
Se puede permitir a los operadores tareas de administración específicas de los tokens de seguridad
Transferencia
Los tokens de seguridad se pueden transferir (cambiar de propietario)
Transferencia por lotes
Los tokens de seguridad se pueden transferir en lotes (cambiar de propietario)
Transferencia con metadatos
Se pueden agregar metadatos a las transferencias de tokens de seguridad
Gestión de metadatos
Los metadatos se pueden administrar para tokens de seguridad
Restricciones de transferencia
Las transferencias de tokens de seguridad pueden restringirse (restricciones)
Congelar / Bloquear
Los operadores pueden congelar / bloquear los saldos de tokens de seguridad
Cumplimiento del operador
A los operadores se les puede permitir tareas de ejecución (como transferencias)
Transferencia de fuerza
Se pueden aplicar transferencias de tokens de seguridad.
Señal de error
La señalización de error se describe para cada estándar
Gestión de documentos
Los documentos se pueden adjuntar a tokens de seguridad [propietarios]
Comandos de token de seguridad NEM
Los estándares de token de seguridad de NEM introducen el término de comandos que se ejecutan para tokens específicos. Por ejemplo, la transferencia del token se realiza ejecutando el comando TransferOwnership para dicho token.
Este concepto de comandos estará disponible para todos los estándares de token de seguridad NEM. Como tal, definiremos una lista de comandos que también se definirán técnicamente en los detalles de implementación.
Comando del Token
Base Lógica
PublishToken
Emitir / publicar un token creado previamente (no reversible)
TransferOwnership
Transfiere un token a un nuevo propietario
TransferOwnershipWithData
Transfiera un token a un nuevo propietario, agregando datos firmados como mensaje
BatchTransferOwnership
Tokens de transferencia por lotes a nuevos propietarios
ForcedTransfer
Forzar la transferencia de un token a un nuevo propietario, con una cuenta de operador
LockBalance
Congelar / Bloquear un saldo de token
UnlockBalance
Descongelar / Desbloquear un saldo de token
ModifyRestriction
Enviar modificaciones a la cuenta / restricciones de mosaico
ModifyMetadata
Enviar modificaciones a los metadatos de cuenta / mosaico
DelegateIssuerPower
Delegar autorizaciones de emisión a la (s) cuenta (s) del operador
AttachDocument
Adjuntar documentos a una instancia de token
Restricciones del Token de Seguridad de NEM
⚠️ Las restricciones específicas de token y cuenta deben describirse aquí.
Metadatos de token de seguridad NEM
⚠️ El uso estándar de metadatos para tokens, cuentas y espacios de nombres debe describirse aquí.
Estándares de NameSpaces
Debido a que cada uno de los estándares de token de seguridad de NEM se comportará de manera diferente a los demás con respecto a las integraciones del conjunto de características, implementaremos comandos de tal manera que cada estándar pueda definir su propia extensión al flujo de ejecución de comandos estándar.
Los comandos se agruparán en espacios de nombres de modo que cada Estándar de token de seguridad de NEM pueda implementar comandos con sus propias prácticas de integración de conjuntos de características. Los siguientes ejemplos PUEDEN aplicarse:
Use el estándar NIP13 y ejecute el comando PublishToken
// Import NIP13 namespace
import { NIP13 } from 'symbol-security-tokens';
// prepare
const tokenId = new TokenIdentifier();
const command = new NIP13.PublishToken();
const options = [Option.create('tokenId', tokenId.toString())];
// now execute command
const result = command.execute(tokenId, options);
Estandares NEM
Las siguientes funciones están disponibles con nuestro estándar de token de seguridad:
NIP # 13 presenta un estándar de token de seguridad NEM que se implementará principalmente con mosaicos, cuentas y transacciones de múltiples firmas. El trabajo en este estándar no ha comenzado en el momento de la escritura.
Notas de integración
Comando
Flujo de ejecución
PublishToken
1) Crea una cuenta de operador determinista 2) Convierta la cuenta del operador en firma múltiple 3) Publique la transacción de prueba de creación en una cuenta determinista 4) Crear mosaico con cuenta de operador
TransferOwnership
1) Cambiar la propiedad del token a través de la modificación de múltiples firmas utilizando la transacción como prueba de ejecución
TransferOwnershipWithData
1) Preparar datos firmados (lado del cliente de terceros) 2) Cambie la propiedad del token a través de la modificación de firma múltiple utilizando la transacción como prueba de ejecución y adjunte datos firmados dentro de la transacción de transferencia desde la cuenta del operador
ForcedTransfer
1) TBD: debe usar restricciones de mosaico
BatchTransferOwnership
1) Cambiar la propiedad de tokens con múltiples transacciones de prueba de ejecución
DelegateIssuerPower
1) Modificar una cuenta de firma múltiple para agregar / eliminar operadores
AttachDocument
1) Publicar hash criptográfico de documento 2) Enviar mensaje en transacción a cuenta determinista
Biblioteca de tokens de seguridad NEM
Este documento define un propósito general NEM Security Token Standards (NST). Esos estándares definidos aprovecharán diferentes conjuntos de características de redes Symbol. Se deben describir detalles de implementación más detallados en el documento de detalles de implementación.
Especificaciones
Para generalizar y facilitar la emisión y administración de tokens de seguridad con Symbol, publicaremos un paquete de software que integra todos los Estándares de tokens de seguridad NEM.
Aún así, cada uno de nuestros diferentes estándares implementará características de manera diferente para ser más flexible y permitir un alcance más amplio de integraciones o implementaciones de casos de uso.
El paquete de software lanzado se desarrollará con Typescript, utilizando el paquete symbol-sdk @> = 0.17.3 para integrar las últimas características de Symbol. La biblioteca DEBE proporcionar interfaces y clases, que los desarrolladores pueden aprovechar para administrar la emisión y el canje de tokens de seguridad en Symbol.
Como prueba de concepto para esta biblioteca, PODEMOS presentar una interfaz de línea de comando (CLI) o una aplicación web básica para proporcionar soporte de token de seguridad listo para usar para Symbol.
Paquetes
Se producirá un paquete entregable junto con este NIP. La denominación de este paquete aún no se ha definido.
Las siguientes son las sugerencias de nombre de paquete disponibles, se pueden agregar más en un momento posterior:
symbol-security-tokens
symbol-financial-instruments
symbol-financial-tools
symbol-derivatives
symbol-instruments
El proceso de toma de decisiones para esta selección de nombre de paquete se realizará internamente, se aceptan más sugerencias.
Propuesta de arquitectura
Cada uno de nuestros estándares de token de seguridad implementará características con un conjunto de características predefinido de Symbol. Es importante tener en cuenta que este conocimiento influirá en la arquitectura del paquete de lanzamiento. Se puede aplicar la siguiente propuesta de solución:
Se define una interfaz estándar que DEBE contener los siguientes métodos:
/**
* Creates a new Security Token with pre-defined Catapult feature set.
*
* @param {string} name
* @param {Address} owner
* @param {TokenSource} source
* @param {Array<Address>} operators
* @return {TokenIdentifier}
**/
public create(
name: string,
owner: Address,
source: TokenSource,
operators: [Address] = []): TokenIdentifier;
/**
* Publish a previously created Security Token with identifier `tokenId`.
*
* @internal This method MUST use the `PublishToken.execute()` method.
* @param {string} name
* @param {Address} owner
* @param {Array<Address>} operators
* @return {PublicProof}
**/
public publish(
tokenId: TokenIdentifier): PublicProof;
/**
* Notify an account `account` about
* Publish a previously created Security Token with identifier `tokenId`.
*
* @internal This method MUST use the `PublishToken` command.
* @param {string} name
* @param {Address} owner
* @param {Array<Address>} operators
* @return {PublicProof}
**/
public notify(
tokenId: TokenIdentifier,
account: Address,
notification: AccountNotification): NotificationProof;
/**
* Verifies **allowance** of `sender` to transfer `tokenId` security token.
*
* @param {Address} sender
* @param {TokenIdentifier} tokenId
* @return {AllowanceResult}
**/
public canTransfer(
sender: Address,
tokenId: TokenIdentifier): AllowanceResult;
/**
* Verifies **allowance** of `operator` to execute `command` with `tokenId` security token.
*
* @internal This method MUST use the `command.canExecute()` method.
* @param {Address} operator
* @param {Address} account
* @param {TokenIdentifier} tokenId
* @param {Command} command
* @param {Array<Option>} argv
* @return {AllowanceResult}
**/
public canExecute(
operator: Address,
account: Address,
tokenId: TokenIdentifier,
command: Command,
argv: [Option] = []): AllowanceResult;
/**
* Execute `command` for Security Token with identifier `tokenId`. Arguments
* the command execution can be passed in `argv`.
*
* @internal This method MUST use the `command.execute()` method.
* @param {Address} operator
* @param {Address} account
* @param {TokenIdentifier} tokenId
* @param {Command} command
* @param {Array<Option>} argv
* @return {CommandResult}
**/
public execute(
operator: Address,
account: Address,
tokenId: TokenIdentifier,
command: Command,
argv: [Option] = []): CommandResult;
/**
* Read metadata of a previously created Security Token with identifier `tokenId`.
*
* @param {TokenIdentifier} tokenId
* @return {Array<TokenMetadata>}
**/
public getMetadata(
tokenId: TokenIdentifier): [TokenMetadata];
/**
* Read restrictions of a previously created Security Token with identifier `tokenId`.
*
* @param {TokenIdentifier} tokenId
* @return {Array<TokenRestriction|AccountRestriction>}
**/
public getRestrictions(
tokenId: TokenIdentifier,
account: Address = null): [TokenRestriction|AccountRestriction];
La definición de las nuevas Normas de token de seguridad NEM debe seguir las pautas de contribución [CONTRIBUTING.MD] [Anexo 1: Pautas de contribución] y [CODE_OF_CONDUCT.md] [Anexo 2: Código de conducta].
Las clases que implementan la interfaz estándar DEBEN hacer uso del paquete symbol-sdk para aprovechar las funciones de Catapult.
Se define una interfaz de comando que DEBE contener los siguientes métodos:
/**
* Verifies **allowance** of `operator` to execute command with `tokenId` security token
* for `account`. Parameters `account` and `operators` will be the same when the account
* is supposed to execute the command directly.
*
* @param {Address} operator
* @param {Address} account
* @param {TokenIdentifier} tokenId
* @param {Array<Option>} argv
* @return {AllowanceResult}
**/
public canExecute(
operator: Address,
account: Address,
tokenId: TokenIdentifier,
argv: [Option] = []): AllowanceResult;
/**
* Execute `command` for Security Token with identifier `tokenId`. Arguments
* the command execution can be passed in `argv`. Parameters `account` and `operators`
* will be the same when the account is supposed to execute the command directly.
*
* @param {Address} operator
* @param {Address} account
* @param {TokenIdentifier} tokenId
* @param {Array<Option>} argv
* @return {CommandResult}
**/
public execute(
operator: Address,
account: Address,
tokenId: TokenIdentifier,
argv: [Option] = []): CommandResult;
⚠️ La definición de los nuevos comandos de token de seguridad NEM debe seguir las pautas de contribución [CONTRIBUTING.MD] [Anexo 1: Pautas de contribución] y [CODE_OF_CONDUCT.md] [Anexo 2: Código de conducta].
Las clases que implementan la interfaz de comandos DEBEN hacer uso del paquete symbol-sdk para aprovechar las funciones de Catapult.
Cumplimiento de requisitos
Siguiendo la lista de requisitos, esta sección definirá las opciones de implementación que DEBEN estar disponibles en NEM Security Token Standards.
DEBE tener una interfaz estándar para consultar la viabilidad de una transferencia y devolver un motivo de fallas.
canTransfer()
canExecute()
DEBE poder realizar transferencias forzadas para acciones legales o recuperación de fondos.
DEBE definir notificaciones estándar para los procesos de emisión y reembolso.
canExecute(... new PublishToken(), [Option.create('tokenId', '...')])
DEBE poder adjuntar metadatos a un subconjunto del saldo del titular del token.
execute (… new ModifyMetadata (), [Option.create (‘data’, ‘…’)])
DEBE poder modificar los metadatos en el momento de la transferencia en función de los datos fuera de la cadena, los datos dentro de la cadena y los parámetros de la transferencia.
execute(... new ModifyMetadata(), [Option.create('data', '...')])
DEBE admitir consultas y suscribirse a actualizaciones en cualquier documentación relevante para la seguridad.
notify()
PUEDE requerir que los datos firmados se pasen a una transacción de transferencia para validarlos en la cadena.
execute(... new TransferOwnershipWithData(), [Option.create('data', '...')])
NO DEBE restringir el rango de clases de activos en las jurisdicciones que pueden representarse.
Este es un mensaje conjunto para nuestra comunidad en nombre del Grupo de Migración de Catapult, compuesto por la Fundación NEM, NEM Studios, NEM Ventures y Tech Bureau Holdings.
Descripción del proyecto
Fecha de lanzamiento dirigida al primer trimestre de 2020
Lo que se ha hecho hasta la fecha:
02-07-2019 Se crea el Comité de Migración
15-09-2019 Propuesta inicial publicada
02-10-2019 Tokenomics redactado
Oct 2019 FC Lanzamiento F1
Nov 2019 El equipo de migración tomó la decisión de admitir Opt-In.
18-11-2019 Lanzamiento interno FC F2
30-11-2019 Recomendaciones de Tokenomics hechas y compartidas con el núcleo
03-12-2019 Lanzamiento RC compatible con SDK Gateway F2
04-12-2019 Recomendaciones de Tokenomics compartidas con los titulares de Supernodo para comentarios
12-12-12 Últimas billeteras compatibles lanzadas (La última actualización es 0.8.9)
16-12-2019 Comienzo de la votación de PDI de Propuesta de Migración y Tokenómica
19-12-2019 La propuesta de marca se dará a conocer al público para su votación
21-12-2019 Propuesta de migración y tokenomics Cierre de votación de POI
Diciembre de 2019 Se iniciaron las pruebas y la revisión
02-01-2020 Cierre de votación de propuesta de marca
Futuros Hitos
13-01-2020 Comienza el nuevo Ticker de Symbol
30-01-2020 Directrices de marca / conjunto de herramientas entregado
Feb – Mar 2020 LANZAMIENTO
Mar 2020 Post lanzamiento reevaluar y reconfirmar planes futuros aún en pie
Con base en los plazos de los hitos anteriores, Catapult todavía apunta al lanzamiento del primer trimestre de 2020. Mantendremos a todos informados a medida que las cosas progresen.
Proceso para el Lanzamiento de Catapult
Una pregunta común de la comunidad se refiere a cuál es el proceso para la toma de decisiones para impulsar el lanzamiento de Catapult. Esta es la recomendación (de alto nivel) de la Fundaciónn, Studios y Ventures a los desarrolladores principales.
El Comité de Migración forma una propuesta inicial de opciones técnicas, tokenómica y marca, y comparte con la comunidad para recibir comentarios. Opciones técnicas completas, Tokenomics y Brand en curso, se espera que finalicen en enero.
La retroalimentación se absorbe y equilibra entre lo que se quiere y lo que es posible, a través de varios grupos de partes interesadas (Devs principales, Super Node Holders, Comunidad más amplia, Entidades NEM, Partes externas) y crea tres propuestas
Tokenomics: en curso, se espera que se comparta públicamente antes del 9 de diciembre
Marca: en curso, se espera que sea compartida a mediados de enero de 2020 a más tardar
Se redactan dos propuestas resumidas que abarcan los tres elementos y se presentan a la comunidad para que tome una decisión. Uno abarcará la tokenómica y la migración, mientras que el otro girará en torno a la marca. Si se rechaza, se volverá a trabajar, pero esto puede afectar el lanzamiento del primer trimestre de 2020 y debe equilibrarse para evitarlo como prioridad
En la actualidad, ambas propuestas han sido aceptadas por la comunidad.
Propuesta de Opt-In
El equipo de migración propone que cada cuenta tenga que suscribirse para recibir tokens de Symbol. Esto incluye cuentas multi-sig y no multi-sig. Las cuentas no recibirán tokens de símbolos o configuraciones de múltiples firmas a menos que se suscriban. Las cuentas pueden suscribirse antes o después del lanzamiento de la cadena pública. Para aquellos que esperan hasta después del lanzamiento, sus tokens de Symbol se mantendrán en una cuenta nominada hasta que sean reclamados cuando el propietario opte por participar. El proceso / entidad para administrar estos tokens no reclamados se definirá y comunicará antes del lanzamiento. Después de un período específico (6 años es el supuesto actual debido al estatuto de limitaciones) la propuesta es quemar tokens no reclamados …
Tecnología y Desarrollo
Actualización Anterior / Actualización Actual
Billetera de Escritorio: la última versión de Desktop Wallet (v0.8.9) se lanzará a principios de la próxima semana.Se ha iniciado una fase beta temprana para este proyecto, de la cual puede ver el código fuente en Github aquí.
Billetera para Dispositivos Móviles: actualmente no hay un lanzamiento público para Mobile Wallet, pero el paquete se ha trabajado y se lanzará en forma de una aplicación de Google Play Store, así como una aplicación de Apple Store. (iOS)
Explorador de Bloques: la última versión de explorador de bloques está disponible como una demostración aquí y también se puede usar para redes privadas de blockchain y también con la testnet experimental de l Fundación NEM para Catapult. Se ha iniciado una fase beta temprana para este proyecto, de la cual puede ver el código fuente en Github: aquí
Carteras de hardware:
Trezor: la integración de la billetera de hardware para Trezor en la billetera de escritorio ha comenzado y ha progresado bastante. El equipo de Labrys está trabajando actualmente en la integración de firmware de Catapult para dispositivos Trezor.
Ledger: un proveedor de servicios de la Fundación NEM también está trabajando en la integración de Catapult para dispositivos de hardware Ledger, este proyecto aún está en su fase inicial y aún no se ha publicado.
REST & SDK Los desarrolladores de NEM Studios han completado los últimos cambios de compatibilidad del servidor. Se actualizaron nuevos lanzamientos de SDK y los diversos clientes los han actualizado.
Revisión / Prueba Las siguientes fases de prueba están comenzando, incluyendo nuevas pruebas de rendimiento y pruebas de penetración por un tercero, a medida que comenzamos el programa de recompensas de errores abiertos en la plataforma de revisión de seguridad HackerOne. Estos esfuerzos continuarán durante el tiempo de lanzamiento
TestNet: se está ejecutando una nueva versión de testnet y se han aplicado configuraciones basadas en la propuesta de tokenomía. Todas las compilaciones actuales y en curso de los distintos clientes apuntarán a la red de forma predeterminada.
¿Que hay de Nuevo?
La Testnet ya está en vivo! Para obtener más información sobre nuestro comunicado de prensa y cómo participar, vaya aquí.
Alcance de Exchange
El alcance de Exchange para Symbol continúa y se ha convertido en el Comité Directivo de Symbol Exchange dirigido por Anton Bosenko, miembro del Consejo de la Fundación NEM. El Comité Directivo de Symbol Exchange también incluye a Alexandra Tinsman, Cryptobeliever, Jeff McDonald, Ъ !!! 11, Greg Saive, Pedro Gutierez y Flora Fang.
Actualización anterior / Actualización Actual
Finalización de la plataforma de lanzamiento que incluirá información sobre:
NEM
Nuevo proyecto
Equipo
Nuevo modelo tokenómico
Plan de marketing y relaciones públicas de alto nivel
Enfoque de liquidez
Plan de soporte NIS1 (XEM)
Líneas de tiempo
Integración de información técnica
Realizar la reunión con uno de los intercambios japoneses
Obteniendo comentarios de los intercambios TIER 1 que enlistan a XEM
¿Que hay de Nuevo?
La versión extendida de la plataforma de lanzamiento está en proceso
La reunión se celebró con el Intercambio japonés y el proceso de preparación de la lista ha comenzado.
Se han establecido canales de comunicación con 10 intercambios, se están negociando
Debido a la naturaleza de dichas negociaciones, no se puede divulgar toda la información.
Estrategia de marca y lanzamiento al mercado
Estrategia de Marca
Las actualizaciones de marca se pueden encontrar en los foros de NEM aquí.
¿Que hay de Nuevo?
El 13 de enero de 2020 (PST), se realizará una votación para el ticker de nuestra nueva marca (Symbol). Para obtener más información (más cercana a la fecha) sobre cómo participar, vaya aquí .
Desde la exitosa votación de la comunidad sobre la nueva marca Symbol durante las vacaciones, se ha trabajado para aumentar la conciencia sobre el nuevo cambio en la marca. Puede encontrar más información sobre nuestro comunicado de prensa aquí.
Tokenomics
Previa/Actual actualización
Varios miembros de la comunidad, el comité de migración y el grupo de titulares de supernodos han expresado ideas / preferencias. Esta información y varios modelos se han completado y compilado en una propuesta concreta que ha sido revisada por el Comité de Migración, el Equipo Central, el Grupo SuperNode y la Comunidad. Ha sido bien recibido en todos los ámbitos y ahora forma parte de la votación del PDI.
¡A partir del 21 de diciembre de 2019, a las 3:00 p.m. PST, la encuesta de votación sobre PDI de Migración y Tokenomics ha concluido! Los resultados son los siguientes:
Sí (aprobación) votos: 365 puntaje ponderado: 3.52268% porcentaje: 95.00
No (rechazar)
votos: 11
puntaje ponderado: 0.18558%
porcentaje: 5.00
Se han cumplido todos los requisitos previos para una votación aprobada (votos “SÍ” con un mínimo de 3% de PDI y 65% de mayoría).
Dada la aprobación de la comunidad, el Comité de Migración ahora considerará que la moción ha sido aprobada, y las acciones comenzarán luego de dicha propuesta.
Imagen obtenida de la encuesta oficial de NEM Wallet
¡A partir del 21 de diciembre de 2019, a las 3:00 p.m. PST, la encuesta de votación sobre PDI de Migración y Tokenomics ha concluido! Los resultados son los siguientes:
Sí (aprobar)
votos: 365
puntaje ponderado: 3.52268%
porcentaje: 95.00
No (rechazar)
votos: 11
puntaje ponderado: 0.18558%
porcentaje: 5.00
Se han cumplido todos los requisitos previos para una votación aprobatoria (votos “SÍ” con un mínimo de 3% de PDI y 65% de mayoría).
Dada la aprobación de la comunidad, el Comité de Migración ahora considerará que la moción ha sido aprobada, y las acciones comenzarán ahora después de dicha propuesta 5.
Teniendo en cuenta el esfuerzo significativo que se hizo para desarrollar toda la documentación, el Comité de Migración está muy agradecido con todos los que han dado su tiempo para permitirnos llegar a esta etapa. Un agradecimiento especial a todos los miembros de la comunidad que participaron en la votación.
Gracias nuevamente por su continua consideración y apoyo,
Este es un mensaje conjunto para nuestra comunidad en nombre del Catapult Migration Group, compuesto por NEM Foundation, NEM Studios, NEM Ventures y Tech Bureau Holdings.
Introducción
En esta publicación presentamos y explicamos el enfoque recomendado para Tokenomics Catapult. Esta es una recomendación y ha sido compilada por el grupo de trabajo Tokenomics, revisado por el Comité de Migración, el equipo central y el grupo de titulares de supernodos.
Muchas gracias a todos los que han estado involucrados en este proceso, algunos de los miembros del grupo de trabajo se mencionan en la propuesta, otros no son para la privacidad personal. Todos son conocidos por el Comité de Migración y son miembros experimentados de la comunidad desde hace mucho tiempo. Su tiempo, pensamientos y esfuerzos son realmente apreciados y el resultado es un enfoque Tokenomics bien equilibrado que creemos.
Se lanzará una propuesta similar, pero más pequeña, para cubrir cualquier cambio en los Tokenomics NIS1 como parte del lanzamiento de Catapult, estos se lanzarán a su debido tiempo, pero se considera más importante aceptar primero los Tokenomics de Catapult para garantizar que la fecha de lanzamiento pueda cumplir.
Descripción general de Tokenomics
La naturaleza de Tokenomics requiere información densa, esta publicación ha sido compilada para proporcionar algún contexto y orientación sobre cómo absorber la propuesta. Damos la bienvenida a todos y cada uno de los comentarios, comentarios, preguntas, etc. de la comunidad.
La propuesta se divide ampliamente en los siguientes componentes principales:
Recompensas en bloque: reduzca los fondos básicos para comenzar la cadena con menos de 9 mil millones de tokens, luego use la nueva función Catapult (Mecanismo de inflación) para volver a inflarlo a 9 mil millones a través de recompensas en bloque a los recolectores. Esto se hará igualando la tasa a la que se extrae BTC, sin los acantilados de 4 años. Esto ofrece buenas recompensas en los primeros años Y una bonita historia de marketing fácil sobre la coincidencia de lanzamientos en BTC
Recompensa de cosecha de nodos: proporcionar al propietario del nodo los bloques cosechados en su nodo mediante contribuciones de los cosechadores delegados, nuevamente utilizando una nueva función Catapult.
El programa SuperNode se eliminará gradualmente durante 6 años y se hará más accesible para la comunidad en general a través de niveles. Ya no será un gran pago, pero eso se ve compensado por las recompensas en bloque, es más una contribución / gracias al costo de ejecutar los nodos, apoyar la red de manera confiable, bloquear tokens, etc.
Dos oportunidades de bonificación para alentar la implementación temprana de nodos en catapulta y proporcionar estabilidad de nodos en NIS1
Verá que los puntos 3 y 4 están marcados como opcionales en la propuesta y, dependiendo de la respuesta de la comunidad, pueden mantenerse, modificarse o eliminarse sin un impacto importante en el modelo general de Tokenomics. Nuestra recomendación es que se incluyan según lo documentado.
Propuesta Completa de Tokenomics
Se ha producido un Resumen de tres páginas para ayudar a resumir la propuesta y el modelo más largos; Es el mejor lugar para comenzar.
La propuesta completa y los modelos de hoja de cálculo también se proporcionan a continuación:
Los siguientes son los siguientes pasos previstos para este trabajo:
Tokenomics de Catapult
Deje este tema abierto para comentarios, aportes, preguntas, etc.
Suponiendo que sea bien recibido, combine la Ruta de Migración y las Propuestas Tokenomics en una sola propuesta que se someterá a votación de PoI a mediados de diciembre.
Tokenomics NIS1
Cree un documento similar, probablemente más pequeño, que describa los cambios sugeridos a NIS1
Tómelo a través de una votación pública, probablemente después de Navidad / Año Nuevo en esta etapa.
Como siempre, el aporte de la comunidad sobre esta propuesta es muy importante y algunos de estos cambios son fundamentales para la forma en que Catapult trabajará en el lanzamiento y décadas en el futuro. ¡Alentamos a todos a leer y participar de la propuesta tanto como sea posible!
Este es un mensaje conjunto para nuestra comunidad en nombre del Catapult Migration Group, compuesto por The NEM Foundation, NEM Studios, NEM Ventures y Tech Bureau Holdings. Con la esperanza de mantener a la comunidad lo más actualizada posible con nuestro progreso, el comité se esforzará por cargar actualizaciones semanales que reflejen cualquier cambio.
Descripción del proyecto
Fecha de lanzamiento proyectada para el primer trimestre de 2020
Lo que se ha hecho hasta la fecha:
02-07-07 Comité de Migración 2019 establecido
15-09-09 Propuesta inicial publicada
02-10-20 Tokenomics redactados
02-10-20 2019 FC Release F1
Hitos futuros:
15-11-2019 Recomendación / actualización del Comité de Migración Emitida
25-11-11 Versión de RC compatible con SDK / REST Gateway F2
30-11-11 Recomendación Tokenomics realizada
27-11-11 Test Net disponible
11-12-2019 Carteras listas
Diciembre – 2019 Comienzo de la prueba y revisión del lápiz (depende del resultado de RC Release F2)
03- Ene- 2020 Directrices de marca / conjunto de herramientas entregadas
Feb – Mar 2020 LANZAMIENTO
Mar 2020 Post lanzamiento reevaluar y reconfirmar planes futuros aún en pie
Con base en los plazos de los hitos anteriores, Catapult todavía apunta al lanzamiento del primer trimestre de 2020. Mantendremos a todos informados a medida que las cosas progresen.
Proceso para el lanzamiento de Catapult
Una pregunta común de la comunidad se refiere a cuál es el proceso para la toma de decisiones para impulsar el lanzamiento de Catapult. Esta es la recomendación (de alto nivel) de Foundation, Studios y Ventures a los desarrolladores principales.
El Comité de Migración forma una propuesta inicial de opciones técnicas, tokenómica y marca, y comparte con la comunidad para recibir comentarios. Opciones técnicas completas, Tokenomics y Brand en curso, se espera que finalicen en enero.
La retroalimentación se absorbe y equilibra entre lo que se quiere y lo que es posible, a través de varios grupos de partes interesadas (Desarrolladores principales, Super titulares de nodos, Comunidad más amplia, Entidades NEM, Partes externas) y crea tres propuestas
Tokenomics: en curso, se espera que sea compartido a finales de noviembre a más tardar
Marca: en curso, se espera que sea compartida a mediados de enero de 2020 a más tardar
Se redacta una propuesta resumida única que abarca los tres elementos y se presenta a la comunidad para que tome una decisión. Si se rechaza, se volverá a trabajar, pero esto puede afectar el lanzamiento del primer trimestre de 2020 y debe equilibrarse para evitarlo como prioridad.
Tecnología
Desarrollo Front End
El progreso que gira en torno al desarrollo front end es el siguiente:
Billetera de Escritorio: la última versión de Billetera de Escritorio es compatible con redes privadas de blockchain y acaba de actualizarse para funcionar también con NEM Foundation Experimental Testnet para Catapult. Los equipos de billetera de escritorio y SDK están cooperando entre entidades para integrar las últimas actualizaciones de la versión del protocolo. Se ha iniciado una fase beta temprana para este proyecto, de la cual puede ver el código fuente en Github:
Billetera para dispositivos: actualmente no hay un lanzamiento público para Mobile Wallet, pero el paquete se ha trabajado y se lanzará en forma de una aplicación de Google Play Store, así como una aplicación de Apple Store. (iOS)
Explorador de Bloques: la última versión del Explorador de Bloques está disponible como demostración aquí y también se puede usar para redes privadas de blockchain y también con la red experimental Testnet para Catapult de la Fundación NEM. Se ha iniciado una fase beta temprana para este proyecto, de la cual puede ver el código fuente en Github:
Billeteras hardware: la integración de la billetera de hardware para Trezor en la billetera de escritorio ha comenzado y ha progresado bastante. El equipo de Labrys está trabajando actualmente en la integración del firmware de Catapult para dispositivos Trezor. Un proveedor de servicios de la Fundación NEM también está trabajando en la integración de Catapult para dispositivos de hardware Ledger, este proyecto aún está en su fase inicial y aún no se ha publicado.
Desarrollo
El progreso del desarrollo de Catapult es el siguiente:
Los desarrolladores de NEM Studios continúan trabajando a través de los últimos cambios del Servidor Fushicho 2. El equipo REST se está acercando al código completo y proporcionará la última versión en los próximos días para que los SDK se puedan actualizar y volver a probar.
Todavía estamos buscando ser el objetivo de la última semana de noviembre para el lanzamiento público de los SDK actualizados.
Revisión y prueba: las siguientes fases de prueba están comenzando a incluir nuevas pruebas de rendimiento y pruebas de penetración por parte de un tercero, a medida que comenzamos el programa de recompensas de errores abiertos en la plataforma de revisión de seguridad HackerOne. Estos esfuerzos continuarán durante el tiempo de lanzamiento.
Dependiendo de los resultados de dichas pruebas, los plazos de entrega pueden extenderse para garantizar una gestión de calidad.
Estrategia de Branding y el Go-To-Market
Estrategia de Branding
En el futuro, todas las actualizaciones de marca se pueden encontrar en los foros de NEM. Te invitamos a unirte a la conversación aquí.
Tokenomics
Varios miembros de la comunidad, el comité de migración y el grupo de titulares de supernodos han expresado ideas / preferencias. En la actualidad, esta información se está recopilando con el fin de hacer una recomendación del Comité de Migración.
Como fragmento de la dirección general, es probable que el enfoque recomiende:
Continuar con el programa supernodo pero gradualmente escalonarlo y hacerlo más accesible para otros miembros de la comunidad.
Aumentar el enfoque de descentralización / democratización para recompensas de nodo / cosecha
Crear un plan de tokenomía que tenga longevidad, para una cadena que estará aquí durante décadas / generaciones por venir
Los detalles de estos se compartirán a continuación, pero los comentarios de la comunidad en general, los titulares de supernodos, el equipo central y el comité de migración se combinan en torno a estos puntos.
Proceso
11/11/2019: Los representantes de MC compartirán un marco de trabajo con un grupo de trabajo de miembros de la comunidad de larga trayectoria e inversión significativa, se discutirá durante 1-2 semanas (más corto si es posible) para identificar una posición común
La semana que comienza el 25 de noviembre, el enfoque documentado se compartirá con el Equipo Central y el Comité de Migración para su revisión
La semana siguiente (suponiendo que se apruebe la revisión anterior), el enfoque documentado se compartirá con la comunidad, inicialmente con los grupos de titulares del Supernodo durante unos días, luego con la comunidad en general. Varias áreas de la tokenómica impactan a los titulares de Supernodos diferentes a la comunidad en general, tienen representantes en el grupo de trabajo, por lo que esto es para dar la oportunidad de responder preguntas sobre esas áreas antes de la discusión general
Luego se compartirá con los equipos más amplios del ecosistema para pruebas / pruebas de cordura (NF, NV, NS, Core Devs, Supernode Group & Forums). Se espera que este sea un proceso relativamente rápido debido al nivel de entrada recibido hasta ahora.
Suponiendo que no haya una gran oposición, se incluirá en la Propuesta de Migración; El objetivo es la última semana de noviembre.
Se está dando prioridad a Catapult Tokenomics ya que son más complejos, NIS1 se ejecutará en paralelo, inicialmente ligeramente por detrás.