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

Avec l'adoption officielle de la « réglementation sur les stablecoins », l'Autorité monétaire de Hong Kong a publié le 26 mai 2025 le « projet de directives de réglementation pour les émetteurs de stablecoins agréé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 agréés doivent respecter de manière continue.

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

Première partie Infrastructure de base 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 la Banque centrale 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é de base

directive de réglementation

Le titulaire de licence doit évaluer la robustesse de la technologie de registre distribué sous-jacente qu'il utilise (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 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 l'ensemble du processus d'évaluation doit être documenté en détail afin de fournir des justifications suffisantes lors des examens réglementaires. Le processus de sélection du grand livre 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 de Hong Kong sur la solidité du livre de comptes est en réalité un avertissement aux émetteurs pour é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 hautement sécurisées telles qu'Ethereum, Arbitrum, etc. Ces réseaux, grâce à leur résilience éprouvée, à leur vaste réseau de nœuds de validation et à la surveillance continue du public, possèdent un avantage naturel. Le coût élevé des attaques (sécurité économique) peut répondre directement aux préoccupations de régulation concernant la résistance aux attaques de 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 mener 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 dominantes.

• 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 associés aux défauts de code, aux vulnérabilités, aux exploitations et autres menaces, et analyser en détail comment ces risques peuvent avoir un impact potentiel sur l'émission, le rachat et les opérations quotidiennes du stablecoin. Ce document est un document clé pour prouver la prudence du choix technologique auprès des autorités de régulation.

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

directive réglementaire

Les documents réglementaires ne spécifient pas un standard de jeton particulier (comme l'ERC-20). Cependant, les documents exigent la mise en œuvre d'un ensemble 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 Banque centrale de Hong Kong a en fait défini une norme de jeton "renforcée par la réglementation" qui dépasse de loin la norme ERC-20. Cette norme 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. Pour 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ée et reconnue par la communauté (comme OpenZeppelin), puis à étendre les fonctionnalités sur cette base.

Guide de mise en œuvre

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

• Extensions de 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 suspension et de reprise globale de toutes les activités des jetons, c'est un outil essentiel pour faire face à des événements de sécurité majeurs.

  • Mintable : utilisé pour permettre aux émetteurs licenciés de frapper de nouveaux jetons par un processus contrôlé et de s'assurer que l'émission de jetons correspond strictement à des actifs de réserve de monnaie fiduciaire suffisants.

  • Brûlable : offre la fonctionnalité de destruction de jetons. Dans la mise en œuvre concrète, cette fonctionnalité sera soumise à un contrôle d'autorisation strict, et non pas autorisée à tout utilisateur de détruire à sa guise.

  • Gelable : utilisé pour suspendre la fonction de transfert de jetons d'un compte spécifique (comme dans le cas de transactions suspectes).

  • Whitelist : utilisé pour mettre en œuvre des mesures de sécurité supplémentaires, n'autorisant que les adresses approuvées et ayant passé la diligence raisonnable à participer aux opérations fondamentales (comme la réception de nouveaux jetons émis).

  • 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 ainsi 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 permissions granulaire et basé sur les rôles. Toutes les fonctions de gestion doivent passer par ce module pour le contrôle des permissions afin de répondre aux exigences de séparation des tâches.

3. Principaux modes de conformité : choix de la liste noire et de la liste blanche

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 diverses mesures, notamment "mettre sur liste noire les adresses de portefeuille identifiées comme sanctionnées ou liées à des activités illégales", ou adopter des mesures plus strictes telles que "la mise en place d'un système de liste blanche pour les adresses de portefeuille des détenteurs de stablecoins, ou l'adoption d'un mode fermé".

Interprétation technique

C'est le point de décision le plus crucial dans l'architecture du système, il détermine directement l'ouverture, l'utilité et la complexité de la conformité des stablecoins.

• 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 de liste blanche : un mode "par défaut désactivé" en boucle fermée. Toute adresse, à moins qu'elle ne soit clairement soumise à une diligence raisonnable et à une approbation par l'émetteur, et ajoutée à la liste blanche sur la chaîne, ne peut détenir ou recevoir des jetons.

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

Ainsi, le modèle de liste noire, également mentionné explicitement par les régulateurs, associé aux puissants outils d'analyse off-chain exigés par la réglementation, constitue une solution plus équilibrée. Elle répond à la fois aux exigences réglementaires et préserve l'utilité des actifs.

En termes de conception, le système peut être construit comme évolutif, ou mettre en œuvre simultanément les deux modes, afin de permettre une transition fluide ou un passage au mode de liste blanche en cas de renforcement 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 : offre une plus grande utilité, capable d'interopérer sans couture avec le vaste écosystème de finance décentralisée (DeFi), fournissant 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 robuste et en temps réel pour détecter et 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 l'adresse de l'expéditeur (from) et celle du destinataire (to) ne sont pas enregistrées sur la liste noire.

• Mode liste blanche

  • Avantages : offre le plus haut niveau de contrôle AML/CFT, réalisant une prévention avant plutôt qu'une remédiation après.

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

  • Méthode de réalisation : dans la fonction de transfert des smart contracts, ajouter une vérification logique, exigeant que l'adresse de l'expéditeur (from) et celle du destinataire (to) doivent toutes deux exister dans la liste blanche. Il est conseillé de développer un système de backend Web dédié pour faciliter les opérations.

Deuxième partie mise en œuvre des smart contracts

Cette section fournit un plan détaillé des fonctionnalités clés des smart contracts, transformant les exigences réglementaires complexes en logique de niveau code, en modes de sécurité et en protocoles d'opération.

1. Conception d'un système de contrôle d'accès raffiné

instructions 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, via 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 est non conforme.

Guide de mise en œuvre

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 des portefeuilles multi-signatures, afin de réaliser une séparation des responsabilités et de minimiser le risque de point 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 plusieurs signatures, et il doit être garanti qu'aucun employé unique ne détient simultanément plusieurs rôles à haut risque. Toutes les opérations doivent être enregistrées dans un journal et soumises à un audit externe annuel, la répartition des autorisations étant supervisée par un administrateur ou un conseil d'administration.

• MINTER_ROLE : responsable du traitement de l'émission de stablecoin ( mint ), y compris la création d'unités de jeton après réception d'une demande d'émission valide, et en s'assurant que l'émission 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 pause des opérations de (pause) stablecoin, 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éactivation de l'opération du stablecoin (resume), 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 opérations sur des portefeuilles ou jetons spécifiques, par exemple geler temporairement des actifs lors de la détection d'activités suspectes (comme un risque de blanchiment d'argent).

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

• BLACKLISTER_ROLE : responsable de la gestion de la blacklist ( blacklist ) et de la suppression de la blacklist ( remove blacklist ), par exemple en ajoutant des portefeuilles suspects à la blacklist 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.

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

Le tableau ci-dessous fournit une spécification claire et intuitive, à l'usage des développeurs et des auditeurs, qui mappe clairement chaque opération privilégiée à son rôle et type 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écupérer | RESUME_ROLE | Multisignature | | gelé | FREEZER_ROLE | multi-signature | | Débloquer | RÔLE_DE_GLACIÈRE | Multisignature | | Ajouter à la liste blanche | WHITELISTER_ROLE | Multi-signature | | Retirer de la liste blanche | WHITELISTER_ROLE | Multisignature | | Ajouter à la liste noire |