#dusk $DUSK @Dusk Dusk: Часть I, которую я почти пропустил
Сегодня я рылся в материале Dusk от 15 августа про токенизацию SME и почти пролистал таблицу жизненного цикла из шести стадий. Я вернулся обратно — и одна колонка не давала мне покоя: «что остаётся».
Структурирование всё ещё нуждается в корпоративных согласованиях. Передачи всё ещё могут требовать нотариуса. Обслуживание всё ещё может требовать человеческого решения по налоговому режиму.
Это изменило то, как я смотрю на $DUSK .
Раньше я думал о токенизации в первую очередь как о способе убрать трение. Но документ читается иначе. Dusk, похоже, строит общий слой записей поверх существующей правовой инфраструктуры, а не делает вид, что инфраструктура исчезает.
Контекст NPEX делает это довольно конкретным: акции Dutch BV могут всё ещё требовать нотариальный акт, даже если право собственности представлено токеном.
Я думаю, что это менее очевидная часть тезиса. Токенизация может убрать проблемы согласования, не убирая юридической ответственности. Для институтов это различие важнее, чем эффектный торговый интерфейс.
Я всё ещё рассматриваю $DUSK как небольшую тестовую позицию, а не гоняюсь за ней. Мне бы хотелось посмотреть, как инфраструктура справляется с реальными операционными ограничениями, а не предполагать, что любая проблема «RWA» решается тем, что актив кладут в onchain.
Затем я заметил ещё одну деталь в руководстве Dusk по безопасности — она подходит под тот же шаблон.
Разделение консенсусной активности и владения стейком ограничивает то, что может сделать украденный ключ узла. Но если мнемоника лежит на сервере, граница становится слабее. Хранение полномочий владельца офлайн улучшает разделение, но создаёт другую ответственность: этот ключ должен оставаться и защищённым, и восстанавливаемым, когда нужно делать unstaking или restaking.
Так что мой вопрос сдвинулся.
Разделение ключей у Dusk — это правильная граница безопасности, или оно просто переносит самый большой операционный риск на восстановление ключа владельца?
#dusk $DUSK
@Dusk_Foundation
$BTW
$br
$CYS
Сегодня я рылся в материале Dusk от 15 августа про токенизацию SME и почти пролистал таблицу жизненного цикла из шести стадий. Я вернулся обратно — и одна колонка не давала мне покоя: «что остаётся».
Структурирование всё ещё нуждается в корпоративных согласованиях. Передачи всё ещё могут требовать нотариуса. Обслуживание всё ещё может требовать человеческого решения по налоговому режиму.
Это изменило то, как я смотрю на $DUSK .
Раньше я думал о токенизации в первую очередь как о способе убрать трение. Но документ читается иначе. Dusk, похоже, строит общий слой записей поверх существующей правовой инфраструктуры, а не делает вид, что инфраструктура исчезает.
Контекст NPEX делает это довольно конкретным: акции Dutch BV могут всё ещё требовать нотариальный акт, даже если право собственности представлено токеном.
Я думаю, что это менее очевидная часть тезиса. Токенизация может убрать проблемы согласования, не убирая юридической ответственности. Для институтов это различие важнее, чем эффектный торговый интерфейс.
Я всё ещё рассматриваю $DUSK как небольшую тестовую позицию, а не гоняюсь за ней. Мне бы хотелось посмотреть, как инфраструктура справляется с реальными операционными ограничениями, а не предполагать, что любая проблема «RWA» решается тем, что актив кладут в onchain.
Затем я заметил ещё одну деталь в руководстве Dusk по безопасности — она подходит под тот же шаблон.
Разделение консенсусной активности и владения стейком ограничивает то, что может сделать украденный ключ узла. Но если мнемоника лежит на сервере, граница становится слабее. Хранение полномочий владельца офлайн улучшает разделение, но создаёт другую ответственность: этот ключ должен оставаться и защищённым, и восстанавливаемым, когда нужно делать unstaking или restaking.
Так что мой вопрос сдвинулся.
Разделение ключей у Dusk — это правильная граница безопасности, или оно просто переносит самый большой операционный риск на восстановление ключа владельца?
#dusk $DUSK
@Dusk_Foundation
$BTW
$br
$CYS