Впервые, когда я посмотрел на программируемое комплаенс-регулирование, я предположил, что главная сложность — доказать, что каждая транзакция следует нужным правилам. Со временем стало ясно, что одного доказательства недостаточно, если сами правила со временем устаревают. Рынки развиваются, нормативные требования меняются, а новые риски появляются постоянно. Пересборка или повторное развертывание смарт-контрактов каждый раз при изменении политики замедлило бы все процессы и привнесло бы ненужные операционные риски.
Ньютон подходит к этой задаче с другой стороны. Вместо того чтобы встраивать логику комплаенса непосредственно в код приложения, политики существуют как независимые компоненты, на которые контракты могут ссылаться во время выполнения. Будь то требование санкционного списка, ограничение по региону, лимит расходов или проверка личности, политику можно обновлять без переписывания самого слоя расчетов. Инфраструктура остается стабильной, пока правила сохраняют гибкость.
Что особенно заметно — принуждение (enforcement) происходит до того, как значение (ценность) начинает перемещаться. Операторы оценивают запрошенное действие, подтверждают (attest), что требуемая политика выполнена, и только затем расчет может продолжиться. Это меняет комплаенс: вместо реактивного расследования — превентивный контроль. Вместо того чтобы отменять транзакции или замораживать активы позже, недействительные действия отсеиваются еще до того, как они станут окончательными.
Такая архитектура задает интересный компромисс. Разделение политики и исполнения повышает адаптивность, но одновременно делает управление (governance) намного более важным. Кто утверждает обновления политики? Насколько прозрачно принимаются эти решения? Могут ли независимые участники проверить, что правило было применено справедливо, а не просто доверять реестру? По мере роста программируемых финансов, главный вопрос может уже заключаться не в том, правильно ли выполняются смарт-контракты, а в том, остаются ли политики, по которым они работают, открытыми, подотчетными и заслуживающими доверия.
@NewtonProtocol $NEWT #newt $BNB
Ньютон подходит к этой задаче с другой стороны. Вместо того чтобы встраивать логику комплаенса непосредственно в код приложения, политики существуют как независимые компоненты, на которые контракты могут ссылаться во время выполнения. Будь то требование санкционного списка, ограничение по региону, лимит расходов или проверка личности, политику можно обновлять без переписывания самого слоя расчетов. Инфраструктура остается стабильной, пока правила сохраняют гибкость.
Что особенно заметно — принуждение (enforcement) происходит до того, как значение (ценность) начинает перемещаться. Операторы оценивают запрошенное действие, подтверждают (attest), что требуемая политика выполнена, и только затем расчет может продолжиться. Это меняет комплаенс: вместо реактивного расследования — превентивный контроль. Вместо того чтобы отменять транзакции или замораживать активы позже, недействительные действия отсеиваются еще до того, как они станут окончательными.
Такая архитектура задает интересный компромисс. Разделение политики и исполнения повышает адаптивность, но одновременно делает управление (governance) намного более важным. Кто утверждает обновления политики? Насколько прозрачно принимаются эти решения? Могут ли независимые участники проверить, что правило было применено справедливо, а не просто доверять реестру? По мере роста программируемых финансов, главный вопрос может уже заключаться не в том, правильно ли выполняются смарт-контракты, а в том, остаются ли политики, по которым они работают, открытыми, подотчетными и заслуживающими доверия.
@NewtonProtocol $NEWT #newt $BNB
