Я читал Ньютона с тем же вопросом, который обычно задаю для инструментов уровня vault.
Не то, что они могут делать.
Сколько старого рабочего процесса они сохраняют?
И именно там для меня VaultKit начал ощущаться иначе.
В документации описывается TypeScript SDK и сопутствующие Solidity-контракты, но то, что осталось у меня в голове, было меньше по масштабу, чем это. Куратор может продолжать использовать знакомый ему vault-flow, при этом каждое действие оборачивается в «клон» Shield и отправляется через проверку (attestation) политики Newton до того, как vault выполнит вызов.
Это очень специфический тип дизайна.
Здесь не пытаются ради самой новизны сделать управление vault «новым». Цель — усложнить ошибку, не заставляя команды перестраивать весь свой стек.
Думаю, в этом и заключается главный конфликт.
В DeFi vault’ах, особенно там, где задействован институциональный капитал, проблема редко сводится только к правилу на бумаге. Самая сложная часть — гарантировать, что это правило действительно выполняется каждый раз, когда vault совершает движение. Newton пытается перенести обещание с уровня куратора прямо в сам путь выполнения.
Вот почему workflow так важен.
Система использует детерминированные клоны на уровне каждого куратора через ShieldFactory, а Newton утверждает, что слой политик работает в режиме mainnet beta. Так что это не просто удачная идея, которая сидит в посте в блоге. Это workflow, построенный вокруг gate, который стоит перед тем, как vault начнёт действовать.
Но при этом всё равно есть компромисс.
Низкое трение — это хорошо только если менеджеры достаточно доверяют маршруту attestation, чтобы использовать его. Если workflow кажется тяжёлым или gate ощущается как дополнительная накладная нагрузка, люди будут держаться за то, что уже знают.
Вот за этой частью я бы и следил.
Не за тем, звучит ли compliance для vault’ов хорошо.
А за тем, делает ли VaultKit compliance похожим на улучшение workflow, а не на налог за workflow.
Это самый аккуратный способ, которым я могу прочитать Ньютона здесь. Вопрос не в том, должны ли менеджеры vault иметь правила. Вопрос в том, могут ли эти правила жить внутри того же потока, которым они уже пользуются, не превращая каждое движение в новый процесс, через который нужно протискиваться.
@NewtonProtocol #newt $NEWT
Не то, что они могут делать.
Сколько старого рабочего процесса они сохраняют?
И именно там для меня VaultKit начал ощущаться иначе.
В документации описывается TypeScript SDK и сопутствующие Solidity-контракты, но то, что осталось у меня в голове, было меньше по масштабу, чем это. Куратор может продолжать использовать знакомый ему vault-flow, при этом каждое действие оборачивается в «клон» Shield и отправляется через проверку (attestation) политики Newton до того, как vault выполнит вызов.
Это очень специфический тип дизайна.
Здесь не пытаются ради самой новизны сделать управление vault «новым». Цель — усложнить ошибку, не заставляя команды перестраивать весь свой стек.
Думаю, в этом и заключается главный конфликт.
В DeFi vault’ах, особенно там, где задействован институциональный капитал, проблема редко сводится только к правилу на бумаге. Самая сложная часть — гарантировать, что это правило действительно выполняется каждый раз, когда vault совершает движение. Newton пытается перенести обещание с уровня куратора прямо в сам путь выполнения.
Вот почему workflow так важен.
Система использует детерминированные клоны на уровне каждого куратора через ShieldFactory, а Newton утверждает, что слой политик работает в режиме mainnet beta. Так что это не просто удачная идея, которая сидит в посте в блоге. Это workflow, построенный вокруг gate, который стоит перед тем, как vault начнёт действовать.
Но при этом всё равно есть компромисс.
Низкое трение — это хорошо только если менеджеры достаточно доверяют маршруту attestation, чтобы использовать его. Если workflow кажется тяжёлым или gate ощущается как дополнительная накладная нагрузка, люди будут держаться за то, что уже знают.
Вот за этой частью я бы и следил.
Не за тем, звучит ли compliance для vault’ов хорошо.
А за тем, делает ли VaultKit compliance похожим на улучшение workflow, а не на налог за workflow.
Это самый аккуратный способ, которым я могу прочитать Ньютона здесь. Вопрос не в том, должны ли менеджеры vault иметь правила. Вопрос в том, могут ли эти правила жить внутри того же потока, которым они уже пользуются, не превращая каждое движение в новый процесс, через который нужно протискиваться.
@NewtonProtocol #newt $NEWT