Guía de implementación de contratos inteligentes para emisores de moneda estable en Hong Kong

Primera parte Infraestructura y estrategia de cumplimiento

1. Elección del libro mayor distribuido de base

Guía de implementación

• Priorizar cadenas de bloques públicas maduras: se recomienda optar por cadenas de bloques públicas maduras y altamente seguras, como Ethereum, Arbitrum, entre otras.
• Evaluación rigurosa de alternativas: Si se considera la adopción de una cadena de consorcio u otro tipo de libro mayor distribuido, se debe llevar a cabo un análisis comparativo riguroso y cuantificable para demostrar que sus estándares de seguridad no son inferiores, e incluso son superiores a los de las cadenas públicas más utilizadas.
• Documento de evaluación de riesgos: el informe de evaluación debe cubrir de manera exhaustiva su capacidad para resistir ataques comunes, el tipo de algoritmo de consenso, así como los riesgos asociados con defectos de código, vulnerabilidades, explotación de vulnerabilidades y otras amenazas, y analizar en detalle cómo estos riesgos pueden afectar potencialmente la emisión, el canje y las operaciones diarias de la moneda estable.

2. Estándares de token central y expansión de funciones de regulación

Guía de implementación

• Estándar básico: se utiliza ERC-20 como estándar básico para garantizar la homogeneidad de la moneda y la interoperabilidad en un ecosistema más amplio.

• Expansión de funciones: se deben integrar los siguientes módulos funcionales para cumplir con los requisitos regulatorios:

  • Pausable: utilizado para implementar la función de pausa y reanudación global de todas las actividades de la moneda, esta es una herramienta fundamental para hacer frente a eventos de seguridad importantes.

  • Mintable: Se utiliza para que los emisores autorizados puedan acuñar nuevos tokens a través de un proceso controlado y garantizar que la cantidad de tokens emitidos corresponda estrictamente a los activos de reserva de moneda fiduciaria.

  • Quemable: proporciona la función de destruir monedas. En la implementación específica, esta función estará controlada por permisos estrictos, en lugar de permitir que cualquier usuario la destruya por sí mismo.

  • Congelable: utilizado para pausar la función de transferencia de monedas de cuentas específicas ( en caso de transacciones sospechosas ).

  • Whitelist: se utiliza para implementar medidas de seguridad adicionales, permitiendo solo que las direcciones aprobadas y sometidas a debida diligencia participen en operaciones clave ( como recibir nuevos tokens emitidos ).

  • Lista negra: se utiliza para implementar una prohibición de transacciones sobre direcciones involucradas en actividades ilegales ( como el lavado de dinero, fraude ), prohibiendo el envío/recepción de monedas. La gestión de la lista negra debe estar vinculada al sistema AML/CFT, monitoreando en tiempo real las transacciones sospechosas.

  • AccessControl: Esta es la base para implementar un sistema de gestión de permisos basado en roles y altamente detallado. Todas las funciones de gestión deben pasar por este módulo para el control de permisos, a fin de cumplir con los requisitos de separación de funciones.

3. Modos de cumplimiento principales: selección de listas negras y listas blancas

Guía de implementación

• Modo de lista negra (, esquema recomendado por defecto ):

  • Ventajas: tiene una mayor utilidad, puede interoperar sin problemas con el amplio ecosistema de finanzas descentralizadas (DeFi), ofreciendo a los usuarios una menor barrera de entrada y una experiencia más fluida.

  • Desventajas: la conformidad depende en gran medida de una sólida capacidad de análisis y monitoreo fuera de la cadena en tiempo real, para detectar y bloquear direcciones ilegales a tiempo.

  • Modo de implementación: en la función de transferencia de contratos inteligentes, agregar una verificación lógica para asegurar que las direcciones del remitente (from) y del destinatario (to) no estén registradas en la lista negra.

• Modo de lista blanca

  • Ventajas: proporciona el más alto nivel de control AML/CFT, logrando la prevención previa, en lugar de la remediación posterior.

  • Desventajas: limita enormemente la universalidad y la tasa de adopción de las monedas estables, lo que genera grandes costos operativos para gestionar la lista blanca, lo que puede dificultar que se convierta en un medio de intercambio ampliamente aceptado.

  • Modo de implementación: en la función de transferencia de contratos inteligentes, se debe agregar una verificación lógica que exija que las direcciones del remitente (from) y del receptor (to) deben estar en la lista blanca. Se sugiere desarrollar un sistema de backend web para usuarios dedicado para realizar operaciones, aumentando la conveniencia de las operaciones.

Segunda parte implementación de contratos inteligentes

1. Sistema de control de acceso diseñado de manera detallada

Guía de implementación

Es necesario definir una serie de roles claros y asignarlos a diferentes entidades o empleados controlados por una billetera multifirma, para lograr la separación de funciones y minimizar el riesgo de un único punto de falla o manipulación colusoria. Cada rol debe limitarse a funciones específicas, todas las operaciones requieren autorización multifirma y se debe garantizar que ningún empleado tenga simultáneamente múltiples roles de alto riesgo. Todas las operaciones deben registrarse en un registro y someterse a una auditoría de terceros anual, la asignación de permisos será supervisada por un administrador o un consejo.

