Guía de implementación de contratos inteligentes para emisores de monedas estables en Hong Kong

Con la aprobación oficial de la "Reglamento de Monedas Estables", la Autoridad Monetaria de Hong Kong publicó el 26 de mayo de 2025 las "Directrices de Supervisión para Emisores de Monedas Estables con Licencia (Borrador)", con el objetivo de garantizar la estabilidad, seguridad y cumplimiento operativo del ecosistema local de monedas estables. Estas directrices detallan los requisitos regulatorios y los estándares operativos que los emisores de monedas estables con licencia deben cumplir de manera continua.

Recientemente, un número creciente de instituciones ha consultado a los equipos de seguridad sobre la implementación de contratos inteligentes de conformidad. Para ayudar a los emisores a comprender y desplegar mejor un sistema de contratos inteligentes conforme, hemos publicado especialmente la "Guía de implementación de contratos inteligentes para emisores de moneda estable en Hong Kong", con el fin de proporcionar un camino técnico claro y recomendaciones prácticas que apoyen el desarrollo saludable del ecosistema de moneda estable en Hong Kong.

Parte Uno Infraestructura y Estrategia de Cumplimiento

Esta sección tiene como objetivo sentar las bases de la arquitectura de alto nivel para el sistema de moneda estable, donde las decisiones de arquitectura están impulsadas completamente por los requisitos más fundamentales en el marco de la Autoridad Monetaria de Hong Kong. Las elecciones realizadas aquí determinarán todo el camino de implementación, asegurando que la conformidad esté profundamente integrada en la pila tecnológica desde el inicio del diseño.

1. Elección de la contabilidad distribuida de base

directrices regulatorias

El titular de la licencia debe evaluar la solidez de la tecnología de libro mayor distribuido subyacente (DLT) que utiliza. Esta evaluación abarca la infraestructura de seguridad, la capacidad de resistencia a ataques comunes (como el ataque del 51%), la garantía de la finalización de las transacciones y la fiabilidad del algoritmo de consenso.

Interpretación técnica

Esta no es una simple preferencia técnica, sino una tarea central de cumplimiento. La elección de la cadena de bloques subyacente debe pasar por una diligencia debida formal, y todo el proceso de evaluación también debe ser documentado en detalle para proporcionar una justificación adecuada durante la revisión regulatoria. El proceso de selección del libro mayor subyacente, de hecho, establece el tono para la seguridad y estabilidad de todo el sistema de moneda estable.

La énfasis de la Autoridad Monetaria de Hong Kong en la solidez del libro mayor, en esencia, es una advertencia para que los emisores eviten adoptar cadenas emergentes que no hayan sido validadas por el mercado, que tengan un alto grado de centralización o cuya seguridad sea cuestionable. La responsabilidad de demostrar su seguridad y estabilidad recae completamente en el emisor. Si el emisor elige una cadena cuya seguridad aún no ha sido ampliamente verificada, debe diseñar e implementar medidas de control compensatorias adicionales.

Guía de implementación

• Elegir cadenas de bloques públicas maduras: se recomienda optar por cadenas de bloques públicas maduras y con alta seguridad, como Ethereum y Arbitrum. Estas redes, gracias a su resistencia comprobada, una extensa red de nodos de validación y una supervisión pública continua, tienen ventajas naturales. Su alto costo de ataque (seguridad económica) puede responder directamente a las preocupaciones regulatorias sobre la resistencia a ataques del 51% y la garantía de la finalización de las transacciones.

• 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 realizar un análisis comparativo riguroso y cuantificable, como una auditoría de seguridad, 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 integral la capacidad de resistir ataques comunes, el tipo de algoritmo de consenso, así como los riesgos relacionados 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, redención y operación diaria de la moneda estable. Este documento es clave para demostrar a las autoridades regulatorias la prudencia en la selección tecnológica.

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

directrices de regulación

