Guia de implementação de contratos inteligentes para emissores de moeda estável de Hong Kong

Primeira Parte Infraestrutura e Estratégia de Conformidade

1. Escolha do livro-razão distribuído subjacente

Recomenda-se a preferência por blockchains públicas maduras e com alta segurança, como Ethereum e Arbitrum. Essas redes possuem vantagens naturais devido à sua resiliência testada ao longo do tempo, à vasta rede de nós validadores e à supervisão pública contínua. O elevado custo de ataque 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.

Se considerar a adoção de uma cadeia de consórcio ou outro tipo de livro-razão distribuído, é necessário realizar uma análise comparativa rigorosa e quantificável, a fim de provar que seus padrões de segurança não são inferiores, ou até superiores, aos das principais cadeias públicas.

O relatório de avaliação de risco deve cobrir de forma abrangente a capacidade de resistir a ataques comuns, o tipo de algoritmo de consenso, bem como os riscos relacionados a defeitos de código, vulnerabilidades, explorações e outras ameaças, e analisar detalhadamente como esses riscos podem impactar potencialmente a emissão, resgate e operação diária da moeda estável. Este documento é um arquivo chave para demonstrar a prudência na escolha técnica às autoridades reguladoras.

2. Padrões de moeda principais e expansão das funções regulatórias

Sugere-se a adoção do ERC-20 como padrão básico, para garantir a homogeneização dos tokens e a interoperabilidade em um ecossistema mais amplo.

É necessário integrar os seguintes módulos funcionais para atender aos requisitos regulatórios:

• Pausável: utilizado para implementar a função de pausa e recuperação global de todas as atividades da moeda, que é uma 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 estritamente aos ativos de reserva em moeda fiduciária.
• Burnable: fornece a funcionalidade de queimar moedas. Na implementação específica, essa funcionalidade será controlada por permissões rigorosas, e não permitirá que qualquer usuário a queime por conta própria.
• Congelável: usado para pausar a funcionalidade de transferência de moeda de contas específicas ( em caso de transações suspeitas ).
• Whitelist: utilizado para implementar medidas de segurança adicionais, permitindo apenas que endereços aprovados e que passaram pela devida diligência participem das operações principais (, como a recepção de novas moedas emitidas ).
• Lista Negra: utilizada para implementar a proibição de transações para endereços envolvidos em atividades ilegais ( como lavagem de dinheiro, fraude ), proibindo o envio/recolha de moedas. A gestão da lista negra deve estar interligada com o sistema AML/CFT, monitorizando em tempo real transações suspeitas.
• AccessControl: esta é a base para a implementação de um sistema de gestão de permissões baseado em funções e de forma detalhada. Todas as funcionalidades de gestão devem passar por este módulo para o controle de permissões, a fim de atender aos requisitos de separação de funções.

3. Principais modos de conformidade: escolha de listas negras e listas brancas

Sugere-se adotar o modo de lista negra como a solução padrão recomendada:

• Vantagens: possui maior utilidade, permitindo a interoperabilidade sem costura com o vasto ecossistema de finanças descentralizadas (DeFi), oferecendo aos usuários um acesso mais baixo 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 de forma oportuna.
• Modo de implementação: na função de transferência dos contratos inteligentes, adicione uma verificação lógica para garantir que os endereços do remetente (from) e do destinatário (to) não estejam registrados na lista negra.

Segunda Parte Contratos Inteligentes Implementação

1. Sistema de controlo de acesso refinado

Deve-se definir uma série de papéis claros e atribuí-los a diferentes entidades ou funcionários controlados por carteiras de múltiplas assinaturas, a fim de garantir a separação de funções e minimizar o risco de pontos únicos de falha ou manipulação colusiva. Cada papel deve ser restrito a funções específicas, todas as operações devem ter autorização de múltiplas assinaturas e assegurar que nenhum funcionário único detenha 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.

Definição de papel:

• MINTER_ROLE: responsável por lidar com a emissão da moeda estável (mint) operação
• BURNER_ROLE: responsável por lidar com a destruição da moeda estável (burn) operação
• PAUSER_ROLE: responsável por pausar (pause) a operação da moeda estável
• RESUME_ROLE: responsável pela recuperação (resume) da operação da moeda estável
• FREEZER_ROLE: responsável por congelar ( freeze ) e descongelar ( remove freeze ) operações de carteiras ou moedas específicas
• WHITELISTER_ROLE: responsável pela gestão da whitelist (whitelist)
• BLACKLISTER_ROLE: responsável pela gestão da blacklist ( blacklist ) e remoção da blacklist ( remove blacklist )
• UPGRADER_ROLE: Se um modelo atualizável for adotado, responsável pela atualização (upgrade) contratos inteligentes

