Большинство проектов на рынке идут по маршруту «сначала выпустили токен — потом дособрали билеты»: токен сначала разгоняют, ликвидность сперва выкапывают, а вопрос комплаенса «потом» — достаточно, чтобы юрконтора выпустила заключение. Скажу грубо: выдержит ли такая схема несколько бычьих циклов под пристальным надзором регуляторов — я не уверен.
Пока не разобрал по частям Zedger и стандарты XSC с номером @Dusk , не осознал, что есть команды, которые продумали это до мелочей. Они закодировали в смарт-контракте жесткую логику комплаенса: проверку подходящих инвесторов, ограничения на передачу, правила дивидендных голосований. Перед расчетом каждой сделки контракт сначала прогоняет валидацию комплаенса: прошел — генерируются ончейн-артефакты/разрешающие доказательства; не прошел — операция попросту блокируется на месте. Это не «доползти до ончейна и потом разбираться, кто виноват», а не допустить некорректные действия с самого источника. Такая концепция «предварительной верификации» по духу очень похожа на базовую логику торгового риск-менеджмента Newton — просто Dusk применил её к более чувствительному слою: реальному внедрению под регулирование.
Слой данных опирается на валидацию через память в приватных аккаунтах, реализуя замкнутый цикл проверки. Теоретически это на одну ступень выше, чем у проектов, которые полагаются на ручную проверку вне блокчейна. Надёжность котировок RedStone, как уже проверено, подтверждена на более чем 110 цепочках — эта часть меня не слишком беспокоит.
Но должен сказать: в публичных материалах сейчас есть пункт, который не дает мне спокойно спать — неясны полномочия на изменение правил.
Даже если смарт-контракт работает идеально, если за кулисами спрятан «админский бэкдор», позволяющий в любой момент менять параметры и правила, устойчивость всей системы к рискам тут же превращается в вопрос. Что будет, если изменится политика регуляторов? Кто инициирует корректировки при изменении налоговых правил? Есть ли обязательные ограничения через time-lock и мультиподписи? На эти ключевые вопросы пока не видно четких ответов.
Моя оценка такова: направление правильное — путь ещё долгий. «Предварительная верификация» превращает правила комплаенса в ончейн-уровневую базовую возможность — эту идею я в долгую считаю перспективной. Но Dusk нужно пройти проверку реальными масштабами капитала: тесты на несколько миллионов долларов проходят, но не означает, что система будет стабильно работать на объёмах в десятки миллиардов. Дальше я буду внимательно следить за внедрением DuskTrade в сотрудничестве с NPEX: когда весь цикл — от матчинг-а ордеров, клиринг/расчётов до комплаенс-валидаций — пройдет end-to-end, тогда можно будет по-настоящему подтвердить реализуемость этого пути.
Как вам кажется: on-chain комплаенс — это окончательное решение или слишком идеализировано? Обсудим в комментариях.
#dusk $DUSK @Dusk
Пока не разобрал по частям Zedger и стандарты XSC с номером @Dusk , не осознал, что есть команды, которые продумали это до мелочей. Они закодировали в смарт-контракте жесткую логику комплаенса: проверку подходящих инвесторов, ограничения на передачу, правила дивидендных голосований. Перед расчетом каждой сделки контракт сначала прогоняет валидацию комплаенса: прошел — генерируются ончейн-артефакты/разрешающие доказательства; не прошел — операция попросту блокируется на месте. Это не «доползти до ончейна и потом разбираться, кто виноват», а не допустить некорректные действия с самого источника. Такая концепция «предварительной верификации» по духу очень похожа на базовую логику торгового риск-менеджмента Newton — просто Dusk применил её к более чувствительному слою: реальному внедрению под регулирование.
Слой данных опирается на валидацию через память в приватных аккаунтах, реализуя замкнутый цикл проверки. Теоретически это на одну ступень выше, чем у проектов, которые полагаются на ручную проверку вне блокчейна. Надёжность котировок RedStone, как уже проверено, подтверждена на более чем 110 цепочках — эта часть меня не слишком беспокоит.
Но должен сказать: в публичных материалах сейчас есть пункт, который не дает мне спокойно спать — неясны полномочия на изменение правил.
Даже если смарт-контракт работает идеально, если за кулисами спрятан «админский бэкдор», позволяющий в любой момент менять параметры и правила, устойчивость всей системы к рискам тут же превращается в вопрос. Что будет, если изменится политика регуляторов? Кто инициирует корректировки при изменении налоговых правил? Есть ли обязательные ограничения через time-lock и мультиподписи? На эти ключевые вопросы пока не видно четких ответов.
Моя оценка такова: направление правильное — путь ещё долгий. «Предварительная верификация» превращает правила комплаенса в ончейн-уровневую базовую возможность — эту идею я в долгую считаю перспективной. Но Dusk нужно пройти проверку реальными масштабами капитала: тесты на несколько миллионов долларов проходят, но не означает, что система будет стабильно работать на объёмах в десятки миллиардов. Дальше я буду внимательно следить за внедрением DuskTrade в сотрудничестве с NPEX: когда весь цикл — от матчинг-а ордеров, клиринг/расчётов до комплаенс-валидаций — пройдет end-to-end, тогда можно будет по-настоящему подтвердить реализуемость этого пути.
Как вам кажется: on-chain комплаенс — это окончательное решение или слишком идеализировано? Обсудим в комментариях.
#dusk $DUSK @Dusk