Los documentos de regulación no especifican un estándar de token particular (como ERC-20). Sin embargo, los documentos exigen la implementación de una serie de funciones de gestión clave, que incluyen la emisión (mint), la quema (burn), la actualización (upgrade), la pausa (pause), la reanudación (resume), la congelación (freeze), la lista negra (blacklist) y la lista blanca (whitelist).

Interpretación técnica

La Autoridad Monetaria de Hong Kong ha definido, de hecho, un estándar de "token mejorado por regulación" que tiene funciones que superan con creces el estándar ERC-20. Este estándar no solo exige contar con funciones básicas de circulación de tokens, sino que también enfatiza la seguridad operativa, la controlabilidad de permisos y la trazabilidad de riesgos. Para maximizar la seguridad mientras se cumplen los requisitos de cumplimiento, la ruta de desarrollo más eficiente y segura es utilizar bibliotecas estándar ampliamente auditadas y reconocidas por la comunidad (como OpenZeppelin), y realizar extensiones de funciones sobre esta base.

Guía de implementación

• Estándar básico: se utiliza ERC-20 como estándar básico para garantizar la homogeneidad de los tokens 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 moneda, que es una herramienta clave 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 asegurar que la cantidad de tokens emitidos corresponda estrictamente a los activos de reserva de moneda fiduciaria.

  • Burnable：proporciona la función de quemar monedas. En la implementación específica, esta función estará controlada por permisos estrictos, en lugar de permitir que cualquier usuario la queme por su cuenta.

  • Freezable: se utiliza para pausar la función de transferencia de monedas de cuentas específicas (como en el caso de transacciones sospechosas).

  • Whitelist: se utiliza para implementar medidas de seguridad adicionales, permitiendo únicamente la participación en operaciones centrales (como la recepción de nuevos tokens emitidos) a direcciones aprobadas y que han pasado la debida diligencia.

  • Lista negra: se utiliza para implementar una prohibición de transacciones sobre direcciones involucradas en actividades ilegales (como el lavado de dinero, fraude), impidiendo que envíen/reciban moneda. 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 granular basado en roles. Todas las funciones de gestión deben pasar por este módulo para controlar los permisos, con el fin de cumplir con los requisitos de separación de funciones.

3. Principales modelos de cumplimiento: selección de listas negras y listas blancas

instrucciones regulatorias

Sobre la supervisión continua, los documentos de consulta sobre la lucha contra el lavado de dinero/financiamiento del terrorismo ( AML/CFT ) proponen diversas medidas, que incluyen "listar en una lista negra las direcciones de billetera identificadas como sancionadas o relacionadas con actividades ilegales", o implementar un control más estricto "con un sistema de lista blanca para las direcciones de billetera de los titulares de moneda estable, o adoptar un modelo de circuito cerrado".

Interpretación técnica

Este es el punto de decisión más crítico dentro de toda la arquitectura del sistema, que determina directamente la apertura, utilidad y complejidad de la operación conforme de la moneda estable.

• Modo de lista negra: un modo de "apertura por defecto". Todas las direcciones pueden comerciar libremente por defecto, solo aquellas que sean explícitamente identificadas y añadidas a la lista negra en la cadena serán restringidas.

• Modo de lista blanca: un modo de "cerrado por defecto". Cualquier dirección, a menos que haya sido sometida a una debida diligencia y aprobación explícitas por parte del emisor y añadida a la lista blanca en la cadena, no podrá poseer ni recibir moneda.

Aunque el modo de lista blanca ofrece capacidades de control de AML (anti-lavado de dinero), un régimen estricto de lista blanca para una moneda estable destinada a un uso amplio significa que la moneda estable solo puede circular entre participantes previamente revisados, lo que la hace parecer más un sistema de libro mayor bancario cerrado en lugar de una moneda digital flexible.

Por lo tanto, el modelo de lista negra, que también ha sido mencionado explícitamente por los reguladores, combinado con las potentes herramientas de análisis fuera de la cadena requeridas por los reguladores, constituye una solución más equilibrada. Satisface los requisitos regulatorios y al mismo tiempo preserva la utilidad de los activos.