• MINTER_ROLE: responsable de manejar la emisión de la moneda estable (mint), que incluye crear unidades de moneda tras recibir una solicitud de emisión válida y asegurar que la acuñación coincida con el aumento correspondiente del fondo de activos de reserva.

• BURNER_ROLE: Responsable de manejar la destrucción de la moneda estable (burn), incluyendo la destrucción de unidades de moneda tras recibir una solicitud de rescate válida.

• PAUSER_ROLE: Responsable de pausar (pause) las operaciones de la moneda estable, como detener temporalmente las transferencias, la emisión o el canje al detectar eventos anómalos ( como amenazas de seguridad ).

• RESUME_ROLE: Responsable de reanudar la operación de la moneda estable (resume), como reactivar las transferencias, la emisión o el canje después de la resolución de un evento de suspensión.

• FREEZER_ROLE: Responsable de congelar (freeze) y descongelar (remove freeze) operaciones de billeteras o monedas específicas, por ejemplo, congelar temporalmente activos al detectar actividades sospechosas ( como riesgo de lavado de dinero ).

• WHITELISTER_ROLE: responsable de gestionar la lista blanca (whitelist), incluyendo la adición o eliminación de direcciones de billetera permitidas, por ejemplo, restringir la emisión de moneda solo a direcciones en la lista blanca.

• BLACKLISTER_ROLE: Responsable de gestionar la lista negra (blacklist) y eliminar la lista negra (remove blacklist), por ejemplo, incluir billeteras sospechosas en la lista negra para evitar transferencias.

• UPGRADER_ROLE: Si se adopta un modelo actualizable, es responsable de la emisión de (upgrade) contratos inteligentes, como actualizar el código del contrato para corregir vulnerabilidades o agregar funcionalidades.

2. emisión ( moneda ) mecanismo

Guía de implementación

Verificación previa: antes de ejecutar la emisión, la función debe verificar si la dirección objetivo to está en la lista negra o en estado congelado.

Proceso de operación:

• Diligencia debida fuera de la cadena: el cliente completa todos los procesos necesarios de identificación del cliente fuera de la cadena ( KYC ) y diligencia debida del cliente ( CDD ). Además, las regulaciones AML/CFT exigen que, para establecer relaciones comerciales o realizar transacciones ocasionales que superen un umbral específico ( como 8,000 HKD ), se debe llevar a cabo CDD.
• Recepción de fondos: el cliente transferirá la cantidad equivalente de fondos fiduciarios a la cuenta bancaria designada por el emisor.
• Validación interna: el sistema interno del emisor confirma la recepción de fondos y actualiza en consecuencia los registros contables de los activos de reserva.
• Ejecución en cadena: el equipo operativo crea y firma una transacción de firma múltiple, llama a la función de acuñación de tokens de los contratos inteligentes, y envía la moneda estable recién acuñada a la dirección de la billetera del cliente que ha sido pre-registrada y verificada.

3. Redención ( mecanismo de destrucción )

Guía de implementación

Preparación para el reembolso: el usuario primero necesita transferir la moneda que desea reembolsar a la dirección designada controlada por el emisor.

Proceso de operación:

• Solicitud fuera de la cadena: el usuario presenta una solicitud de redención fuera de la cadena a través de la plataforma del emisor. Antes de procesar la solicitud, el emisor debe realizar la debida diligencia del cliente adecuada (CDD).
• Verificación del sistema: el sistema del emisor verifica la validez de la solicitud de verificación y comprueba si el usuario ha completado la operación de transferencia de la moneda correspondiente en la cadena.
• Pago en moneda fiduciaria: el emisor transferirá el equivalente en moneda fiduciaria a la cuenta bancaria que el usuario haya registrado y verificado previamente.
• Quema en cadena: después de confirmar el éxito de la transferencia de moneda fiduciaria, una billetera multisig con el rol BURNER_ROLE invoca la función de quema para destruir la cantidad correspondiente de monedas desde la dirección especificada.

4. Implementar control de emergencia: suspender y congelar

Guía de implementación

Función de pausa: solo puede ser llamada por una billetera multifirma que posea el PAUSER_ROLE, utilizada para interrumpir globalmente la función del contrato. Las condiciones para activarla incluyen la detección de eventos anómalos (, como ataques de red o desajustes en los activos de reserva ), que requieren la aprobación de la junta directiva o de la alta dirección. La función de reanudación es manejada por un RESUME_ROLE independiente, para lograr la separación de funciones.

Función de congelación: llamada por una billetera multisig que posee el rol FREEZER_ROLE, utilizada para limitar las transferencias a direcciones específicas. Las condiciones de activación incluyen actividades sospechosas ( como alertas de AML o órdenes judiciales ), que deben ejecutarse tras la verificación fuera de la cadena. La descongelación es manejada por el mismo rol, pero requiere una verificación de auditoría adicional, publicando un anuncio relevante para evitar abusos.

