Guía de implementación de contratos inteligentes para emisores de moneda estable en Hong Kong
Con la aprobación oficial de la "Regulación 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 Licenciados (Borrador)", con el objetivo de garantizar la estabilidad, seguridad y operación conforme del ecosistema local de monedas estables. Dichas directrices detallan los requisitos regulatorios y los estándares operativos que los emisores de monedas estables con licencia deben cumplir de manera continua.
Recientemente, cada vez más instituciones han consultado al equipo de seguridad sobre la implementación de contratos inteligentes de manera conforme. Para ayudar a los emisores a comprender y desplegar mejor un sistema de contratos inteligentes conforme, hemos publicado esta guía de implementación para proporcionar una ruta técnica clara y recomendaciones prácticas, apoyando el desarrollo saludable del ecosistema de moneda estable en Hong Kong.
Primera parte Infraestructura y estrategia de cumplimiento
Esta sección tiene como objetivo establecer la piedra angular de la arquitectura de alto nivel para el sistema de moneda estable, donde las decisiones arquitectónicas están completamente impulsadas por los requisitos más fundamentales del 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 del libro mayor distribuido subyacente
directiva regulatoria
Los titulares de licencias deben evaluar la solidez de la tecnología de contabilidad distribuida subyacente (DLT) que utilizan. Esta evaluación abarca la infraestructura de seguridad, la capacidad de resistencia a ataques comunes (como el ataque del 51%), las garantías de la finalización de transacciones y la fiabilidad de los contratos inteligentes.
Interpretación técnica
Esta no es una simple elección de preferencia técnica, sino una tarea central de cumplimiento. La elección de la blockchain subyacente debe someterse a una debida diligencia formal, y todo el proceso de evaluación debe ser detalladamente documentado para proporcionar una justificación adecuada durante la revisión regulatoria. El proceso de selección del libro mayor subyacente establece en realidad el tono para la seguridad y estabilidad de todo el sistema de moneda estable.
El énfasis de la Autoridad Monetaria de Hong Kong en la solidez del libro mayor, en esencia, es una advertencia a los emisores para evitar el uso de bloques emergentes que no han sido validados por el mercado, que tienen un grado de centralización excesivo o cuya seguridad es 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 validada, debe diseñar e implementar medidas de control compensatorias adicionales.
Guía de implementación
Seleccionar primero cadenas de bloques públicas maduras: se recomienda optar primero por cadenas de bloques públicas maduras y altamente seguras como Ethereum, Arbitrum, entre otras. Estas redes tienen ventajas naturales debido a su resistencia probada, una amplia red de nodos de validación y una supervisión pública continua. 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 llevar a cabo 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 establecidas.
Documento de evaluación de riesgos: El informe de evaluación debe cubrir de manera integral su capacidad para 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 los reguladores la prudencia en la selección de tecnología.
2. Estándares de tokens principales y expansión de funciones de regulación
directrices de supervisión
Los documentos regulatorios 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 centrales, que incluyen la emisión (mint), la destrucción (burn), la actualización (upgrade), la pausa (pause), la reanudación (resume), la congelación (freeze), la inclusión en la lista negra (blacklist) y la inclusión en la lista blanca (whitelist).
Interpretación técnica
La Autoridad Monetaria de Hong Kong ha definido un estándar de token "mejorado por regulación" que en realidad tiene una funcionalidad que supera el estándar ERC-20. Este estándar no solo exige tener 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, el camino de desarrollo más eficiente y seguro es adoptar bibliotecas estándar ampliamente auditadas y reconocidas por la comunidad (como OpenZeppelin) y expandir las funciones sobre esa base.
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.
Ampliación de funciones: debe integrar los siguientes módulos funcionales para cumplir con los requisitos regulatorios:
Pausable: se utiliza para implementar una función de pausa y reanudación global para todas las actividades de moneda, que es una herramienta central para hacer frente a eventos de seguridad importantes.
Mintable: utilizado para que los emisores licenciados 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 en moneda fiduciaria.
Quemable：proporciona la función de destruir monedas. En la implementación específica, esta función estará sujeta a un control de permisos estricto, en lugar de permitir que cualquier usuario la destruya por su cuenta.
Freezable: utilizado para pausar la función de transferencia de monedas de cuentas específicas (como en transacciones sospechosas).
Whitelist: Se utiliza para implementar medidas de seguridad adicionales, permitiendo únicamente que las direcciones aprobadas y que han pasado la debida diligencia participen en operaciones clave (como recibir nuevas monedas emitidas).
Lista negra: se utiliza para implementar una prohibición de transacciones en direcciones involucradas en actividades ilegales (como el lavado de dinero, el 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 con un enfoque detallado. Todas las funciones de gestión deben ser controladas a través de este módulo para cumplir con los requisitos de separación de funciones.
3. Principales modos de cumplimiento: selección de lista negra y lista blanca.
Instrucción regulatoria
Sobre la monitorización continua, el documento de consulta sobre la lucha contra el lavado de dinero/financiamiento del terrorismo ( AML/CFT ) propone diversas medidas, entre las que se incluyen "incluir en una lista negra las direcciones de billetera identificadas como sancionadas o relacionadas con actividades ilegales", o implementar un enfoque más estricto como "la aplicación de 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 en toda la arquitectura del sistema, que determina directamente la apertura, la utilidad y la complejidad de las operaciones de cumplimiento de la moneda estable.
Modo de lista negra: un modo de "apertura predeterminada". Todas las direcciones pueden comerciar libremente por defecto, y solo aquellas que sean identificadas claramente y añadidas a la lista negra en la cadena serán restringidas.
Modo de lista blanca: un modo de "cierre predeterminado". Cualquier dirección, a menos que haya pasado por la debida diligencia y aprobación explícitas del emisor y haya sido añadida a la lista blanca en la cadena, no podrá poseer ni recibir moneda.
A pesar de que el modo de lista blanca proporciona capacidades de control AML (anti lavado de dinero), para una moneda estable destinada a ser ampliamente utilizada, un régimen de lista blanca estricto significa que la moneda solo puede circular entre participantes preseleccionados, 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 se menciona explícitamente en la regulación, combinado con las potentes herramientas de análisis fuera de la cadena requeridas por la regulación, constituye una solución más equilibrada. Satisface tanto los requisitos regulatorios como la utilidad de los activos.
En diseño, el sistema puede ser construido como escalable, o implementar simultáneamente dos modos, para que en el futuro, cuando se endurezcan las regulaciones o cambie el modelo de negocio, pueda hacer una transición suave o cambiar al modo de lista blanca.
Guía de implementación
Modo de lista negra (solución recomendada por defecto):
Ventajas: presenta una mayor utilidad, capaz de interoperar sin problemas con el vasto ecosistema de finanzas descentralizadas (DeFi), proporcionando a los usuarios una barrera de entrada más baja y una experiencia más fluida.
Desventajas: la conformidad depende en gran medida de la capacidad de análisis de monitoreo fuera de la cadena, fuerte y en tiempo real, para detectar y bloquear direcciones ilegales de manera oportuna.
Forma de implementación: en la función de transferencia de contratos inteligentes, añadir 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 la moneda estable, lo que conlleva enormes costos operativos para gestionar la lista blanca, y puede dificultar su aceptación como un medio de intercambio ampliamente utilizado.
Modo de implementación: en la función de transferencia de contratos inteligentes, agregar una verificación lógica que requiera que las direcciones del remitente (from) y del destinatario (to) existan en la lista blanca. Se sugiere desarrollar un sistema de backend web dedicado para facilitar la operación.
Segunda parte implementación de contratos inteligentes
Esta sección proporciona un plano detallado de las funciones centrales de los contratos inteligentes, transformando los complejos requisitos regulatorios en lógica de código específico, modos de seguridad y protocolos operativos.
1. Sistema de control de acceso diseñado de manera detallada
directrices 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 múltiples firmas)". Las responsabilidades de diferentes operaciones deben estar adecuadamente aisladas.
Interpretación técnica
Esto significa que un poderoso y basado en roles sistema de control de acceso (RBAC) es obligatorio. Cualquier forma de una única "propietario" o "administrador" clave privada, es no conforme.
Guía de implementación
Se deben definir una serie de roles claros y asignar estos roles a diferentes entidades o empleados controlados por billeteras de múltiples firmas, para lograr la separación de responsabilidades y minimizar el riesgo de un único punto de fallo o manipulación colusoria. Cada rol debe limitarse a funciones específicas, todas las operaciones deben ser autorizadas por múltiples firmas y asegurarse de 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 anual por un tercero, la asignación de permisos debe ser supervisada por un administrador o una junta directiva.
MINTER_ROLE: Responsable de manejar la emisión de monedas estables ( mint ), incluyendo la creación de unidades de token tras recibir una solicitud de emisión válida, y asegurando que la emisión coincida con el correspondiente aumento en la reserva de activos.
BURNER_ROLE: Responsable de manejar la operación de quema de moneda estable (burn), incluida la quema de unidades de moneda tras recibir una solicitud de rescate válida.
PAUSER_ROLE: Responsable de pausar la operación de la moneda estable (pause), por ejemplo, al detectar eventos anómalos (como amenazas de seguridad) para detener temporalmente las transferencias, la emisión o el rescate.
RESUME_ROLE: Responsable de restaurar la operación de (resume) moneda estable, 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 tokens específicos, por ejemplo, congelar temporalmente activos al detectar actividades sospechosas (como riesgos de lavado de dinero).
WHITELISTER_ROLE: responsable de gestionar la lista blanca (whitelist), incluyendo agregar o eliminar direcciones de billeteras permitidas, por ejemplo, restringir la emisión de monedas solo a las direcciones de la lista blanca.
BLACKLISTER_ROLE: Responsable de gestionar la lista negra (blacklist) y de 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 actualización (upgrade) de los contratos inteligentes, por ejemplo, actualizar el código del contrato para corregir vulnerabilidades o agregar funciones.
Tabla 1: Matriz de Control de Acceso Basada en Roles ( Matriz RBAC )
La tabla a continuación proporciona una norma clara e intuitiva para que los desarrolladores y auditores la utilicen, mapeando claramente cada operación privilegiada a su rol y tipo de control requerido.
| Operación | Rol requerido | Tipo de control |
|------|----------|----------|
| moneda | MINTER_ROLE | múltiples firmas |
| destrucción | ROL_DE_QUEMA | firma múltiple |
| Pausar | PAUSER_ROLE | Multifirma |
| Recuperar | RESUME_ROLE | Multisig |
| Congelado | FREEZER_ROLE | Multifirma |
| descongelar | ROL_DE_FREEZER | múltiples firmas |
| Añadir a la lista blanca | WHITELISTER_ROLE | Multifirma |
| Eliminar de la lista blanca | WHITELISTER_ROLE | Multisig |
| Añadir a la lista negra |
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
12 me gusta
Recompensa
12
5
Republicar
Compartir
Comentar
0/400
SighingCashier
· 08-10 15:32
La regulación ha llegado, solo Hong Kong puede entenderlo.
Ver originalesResponder0
NotGonnaMakeIt
· 08-10 01:51
¿El dólar de Hong Kong ya tiene moneda estable? Honestamente, esta noticia es demasiado impactante.
Ver originalesResponder0
Deconstructionist
· 08-10 01:51
Buena regulación, Información favorable.
Ver originalesResponder0
HashBard
· 08-10 01:49
ngmi lol... hong kong solo está acelerando el libro de jugadas de singapur
Ver originalesResponder0
MintMaster
· 08-10 01:27
¿Ir a la luna? ¡No tonterías, la estabilidad es el camino a seguir!
Guía de implementación del cumplimiento de contratos inteligentes para la emisión de moneda estable en Hong Kong
Guía de implementación de contratos inteligentes para emisores de moneda estable en Hong Kong
Con la aprobación oficial de la "Regulación 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 Licenciados (Borrador)", con el objetivo de garantizar la estabilidad, seguridad y operación conforme del ecosistema local de monedas estables. Dichas directrices detallan los requisitos regulatorios y los estándares operativos que los emisores de monedas estables con licencia deben cumplir de manera continua.
Recientemente, cada vez más instituciones han consultado al equipo de seguridad sobre la implementación de contratos inteligentes de manera conforme. Para ayudar a los emisores a comprender y desplegar mejor un sistema de contratos inteligentes conforme, hemos publicado esta guía de implementación para proporcionar una ruta técnica clara y recomendaciones prácticas, apoyando el desarrollo saludable del ecosistema de moneda estable en Hong Kong.
Primera parte Infraestructura y estrategia de cumplimiento
Esta sección tiene como objetivo establecer la piedra angular de la arquitectura de alto nivel para el sistema de moneda estable, donde las decisiones arquitectónicas están completamente impulsadas por los requisitos más fundamentales del 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 del libro mayor distribuido subyacente
directiva regulatoria
Los titulares de licencias deben evaluar la solidez de la tecnología de contabilidad distribuida subyacente (DLT) que utilizan. Esta evaluación abarca la infraestructura de seguridad, la capacidad de resistencia a ataques comunes (como el ataque del 51%), las garantías de la finalización de transacciones y la fiabilidad de los contratos inteligentes.
Interpretación técnica
Esta no es una simple elección de preferencia técnica, sino una tarea central de cumplimiento. La elección de la blockchain subyacente debe someterse a una debida diligencia formal, y todo el proceso de evaluación debe ser detalladamente documentado para proporcionar una justificación adecuada durante la revisión regulatoria. El proceso de selección del libro mayor subyacente establece en realidad el tono para la seguridad y estabilidad de todo el sistema de moneda estable.
El énfasis de la Autoridad Monetaria de Hong Kong en la solidez del libro mayor, en esencia, es una advertencia a los emisores para evitar el uso de bloques emergentes que no han sido validados por el mercado, que tienen un grado de centralización excesivo o cuya seguridad es 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 validada, debe diseñar e implementar medidas de control compensatorias adicionales.
Guía de implementación
Seleccionar primero cadenas de bloques públicas maduras: se recomienda optar primero por cadenas de bloques públicas maduras y altamente seguras como Ethereum, Arbitrum, entre otras. Estas redes tienen ventajas naturales debido a su resistencia probada, una amplia red de nodos de validación y una supervisión pública continua. 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 llevar a cabo 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 establecidas.
Documento de evaluación de riesgos: El informe de evaluación debe cubrir de manera integral su capacidad para 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 los reguladores la prudencia en la selección de tecnología.
2. Estándares de tokens principales y expansión de funciones de regulación
directrices de supervisión
Los documentos regulatorios 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 centrales, que incluyen la emisión (mint), la destrucción (burn), la actualización (upgrade), la pausa (pause), la reanudación (resume), la congelación (freeze), la inclusión en la lista negra (blacklist) y la inclusión en la lista blanca (whitelist).
Interpretación técnica
La Autoridad Monetaria de Hong Kong ha definido un estándar de token "mejorado por regulación" que en realidad tiene una funcionalidad que supera el estándar ERC-20. Este estándar no solo exige tener 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, el camino de desarrollo más eficiente y seguro es adoptar bibliotecas estándar ampliamente auditadas y reconocidas por la comunidad (como OpenZeppelin) y expandir las funciones sobre esa base.
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.
Ampliación de funciones: debe integrar los siguientes módulos funcionales para cumplir con los requisitos regulatorios:
Pausable: se utiliza para implementar una función de pausa y reanudación global para todas las actividades de moneda, que es una herramienta central para hacer frente a eventos de seguridad importantes.
Mintable: utilizado para que los emisores licenciados 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 en moneda fiduciaria.
Quemable：proporciona la función de destruir monedas. En la implementación específica, esta función estará sujeta a un control de permisos estricto, en lugar de permitir que cualquier usuario la destruya por su cuenta.
Freezable: utilizado para pausar la función de transferencia de monedas de cuentas específicas (como en transacciones sospechosas).
Whitelist: Se utiliza para implementar medidas de seguridad adicionales, permitiendo únicamente que las direcciones aprobadas y que han pasado la debida diligencia participen en operaciones clave (como recibir nuevas monedas emitidas).
Lista negra: se utiliza para implementar una prohibición de transacciones en direcciones involucradas en actividades ilegales (como el lavado de dinero, el 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 con un enfoque detallado. Todas las funciones de gestión deben ser controladas a través de este módulo para cumplir con los requisitos de separación de funciones.
3. Principales modos de cumplimiento: selección de lista negra y lista blanca.
Instrucción regulatoria
Sobre la monitorización continua, el documento de consulta sobre la lucha contra el lavado de dinero/financiamiento del terrorismo ( AML/CFT ) propone diversas medidas, entre las que se incluyen "incluir en una lista negra las direcciones de billetera identificadas como sancionadas o relacionadas con actividades ilegales", o implementar un enfoque más estricto como "la aplicación de 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 en toda la arquitectura del sistema, que determina directamente la apertura, la utilidad y la complejidad de las operaciones de cumplimiento de la moneda estable.
Modo de lista negra: un modo de "apertura predeterminada". Todas las direcciones pueden comerciar libremente por defecto, y solo aquellas que sean identificadas claramente y añadidas a la lista negra en la cadena serán restringidas.
Modo de lista blanca: un modo de "cierre predeterminado". Cualquier dirección, a menos que haya pasado por la debida diligencia y aprobación explícitas del emisor y haya sido añadida a la lista blanca en la cadena, no podrá poseer ni recibir moneda.
A pesar de que el modo de lista blanca proporciona capacidades de control AML (anti lavado de dinero), para una moneda estable destinada a ser ampliamente utilizada, un régimen de lista blanca estricto significa que la moneda solo puede circular entre participantes preseleccionados, 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 se menciona explícitamente en la regulación, combinado con las potentes herramientas de análisis fuera de la cadena requeridas por la regulación, constituye una solución más equilibrada. Satisface tanto los requisitos regulatorios como la utilidad de los activos.
En diseño, el sistema puede ser construido como escalable, o implementar simultáneamente dos modos, para que en el futuro, cuando se endurezcan las regulaciones o cambie el modelo de negocio, pueda hacer una transición suave o cambiar al modo de lista blanca.
Guía de implementación
Modo de lista negra (solución recomendada por defecto):
Ventajas: presenta una mayor utilidad, capaz de interoperar sin problemas con el vasto ecosistema de finanzas descentralizadas (DeFi), proporcionando a los usuarios una barrera de entrada más baja y una experiencia más fluida.
Desventajas: la conformidad depende en gran medida de la capacidad de análisis de monitoreo fuera de la cadena, fuerte y en tiempo real, para detectar y bloquear direcciones ilegales de manera oportuna.
Forma de implementación: en la función de transferencia de contratos inteligentes, añadir 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 la moneda estable, lo que conlleva enormes costos operativos para gestionar la lista blanca, y puede dificultar su aceptación como un medio de intercambio ampliamente utilizado.
Modo de implementación: en la función de transferencia de contratos inteligentes, agregar una verificación lógica que requiera que las direcciones del remitente (from) y del destinatario (to) existan en la lista blanca. Se sugiere desarrollar un sistema de backend web dedicado para facilitar la operación.
Segunda parte implementación de contratos inteligentes
Esta sección proporciona un plano detallado de las funciones centrales de los contratos inteligentes, transformando los complejos requisitos regulatorios en lógica de código específico, modos de seguridad y protocolos operativos.
1. Sistema de control de acceso diseñado de manera detallada
directrices 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 múltiples firmas)". Las responsabilidades de diferentes operaciones deben estar adecuadamente aisladas.
Interpretación técnica
Esto significa que un poderoso y basado en roles sistema de control de acceso (RBAC) es obligatorio. Cualquier forma de una única "propietario" o "administrador" clave privada, es no conforme.
Guía de implementación
Se deben definir una serie de roles claros y asignar estos roles a diferentes entidades o empleados controlados por billeteras de múltiples firmas, para lograr la separación de responsabilidades y minimizar el riesgo de un único punto de fallo o manipulación colusoria. Cada rol debe limitarse a funciones específicas, todas las operaciones deben ser autorizadas por múltiples firmas y asegurarse de 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 anual por un tercero, la asignación de permisos debe ser supervisada por un administrador o una junta directiva.
MINTER_ROLE: Responsable de manejar la emisión de monedas estables ( mint ), incluyendo la creación de unidades de token tras recibir una solicitud de emisión válida, y asegurando que la emisión coincida con el correspondiente aumento en la reserva de activos.
BURNER_ROLE: Responsable de manejar la operación de quema de moneda estable (burn), incluida la quema de unidades de moneda tras recibir una solicitud de rescate válida.
PAUSER_ROLE: Responsable de pausar la operación de la moneda estable (pause), por ejemplo, al detectar eventos anómalos (como amenazas de seguridad) para detener temporalmente las transferencias, la emisión o el rescate.
RESUME_ROLE: Responsable de restaurar la operación de (resume) moneda estable, 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 tokens específicos, por ejemplo, congelar temporalmente activos al detectar actividades sospechosas (como riesgos de lavado de dinero).
WHITELISTER_ROLE: responsable de gestionar la lista blanca (whitelist), incluyendo agregar o eliminar direcciones de billeteras permitidas, por ejemplo, restringir la emisión de monedas solo a las direcciones de la lista blanca.
BLACKLISTER_ROLE: Responsable de gestionar la lista negra (blacklist) y de 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 actualización (upgrade) de los contratos inteligentes, por ejemplo, actualizar el código del contrato para corregir vulnerabilidades o agregar funciones.
Tabla 1: Matriz de Control de Acceso Basada en Roles ( Matriz RBAC )
La tabla a continuación proporciona una norma clara e intuitiva para que los desarrolladores y auditores la utilicen, mapeando claramente cada operación privilegiada a su rol y tipo de control requerido.
| Operación | Rol requerido | Tipo de control | |------|----------|----------| | moneda | MINTER_ROLE | múltiples firmas | | destrucción | ROL_DE_QUEMA | firma múltiple | | Pausar | PAUSER_ROLE | Multifirma | | Recuperar | RESUME_ROLE | Multisig | | Congelado | FREEZER_ROLE | Multifirma | | descongelar | ROL_DE_FREEZER | múltiples firmas | | Añadir a la lista blanca | WHITELISTER_ROLE | Multifirma | | Eliminar de la lista blanca | WHITELISTER_ROLE | Multisig | | Añadir a la lista negra |