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 "Guide de réglementation des émetteurs de stablecoins agréés (brouillon)", visant à garantir la stabilité, la sécurité et la conformité de l'écosystème local des stablecoins. Ce guide énumère en détail les exigences réglementaires et les normes opérationnelles que les émetteurs de stablecoins agréés doivent respecter en permanence.
Récemment, de plus en plus d'institutions ont consulté les équipes de sécurité sur les questions de mise en œuvre conforme des contrats intelligents. Afin d'aider les émetteurs à mieux comprendre et déployer un système de contrats intelligents conforme, nous avons spécialement publié le "Guide de mise en œuvre des contrats intelligents pour les émetteurs de stablecoins à Hong Kong", afin de fournir des chemins techniques clairs et des conseils 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 fondations de l'architecture de haut niveau pour le système de stablecoins, ces décisions architecturales étant entièrement guidées par les exigences fondamentales du cadre de la Hong Kong Monetary Authority. Les choix faits ici détermineront l'ensemble du parcours de mise en œuvre, garantissant que la conformité est profondément intégrée dans la pile technologique dès le départ.
1. Choix du registre distribué de base
Directive de régulation
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é fondamentale. Le choix de la blockchain sous-jacente doit être soumis à une diligence raisonnable 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 stablecoins.
L'accent mis par la Banque centrale de Hong Kong sur la solidité des livres de comptes est en réalité un avertissement aux émetteurs pour éviter d'adopter des blockchains émergentes qui n'ont pas été validé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
Privilégier les blockchains publiques matures : il est conseillé de privilégier des blockchains publiques matures et hautement sécurisées comme Ethereum, Arbitrum, etc. Ces réseaux, grâce à leur résilience éprouvée, leur vaste réseau de nœuds de validation et leur surveillance publique continue, présentent des avantages naturels. Leur coût d'attaque élevé (sécurité économique) peut répondre directement aux préoccupations réglementaires 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 un autre type de grand livre distribué, une analyse comparative rigoureuse et quantifiable doit être menée, 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, à l'exploitation des vulnérabilités et à d'autres menaces, et analyser en détail comment ces risques peuvent avoir un impact potentiel sur l'émission, le rachat et le fonctionnement quotidien des stablecoins. Ce document est un document clé pour prouver la prudence du choix technologique aux régulateurs.
2. Normes de jetons clés et extensions des fonctions de régulation
Directive de réglementation
Les documents de réglementation ne spécifient pas un standard de jeton particulier (comme ERC-20). Cependant, les documents exigent la mise en œuvre d'une série de fonctions de gestion essentielles, y compris la frappe (mint), la destruction (burn), la mise à niveau (upgrade), la pause (pause), la reprise (resume), le gel (freeze), la liste noire (blacklist), la liste blanche (whitelist), etc.
Interprétation technique
La Banque populaire de Hong Kong a en fait défini un standard de jetons "renforcé par la réglementation" dont les fonctionnalités dépassent largement celles du 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é au maximum tout en répondant aux 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 : Utiliser 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 jetons, c'est un outil central pour faire face à des événements de sécurité majeurs.
Mintable : utilisé pour permettre aux émetteurs agréés de frapper de nouveaux tokens via un processus contrôlé et de s'assurer que l'émission de tokens correspond strictement à un actif de réserve en monnaie fiduciaire.
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 autorisée à tout utilisateur de détruire à sa guise.
Gelable : utilisé pour suspendre la fonction de transfert de tokens d'un compte spécifique (par exemple, en cas de transactions suspectes).
Liste blanche : utilisée pour mettre en œuvre des mesures de sécurité supplémentaires, permettant uniquement aux adresses approuvées par une diligence raisonnable de participer aux opérations clés (comme la réception de nouveaux jetons émis).
Liste noire : utilisée pour imposer une interdiction de transaction sur les adresses impliquées dans des activités illégales (telles que 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 d'accès granulaire et basé sur les rôles. 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 responsabilités.
3. Principaux modes de conformité : choix de la liste noire et de la liste blanche
Directive de régulation
Le document de consultation sur la surveillance continue, la lutte contre le blanchiment d'argent / le financement du terrorisme ( AML/CFT ) propose plusieurs mesures, y compris "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 "mettre en place un système de liste blanche pour les adresses de portefeuille des détenteurs de stablecoins, ou adopter un modèle 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 de conformité de la monnaie stable.
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, à moins qu'elle ne fasse l'objet d'une enquête de diligence raisonnable et d'une approbation explicite de l'émetteur, et qu'elle soit ajoutée à la liste blanche sur la chaîne, ne peut détenir ou recevoir des jetons.
Bien que le mode de liste blanche offre des capacités de contrôle AML (anti-blanchiment d'argent), un système de liste blanche strict pour une stablecoin destinée à être largement utilisée signifie que la stablecoin ne peut circuler qu'entre des participants préalablement vérifiés, ce qui la rend plus semblable à un système de livre bancaire fermé qu'à une monnaie numérique flexible.
Ainsi, le modèle de liste noire également mentionné explicitement par les régulateurs, combiné avec les 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 conserve l'utilité des actifs.
Dans sa conception, le système peut être construit pour être évolutif, ou pour fonctionner simultanément en 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.
Guide de mise en œuvre
Mode liste noire (solution recommandée par défaut) :
Avantages : offre une plus grande praticité, permettant une interopérabilité transparente avec le vaste écosystème financier décentralisé (DeFi), offrant aux utilisateurs une barrière d'entrée plus basse et une expérience plus fluide.
Inconvénients : La conformité dépend fortement de la 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 du contrat intelligent, 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 : 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 : limite considérablement l'universalité et le taux d'adoption des stablecoins, entraîne d'énormes coûts opérationnels pour la gestion des listes blanches, ce qui peut rendre difficile leur acceptation en tant que moyen d'échange largement reconnu.
Mode de réalisation : dans la fonction de transfert du contrat intelligent, ajouter une vérification logique, exigeant que les adresses de l'expéditeur (from) et du destinataire (to) soient toutes deux présentes dans la liste blanche. Il est conseillé de développer un système d'arrière-plan Web utilisateur dédié pour effectuer les opérations, afin d'augmenter la commodité des opérations.
Deuxième partie Mise en œuvre des contrats intelligents
Cette section fournit une feuille de route détaillée pour les fonctionnalités centrales des contrats intelligents, transformant des exigences réglementaires complexes en logique de code concrète, en modèles de sécurité et en protocoles opérationnels.
1. Concevoir un système de contrôle d'accès raffiné
Directive de réglementation
La conception des opérations à haut risque doit "prévenir qu'une seule partie puisse exécuter unilatéralement des opérations connexes (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 unique "propriétaire" ou "administrateur" 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érents entités ou employés contrôlés par des portefeuilles multi-signatures, afin de réaliser une séparation des fonctions et de minimiser les risques de points de défaillance uniques ou de manipulation collusoire. Chaque rôle doit être limité à des fonctions spécifiques, toutes les opérations nécessitant une autorisation multi-signature, et il faut s'assurer qu'aucun employé ne détient simultanément plusieurs rôles à haut risque. Toutes les opérations doivent être enregistrées dans des journaux et soumises à un audit tiers annuel, la répartition des droits étant supervisée par un administrateur ou un conseil d'administration.
MINTER_ROLE : Responsable du traitement des opérations de minting de stablecoins (mint), y compris la création d'unités de tokens après réception d'une demande d'émission valide, et garantir 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 tokens après réception d'une demande de rachat valide.
PAUSER_ROLE : Responsable de la suspension de l'opération de la monnaie stable (pause), par exemple, en arrêtant temporairement les transferts, la frappe ou le rachat en cas d'événements anormaux (tels que des menaces de sécurité).
RESUME_ROLE : Responsable de la restauration des opérations de (resume) stablecoin, par exemple, de réactiver les transferts, le minting ou le rachat après la résolution d'un événement de suspension.
FREEZER_ROLE : Responsable de geler (freeze) et de lever le gel (remove freeze) des opérations sur des portefeuilles ou des jetons spécifiques, par exemple en gelant temporairement les 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 d'adresses de portefeuille autorisées, par exemple, en limitant le minting uniquement aux adresses de la liste blanche.
BLACKLISTER_ROLE : Responsable de la gestion de la liste noire (blacklist) et de la suppression de la liste noire (remove blacklist), par exemple en mettant des portefeuilles suspects sur liste noire pour empêcher les transferts.
UPGRADER_ROLE : Si un modèle évolutif est adopté, responsable de la mise à niveau du contrat intelligent (upgrade), 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ée sur les rôles ( Matrice RBAC )
Le tableau ci-dessous fournit une norme claire et intuitive à l'usage des développeurs et des auditeurs, cartographiant explicitement chaque opération privilégiée à son rôle et type de contrôle requis.
| Action | Rôle requis | Type de contrôle |
|------|----------|----------|
| Monnaie (Mint) | RÔLE_DE_MINTEUR | Multi-signature |
| Détruire (Burn) | RÔLE_DE_DÉTRUCTION | Multisignature |
| Pause (Pause) | RÔLE_PAUSER | Multisignature |
| Récupérer (Reprendre) | REPRENDRE_ROLE | Multisignature |
| Gel (Freeze) | RÔLE_DE_GEL | Multi-signature |
| Débloquer (Débloquer) | RÔLE_DE_DÉBLOQUAGE | Multisignature |
| Ajouter à la liste blanche (Whitelist) | WHITELISTER_ROLE | Multisignature |
| Retirer de la liste blanche (Retirer de la liste blanche) | WHITELISTER_
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
8 J'aime
Récompense
8
6
Partager
Commentaire
0/400
BearWhisperGod
· Il y a 2h
l'univers de la cryptomonnaie tôt, lis et va dormir
Voir l'originalRépondre0
HallucinationGrower
· Il y a 2h
Cette action de Hong Kong est pas mal~
Voir l'originalRépondre0
MintMaster
· Il y a 2h
C'est encore normalisé.
Voir l'originalRépondre0
NFTHoarder
· Il y a 2h
La gouvernance des stablecoins est enfin arrivée, j'attends avec impatience la frénésie.
Voir l'originalRépondre0
MetadataExplorer
· Il y a 2h
Le port a agi, hein ? Hmm, cette opération est plutôt stable.
Voir l'originalRépondre0
WalletDetective
· Il y a 2h
La régulation est de retour, investisseurs détaillant, reposez-vous.
La Hong Kong Monetary Authority a publié un guide d'implémentation des smart contracts pour les stablecoins, axé sur la conformité et la sécurité.
Texte
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 "Guide de réglementation des émetteurs de stablecoins agréés (brouillon)", visant à garantir la stabilité, la sécurité et la conformité de l'écosystème local des stablecoins. Ce guide énumère en détail les exigences réglementaires et les normes opérationnelles que les émetteurs de stablecoins agréés doivent respecter en permanence.
Récemment, de plus en plus d'institutions ont consulté les équipes de sécurité sur les questions de mise en œuvre conforme des contrats intelligents. Afin d'aider les émetteurs à mieux comprendre et déployer un système de contrats intelligents conforme, nous avons spécialement publié le "Guide de mise en œuvre des contrats intelligents pour les émetteurs de stablecoins à Hong Kong", afin de fournir des chemins techniques clairs et des conseils 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 fondations de l'architecture de haut niveau pour le système de stablecoins, ces décisions architecturales étant entièrement guidées par les exigences fondamentales du cadre de la Hong Kong Monetary Authority. Les choix faits ici détermineront l'ensemble du parcours de mise en œuvre, garantissant que la conformité est profondément intégrée dans la pile technologique dès le départ.
1. Choix du registre distribué de base
Directive de régulation
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é fondamentale. Le choix de la blockchain sous-jacente doit être soumis à une diligence raisonnable 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 stablecoins.
L'accent mis par la Banque centrale de Hong Kong sur la solidité des livres de comptes est en réalité un avertissement aux émetteurs pour éviter d'adopter des blockchains émergentes qui n'ont pas été validé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
Privilégier les blockchains publiques matures : il est conseillé de privilégier des blockchains publiques matures et hautement sécurisées comme Ethereum, Arbitrum, etc. Ces réseaux, grâce à leur résilience éprouvée, leur vaste réseau de nœuds de validation et leur surveillance publique continue, présentent des avantages naturels. Leur coût d'attaque élevé (sécurité économique) peut répondre directement aux préoccupations réglementaires 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 un autre type de grand livre distribué, une analyse comparative rigoureuse et quantifiable doit être menée, 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, à l'exploitation des vulnérabilités et à d'autres menaces, et analyser en détail comment ces risques peuvent avoir un impact potentiel sur l'émission, le rachat et le fonctionnement quotidien des stablecoins. Ce document est un document clé pour prouver la prudence du choix technologique aux régulateurs.
2. Normes de jetons clés et extensions des fonctions de régulation
Directive de réglementation
Les documents de réglementation ne spécifient pas un standard de jeton particulier (comme ERC-20). Cependant, les documents exigent la mise en œuvre d'une série de fonctions de gestion essentielles, y compris la frappe (mint), la destruction (burn), la mise à niveau (upgrade), la pause (pause), la reprise (resume), le gel (freeze), la liste noire (blacklist), la liste blanche (whitelist), etc.
Interprétation technique
La Banque populaire de Hong Kong a en fait défini un standard de jetons "renforcé par la réglementation" dont les fonctionnalités dépassent largement celles du 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é au maximum tout en répondant aux 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 : Utiliser 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 jetons, c'est un outil central pour faire face à des événements de sécurité majeurs.
Mintable : utilisé pour permettre aux émetteurs agréés de frapper de nouveaux tokens via un processus contrôlé et de s'assurer que l'émission de tokens correspond strictement à un actif de réserve en monnaie fiduciaire.
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 autorisée à tout utilisateur de détruire à sa guise.
Gelable : utilisé pour suspendre la fonction de transfert de tokens d'un compte spécifique (par exemple, en cas de transactions suspectes).
Liste blanche : utilisée pour mettre en œuvre des mesures de sécurité supplémentaires, permettant uniquement aux adresses approuvées par une diligence raisonnable de participer aux opérations clés (comme la réception de nouveaux jetons émis).
Liste noire : utilisée pour imposer une interdiction de transaction sur les adresses impliquées dans des activités illégales (telles que 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 d'accès granulaire et basé sur les rôles. 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 responsabilités.
3. Principaux modes de conformité : choix de la liste noire et de la liste blanche
Directive de régulation
Le document de consultation sur la surveillance continue, la lutte contre le blanchiment d'argent / le financement du terrorisme ( AML/CFT ) propose plusieurs mesures, y compris "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 "mettre en place un système de liste blanche pour les adresses de portefeuille des détenteurs de stablecoins, ou adopter un modèle 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 de conformité de la monnaie stable.
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, à moins qu'elle ne fasse l'objet d'une enquête de diligence raisonnable et d'une approbation explicite de l'émetteur, et qu'elle soit ajoutée à la liste blanche sur la chaîne, ne peut détenir ou recevoir des jetons.
Bien que le mode de liste blanche offre des capacités de contrôle AML (anti-blanchiment d'argent), un système de liste blanche strict pour une stablecoin destinée à être largement utilisée signifie que la stablecoin ne peut circuler qu'entre des participants préalablement vérifiés, ce qui la rend plus semblable à un système de livre bancaire fermé qu'à une monnaie numérique flexible.
Ainsi, le modèle de liste noire également mentionné explicitement par les régulateurs, combiné avec les 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 conserve l'utilité des actifs.
Dans sa conception, le système peut être construit pour être évolutif, ou pour fonctionner simultanément en 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.
Guide de mise en œuvre
Mode liste noire (solution recommandée par défaut) :
Avantages : offre une plus grande praticité, permettant une interopérabilité transparente avec le vaste écosystème financier décentralisé (DeFi), offrant aux utilisateurs une barrière d'entrée plus basse et une expérience plus fluide.
Inconvénients : La conformité dépend fortement de la 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 du contrat intelligent, 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 : 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 : limite considérablement l'universalité et le taux d'adoption des stablecoins, entraîne d'énormes coûts opérationnels pour la gestion des listes blanches, ce qui peut rendre difficile leur acceptation en tant que moyen d'échange largement reconnu.
Mode de réalisation : dans la fonction de transfert du contrat intelligent, ajouter une vérification logique, exigeant que les adresses de l'expéditeur (from) et du destinataire (to) soient toutes deux présentes dans la liste blanche. Il est conseillé de développer un système d'arrière-plan Web utilisateur dédié pour effectuer les opérations, afin d'augmenter la commodité des opérations.
Deuxième partie Mise en œuvre des contrats intelligents
Cette section fournit une feuille de route détaillée pour les fonctionnalités centrales des contrats intelligents, transformant des exigences réglementaires complexes en logique de code concrète, en modèles de sécurité et en protocoles opérationnels.
1. Concevoir un système de contrôle d'accès raffiné
Directive de réglementation
La conception des opérations à haut risque doit "prévenir qu'une seule partie puisse exécuter unilatéralement des opérations connexes (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 unique "propriétaire" ou "administrateur" 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érents entités ou employés contrôlés par des portefeuilles multi-signatures, afin de réaliser une séparation des fonctions et de minimiser les risques de points de défaillance uniques ou de manipulation collusoire. Chaque rôle doit être limité à des fonctions spécifiques, toutes les opérations nécessitant une autorisation multi-signature, et il faut s'assurer qu'aucun employé ne détient simultanément plusieurs rôles à haut risque. Toutes les opérations doivent être enregistrées dans des journaux et soumises à un audit tiers annuel, la répartition des droits étant supervisée par un administrateur ou un conseil d'administration.
MINTER_ROLE : Responsable du traitement des opérations de minting de stablecoins (mint), y compris la création d'unités de tokens après réception d'une demande d'émission valide, et garantir 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 tokens après réception d'une demande de rachat valide.
PAUSER_ROLE : Responsable de la suspension de l'opération de la monnaie stable (pause), par exemple, en arrêtant temporairement les transferts, la frappe ou le rachat en cas d'événements anormaux (tels que des menaces de sécurité).
RESUME_ROLE : Responsable de la restauration des opérations de (resume) stablecoin, par exemple, de réactiver les transferts, le minting ou le rachat après la résolution d'un événement de suspension.
FREEZER_ROLE : Responsable de geler (freeze) et de lever le gel (remove freeze) des opérations sur des portefeuilles ou des jetons spécifiques, par exemple en gelant temporairement les 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 d'adresses de portefeuille autorisées, par exemple, en limitant le minting uniquement aux adresses de la liste blanche.
BLACKLISTER_ROLE : Responsable de la gestion de la liste noire (blacklist) et de la suppression de la liste noire (remove blacklist), par exemple en mettant des portefeuilles suspects sur liste noire pour empêcher les transferts.
UPGRADER_ROLE : Si un modèle évolutif est adopté, responsable de la mise à niveau du contrat intelligent (upgrade), 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ée sur les rôles ( Matrice RBAC )
Le tableau ci-dessous fournit une norme claire et intuitive à l'usage des développeurs et des auditeurs, cartographiant explicitement chaque opération privilégiée à son rôle et type de contrôle requis.
| Action | Rôle requis | Type de contrôle | |------|----------|----------| | Monnaie (Mint) | RÔLE_DE_MINTEUR | Multi-signature | | Détruire (Burn) | RÔLE_DE_DÉTRUCTION | Multisignature | | Pause (Pause) | RÔLE_PAUSER | Multisignature | | Récupérer (Reprendre) | REPRENDRE_ROLE | Multisignature | | Gel (Freeze) | RÔLE_DE_GEL | Multi-signature | | Débloquer (Débloquer) | RÔLE_DE_DÉBLOQUAGE | Multisignature | | Ajouter à la liste blanche (Whitelist) | WHITELISTER_ROLE | Multisignature | | Retirer de la liste blanche (Retirer de la liste blanche) | WHITELISTER_