#dusk $DUSK @Dusk
Я некоторое время сидел с комплаенс-слоем Dusk и кое-что, что сначала не мог подтвердить, в итоге оказалось прямо сказанным.
Что ясно: Citadel существует, чтобы ограничивать (gate) определённые действия — проверять право на них (например, резидентство или аккредитацию), не раскрывая полную идентичность, — через трёхсторонний протокол между Пользователем, Поставщиком лицензии и Поставщиком сервиса.
Что я изначально не был уверен: какие именно действия требуют этого шлюза, а какие остаются открытыми. Документация Dusk по рыночной инфраструктуре отвечает на это напрямую. В ней говорится, что обслуживание и раскрытие — отчётность, корпоративные действия, выборочный доступ к необходимой информации — могут быть реализованы по-разному разными приложениями: Dusk предоставляет протокольные строительные блоки и пути исполнения, а не фиксированное, единое для всей сети правило.
Это подтверждает то, в чём я лишь подозревал раньше. Решение о шлюзовании не в том, что протокол Dusk требует: «действие X всегда нуждается в лицензии». Решение принимает каждое приложение, построенное на Citadel, выбирая, что именно ограничивать. Регулируемый dApp NPEX, который активно разворачивается на DuskEVM по состоянию на 2026 год, — самое наглядное живое испытание этого. Хотя хочу уточнить, что это развёртывание продолжается, а не подтверждённое, полностью завершённое внедрение, на которое я могу указать как на окончательное доказательство.
Это заставляет думать, что более глубокий вопрос не в том «что именно Citadel шлюзирует» — а в том, что Citadel изначально не предназначали отвечать на этот вопрос на уровне протокола. Ответ всегда должен был лежать на том, кто выпускает актив поверх него.
Поэтому фраза «какие-то действия требуют лицензии, а другие — нет» — это не реальная политика Dusk для всей сети. Это выбор конфигурации на уровне конкретного эмитента, с использованием инструментов, которые Dusk собрал специально для настройки именно так.
В общем, время покажет 👍
Я некоторое время сидел с комплаенс-слоем Dusk и кое-что, что сначала не мог подтвердить, в итоге оказалось прямо сказанным.
Что ясно: Citadel существует, чтобы ограничивать (gate) определённые действия — проверять право на них (например, резидентство или аккредитацию), не раскрывая полную идентичность, — через трёхсторонний протокол между Пользователем, Поставщиком лицензии и Поставщиком сервиса.
Что я изначально не был уверен: какие именно действия требуют этого шлюза, а какие остаются открытыми. Документация Dusk по рыночной инфраструктуре отвечает на это напрямую. В ней говорится, что обслуживание и раскрытие — отчётность, корпоративные действия, выборочный доступ к необходимой информации — могут быть реализованы по-разному разными приложениями: Dusk предоставляет протокольные строительные блоки и пути исполнения, а не фиксированное, единое для всей сети правило.
Это подтверждает то, в чём я лишь подозревал раньше. Решение о шлюзовании не в том, что протокол Dusk требует: «действие X всегда нуждается в лицензии». Решение принимает каждое приложение, построенное на Citadel, выбирая, что именно ограничивать. Регулируемый dApp NPEX, который активно разворачивается на DuskEVM по состоянию на 2026 год, — самое наглядное живое испытание этого. Хотя хочу уточнить, что это развёртывание продолжается, а не подтверждённое, полностью завершённое внедрение, на которое я могу указать как на окончательное доказательство.
Это заставляет думать, что более глубокий вопрос не в том «что именно Citadel шлюзирует» — а в том, что Citadel изначально не предназначали отвечать на этот вопрос на уровне протокола. Ответ всегда должен был лежать на том, кто выпускает актив поверх него.
Поэтому фраза «какие-то действия требуют лицензии, а другие — нет» — это не реальная политика Dusk для всей сети. Это выбор конфигурации на уровне конкретного эмитента, с использованием инструментов, которые Dusk собрал специально для настройки именно так.
В общем, время покажет 👍