Guide de mise en œuvre des smart contracts pour les émetteurs de stablecoin à Hong Kong

Avec l'adoption officielle du "Règlement sur les stablecoins", la Hong Kong Monetary Authority a publié le 26 mai 2025 le "Projet de directives de régulation pour les émetteurs de stablecoins licenciés", visant à garantir la stabilité, la sécurité et la conformité de l'écosystème local des stablecoins. Ces directives énoncent en détail les exigences réglementaires et les normes opérationnelles que les émetteurs de stablecoins licenciés doivent respecter en permanence.

Récemment, de plus en plus d'institutions ont consulté l'équipe de sécurité sur les questions de mise en œuvre conforme des smart contracts. Pour aider les émetteurs à mieux comprendre et déployer un système de smart contracts conforme, nous avons spécialement publié le "Guide de mise en œuvre des smart contracts pour les émetteurs de stablecoin à Hong Kong", afin de fournir des voies techniques claires et des recommandations pratiques, soutenant le développement sain de l'écosystème des stablecoins à Hong Kong.

Première partie Infrastructure et stratégie de conformité

Cette section vise à établir les bases de l'architecture de haut niveau pour le système de stablecoin, ces décisions d'architecture étant entièrement guidées par les exigences fondamentales du cadre de l'Autorité monétaire de Hong Kong. Les choix faits ici détermineront l'ensemble du chemin de mise en œuvre, garantissant que la conformité est profondément intégrée dans la pile technologique dès le début de la conception.

1. Choix du registre distribué sous-jacent

Directive de réglementation

