Руководство по реализации смарт-контрактов для发行 стейблкоинов в Гонконге
С принятием «Положений о стейблкоинах» Управление финансовых услуг Гонконга 26 мая 2025 года выпустило «Руководящие принципы по надзору за лицензированными эмитентами стейблкоинов (черновик)», нацеленные на обеспечение стабильной, безопасной и соответствующей деятельности местной экосистемы стейблкоинов. В этих руководящих принципах подробно изложены требования к соблюдению норм и операционные стандарты, которые должны постоянно соблюдать лицензированные эмитенты стейблкоинов.
В последнее время все больше учреждений обращаются к команде безопасности с вопросами о соблюдении норм при внедрении смарт-контрактов. Чтобы помочь эмитентам лучше понять и развернуть систему соблюдения смарт-контрактов, мы специально выпустили «Руководство по внедрению смарт-контрактов для эмитентов стейблкоинов Гонконга», чтобы предоставить четкие технические пути и практические рекомендации, поддерживающие здоровое развитие экосистемы стейблкоинов Гонконга.
Первая часть Инфраструктура и стратегии соблюдения
Эта часть направлена на создание фундамента высокоуровневой архитектуры для системы стейблкоинов, где решения по архитектуре полностью обусловлены основными требованиями рамок Управления финансовыми услугами Гонконга. Выбор, сделанный здесь, определит весь путь реализации, обеспечивая глубокую интеграцию соблюдения норм в технологический стек с самого начала проектирования.
1. Выбор базового распределенного реестра
Регуляторные указания
Лицензиаты должны оценить надежность используемой ими основной распределенной реестровой технологии (DLT). Эта оценка охватывает безопасность инфраструктуры, устойчивость к распространенным атакам (таким как атака 51%), гарантии окончательности транзакций и надежность алгоритма консенсуса.
Технический анализ
Это не просто вопрос выбора технических предпочтений, а основная задача соблюдения норм. Выбор базовой блокчейн-технологии должен проходить через формальное дью-дилидженс, и весь процесс оценки должен быть детально задокументирован, чтобы предоставить достаточные обоснования во время регуляторного контроля. Процесс выбора базового реестра фактически задает тон для безопасности и стабильности всей системы стейблкоинов.
Подчеркивание надежности бухгалтерского учета Управлением денежного обращения Гонконга фактически является предостережением для эмитентов избегать использования новых блокчейнов, которые не были проверены рынком, имеют слишком высокий уровень централизации или безопасность которых вызывает сомнения. Ответственность за доказательство их безопасности и стабильности полностью лежит на эмитентах. Если эмитенты выберут цепочку, безопасность которой еще не была широко проверена, они должны разработать и реализовать дополнительные компенсирующие контролирующие меры.
Руководство по реализации
Приоритет на зрелые публичные цепочки: рекомендуется отдавать предпочтение таким зрелым и безопасным публичным блокчейнам, как Ethereum, Arbitrum и т.д. Эти сети обладают естественными преимуществами благодаря своей проверенной устойчивости, обширной сети валидаторов и постоянному общественному контролю. Их высокая стоимость атак (экономическая безопасность) может напрямую ответить на опасения регуляторов по поводу защиты от атаки 51% и обеспечения окончательности транзакций.
Строгая оценка альтернативных решений: если рассматривается возможность использования консорциума или других типов распределенных реестров, необходимо провести тщательный и количественно обоснованный сравнительный анализ, например, аудит безопасности, чтобы доказать, что их стандарты безопасности не ниже, а даже превышают стандарты основных общественных цепей.
Документ по оценке рисков: Оценочный отчет должен полностью охватывать способность противостоять распространенным атакам, типы алгоритмов консенсуса, а также риски, связанные с дефектами кода, уязвимостями, эксплуатацией уязвимостей и другими угрозами, и подробно анализировать, как эти риски могут потенциально повлиять на выпуск, выкуп и повседневную деятельность стейблкоина. Этот документ является ключевым документом для доказательства осторожности выбора технологии перед регулирующими органами.
2. Стандарты токенов и расширение регуляторных функций
регуляторные указания
Регуляторные документы не указывают на какой-либо конкретный стандарт токена (например, ERC-20). Тем не менее, документы требуют реализации ряда основных функций управления, включая выпуск (mint), сжигание (burn), обновление (upgrade), приостановку (pause), восстановление (resume), заморозку (freeze), черный список (blacklist), белый список (whitelist) и другие операции.
Технический анализ
Фактически, Управление денежно-кредитной политики Гонконга определило стандарт "регулируемого улучшенного" токена, который имеет функции, выходящие далеко за рамки стандарта ERC-20. Этот стандарт не только требует наличия базовых функций обращения токенов, но и подчеркивает важность безопасности операций, управляемости правами доступа и прослеживаемости рисков. Чтобы максимально обеспечить безопасность при соблюдении требований комплаенса, наиболее эффективным и надежным путем разработки является использование стандартной библиотеки, прошедшей широкую проверку и признанной сообществом (например, OpenZeppelin), и на этой основе расширение функциональности.
Руководство по внедрению
Базовый стандарт: использовать ERC-20 в качестве базового стандарта для обеспечения однородности токенов и их совместимости в более широкой экосистеме.
Расширение функционала: необходимо интегрировать следующие функциональные модули для соблюдения требований регулирования:
Приостановка: используется для реализации глобальной функции приостановки и восстановления всех активностей токенов, что является основным инструментом для реагирования на серьезные инциденты безопасности.
Mintable: используется для реализации лицензированными эмитентами процесса контролируемого выпуска новых токенов и обеспечения строгого соответствия объема выпуска токенов достаточным резервным активам в фиатной валюте.
Сжигаемый: предоставляет возможность уничтожения токенов. В конкретной реализации эта функция будет строго контролироваться правами доступа, а не позволять любому пользователю уничтожать токены по своему усмотрению.
Freezable: используется для приостановки функции перевода токенов для определенных аккаунтов (например, в случае подозрительных транзакций).
Белый список: используется для внедрения дополнительных мер безопасности, разрешая участие в основных операциях (например, получение новых токенов), только для адресов, прошедших дью-дилижанс и одобренных.
Черный список: используется для реализации запрета на транзакции для адресов, связанных с незаконной деятельностью (такими как отмывание денег, мошенничество), запрещая им отправлять/получать токены. Управление черным списком должно быть связано с системой AML/CFT, для реального мониторинга подозрительных транзакций.
AccessControl: это основа для реализации детализированной системы управления правами доступа на основе ролей. Все управленческие функции должны проходить контроль доступа через этот модуль, чтобы соответствовать требованиям разделения обязанностей.
3. Основные модели соблюдения: выбор черного списка и белого списка
регуляторная инструкция
Что касается постоянного мониторинга, документы по консультированию по противодействию отмыванию денег/борьбе с финансированием терроризма ( AML/CFT ) предлагают различные меры, включая "внесение в черный список адресов кошельков, которые будут идентифицированы как подпадающие под санкции или связанные с незаконной деятельностью", или более строгий подход "введение системы белых списков для адресов кошельков держателей стейблкоинов или использование замкнутой системы".
Технический анализ
Это наиболее критическая точка принятия решений в архитектуре всей системы, которая напрямую определяет открытость, практическую полезность и сложность соблюдения норм для стейблкоина.
Режим черного списка: режим "по умолчанию открытый". Все адреса по умолчанию могут свободно торговать, только те адреса, которые были явно идентифицированы и добавлены в черный список на блокчейне, будут ограничены.
Режим белого списка: замкнутый режим "по умолчанию отключен". Любой адрес, если он не прошел явное должное расследование и одобрение со стороны эмитента и не был добавлен в белый список на блокчейне, не может владеть или получать токены.
Несмотря на то, что режим белого списка предоставляет возможности контроля AML (борьба с отмыванием денег), строгая система белого списка для стейблкоина, предназначенного для широкого использования, означает, что стейблкоин может обращаться только между предварительно проверенными участниками, что делает его более похожим на закрытую банковскую книгу, а не на гибкую цифровую валюту.
Таким образом, также упомянутый в регуляции режим черного списка, в сочетании с мощными инструментами анализа вне цепи, требуемыми регуляторами, представляет собой более сбалансированное решение. Оно удовлетворяет требованиям регуляторов и сохраняет практическое применение активов.
В дизайне система может быть построена как масштабируемая или одновременно реализовать оба режима, чтобы в будущем, при ужесточении регулирования или изменении бизнес-модели, можно было плавно перейти или переключиться на режим белого списка.
Руководство по реализации
Режим черного списка (рекомендуемая схема по умолчанию):
Преимущества: обладает более высокой практичностью, может бесшовно взаимодействовать с обширной экосистемой децентрализованных финансов (DeFi), обеспечивая пользователям более низкий порог использования и более плавный опыт.
Недостатки: соблюдение нормативных требований сильно зависит от мощных, оперативных возможностей анализа оффлайн-данных, чтобы вовремя обнаруживать и блокировать незаконные адреса.
Способ реализации: в функции перевода смарт-контракта добавить логическую проверку, чтобы убедиться, что адреса отправителя (from) и получателя (to) не занесены в черный список.
Режим белого списка
Преимущества: обеспечивает высший уровень контроля AML/CFT, реализуя предварительное предотвращение, а не последующее устранение.
Недостатки: Это сильно ограничивает универсальность и уровень принятия стейблкоинов, создавая огромные операционные расходы на управление белыми списками, что может затруднить их становление широко принимаемым средством обмена.
Способ реализации: в функции перевода смарт-контрактов добавить логическую проверку, требующую, чтобы адреса отправителя (from) и получателя (to) находились в белом списке. Рекомендуется разработать специализированную веб-панель пользователя для удобства операций.
Вторая часть реализации смарт-контрактов
В этой части представлена подробная схема основных функций смарт-контрактов, которая преобразует сложные требования регулирования в конкретную кодовую логику, безопасные модели и операционные протоколы.
1. Дизайн детализированной системы контроля доступа
Регуляторные указания
Дизайн высокорисковых операций должен "предотвращать возможность того, чтобы одна сторона могла в одностороннем порядке выполнять соответствующие действия (например, через протоколы многоподписей)". Обязанности по различным операциям должны быть должным образом изолированы.
Технический анализ
Это означает, что мощная и основанная на ролях система контроля доступа (RBAC) является обязательной. Любая форма единственного "владельца" или "администратора" приватного ключа является некондиционной.
Руководство по внедрению
Необходимо определить ряд четких ролей и распределить эти роли между различными лицами или сотрудниками, контролируемыми мультиподписными кошельками, для достижения разделения обязанностей и минимизации риска единой точки отказа или сговора. Каждая роль должна быть ограничена определенными функциями, все операции должны быть авторизованы множественной подписью, и необходимо обеспечить, чтобы ни один сотрудник не занимал одновременно несколько высокорисковых ролей. Все операции должны быть зарегистрированы в журналах и подлежать ежегодному стороннему аудиту, распределение прав должно контролироваться администратором или советом директоров.
MINTER_ROLE: отвечает за обработку операций по выпуску стейблкоинов (mint), включая создание единиц токенов после получения действительного запроса на выпуск и обеспечение соответствующего увеличения эмиссии с резервным активом.
BURNER_ROLE: отвечает за обработку операций по уничтожению стейблкоинов (burn), включая уничтожение единиц токенов после получения действительного запроса на выкуп.
PAUSER_ROLE: отвечает за приостановку (pause) стейблкоин операций, таких как временная остановка переводов, выпуска или выкупа при обнаружении аномальных событий (например, угроз безопасности).
RESUME_ROLE: отвечает за восстановление операции (resume) стейблкоина, например, повторное включение перевода, эмиссии или выкупа после устранения события приостановки.
FREEZER_ROLE: отвечает за заморозку (freeze) и снятие заморозки (remove freeze) определенных кошельков или токенов, например, временную заморозку активов при обнаружении подозрительной активности (например, риск отмывания денег).
WHITELISTER_ROLE: отвечает за управление белым списком (whitelist), включая добавление или удаление разрешенных адресов кошельков, например, ограничение выпуска токенов только для адресов из белого списка.
BLACKLISTER_ROLE: отвечает за управление черным списком (blacklist) и удаление черного списка (remove blacklist), например, добавление подозрительных кошельков в черный список для предотвращения переводов.
UPGRADER_ROLE: Если используется модель с возможностью обновления, отвечает за обновление (upgrade) смарт-контрактов, например, обновление кода контракта для исправления уязвимостей или добавления функций.
Матрица контроля доступа на основе ролей ( RBAC Matrix )
Ниже представлена ясная и наглядная спецификация, предназначенная для использования разработчиками и аудиторами, которая четко сопоставляет каждую привилегированную операцию с необходимыми ролями и типами контроля.
| Операция | Необходимая роль | Тип управления |
|------|----------|----------|
| токен | MINTER_ROLE | многофакторная подпись |
| УНИЧТОЖЕНИЕ | BURNER_ROLE | МНОГОСТОРОННЯЯ ПОДПИСКА |
| Приостановить | PAUSER_ROLE | Мультиподпись |
| Восстановить | RESUME_ROLE | Мультиподпись |
| Заморозка | FREEZER_ROLE | Мультиподпись |
| разморозка | FREEZER_ROLE | мультиподпись |
| Добавить в белый список | WHITELISTER_ROLE | Мультиподпись |
| Удалить из белого списка | WHITELISTER_ROLE | Мульти
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
10 Лайков
Награда
10
2
Репост
Поделиться
комментарий
0/400
token_therapist
· 3ч назад
Гонконгское регулирование - это то, что нужно исправить.
Посмотреть ОригиналОтветить0
tx_pending_forever
· 3ч назад
Наконец-то вышли на правильный путь, Гонконг собирается жестко противостоять USDT.
Руководство по внедрению смарт-контрактов стейблкоинов Управления финансовых услуг Гонконга: Соответствие и техническая дорожная карта
Руководство по реализации смарт-контрактов для发行 стейблкоинов в Гонконге
С принятием «Положений о стейблкоинах» Управление финансовых услуг Гонконга 26 мая 2025 года выпустило «Руководящие принципы по надзору за лицензированными эмитентами стейблкоинов (черновик)», нацеленные на обеспечение стабильной, безопасной и соответствующей деятельности местной экосистемы стейблкоинов. В этих руководящих принципах подробно изложены требования к соблюдению норм и операционные стандарты, которые должны постоянно соблюдать лицензированные эмитенты стейблкоинов.
В последнее время все больше учреждений обращаются к команде безопасности с вопросами о соблюдении норм при внедрении смарт-контрактов. Чтобы помочь эмитентам лучше понять и развернуть систему соблюдения смарт-контрактов, мы специально выпустили «Руководство по внедрению смарт-контрактов для эмитентов стейблкоинов Гонконга», чтобы предоставить четкие технические пути и практические рекомендации, поддерживающие здоровое развитие экосистемы стейблкоинов Гонконга.
Первая часть Инфраструктура и стратегии соблюдения
Эта часть направлена на создание фундамента высокоуровневой архитектуры для системы стейблкоинов, где решения по архитектуре полностью обусловлены основными требованиями рамок Управления финансовыми услугами Гонконга. Выбор, сделанный здесь, определит весь путь реализации, обеспечивая глубокую интеграцию соблюдения норм в технологический стек с самого начала проектирования.
1. Выбор базового распределенного реестра
Регуляторные указания
Лицензиаты должны оценить надежность используемой ими основной распределенной реестровой технологии (DLT). Эта оценка охватывает безопасность инфраструктуры, устойчивость к распространенным атакам (таким как атака 51%), гарантии окончательности транзакций и надежность алгоритма консенсуса.
Технический анализ
Это не просто вопрос выбора технических предпочтений, а основная задача соблюдения норм. Выбор базовой блокчейн-технологии должен проходить через формальное дью-дилидженс, и весь процесс оценки должен быть детально задокументирован, чтобы предоставить достаточные обоснования во время регуляторного контроля. Процесс выбора базового реестра фактически задает тон для безопасности и стабильности всей системы стейблкоинов.
Подчеркивание надежности бухгалтерского учета Управлением денежного обращения Гонконга фактически является предостережением для эмитентов избегать использования новых блокчейнов, которые не были проверены рынком, имеют слишком высокий уровень централизации или безопасность которых вызывает сомнения. Ответственность за доказательство их безопасности и стабильности полностью лежит на эмитентах. Если эмитенты выберут цепочку, безопасность которой еще не была широко проверена, они должны разработать и реализовать дополнительные компенсирующие контролирующие меры.
Руководство по реализации
Приоритет на зрелые публичные цепочки: рекомендуется отдавать предпочтение таким зрелым и безопасным публичным блокчейнам, как Ethereum, Arbitrum и т.д. Эти сети обладают естественными преимуществами благодаря своей проверенной устойчивости, обширной сети валидаторов и постоянному общественному контролю. Их высокая стоимость атак (экономическая безопасность) может напрямую ответить на опасения регуляторов по поводу защиты от атаки 51% и обеспечения окончательности транзакций.
Строгая оценка альтернативных решений: если рассматривается возможность использования консорциума или других типов распределенных реестров, необходимо провести тщательный и количественно обоснованный сравнительный анализ, например, аудит безопасности, чтобы доказать, что их стандарты безопасности не ниже, а даже превышают стандарты основных общественных цепей.
Документ по оценке рисков: Оценочный отчет должен полностью охватывать способность противостоять распространенным атакам, типы алгоритмов консенсуса, а также риски, связанные с дефектами кода, уязвимостями, эксплуатацией уязвимостей и другими угрозами, и подробно анализировать, как эти риски могут потенциально повлиять на выпуск, выкуп и повседневную деятельность стейблкоина. Этот документ является ключевым документом для доказательства осторожности выбора технологии перед регулирующими органами.
2. Стандарты токенов и расширение регуляторных функций
регуляторные указания
Регуляторные документы не указывают на какой-либо конкретный стандарт токена (например, ERC-20). Тем не менее, документы требуют реализации ряда основных функций управления, включая выпуск (mint), сжигание (burn), обновление (upgrade), приостановку (pause), восстановление (resume), заморозку (freeze), черный список (blacklist), белый список (whitelist) и другие операции.
Технический анализ
Фактически, Управление денежно-кредитной политики Гонконга определило стандарт "регулируемого улучшенного" токена, который имеет функции, выходящие далеко за рамки стандарта ERC-20. Этот стандарт не только требует наличия базовых функций обращения токенов, но и подчеркивает важность безопасности операций, управляемости правами доступа и прослеживаемости рисков. Чтобы максимально обеспечить безопасность при соблюдении требований комплаенса, наиболее эффективным и надежным путем разработки является использование стандартной библиотеки, прошедшей широкую проверку и признанной сообществом (например, OpenZeppelin), и на этой основе расширение функциональности.
Руководство по внедрению
Базовый стандарт: использовать ERC-20 в качестве базового стандарта для обеспечения однородности токенов и их совместимости в более широкой экосистеме.
Расширение функционала: необходимо интегрировать следующие функциональные модули для соблюдения требований регулирования:
Приостановка: используется для реализации глобальной функции приостановки и восстановления всех активностей токенов, что является основным инструментом для реагирования на серьезные инциденты безопасности.
Mintable: используется для реализации лицензированными эмитентами процесса контролируемого выпуска новых токенов и обеспечения строгого соответствия объема выпуска токенов достаточным резервным активам в фиатной валюте.
Сжигаемый: предоставляет возможность уничтожения токенов. В конкретной реализации эта функция будет строго контролироваться правами доступа, а не позволять любому пользователю уничтожать токены по своему усмотрению.
Freezable: используется для приостановки функции перевода токенов для определенных аккаунтов (например, в случае подозрительных транзакций).
Белый список: используется для внедрения дополнительных мер безопасности, разрешая участие в основных операциях (например, получение новых токенов), только для адресов, прошедших дью-дилижанс и одобренных.
Черный список: используется для реализации запрета на транзакции для адресов, связанных с незаконной деятельностью (такими как отмывание денег, мошенничество), запрещая им отправлять/получать токены. Управление черным списком должно быть связано с системой AML/CFT, для реального мониторинга подозрительных транзакций.
AccessControl: это основа для реализации детализированной системы управления правами доступа на основе ролей. Все управленческие функции должны проходить контроль доступа через этот модуль, чтобы соответствовать требованиям разделения обязанностей.
3. Основные модели соблюдения: выбор черного списка и белого списка
регуляторная инструкция
Что касается постоянного мониторинга, документы по консультированию по противодействию отмыванию денег/борьбе с финансированием терроризма ( AML/CFT ) предлагают различные меры, включая "внесение в черный список адресов кошельков, которые будут идентифицированы как подпадающие под санкции или связанные с незаконной деятельностью", или более строгий подход "введение системы белых списков для адресов кошельков держателей стейблкоинов или использование замкнутой системы".
Технический анализ
Это наиболее критическая точка принятия решений в архитектуре всей системы, которая напрямую определяет открытость, практическую полезность и сложность соблюдения норм для стейблкоина.
Режим черного списка: режим "по умолчанию открытый". Все адреса по умолчанию могут свободно торговать, только те адреса, которые были явно идентифицированы и добавлены в черный список на блокчейне, будут ограничены.
Режим белого списка: замкнутый режим "по умолчанию отключен". Любой адрес, если он не прошел явное должное расследование и одобрение со стороны эмитента и не был добавлен в белый список на блокчейне, не может владеть или получать токены.
Несмотря на то, что режим белого списка предоставляет возможности контроля AML (борьба с отмыванием денег), строгая система белого списка для стейблкоина, предназначенного для широкого использования, означает, что стейблкоин может обращаться только между предварительно проверенными участниками, что делает его более похожим на закрытую банковскую книгу, а не на гибкую цифровую валюту.
Таким образом, также упомянутый в регуляции режим черного списка, в сочетании с мощными инструментами анализа вне цепи, требуемыми регуляторами, представляет собой более сбалансированное решение. Оно удовлетворяет требованиям регуляторов и сохраняет практическое применение активов.
В дизайне система может быть построена как масштабируемая или одновременно реализовать оба режима, чтобы в будущем, при ужесточении регулирования или изменении бизнес-модели, можно было плавно перейти или переключиться на режим белого списка.
Руководство по реализации
Режим черного списка (рекомендуемая схема по умолчанию):
Преимущества: обладает более высокой практичностью, может бесшовно взаимодействовать с обширной экосистемой децентрализованных финансов (DeFi), обеспечивая пользователям более низкий порог использования и более плавный опыт.
Недостатки: соблюдение нормативных требований сильно зависит от мощных, оперативных возможностей анализа оффлайн-данных, чтобы вовремя обнаруживать и блокировать незаконные адреса.
Способ реализации: в функции перевода смарт-контракта добавить логическую проверку, чтобы убедиться, что адреса отправителя (from) и получателя (to) не занесены в черный список.
Режим белого списка
Преимущества: обеспечивает высший уровень контроля AML/CFT, реализуя предварительное предотвращение, а не последующее устранение.
Недостатки: Это сильно ограничивает универсальность и уровень принятия стейблкоинов, создавая огромные операционные расходы на управление белыми списками, что может затруднить их становление широко принимаемым средством обмена.
Способ реализации: в функции перевода смарт-контрактов добавить логическую проверку, требующую, чтобы адреса отправителя (from) и получателя (to) находились в белом списке. Рекомендуется разработать специализированную веб-панель пользователя для удобства операций.
Вторая часть реализации смарт-контрактов
В этой части представлена подробная схема основных функций смарт-контрактов, которая преобразует сложные требования регулирования в конкретную кодовую логику, безопасные модели и операционные протоколы.
1. Дизайн детализированной системы контроля доступа
Регуляторные указания
Дизайн высокорисковых операций должен "предотвращать возможность того, чтобы одна сторона могла в одностороннем порядке выполнять соответствующие действия (например, через протоколы многоподписей)". Обязанности по различным операциям должны быть должным образом изолированы.
Технический анализ
Это означает, что мощная и основанная на ролях система контроля доступа (RBAC) является обязательной. Любая форма единственного "владельца" или "администратора" приватного ключа является некондиционной.
Руководство по внедрению
Необходимо определить ряд четких ролей и распределить эти роли между различными лицами или сотрудниками, контролируемыми мультиподписными кошельками, для достижения разделения обязанностей и минимизации риска единой точки отказа или сговора. Каждая роль должна быть ограничена определенными функциями, все операции должны быть авторизованы множественной подписью, и необходимо обеспечить, чтобы ни один сотрудник не занимал одновременно несколько высокорисковых ролей. Все операции должны быть зарегистрированы в журналах и подлежать ежегодному стороннему аудиту, распределение прав должно контролироваться администратором или советом директоров.
MINTER_ROLE: отвечает за обработку операций по выпуску стейблкоинов (mint), включая создание единиц токенов после получения действительного запроса на выпуск и обеспечение соответствующего увеличения эмиссии с резервным активом.
BURNER_ROLE: отвечает за обработку операций по уничтожению стейблкоинов (burn), включая уничтожение единиц токенов после получения действительного запроса на выкуп.
PAUSER_ROLE: отвечает за приостановку (pause) стейблкоин операций, таких как временная остановка переводов, выпуска или выкупа при обнаружении аномальных событий (например, угроз безопасности).
RESUME_ROLE: отвечает за восстановление операции (resume) стейблкоина, например, повторное включение перевода, эмиссии или выкупа после устранения события приостановки.
FREEZER_ROLE: отвечает за заморозку (freeze) и снятие заморозки (remove freeze) определенных кошельков или токенов, например, временную заморозку активов при обнаружении подозрительной активности (например, риск отмывания денег).
WHITELISTER_ROLE: отвечает за управление белым списком (whitelist), включая добавление или удаление разрешенных адресов кошельков, например, ограничение выпуска токенов только для адресов из белого списка.
BLACKLISTER_ROLE: отвечает за управление черным списком (blacklist) и удаление черного списка (remove blacklist), например, добавление подозрительных кошельков в черный список для предотвращения переводов.
UPGRADER_ROLE: Если используется модель с возможностью обновления, отвечает за обновление (upgrade) смарт-контрактов, например, обновление кода контракта для исправления уязвимостей или добавления функций.
Матрица контроля доступа на основе ролей ( RBAC Matrix )
Ниже представлена ясная и наглядная спецификация, предназначенная для использования разработчиками и аудиторами, которая четко сопоставляет каждую привилегированную операцию с необходимыми ролями и типами контроля.
| Операция | Необходимая роль | Тип управления | |------|----------|----------| | токен | MINTER_ROLE | многофакторная подпись | | УНИЧТОЖЕНИЕ | BURNER_ROLE | МНОГОСТОРОННЯЯ ПОДПИСКА | | Приостановить | PAUSER_ROLE | Мультиподпись | | Восстановить | RESUME_ROLE | Мультиподпись | | Заморозка | FREEZER_ROLE | Мультиподпись | | разморозка | FREEZER_ROLE | мультиподпись | | Добавить в белый список | WHITELISTER_ROLE | Мультиподпись | | Удалить из белого списка | WHITELISTER_ROLE | Мульти