2. emissão(moeda) mecanismo

Verificação prévia: a função deve verificar se o endereço de destino to está na lista negra ou congelado antes de executar a emissão.

Processo de operação:

1. Due diligence off-chain: o cliente completa todos os processos necessários de identificação de cliente off-chain ( KYC ) e due diligence do cliente ( CDD ).
2. Recepção de fundos: O cliente transfere o valor equivalente em moeda fiduciária para a conta bancária designada pelo emissor.
3. Validação interna: o sistema interno do emissor confirma a receção de fundos e atualiza os registos contábeis dos ativos de reserva.
4. Execução na cadeia: a equipe de operações cria e assina uma transação multi-assinatura, chamando a função de emissão de tokens dos contratos inteligentes, enviando a nova moeda estável cunhada para o endereço da carteira previamente registrado e verificado do cliente.

3. resgate ( mecanismo de destruição )

Preparação para resgate: O usuário deve primeiro transferir os tokens que deseja resgatar para o endereço designado controlado pelo emissor.

Processo de operação:

1. Pedido off-chain: O usuário submete um pedido de resgate off-chain através da plataforma do emissor. Antes de processar o pedido, o emissor deve realizar a devida diligência do cliente.
2. Validação do sistema: o sistema do emissor verifica a validade do pedido de validação e verifica se o usuário completou a operação de transferência de moeda correspondente na blockchain.
3. Pagamento em moeda fiat: o emissor transferirá o valor equivalente em moeda fiat para a conta bancária que o usuário registrou e verificou previamente.
4. Destruição na cadeia: Após confirmar o sucesso da transferência de moeda fiduciária, a carteira de múltipla assinatura que possui o BURNER_ROLE chama a função de destruição, destruindo a quantidade correspondente de moedas do endereço especificado.

( 4. Implementação de controle de emergência: suspensão e congelamento

Função de pausa: chamada apenas por carteiras multifirma que possuem o PAUSER_ROLE, destinada a interromper globalmente a funcionalidade do contrato. As condições de ativação incluem a detecção de eventos anômalos ), como ataques de rede ou incompatibilidade de ativos de reserva ###, necessitando de aprovação do conselho ou da alta administração. A função de recuperação é tratada por um RESUME_ROLE independente, para garantir a separação de responsabilidades.

Função de congelamento: chamada por uma carteira multi-assinatura com o papel FREEZER_ROLE, usada para restringir transferências para endereços específicos. As condições de ativação incluem atividades suspeitas (, como alertas de AML ou ordens judiciais ), que devem ser verificadas fora da cadeia antes da execução. O descongelamento é tratado pelo mesmo papel, mas requer auditoria adicional e verificação, publicando anúncios relevantes para prevenir abusos.

( 5. Filtro de endereços e mecanismo de lista negra

• Implementação da função: implementar uma função para adicionar e remover da lista negra, que só pode ser chamada por uma carteira multi-assinatura que possua o BLACKLISTER_ROLE.
• Limite de transferência: endereços na lista negra estão proibidos de transferir/receptar moedas.
• Processo operacional: a ferramenta de análise emite um alerta, desencadeia uma revisão de conformidade interna, após a confirmação da equipe de conformidade, a transação de adição à lista negra é iniciada pela carteira multi-assinatura do BLACKLISTER_ROLE.

) 6. A escalabilidade dos contratos inteligentes

• Modelo de proxy: Para contratos inteligentes do tipo EVM, pode-se utilizar o modelo de proxy ERC-1967 maduro para alcançar a capacidade de atualização.
• Controle de permissões: a função de atualização deve ser chamada apenas por uma carteira multi-assinatura que possua o UPGRADER_ROLE.
• Processo de gestão de mudanças: De acordo com os requisitos regulamentares, antes de propor qualquer atualização, deve ser concluído um rigoroso processo de gestão de mudanças, que inclui uma auditoria de segurança abrangente e independente de terceiros dos novos contratos inteligentes.

7. Registros de eventos on-chain para análise e relatório