5. Filtrado de direcciones y mecanismo de lista negra

Guía de implementación

• Implementación de función: función para agregar y eliminar de la lista negra, y solo puede ser llamada por una billetera multifirma que posea el papel BLACKLISTER_ROLE.
• Restricciones de transferencia: se prohíbe que las direcciones en la lista negra transfieran/reciban monedas.
• Proceso de operación: La herramienta de análisis emite una alerta, se activa una revisión de cumplimiento interno, después de que el equipo de cumplimiento confirme, la transacción de añadir a la lista negra es iniciada por la billetera multifirma de BLACKLISTER_ROLE.

6. La capacidad de actualización de los contratos inteligentes

Guía de implementación

• Modelo de proxy: para contratos inteligentes de tipo EVM, se puede utilizar el modelo de proxy ERC-1967 maduro para lograr la capacidad de actualización.
• Control de permisos: la función de actualización debe ser llamada únicamente por un monedero multifirma que posea el UPGRADER_ROLE.
• Proceso de gestión de cambios: de acuerdo con los requisitos regulatorios, antes de proponer cualquier actualización, se debe completar un estricto proceso de gestión de cambios, que incluye una auditoría de seguridad completa e independiente de los nuevos contratos inteligentes.

7. Registros de eventos en cadena para análisis e informes

Guía de implementación

Además de los requisitos de transferencia (Transfer) y autorización (Approval) del estándar ERC-20, el contrato debe definir y emitir eventos personalizados para todas las acciones de gestión y cambios de estado:

• Emisión/Quema ( Minted/Burned ) evento
• Contratos inteligentes pausados/reanudados ( Pausado/Reanudar ) evento
• Añadir/Quitar de la lista negra (BlacklistAdded/BlacklistRemoved) evento
• Añadir/Eliminar de la lista blanca (WhitelistAdded/WhitelistRemoved) evento
• Congelación/Descongelación de dirección ( AddressFrozen/AddressUnfrozen ) evento
• Cambio de rol privilegiado ( RoleGranted/RoleRevoked ) evento
• Actualización de contratos inteligentes ( Upgraded ) evento

Parte Tres Seguridad Operativa y Gestión del Ciclo de Vida

1. Arquitectura de gestión de claves de seguridad

Guía de implementación

• Generación de claves: debe llevarse a cabo a través de una "ceremonia de claves" documentada en detalle (key ceremony), en un entorno físico seguro y completamente aislado de redes externas.
• Almacenamiento de claves: Todos los roles de gestión deben ser controlados por una billetera de múltiples firmas. Las claves privadas utilizadas por los firmantes de estas billeteras multifirma deben almacenarse en HSM o en otras billeteras de hardware seguras. Para los roles más críticos, las claves correspondientes deben almacenarse en un sistema aislado, físicamente separado de cualquier entorno en línea.
• Uso de clave: se debe aplicar obligatoriamente una política de múltiples firmas. Para las firmas de transacciones que involucren "claves privadas importantes", puede ser necesario que las personas relevantes estén presentes para operar.
• Copia de seguridad y recuperación: Las copias de seguridad de las fragmentaciones de clave o de las frases de recuperación deben almacenarse en múltiples ubicaciones seguras y geográficamente dispersas dentro de Hong Kong ( o en lugares aprobados por los reguladores ), y deben utilizar un embalaje a prueba de manipulaciones.

2. Proceso de despliegue completo y monitoreo en tiempo de ejecución

Guía de implementación

Antes de la implementación oficial, se debe elaborar y aplicar estrictamente una "lista de verificación previa a la implementación":

• Pruebas completas: asegurar una cobertura de pruebas unitarias del 95% o más, una cobertura del 100% en el código central, y asegurar la salida de informes de cobertura de pruebas unitarias.
• Auditoría independiente: completar al menos un informe de auditoría de seguridad independiente emitido por una empresa de auditoría de buena reputación, preferiblemente dos.
• Congelación de código: después de completar la auditoría, congelar el código hasta el lanzamiento, sin realizar ningún cambio en el código.
• Pruebas de regresión: antes de la implementación oficial, se deben ejecutar pruebas unitarias y realizar pruebas de regresión.
• Aprobación de cumplimiento: obtener la aprobación formal del equipo de cumplimiento interno, confirmando que la lógica del contrato cumple con todos los requisitos regulatorios relevantes.
• Ejercicio de despliegue: preparar un script de despliegue detallado y realizar un ejercicio de despliegue completo en una red de pruebas que sea completamente idéntica al entorno de la red principal.
• Despliegue autorizado: la operación de despliegue final es ejecutada por la billetera autorizada.

Una vez completada la implementación, se deben tomar medidas de monitoreo adecuadas para implementar medidas de mitigación oportunas sobre el uso de roles privilegiados y las amenazas emergentes:

• Monitoreo de actividades en la cadena: monitoreo del rol de gestión