En diseño, el sistema puede ser construido como escalable, o implementar simultáneamente dos modos, para poder hacer una transición suave o cambiar al modo de lista blanca en caso de un endurecimiento regulatorio o un cambio en el modelo de negocio en el futuro.

Guía de implementación

• Modo de lista negra (solución recomendada por defecto):

  • Ventajas: tiene una mayor utilidad, pudiendo 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 de monitoreo en tiempo real fuera de la cadena para detectar y bloquear direcciones ilegales de manera oportuna.

  • 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 versatilidad y la tasa de adopción de la moneda estable, lo que conlleva grandes gastos 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, agregar una verificación lógica que exija que las direcciones del remitente (from) y del receptor (to) deben existir en la lista blanca. Se sugiere desarrollar un sistema de backend web para usuarios dedicado para facilitar las operaciones.

Segunda parte Contratos inteligentes implementación

Esta sección proporciona un plano detallado de las funciones centrales de los contratos inteligentes, transformando los complejos requisitos regulatorios en lógica a nivel de código, modos de seguridad y protocolos operativos.

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

instrucciones regulatorias

El diseño de operaciones de alto riesgo debe "prevenir que cualquier parte única pueda ejecutar unilateralmente las operaciones relacionadas (por ejemplo, a través de un protocolo de firma múltiple)". Las responsabilidades de las diferentes operaciones deben estar adecuadamente aisladas.

Interpretación técnica

Esto significa que un sistema de control de acceso basado en roles (RBAC) es obligatorio. Cualquier forma de una única "propietario" o "administrador" clave privada, no es conforme.

Guía de implementación

Es necesario definir una serie de roles claros y asignar estos roles a diferentes entidades o empleados controlados por una billetera multisig, para lograr la separación de responsabilidades y minimizar el riesgo de puntos únicos de falla o manipulación en conspiración. Cada rol debe limitarse a funciones específicas, todas las operaciones requieren autorización multisig, y se debe asegurar que ningún empleado tenga simultáneamente múltiples roles de alto riesgo. Todas las operaciones deben ser registradas en un log y someterse a una auditoría anual por un tercero, la asignación de permisos debe ser supervisada por un administrador o una junta directiva.

• MINTER_ROLE: encargado de manejar la operación de emisión de moneda estable (mint), que incluye la creación de unidades de token tras recibir una solicitud de emisión válida, y asegurar que la emisión coincida con el aumento correspondiente en el grupo 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 redención válida.

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

• RESUME_ROLE: Responsable de la recuperación de la operación de la moneda estable (resume), como reactivar transferencias, emisión o redención después de resolver eventos de pausa.

• FREEZER_ROLE: Responsable de congelar (freeze) y descongelar (remove freeze) operaciones de billeteras o monedas específicas, como 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, como limitar la emisión de monedas solo a direcciones de la lista blanca.

• BLACKLISTER_ROLE: Responsable de gestionar la lista negra (blacklist) y eliminar la lista negra (remove blacklist), como incluir carteras sospechosas en la lista negra para detener transferencias.

• UPGRADER_ROLE: Si se utiliza un modelo actualizable, es responsable de la emisión (upgrade) de los contratos inteligentes, por ejemplo, actualizar el código del contrato para corregir vulnerabilidades o añadir funciones.

Matriz de control de acceso basado en roles ( RBAC Matrix )

La tabla a continuación proporciona una especificación clara e intuitiva para el uso de desarrolladores y auditores, mapeando claramente cada operación privilegiada a su rol requerido y tipo de control.

| Operación | Rol requerido | Tipo de control | |------|----------|----------| | moneda | ROL_DE_ACREEDOR | firma múltiple | | destrucción | ROL_DE_QUEMADO | firma múltiple | | Pausar | PAUSER_ROLE | Multisig | | Recuperar | RESUME_ROLE | firma múltiple | | Congelado | FREEZER_ROLE | Multisig | | Descongelar | ROL_DE_FREEZER | Multisig | | Añadir a la lista blanca | WHITELISTER_ROLE | Múltiples firmas | | Eliminar de la lista blanca | WHITELISTER_ROLE | Múltiple