Com a aprovação oficial da "Regulamentação sobre Stablecoins", a Autoridade Monetária de Hong Kong publicou, a 26 de maio de 2025, a "Orientação Regulamentar para Emissores Licenciados de Stablecoins (Rascunho)", com o objetivo de garantir a estabilidade, segurança e conformidade do ecossistema local de stablecoins. Esta orientação detalha os requisitos regulatórios e os padrões operacionais que os emissores licenciados de stablecoins devem cumprir continuamente.
Recentemente, cada vez mais instituições têm consultado as equipes de segurança sobre questões relacionadas à implementação de contratos inteligentes em conformidade. Para ajudar os emissores a entender e implementar melhor um sistema de contratos inteligentes em conformidade, publicamos especialmente o "Guia de Implementação de Contratos Inteligentes para Emissores de Stablecoins de Hong Kong", para fornecer um caminho técnico claro e recomendações práticas, apoiando o desenvolvimento saudável do ecossistema de stablecoins de Hong Kong.
Primeira Parte Infraestrutura e Estratégia de Conformidade
Esta seção tem como objetivo estabelecer a base da arquitetura de alto nível para sistemas de stablecoin, onde as decisões arquitetônicas são completamente impulsionadas pelos requisitos fundamentais do quadro da Autoridade Monetária de Hong Kong. As escolhas feitas aqui determinarão todo o caminho de implementação, garantindo que a conformidade seja profundamente incorporada na pilha tecnológica desde o início do design.
1. Seleção do livro-razão distribuído de base
Instruções regulatórias
Os licenciados devem avaliar a robustez da tecnologia de livro-razão distribuído subjacente que estão a utilizar (DLT). Esta avaliação abrange a infraestrutura de segurança, a capacidade de resistência a ataques comuns (como o ataque de 51%), a garantia de finalização de transações e a fiabilidade do algoritmo de consenso.
Interpretação Técnica
Esta não é uma simples escolha de preferência técnica, mas uma tarefa de conformidade essencial. A escolha da blockchain subjacente deve passar por uma devida diligência formal, e todo o processo de avaliação deve ser devidamente registrado para fornecer uma base adequada durante a revisão regulatória. O processo de escolha do livro-razão subjacente, na verdade, estabelece o tom para a segurança e estabilidade de todo o sistema de stablecoins.
A ênfase da Autoridade Monetária de Hong Kong na solidez do livro razão é, na verdade, um aviso para que os emissores evitem adotar blockchains emergentes que não foram validadas pelo mercado, que têm um grau excessivo de centralização ou cuja segurança é duvidosa. A responsabilidade de provar sua segurança e estabilidade recai inteiramente sobre o emissor. Se o emissor escolher uma blockchain cuja segurança ainda não foi amplamente validada, deve projetar e implementar medidas de controle compensatórias adicionais.
Guia de Implementação
Priorize escolher blockchains públicas maduras: recomenda-se optar prioritariamente por blockchains públicas maduras e com alta segurança, como Ethereum e Arbitrum. Essas redes possuem vantagens naturais devido à sua resiliência comprovada, vasta rede de nós de validação e supervisão pública contínua. Seu alto custo de ataque (segurança econômica) pode responder diretamente às preocupações regulatórias sobre a resistência a ataques de 51% e a garantia da finalização das transações.
Avaliação rigorosa das alternativas: Se considerar a adoção de uma blockchain de consórcio ou outro tipo de livro-razão distribuído, deve ser realizada uma análise comparativa rigorosa e quantificável, como uma auditoria de segurança, para demonstrar que seus padrões de segurança não são inferiores e até superam os das blockchains públicas mainstream.
Documento de Avaliação de Risco: O relatório de avaliação deve cobrir de forma abrangente a capacidade de resistir a ataques comuns, o tipo de algoritmo de consenso, bem como os riscos relacionados a falhas de código, vulnerabilidades, explorações e outras ameaças, analisando detalhadamente como esses riscos podem impactar potencialmente a emissão, a troca e as operações diárias da moeda estável. Este documento é o arquivo chave para demonstrar a prudência na escolha técnica junto das entidades reguladoras.
2. Padrão de token central e expansão da funcionalidade de regulamentação
Diretiva de supervisão
Os documentos regulatórios não especificam um padrão de token específico (como ERC-20). No entanto, os documentos exigem a implementação de uma série de funções de gestão essenciais, incluindo mintagem (mint), queima (burn), atualização (upgrade), pausa (pause), retoma (resume), congelamento (freeze), lista negra (blacklist), lista branca (whitelist) e outras operações.
Interpretação técnica
O Banco da China em Hong Kong definiu, de fato, um padrão de "token aprimorado pela regulamentação" que vai muito além do padrão ERC-20. Este padrão não só exige a capacidade básica de circulação de tokens, mas também enfatiza a segurança operacional, a controlabilidade de permissões e a rastreabilidade de riscos. Para garantir a máxima segurança enquanto atende aos requisitos de conformidade, o caminho de desenvolvimento mais eficiente e seguro é usar bibliotecas padrão amplamente auditadas e reconhecidas pela comunidade (como OpenZeppelin) e, a partir daí, expandir as funcionalidades.
Guia de Implementação
Padrão básico: utiliza ERC-20 como padrão básico para garantir a homogeneidade dos tokens e a interoperabilidade em um ecossistema mais amplo.
Expansão de funcionalidades: devem ser integrados os seguintes módulos de funcionalidade para atender aos requisitos regulatórios:
Pausable: utilizado para implementar a funcionalidade de pausa e recuperação global de todas as atividades de tokens, que é a ferramenta central para lidar com eventos de segurança significativos.
Mintable: utilizado para permitir que emissores licenciados mintem novos tokens através de um processo controlado, garantindo que a quantidade de tokens emitidos corresponda rigorosamente ao ativo de reserva em moeda fiduciária.
Queimável: fornece a funcionalidade de queimar tokens. Na implementação específica, esta funcionalidade será controlada por permissões rigorosas, em vez de permitir que qualquer usuário a queime por conta própria.
Congelável: usado para pausar a funcionalidade de transferência de tokens de contas específicas (como em transações suspeitas).
Whitelist: Utilizado para implementar medidas de segurança adicionais, permitindo apenas que endereços aprovados e devidamente verificados participem de operações essenciais (como receber novos tokens emitidos).
Lista negra: utilizada para implementar proibições de transação em endereços envolvidos em atividades ilegais (como lavagem de dinheiro, fraude), proibindo o envio/recebimento de tokens. A gestão da lista negra deve estar integrada ao sistema AML/CFT, monitorizando transações suspeitas em tempo real.
AccessControl: Esta é a base para implementar um sistema de gestão de permissões baseado em funções e detalhado. Todas as funções de gestão devem ser controladas por este módulo para atender aos requisitos de separação de responsabilidades.
3. Principais modos de conformidade: seleção de lista negra e lista branca
Instruções de Regulamentação
Em relação à monitorização contínua, o documento de consulta sobre a prevenção de lavagem de dinheiro/combate ao financiamento do terrorismo ( AML/CFT ) propôs várias medidas, incluindo "colocar em lista negra endereços de carteiras identificados como sancionados ou relacionados com atividades ilegais", ou implementar um regime mais rigoroso de "lista branca para endereços de carteiras de detentores de stablecoins, ou adotar um modelo de circuito fechado".
Interpretação Técnica
Este é o ponto de decisão mais crítico em toda a arquitetura do sistema, que determina diretamente a abertura, utilidade e complexidade das operações de conformidade da moeda estável.
Modo de lista negra: um modo de "abertura padrão". Todos os endereços podem negociar livremente por padrão, apenas aqueles que são claramente identificados e adicionados à lista negra na cadeia serão restritos.
Modo de lista branca: um modo de "fechado por padrão". Qualquer endereço, a menos que tenha passado por uma devida diligência e aprovação explícitas por parte do emissor e seja adicionado à lista branca na blockchain, não pode possuir ou receber tokens.
Embora o modo de lista branca ofereça capacidade de controle de AML (anti-lavagem de dinheiro), um sistema rigoroso de lista branca significa que a stablecoin só pode circular entre participantes previamente verificados, o que a torna mais semelhante a um sistema de livro contábil bancário fechado, em vez de uma moeda digital flexível.
Assim, o modelo da lista negra, que também é mencionado especificamente pelos reguladores, combinado com as poderosas ferramentas de análise off-chain exigidas pela regulação, forma uma solução mais equilibrada. Esta solução atende às exigências regulatórias e mantém a utilidade dos ativos.
No design, o sistema pode ser construído como escalável, ou implementar simultaneamente os dois modos, de modo a permitir uma transição suave ou uma mudança para o modo de lista branca no futuro, caso haja um endurecimento da regulamentação ou uma mudança no modelo de negócios.
Guia de Implementação
Modo de lista negra (esquema recomendado por padrão):
Vantagens: possui maior utilidade, permitindo a interoperabilidade perfeita com o vasto ecossistema de finanças descentralizadas (DeFi), oferecendo aos usuários uma barreira de entrada mais baixa e uma experiência mais fluida.
Desvantagens: A conformidade depende fortemente de uma capacidade robusta de análise de monitoramento off-chain em tempo real para detectar e bloquear endereços ilegais a tempo.
Modo de implementação: Na função de transferência do contrato inteligente, adicione uma verificação lógica para garantir que o endereço do remetente (from) e o endereço do destinatário (to) não estejam registrados na lista negra.
Modo de Lista Branca
Vantagens: oferece o mais alto nível de controle AML/CFT, implementando a prevenção antecipada em vez de remediação posterior.
Desvantagens: limita enormemente a utilidade e a taxa de adoção das stablecoins, trazendo enormes custos operacionais para a gestão de listas brancas, o que pode dificultar a sua aceitação como um meio de troca amplamente utilizado.
Modo de implementação: na função de transferência do contrato inteligente, adicionar uma verificação lógica, exigindo que os endereços do remetente (from) e do destinatário (to) estejam ambos incluídos na lista branca. Recomenda-se desenvolver um sistema de backend web dedicado para operações, aumentando a conveniência das operações.
Segunda Parte Implementação do Contrato Inteligente
Esta parte fornece um plano detalhado das funções principais do contrato inteligente, transformando requisitos regulatórios complexos em lógica de nível de código, modos de segurança e protocolos operacionais específicos.
1. Sistema de controle de acesso detalhado
Instrução regulatória
O design de operações de alto risco deve "prevenir que qualquer parte única possa executar unilateralmente operações relacionadas (por exemplo, através de um protocolo de múltiplas assinaturas)". As responsabilidades de diferentes operações devem ser devidamente isoladas.
Interpretação Técnica
Isto significa que um sistema de controlo de acesso robusto e baseado em funções (RBAC) é obrigatório. Qualquer forma de chave privada "proprietário" ou "administrador" única é considerada não conforme.
Guia de Implementação
É necessário definir uma série de papéis claros e atribuí-los a diferentes entidades ou funcionários controlados por carteiras multi-assinatura, a fim de implementar a separação de funções, minimizando o risco de pontos únicos de falha ou manipulação conivente. Cada papel deve ser limitado a funções específicas, todas as operações devem ter autorização multi-assinada e garantir que nenhum funcionário tenha simultaneamente vários papéis de alto risco. Todas as operações devem ser registradas em log e sujeitas a auditoria anual de terceiros, e a atribuição de permissões deve ser supervisionada por um administrador ou conselho.
MINTER_ROLE: Responsável por lidar com operações de mintagem de stablecoin (mint), incluindo a criação de unidades de token após receber um pedido de emissão válido, e garantir que a mintagem corresponda ao aumento correspondente no pool de ativos de reserva.
BURNER_ROLE: Responsável por processar a destruição de stablecoins (burn), incluindo a destruição de unidades de tokens após receber um pedido de resgate válido.
PAUSER_ROLE: Responsável por pausar (pause) operações de stablecoin, como interromper temporariamente transferências, emissão ou resgate ao detectar eventos anormais (como ameaças de segurança).
RESUME_ROLE: Responsável por restaurar a operação do (resume) stablecoin, como reativar transferências, cunhagem ou resgate após a resolução de eventos de suspensão.
FREEZER_ROLE: Responsável por congelar (freeze) e descongelar (remove freeze) operações de carteiras ou tokens específicos, como congelar temporariamente activos ao detectar atividades suspeitas (como risco de lavagem de dinheiro).
WHITELISTER_ROLE: responsável por gerenciar a whitelist (whitelist), incluindo a adição ou remoção de endereços de carteira permitidos, como restringir a cunhagem apenas a endereços da whitelist.
BLACKLISTER_ROLE: Responsável pela gestão da lista negra (blacklist) e remoção da lista negra (remove blacklist), por exemplo, adicionar carteiras suspeitas à lista negra para impedir transferências.
UPGRADER_ROLE: Se um modelo atualizável for adotado, é responsável pela atualização do contrato inteligente (upgrade), por exemplo, atualizar o código do contrato para corrigir vulnerabilidades ou adicionar funcionalidades.
Tabela 1: Matriz de Controle de Acesso Baseada em Papel ( Matriz RBAC )
A tabela abaixo fornece uma norma clara e intuitiva, a ser utilizada por desenvolvedores e auditores, mapeando claramente cada operação privilegiada para os papéis e tipos de controle necessários.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
8 Curtidas
Recompensa
8
6
Compartilhar
Comentário
0/400
BearWhisperGod
· 6h atrás
mundo crypto mais cedo, leia e durma
Ver originalResponder0
HallucinationGrower
· 6h atrás
A ação de Hong Kong desta vez está boa~
Ver originalResponder0
MintMaster
· 6h atrás
Já está em conformidade novamente.
Ver originalResponder0
NFTHoarder
· 6h atrás
A governança da moeda estável finalmente chegou. Estou ansioso por isso.
Ver originalResponder0
MetadataExplorer
· 6h atrás
O porto já se mexeu? Hum, essa operação é bastante estável.
Ver originalResponder0
WalletDetective
· 6h atrás
A regulamentação está de volta, investidores de retalho, fiquem tranquilos.
O HKMA de Hong Kong publica diretrizes de implementação de contratos inteligentes de moeda estável, com foco na conformidade e segurança.
Texto
Com a aprovação oficial da "Regulamentação sobre Stablecoins", a Autoridade Monetária de Hong Kong publicou, a 26 de maio de 2025, a "Orientação Regulamentar para Emissores Licenciados de Stablecoins (Rascunho)", com o objetivo de garantir a estabilidade, segurança e conformidade do ecossistema local de stablecoins. Esta orientação detalha os requisitos regulatórios e os padrões operacionais que os emissores licenciados de stablecoins devem cumprir continuamente.
Recentemente, cada vez mais instituições têm consultado as equipes de segurança sobre questões relacionadas à implementação de contratos inteligentes em conformidade. Para ajudar os emissores a entender e implementar melhor um sistema de contratos inteligentes em conformidade, publicamos especialmente o "Guia de Implementação de Contratos Inteligentes para Emissores de Stablecoins de Hong Kong", para fornecer um caminho técnico claro e recomendações práticas, apoiando o desenvolvimento saudável do ecossistema de stablecoins de Hong Kong.
Primeira Parte Infraestrutura e Estratégia de Conformidade
Esta seção tem como objetivo estabelecer a base da arquitetura de alto nível para sistemas de stablecoin, onde as decisões arquitetônicas são completamente impulsionadas pelos requisitos fundamentais do quadro da Autoridade Monetária de Hong Kong. As escolhas feitas aqui determinarão todo o caminho de implementação, garantindo que a conformidade seja profundamente incorporada na pilha tecnológica desde o início do design.
1. Seleção do livro-razão distribuído de base
Instruções regulatórias
Os licenciados devem avaliar a robustez da tecnologia de livro-razão distribuído subjacente que estão a utilizar (DLT). Esta avaliação abrange a infraestrutura de segurança, a capacidade de resistência a ataques comuns (como o ataque de 51%), a garantia de finalização de transações e a fiabilidade do algoritmo de consenso.
Interpretação Técnica
Esta não é uma simples escolha de preferência técnica, mas uma tarefa de conformidade essencial. A escolha da blockchain subjacente deve passar por uma devida diligência formal, e todo o processo de avaliação deve ser devidamente registrado para fornecer uma base adequada durante a revisão regulatória. O processo de escolha do livro-razão subjacente, na verdade, estabelece o tom para a segurança e estabilidade de todo o sistema de stablecoins.
A ênfase da Autoridade Monetária de Hong Kong na solidez do livro razão é, na verdade, um aviso para que os emissores evitem adotar blockchains emergentes que não foram validadas pelo mercado, que têm um grau excessivo de centralização ou cuja segurança é duvidosa. A responsabilidade de provar sua segurança e estabilidade recai inteiramente sobre o emissor. Se o emissor escolher uma blockchain cuja segurança ainda não foi amplamente validada, deve projetar e implementar medidas de controle compensatórias adicionais.
Guia de Implementação
Priorize escolher blockchains públicas maduras: recomenda-se optar prioritariamente por blockchains públicas maduras e com alta segurança, como Ethereum e Arbitrum. Essas redes possuem vantagens naturais devido à sua resiliência comprovada, vasta rede de nós de validação e supervisão pública contínua. Seu alto custo de ataque (segurança econômica) pode responder diretamente às preocupações regulatórias sobre a resistência a ataques de 51% e a garantia da finalização das transações.
Avaliação rigorosa das alternativas: Se considerar a adoção de uma blockchain de consórcio ou outro tipo de livro-razão distribuído, deve ser realizada uma análise comparativa rigorosa e quantificável, como uma auditoria de segurança, para demonstrar que seus padrões de segurança não são inferiores e até superam os das blockchains públicas mainstream.
Documento de Avaliação de Risco: O relatório de avaliação deve cobrir de forma abrangente a capacidade de resistir a ataques comuns, o tipo de algoritmo de consenso, bem como os riscos relacionados a falhas de código, vulnerabilidades, explorações e outras ameaças, analisando detalhadamente como esses riscos podem impactar potencialmente a emissão, a troca e as operações diárias da moeda estável. Este documento é o arquivo chave para demonstrar a prudência na escolha técnica junto das entidades reguladoras.
2. Padrão de token central e expansão da funcionalidade de regulamentação
Diretiva de supervisão
Os documentos regulatórios não especificam um padrão de token específico (como ERC-20). No entanto, os documentos exigem a implementação de uma série de funções de gestão essenciais, incluindo mintagem (mint), queima (burn), atualização (upgrade), pausa (pause), retoma (resume), congelamento (freeze), lista negra (blacklist), lista branca (whitelist) e outras operações.
Interpretação técnica
O Banco da China em Hong Kong definiu, de fato, um padrão de "token aprimorado pela regulamentação" que vai muito além do padrão ERC-20. Este padrão não só exige a capacidade básica de circulação de tokens, mas também enfatiza a segurança operacional, a controlabilidade de permissões e a rastreabilidade de riscos. Para garantir a máxima segurança enquanto atende aos requisitos de conformidade, o caminho de desenvolvimento mais eficiente e seguro é usar bibliotecas padrão amplamente auditadas e reconhecidas pela comunidade (como OpenZeppelin) e, a partir daí, expandir as funcionalidades.
Guia de Implementação
Padrão básico: utiliza ERC-20 como padrão básico para garantir a homogeneidade dos tokens e a interoperabilidade em um ecossistema mais amplo.
Expansão de funcionalidades: devem ser integrados os seguintes módulos de funcionalidade para atender aos requisitos regulatórios:
Pausable: utilizado para implementar a funcionalidade de pausa e recuperação global de todas as atividades de tokens, que é a ferramenta central para lidar com eventos de segurança significativos.
Mintable: utilizado para permitir que emissores licenciados mintem novos tokens através de um processo controlado, garantindo que a quantidade de tokens emitidos corresponda rigorosamente ao ativo de reserva em moeda fiduciária.
Queimável: fornece a funcionalidade de queimar tokens. Na implementação específica, esta funcionalidade será controlada por permissões rigorosas, em vez de permitir que qualquer usuário a queime por conta própria.
Congelável: usado para pausar a funcionalidade de transferência de tokens de contas específicas (como em transações suspeitas).
Whitelist: Utilizado para implementar medidas de segurança adicionais, permitindo apenas que endereços aprovados e devidamente verificados participem de operações essenciais (como receber novos tokens emitidos).
Lista negra: utilizada para implementar proibições de transação em endereços envolvidos em atividades ilegais (como lavagem de dinheiro, fraude), proibindo o envio/recebimento de tokens. A gestão da lista negra deve estar integrada ao sistema AML/CFT, monitorizando transações suspeitas em tempo real.
AccessControl: Esta é a base para implementar um sistema de gestão de permissões baseado em funções e detalhado. Todas as funções de gestão devem ser controladas por este módulo para atender aos requisitos de separação de responsabilidades.
3. Principais modos de conformidade: seleção de lista negra e lista branca
Instruções de Regulamentação
Em relação à monitorização contínua, o documento de consulta sobre a prevenção de lavagem de dinheiro/combate ao financiamento do terrorismo ( AML/CFT ) propôs várias medidas, incluindo "colocar em lista negra endereços de carteiras identificados como sancionados ou relacionados com atividades ilegais", ou implementar um regime mais rigoroso de "lista branca para endereços de carteiras de detentores de stablecoins, ou adotar um modelo de circuito fechado".
Interpretação Técnica
Este é o ponto de decisão mais crítico em toda a arquitetura do sistema, que determina diretamente a abertura, utilidade e complexidade das operações de conformidade da moeda estável.
Modo de lista negra: um modo de "abertura padrão". Todos os endereços podem negociar livremente por padrão, apenas aqueles que são claramente identificados e adicionados à lista negra na cadeia serão restritos.
Modo de lista branca: um modo de "fechado por padrão". Qualquer endereço, a menos que tenha passado por uma devida diligência e aprovação explícitas por parte do emissor e seja adicionado à lista branca na blockchain, não pode possuir ou receber tokens.
Embora o modo de lista branca ofereça capacidade de controle de AML (anti-lavagem de dinheiro), um sistema rigoroso de lista branca significa que a stablecoin só pode circular entre participantes previamente verificados, o que a torna mais semelhante a um sistema de livro contábil bancário fechado, em vez de uma moeda digital flexível.
Assim, o modelo da lista negra, que também é mencionado especificamente pelos reguladores, combinado com as poderosas ferramentas de análise off-chain exigidas pela regulação, forma uma solução mais equilibrada. Esta solução atende às exigências regulatórias e mantém a utilidade dos ativos.
No design, o sistema pode ser construído como escalável, ou implementar simultaneamente os dois modos, de modo a permitir uma transição suave ou uma mudança para o modo de lista branca no futuro, caso haja um endurecimento da regulamentação ou uma mudança no modelo de negócios.
Guia de Implementação
Modo de lista negra (esquema recomendado por padrão):
Vantagens: possui maior utilidade, permitindo a interoperabilidade perfeita com o vasto ecossistema de finanças descentralizadas (DeFi), oferecendo aos usuários uma barreira de entrada mais baixa e uma experiência mais fluida.
Desvantagens: A conformidade depende fortemente de uma capacidade robusta de análise de monitoramento off-chain em tempo real para detectar e bloquear endereços ilegais a tempo.
Modo de implementação: Na função de transferência do contrato inteligente, adicione uma verificação lógica para garantir que o endereço do remetente (from) e o endereço do destinatário (to) não estejam registrados na lista negra.
Modo de Lista Branca
Vantagens: oferece o mais alto nível de controle AML/CFT, implementando a prevenção antecipada em vez de remediação posterior.
Desvantagens: limita enormemente a utilidade e a taxa de adoção das stablecoins, trazendo enormes custos operacionais para a gestão de listas brancas, o que pode dificultar a sua aceitação como um meio de troca amplamente utilizado.
Modo de implementação: na função de transferência do contrato inteligente, adicionar uma verificação lógica, exigindo que os endereços do remetente (from) e do destinatário (to) estejam ambos incluídos na lista branca. Recomenda-se desenvolver um sistema de backend web dedicado para operações, aumentando a conveniência das operações.
Segunda Parte Implementação do Contrato Inteligente
Esta parte fornece um plano detalhado das funções principais do contrato inteligente, transformando requisitos regulatórios complexos em lógica de nível de código, modos de segurança e protocolos operacionais específicos.
1. Sistema de controle de acesso detalhado
Instrução regulatória
O design de operações de alto risco deve "prevenir que qualquer parte única possa executar unilateralmente operações relacionadas (por exemplo, através de um protocolo de múltiplas assinaturas)". As responsabilidades de diferentes operações devem ser devidamente isoladas.
Interpretação Técnica
Isto significa que um sistema de controlo de acesso robusto e baseado em funções (RBAC) é obrigatório. Qualquer forma de chave privada "proprietário" ou "administrador" única é considerada não conforme.
Guia de Implementação
É necessário definir uma série de papéis claros e atribuí-los a diferentes entidades ou funcionários controlados por carteiras multi-assinatura, a fim de implementar a separação de funções, minimizando o risco de pontos únicos de falha ou manipulação conivente. Cada papel deve ser limitado a funções específicas, todas as operações devem ter autorização multi-assinada e garantir que nenhum funcionário tenha simultaneamente vários papéis de alto risco. Todas as operações devem ser registradas em log e sujeitas a auditoria anual de terceiros, e a atribuição de permissões deve ser supervisionada por um administrador ou conselho.
MINTER_ROLE: Responsável por lidar com operações de mintagem de stablecoin (mint), incluindo a criação de unidades de token após receber um pedido de emissão válido, e garantir que a mintagem corresponda ao aumento correspondente no pool de ativos de reserva.
BURNER_ROLE: Responsável por processar a destruição de stablecoins (burn), incluindo a destruição de unidades de tokens após receber um pedido de resgate válido.
PAUSER_ROLE: Responsável por pausar (pause) operações de stablecoin, como interromper temporariamente transferências, emissão ou resgate ao detectar eventos anormais (como ameaças de segurança).
RESUME_ROLE: Responsável por restaurar a operação do (resume) stablecoin, como reativar transferências, cunhagem ou resgate após a resolução de eventos de suspensão.
FREEZER_ROLE: Responsável por congelar (freeze) e descongelar (remove freeze) operações de carteiras ou tokens específicos, como congelar temporariamente activos ao detectar atividades suspeitas (como risco de lavagem de dinheiro).
WHITELISTER_ROLE: responsável por gerenciar a whitelist (whitelist), incluindo a adição ou remoção de endereços de carteira permitidos, como restringir a cunhagem apenas a endereços da whitelist.
BLACKLISTER_ROLE: Responsável pela gestão da lista negra (blacklist) e remoção da lista negra (remove blacklist), por exemplo, adicionar carteiras suspeitas à lista negra para impedir transferências.
UPGRADER_ROLE: Se um modelo atualizável for adotado, é responsável pela atualização do contrato inteligente (upgrade), por exemplo, atualizar o código do contrato para corrigir vulnerabilidades ou adicionar funcionalidades.
Tabela 1: Matriz de Controle de Acesso Baseada em Papel ( Matriz RBAC )
A tabela abaixo fornece uma norma clara e intuitiva, a ser utilizada por desenvolvedores e auditores, mapeando claramente cada operação privilegiada para os papéis e tipos de controle necessários.
| Operação | Função Necessária | Tipo de Controle | |------|----------|----------| | Moeda (Mint) | MINTER_ROLE | Multassinado | | Destruir (Burn) | BURNER_ROLE | Multisig | | Pausar (Pause) | PAUSER_ROLE | Múltipla assinatura | | Restaurar (Retomar) | RETOMAR_FUNÇÃO | Multiassinatura | | Congelar (Freeze) | FUNÇÃO_FREEZER | Multisig | | Descongelar (Unfreeze) | FUNÇÃO_FREEZER | Multisig | | Adicionar à lista branca (Whitelist) | WHITELISTER_ROLE | Múltiplas assinaturas | | Remover da Lista Branca (Remove from Whitelist) | WHITELISTER_