Les titulaires de licence doivent évaluer la robustesse de la technologie de registre distribué sous-jacente qu'ils utilisent (DLT). Cette évaluation couvre l'infrastructure de sécurité, la résistance aux attaques courantes (telles que l'attaque à 51 %), la garantie de la finalité des transactions et la fiabilité des algorithmes de consensus.

Interprétation technique

Ce n'est pas un simple choix de préférence technique, mais une tâche de conformité essentielle. Le choix de la blockchain sous-jacente doit faire l'objet d'une due diligence formelle, et tout le processus d'évaluation doit être soigneusement documenté afin de fournir des justifications adéquates lors des examens réglementaires. Le processus de sélection du livre de comptes sous-jacent établit en réalité le ton pour la sécurité et la stabilité de l'ensemble du système de stablecoin.

L'accent mis par la Banque centrale de Hong Kong sur la robustesse du livre de comptes est en réalité un avertissement pour les émetteurs afin d'éviter d'adopter des blockchains émergentes qui n'ont pas été vérifiées par le marché, qui sont trop centralisées ou dont la sécurité est douteuse. La responsabilité de prouver leur sécurité et leur stabilité incombe entièrement à l'émetteur. Si l'émetteur choisit une chaîne dont la sécurité n'a pas été largement vérifiée, il doit concevoir et mettre en œuvre des mesures de contrôle compensatoires supplémentaires.

Guide de mise en œuvre

• Choisir en priorité des blockchains publiques matures : il est conseillé de privilégier des blockchains publiques matures et sécurisées comme Ethereum ou Arbitrum. Ces réseaux bénéficient d'avantages naturels grâce à leur résilience éprouvée, à leur vaste réseau de nœuds de validation et à la surveillance continue du public. Leur coût élevé d'attaque (sécurité économique) peut directement répondre aux préoccupations réglementaires concernant la résistance aux attaques à 51 % et la garantie de la finalité des transactions.

• Évaluation rigoureuse des alternatives : si l'on envisage d'adopter une chaîne de consortium ou d'autres types de registres distribués, il est nécessaire de réaliser une analyse comparative rigoureuse et quantifiable, comme un audit de sécurité, pour prouver que ses normes de sécurité ne sont pas inférieures, voire supérieures à celles des chaînes publiques mainstream.

• Document d'évaluation des risques : le rapport d'évaluation doit couvrir de manière exhaustive la capacité à résister aux attaques courantes, le type d'algorithme de consensus, ainsi que les risques liés aux défauts de code, aux vulnérabilités, aux exploits et à d'autres menaces, et analyser en détail comment ces risques peuvent avoir un impact potentiel sur l'émission, le rachat et l'exploitation quotidienne des stablecoins. Ce document est un document clé pour prouver la prudence des choix technologiques auprès des autorités réglementaires.

2. Normes de jetons de base et extension des fonctions de régulation

Directive de régulation

Les documents de réglementation ne spécifient aucun standard de jeton particulier (comme ERC-20). Cependant, les documents imposent la mise en œuvre d'un certain nombre de fonctionnalités de gestion essentielles, y compris l'émission (mint), la destruction (burn), la mise à niveau (upgrade), la suspension (pause), la reprise (resume), le gel (freeze), la liste noire (blacklist), la liste blanche (whitelist), etc.

Interprétation technique

La Hong Kong Monetary Authority a en fait défini un standard de jeton "renforcé par la régulation" qui dépasse largement le standard ERC-20. Ce standard exige non seulement des fonctions de circulation de jetons de base, mais met également l'accent sur la sécurité opérationnelle, le contrôle des autorisations et la traçabilité des risques. Afin de garantir la sécurité tout en respectant les exigences de conformité, le chemin de développement le plus efficace et le plus sûr consiste à utiliser une bibliothèque standard largement audité et reconnue par la communauté (comme OpenZeppelin) pour y ajouter des extensions fonctionnelles.

Guide d'exécution

• Standard de base : utilisation de l'ERC-20 comme standard de base pour garantir l'homogénéité des jetons et leur interopérabilité dans un écosystème plus large.

• Extension des fonctionnalités : Les modules fonctionnels suivants doivent être intégrés pour répondre aux exigences réglementaires :

  • Pausable : utilisé pour mettre en œuvre une fonction de pause et de reprise globale pour toutes les activités de jeton, c'est un outil clé pour faire face à des événements de sécurité majeurs.

  • Émission : permet aux émetteurs agréés de frapper de nouveaux jetons via un processus contrôlé et d'assurer que l'émission de jetons correspond strictement à un actif de réserve en monnaie fiduciaire suffisant.

  • Brûlable : fournit la fonction de destruction de jetons. Dans la mise en œuvre spécifique, cette fonction sera strictement contrôlée par des autorisations, et non pas laissée à la libre destruction par n'importe quel utilisateur.

  • Freezable : utilisé pour suspendre la fonction de transfert de jetons de comptes spécifiques (par exemple, en cas de transactions suspectes).

  • Liste blanche : utilisée pour mettre en œuvre des mesures de sécurité supplémentaires, n'autorisant la participation aux opérations principales (comme la réception de nouveaux jetons émis) que par des adresses approuvées après une diligence raisonnable.

  • Liste noire : utilisée pour interdire les transactions des adresses impliquées dans des activités illégales (comme le blanchiment d'argent, la fraude), interdisant l'envoi/réception de jetons. La gestion de la liste noire doit être liée au système AML/CFT, surveillant en temps réel les transactions suspectes.

  • AccessControl : c'est la base d'un système de gestion des droits basé sur des rôles et finement granulaire. Toutes les fonctions de gestion doivent passer par ce module pour le contrôle des droits, afin de répondre aux exigences de séparation des fonctions.

3. Modèles de conformité principaux : choix des listes noires et blanches

Directive de régulation

Concernant la surveillance continue, le document de consultation sur la lutte contre le blanchiment d'argent / le financement du terrorisme ( AML/CFT ) propose plusieurs mesures, notamment "mettre sur liste noire les adresses de portefeuille identifiées comme étant soumises à des sanctions ou liées à des activités illégales", ou adopter une approche plus stricte "en mettant en place un système de liste blanche pour les adresses de portefeuille des détenteurs de stablecoin, ou en utilisant un mode en boucle fermée".

Interprétation technique

C'est le point de décision le plus crucial dans l'architecture du système, qui détermine directement l'ouverture, l'utilité et la complexité des opérations conformes du stablecoin.

• Mode liste noire : un mode "par défaut ouvert". Toutes les adresses peuvent échanger librement par défaut, seules celles qui sont explicitement identifiées et ajoutées à la liste noire sur la chaîne seront restreintes.

• Mode liste blanche : un mode "par défaut désactivé" en boucle fermée. Toute adresse ne peut détenir ou recevoir des jetons que si elle a été explicitement soumise à une due diligence et approuvée par l'émetteur, et ajoutée à la liste blanche sur la chaîne.

Bien que le mode de liste blanche offre des capacités de contrôle AML (lutte contre le blanchiment d'argent), un système de liste blanche stricte pour un stablecoin destiné à être largement utilisé signifie que le stablecoin ne peut circuler qu'entre des participants préalablement examinés, ce qui le rend plus semblable à un système de livre de banque fermé qu'à une monnaie numérique flexible.

Ainsi, le mode de liste noire, également mentionné explicitement par les régulateurs, combiné aux puissants outils d'analyse hors chaîne exigés par la réglementation, constitue une solution plus équilibrée. Elle répond à la fois aux exigences réglementaires et préserve la praticité des actifs.

Dans sa conception, le système peut être construit de manière évolutive, ou mettre en œuvre simultanément deux modes, afin de pouvoir passer en douceur ou basculer vers un mode de liste blanche en cas de resserrement de la réglementation ou de changement de modèle commercial à l'avenir.

Guide de mise en œuvre

• Mode liste noire (solution recommandée par défaut) :

  • Avantages : possède une plus grande utilité, capable d'interopérer sans couture avec le vaste écosystème de la finance décentralisée (DeFi), offrant aux utilisateurs un seuil d'utilisation plus bas et une expérience plus fluide.

  • Inconvénients : la conformité dépend fortement d'une capacité d'analyse de surveillance hors chaîne puissante et en temps réel, afin de détecter et de bloquer rapidement les adresses illégales.

  • Méthode de mise en œuvre : dans la fonction de transfert des smart contracts, ajouter une vérification logique pour s'assurer que les adresses de l'expéditeur (from) et du destinataire (to) ne sont pas enregistrées sur la liste noire.

• Mode liste blanche

  • Avantages : fournit le plus haut niveau de contrôle AML/CFT, réalisant une prévention en amont plutôt qu'une remédiation en aval.

  • Inconvénients : cela limite considérablement la universalité et le taux d'adoption des stablecoins, engendrant de grandes dépenses opérationnelles pour la gestion des listes blanches, ce qui pourrait rendre difficile leur acceptation en tant que moyen d'échange largement utilisé.

  • Mode de réalisation : dans la fonction de transfert des smart contracts, ajouter une vérification logique, exigeant que les adresses de l'expéditeur (from) et du destinataire (to) soient toutes deux présentes sur la liste blanche. Il est conseillé de développer un système de back-office Web dédié pour faciliter les opérations.

Deuxième partie Mise en œuvre des smart contracts

Cette section fournit une feuille de route détaillée pour les fonctionnalités clés des smart contracts, transformant des exigences réglementaires complexes en logique de code concrète, en modes de sécurité et en protocoles d'opération.

1. Système de contrôle d'accès conçu de manière détaillée

Directive de régulation

La conception des opérations à haut risque doit "prévenir qu'une seule partie puisse exécuter unilatéralement les opérations concernées (par exemple, par le biais d'un protocole de signatures multiples)". Les responsabilités des différentes opérations doivent être suffisamment isolées.

Interprétation technique

Cela signifie qu'un système de contrôle d'accès basé sur les rôles puissant et (RBAC) est obligatoire. Toute forme de clé privée "propriétaire" ou "administrateur" unique n'est pas conforme.

Guide d'exécution

Il est nécessaire de définir une série de rôles clairs et d'attribuer ces rôles à différentes entités ou employés contrôlés par un portefeuille multi-signatures, afin de réaliser une séparation des fonctions et de minimiser le risque de points de défaillance unique ou de manipulation collusoire. Chaque rôle doit être limité à des fonctions spécifiques, toutes les opérations doivent être autorisées par multi-signatures, et il est essentiel qu'aucun employé unique ne détienne simultanément plusieurs rôles à haut risque. Toutes les opérations doivent être consignées dans un journal et soumises à un audit tiers annuel, la répartition des autorisations étant supervisée par l'administrateur ou le conseil d'administration.

• MINTER_ROLE : Responsable du traitement des opérations de minting de stablecoin (mint), y compris la création d'unités de jeton après réception d'une demande d'émission valide, et s'assurant que le minting correspond à l'augmentation correspondante du pool d'actifs de réserve.

• BURNER_ROLE : responsable du traitement de la destruction des stablecoins (burn), y compris la destruction des unités de jetons après réception d'une demande de rachat valide.

• PAUSER_ROLE : Responsable de la suspension de l'opération de la stablecoin (pause), par exemple, en cas d'événements anormaux (comme une menace de sécurité) pour arrêter temporairement les transferts, l'émission ou le rachat.

• RESUME_ROLE : responsable de la récupération de l'opération (resume) stablecoin, par exemple, réactiver les transferts, l'émission ou le rachat après la résolution d'un événement de suspension.

• FREEZER_ROLE : Responsable de geler (freeze) et de dégel (remove freeze) des portefeuilles ou jetons spécifiques, par exemple en gelant temporairement les actifs lors de la détection d'activités suspectes (comme le risque de blanchiment d'argent).

• WHITELISTER_ROLE : responsable de la gestion de la whitelist (whitelist), y compris l'ajout ou la suppression d'adresses de portefeuille autorisées, par exemple, limiter l'émission de jetons uniquement aux adresses de la whitelist.

• BLACKLISTER_ROLE : responsable de la gestion de la liste noire ( blacklist ) et de la suppression de la liste noire ( remove blacklist ), par exemple, mettre des portefeuilles suspects sur liste noire pour empêcher les transferts.

• UPGRADER_ROLE : Si un modèle évolutif est adopté, responsable de l'émission (upgrade) des smart contracts, par exemple mettre à jour le code du contrat pour corriger des vulnérabilités ou ajouter des fonctionnalités.

Matrice de contrôle d'accès basé sur les rôles ( RBAC Matrix )

Le tableau ci-dessous fournit une spécification claire et intuitive à l'usage des développeurs et des auditeurs, en établissant clairement une correspondance entre chaque opération de privilège et les rôles et types de contrôle requis.

| Opération | Rôle requis | Type de contrôle | |------|----------|----------| | jeton | MINTER_ROLE | multi-signature | | destruction | BURNER_ROLE | multi-signature | | Suspendre | PAUSER_ROLE | Multisignature | | Rétablir | RESUME_ROLE | Multi-signature | | gelé | FREEZER_ROLE | multi-signature | | Déverrouiller | FREEZER_ROLE | Multisignature | | Ajouter à la liste blanche | WHITELISTER_ROLE | Multisignature | | Retirer de la liste blanche | WHITELISTER_ROLE | Multiple