Token de Seguridad

Introducción

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.

Fuente: ERC # 1400 Security Token Standard

Descripción de las características

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:

Feature	NIP-13
Emisión	✅
Delegación de poder del emisor	✅
Transferencia	✅
Transferencia por lotes	✅
Transferencia por Metadatos	✅
Administración de Metadatos	✅
Restricciones de Transferencia	✅
Congelamiento/Bloqueo	✅
Transferencia de fuerza	✅
Señal de error	✅
Cumplimiento del operador	✅
Administración de Documentos	✅

NIP-13

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:

- package.json
> src/
  > interfaces/
    - Standard.ts
    - Command.ts
  > standards/
    - NIP13.ts
    - etc.
  > commands/
    - Option.ts
    - Command.ts
    > NIP13/
      - PublishToken.ts
      - TransferOwnership.ts
      - AttachDocument.ts
      - ...
  > model/
    - AccountMetadata.ts with properties `account: Address`, `field: string`, `value: string`
    - AccountRestriction.ts with properties `account: Address`, `restriction: AddressRestriction`
    - AllowanceResult.ts with properties `status: boolean`, `message: string | undefined`
    - CommandResult.ts with properties `status: boolean`, `message: string | undefined`
    - NotificationProof.ts with properties ``transactionHash: TransactionHash`
    - PublicProof.ts with properties `tokenId: TokenIdentifier`, `transactionHash: TransactionHash`
    - TokenIdentifier.ts with properties `id: UInt64`
    - TokenSource.ts with properties `source: string` (network generationHash)
    - TokenMetadata.ts with properties `tokenId: TokenIdentifier`, `field: string`, `value: string`
    - TokenRestriction.ts with properties `tokenId: TokenIdentifier`, `restriction: MosaicRestriction`

Implementación de Propuesta

Interface

• 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.

execute (… new ForcedTransfer (), [Option.create (‘remitente’, ‘…’), Option.create (‘destinatario’, ‘…’)])

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.

Fuente: Github NEM