Além dos requisitos de transferência ###Transfer### e autorização (Approval) do padrão ERC-20, o contrato deve definir e emitir eventos personalizados para todas as ações de gerenciamento e mudanças de estado:

• Emissão/Queima ( Minted/Burned ) evento
• Pausar/Retomar ( Pausado/Retomar ) evento
• Adicionar/Remover da lista negra ( BlacklistAdded/BlacklistRemoved ) evento
• Adição/remoção da lista branca (WhitelistAdded/WhitelistRemoved) evento
• Congelamento/Descongelamento de Endereço ( AddressFrozen/AddressUnfrozen ) evento
• Mudança de papel privilegiado ( RoleGranted/RoleRevoked ) evento
• Atualização de contrato ( Upgraded ) evento

Terceira Parte Segurança Operacional e Gestão do Ciclo de Vida

( 1. Estrutura de gestão de chaves de segurança

• Geração de chaves: deve ser realizada através de uma "cerimônia de chaves" documentada em detalhes )key ceremony###, em um ambiente fisicamente seguro, completamente isolado da rede externa.
• Armazenamento de chaves: todos os papéis de gestão devem ser controlados por carteiras multisig. As chaves privadas usadas pelos signatários dessas carteiras multisig devem ser armazenadas em HSM ou em outras carteiras de hardware seguras. Para os papéis mais críticos, as chaves correspondentes devem ser mantidas em sistemas isolados, fisicamente separados de qualquer ambiente online.
• Uso de chaves: deve ser aplicada uma estratégia de múltiplas assinaturas. Para a assinatura de transações que envolvem "chaves privadas importantes", pode ser necessário que as pessoas relevantes estejam presentes pessoalmente.
• Backup e recuperação: o backup de fragmentos de chave ou palavras-chave deve ser armazenado em vários locais seguros e geograficamente dispersos dentro de Hong Kong ( ou em locais aprovados pela regulamentação ), e deve ser protegido por embalagens à prova de adulteração.

( 2. Processo de implantação completo e monitoramento em tempo de execução

Antes da implementação oficial, deve-se elaborar e executar rigorosamente uma "lista de verificação pré-implementação":

• Testes abrangentes: garantir uma cobertura de testes unitários superior a 95%, cobertura de código central de 100%, garantir a saída de relatórios de cobertura de testes unitários.
• Auditoria independente: completar pelo menos um, preferencialmente dois relatórios de auditoria de segurança independentes emitidos por empresas de auditoria de boa reputação.
• Congelamento de código: Após a conclusão da auditoria, o código será congelado até o lançamento, sem quaisquer alterações no código.
• Teste de regressão: antes da implementação oficial, realize testes de unidade e efetue o teste de regressão.
• Assinatura de conformidade: obter a assinatura oficial da equipe interna de conformidade, confirmando que a lógica do contrato atende a todos os requisitos regulatórios relevantes.
• Exercício de implementação: preparar um script de implementação detalhado e realizar um exercício de implementação completo em uma rede de testes que seja totalmente consistente com o ambiente da mainnet.
• Implementação autorizada: A operação final de implementação é executada pela carteira autorizada.

Após a conclusão da implementação, devem ser tomadas medidas de monitoramento adequadas para implementar medidas de mitigação em tempo hábil em relação ao uso de funções privilegiadas e a novas ameaças que surgirem:

• Monitoramento de atividades na cadeia: monitorar o uso de funções de gerenciamento e detectar rapidamente a ocorrência de situações não autorizadas.
• Monitorização de Inteligência de Ameaças: deve-se identificar rapidamente novas ameaças e analisar a inteligência de ameaças, para que se possam implementar medidas de mitigação de forma oportuna.

) 3. Fornecer suporte técnico para continuidade de negócios e plano de saída

Elaborar um plano de saída de negócios: o plano abrange várias situações que podem levar a uma terminação ordenada e inclui medidas de monitoramento para a ocorrência real ou potencial dessas situações.

Processo de saída em cadeia:

• Deve-se suspender os contratos inteligentes para parar todas as transferências de moedas, a fim de maximizar os rendimentos da conversão de ativos de reserva e minimizar o impacto na estabilidade geral do mercado.
• Com base na funcionalidade de resgate e na funcionalidade de lista branca, auxilia os detentores de moeda estável a submeter pedidos de resgate.