Я читал о том, как протокол Newton подключается к Uniswap v4, и меня затянуло в тему, о которой раньше почти не думал. Судя по всему, интеграция использует hook-архитектуру Uniswap, чтобы обеспечивать проверки на соответствие прямо в момент свопа, то есть транзакцию можно оценить по политике слоя Newton ещё до того, как ликвидность вообще коснётся её. Иногда мне кажется, что большинство людей, вовлечённых в этот проект, не до конца понимают, насколько структурно это отличается от «прикручивания» комплаенса к протоколу постфактум.
Самое интересное — размещение проверки. Hooks в Uniswap v4 выполняются в определённые моменты жизненного цикла транзакции, и Newton, похоже, использует эту точку входа, чтобы прогонять AML-логику до того, как своп завершится, а не помечать как проблему уже после. Мне кажется, что это может иметь огромное значение для организаций, которым нужна чистая прослеживаемость транзакций: комплаенс-флаг, поставленный постфактум, — это проблема, а блокирование политики до свопа — это система, работающая так, как задумано.
Вопрос, который приходит на ум, — как это ведёт себя при реальном стрессе ликвидности. Когда рынки двигаются быстро и объём транзакций резко растёт, добавление шага оценки политики внутри hook’а свопа вносит задержки и потенциальные точки отказа, которых просто нет в обычном пуле Uniswap. Снаружи я не совсем уверен, как Newton обрабатывает сценарий, когда движок политики медленный или недоступен в середине свопа, и не приводит ли это к худшему пользовательскому опыту, чем компенсирует выгода от комплаенса в такие моменты.
Бета на мейннете, вероятно, ещё не сталкивается с объёмами свопов, которые достаточно явно вскроют эти пограничные случаи. Но проектирование инфраструктуры комплаенса, которая корректно работает в масштабе, — это совершенно другая инженерная задача, чем разработка решения, которое хорошо функционирует в контролируемых условиях. В любом случае, время покажет...
@NewtonProtocol #Newt $NEWT
$LAB
$SKYAI
Самое интересное — размещение проверки. Hooks в Uniswap v4 выполняются в определённые моменты жизненного цикла транзакции, и Newton, похоже, использует эту точку входа, чтобы прогонять AML-логику до того, как своп завершится, а не помечать как проблему уже после. Мне кажется, что это может иметь огромное значение для организаций, которым нужна чистая прослеживаемость транзакций: комплаенс-флаг, поставленный постфактум, — это проблема, а блокирование политики до свопа — это система, работающая так, как задумано.
Вопрос, который приходит на ум, — как это ведёт себя при реальном стрессе ликвидности. Когда рынки двигаются быстро и объём транзакций резко растёт, добавление шага оценки политики внутри hook’а свопа вносит задержки и потенциальные точки отказа, которых просто нет в обычном пуле Uniswap. Снаружи я не совсем уверен, как Newton обрабатывает сценарий, когда движок политики медленный или недоступен в середине свопа, и не приводит ли это к худшему пользовательскому опыту, чем компенсирует выгода от комплаенса в такие моменты.
Бета на мейннете, вероятно, ещё не сталкивается с объёмами свопов, которые достаточно явно вскроют эти пограничные случаи. Но проектирование инфраструктуры комплаенса, которая корректно работает в масштабе, — это совершенно другая инженерная задача, чем разработка решения, которое хорошо функционирует в контролируемых условиях. В любом случае, время покажет...
@NewtonProtocol #Newt $NEWT
$LAB
$SKYAI