#dusk $DUSK
Меня привлекло не €300M, фигурирующие в NPEX — меня зацепила меньшая деталь, спрятанная в документах Dusk по рыночной инфраструктуре: прежде чем любой актив сможет переместиться, кошелёк должен быть привязан к верифицированному участнику. Не KYC один раз и забыть. Привязка выполняется к каждому активу как к исполнимому условию передачи.
Я хотел понять, что это означает механически, потому что «комплаентная токенизация» часто используется довольно свободно.
Вот последовательность, которую Dusk описывает для онбординга чего-то вроде NPEX: эмитент задаёт правила допустимости для актива. Кошельки инвесторов привязываются к верифицированным учётным данным. С этого момента слой контрактов Transfer обеспечивает, кто вообще может держать или перемещать токен — ограничение находится на уровне расчётов, а не в галочке на фронтенде. Сам расчёт сводит вместе «денежную» и «активную» стороны сделки для детерминированной финальности, так что не возникает состояния, когда доли переместились, а оплата — нет.
Почему это важно: NPEX — голландская MTF под надзором AFM. Она не может просто указать на публичный ERC-20 и назвать его ценной бумагой. Проверка допустимости должна быть исполнимой в блокчейне, а не только на интерфейсе — иначе регулируемая часть превращается в театральный спектакль.
Тот момент, который я хотел бы проверить, но не увидел полностью в спецификации: что происходит, когда допустимость меняется — инвестора исключают из реестра или обновляется юрисдикционное правило для токенов, которые уже находятся у него? Привязка аннулируется ретроспективно или она лишь ограничивает будущие переводы?
Это и есть реальный тест того, является ли это настоящей системой регулируемых активов, либо проверка комплаенса выполняется только на момент эмиссии.
Движение NPEX на €300M — это один датапоинт. То, выдерживает ли логика контроля переводов проверку в рамках реального регуляторного пограничного случая, и решит, переносится ли это на остальную часть сектора.
С искренним интересом: как Dusk решает кейс с отзывом — кто-то копался в спецификации Transfer, управляемой Zedger/Hedger, достаточно глубоко, чтобы знать?
@Dusk_Foundation $DUSK #dusk
Меня привлекло не €300M, фигурирующие в NPEX — меня зацепила меньшая деталь, спрятанная в документах Dusk по рыночной инфраструктуре: прежде чем любой актив сможет переместиться, кошелёк должен быть привязан к верифицированному участнику. Не KYC один раз и забыть. Привязка выполняется к каждому активу как к исполнимому условию передачи.
Я хотел понять, что это означает механически, потому что «комплаентная токенизация» часто используется довольно свободно.
Вот последовательность, которую Dusk описывает для онбординга чего-то вроде NPEX: эмитент задаёт правила допустимости для актива. Кошельки инвесторов привязываются к верифицированным учётным данным. С этого момента слой контрактов Transfer обеспечивает, кто вообще может держать или перемещать токен — ограничение находится на уровне расчётов, а не в галочке на фронтенде. Сам расчёт сводит вместе «денежную» и «активную» стороны сделки для детерминированной финальности, так что не возникает состояния, когда доли переместились, а оплата — нет.
Почему это важно: NPEX — голландская MTF под надзором AFM. Она не может просто указать на публичный ERC-20 и назвать его ценной бумагой. Проверка допустимости должна быть исполнимой в блокчейне, а не только на интерфейсе — иначе регулируемая часть превращается в театральный спектакль.
Тот момент, который я хотел бы проверить, но не увидел полностью в спецификации: что происходит, когда допустимость меняется — инвестора исключают из реестра или обновляется юрисдикционное правило для токенов, которые уже находятся у него? Привязка аннулируется ретроспективно или она лишь ограничивает будущие переводы?
Это и есть реальный тест того, является ли это настоящей системой регулируемых активов, либо проверка комплаенса выполняется только на момент эмиссии.
Движение NPEX на €300M — это один датапоинт. То, выдерживает ли логика контроля переводов проверку в рамках реального регуляторного пограничного случая, и решит, переносится ли это на остальную часть сектора.
С искренним интересом: как Dusk решает кейс с отзывом — кто-то копался в спецификации Transfer, управляемой Zedger/Hedger, достаточно глубоко, чтобы знать?
@Dusk_Foundation $DUSK #dusk