#dusk $DUSK @Dusk
Я немного иначе задумался о посттрейдинговом дизайне Dusk после чтения материалов о жизненном цикле. Раньше я думал, что программируемое соответствие — это в основном про то, чтобы убедиться, что сделку можно выполнить до того, как она произойдёт. Но более сложный вопрос, похоже, начинается после сделки, когда нужно, чтобы корректными оставались право собственности, право голоса, право на дивиденды и статус соответствия.
Отсюда следует, что идея сделать соответствие программируемым действительно полезна, но и немного неуютна. Код может последовательно применять правило. Он не может автоматически знать, что делать, когда реальная ситуация за этим правилом меняется или не соответствует предположениям, на которых правило было построено. Если меняется право держателя на участие или требуется исключение из какого-то регуляторного условия, должен существовать механизм, который корректно обрабатывает это состояние, а не просто полагаться на исходную логику.
И именно здесь, как мне кажется, Dusk становится интереснее, чем просто токенизация актива. Сам токен — почти самый простой слой. Сложнее всего поддерживать запись в актуальном и достоверном состоянии по мере того, как продолжают происходить сделки. Но меня всё ещё волнует вопрос о слое переопределения. Кому на самом деле доверено вмешиваться, когда закодированные правила дают неверный результат, и как не допустить, чтобы эта полномочность стала самым слабым звеном в системе, которая в остальном должна быть программируемой?
Я немного иначе задумался о посттрейдинговом дизайне Dusk после чтения материалов о жизненном цикле. Раньше я думал, что программируемое соответствие — это в основном про то, чтобы убедиться, что сделку можно выполнить до того, как она произойдёт. Но более сложный вопрос, похоже, начинается после сделки, когда нужно, чтобы корректными оставались право собственности, право голоса, право на дивиденды и статус соответствия.
Отсюда следует, что идея сделать соответствие программируемым действительно полезна, но и немного неуютна. Код может последовательно применять правило. Он не может автоматически знать, что делать, когда реальная ситуация за этим правилом меняется или не соответствует предположениям, на которых правило было построено. Если меняется право держателя на участие или требуется исключение из какого-то регуляторного условия, должен существовать механизм, который корректно обрабатывает это состояние, а не просто полагаться на исходную логику.
И именно здесь, как мне кажется, Dusk становится интереснее, чем просто токенизация актива. Сам токен — почти самый простой слой. Сложнее всего поддерживать запись в актуальном и достоверном состоянии по мере того, как продолжают происходить сделки. Но меня всё ещё волнует вопрос о слое переопределения. Кому на самом деле доверено вмешиваться, когда закодированные правила дают неверный результат, и как не допустить, чтобы эта полномочность стала самым слабым звеном в системе, которая в остальном должна быть программируемой?