На прошлой неделе я действительно попытался использовать протокол Newton. Не просто читал документацию. Я хотел понять, работает ли эта штука с «верифицируемой автоматизацией» на самом деле, или это очередное крипто-решение, которое ищет проблему.
Вот что я нашёл.
И вот что реально сработало
Я начал с их демо. Подключил свой кошелёк, настроил простую политику: блокировать любые транзакции на сумму свыше $100, если риск-показатель кошелька высокий. Затем я попробовал смоделировать перевод.
Не прошло. Не потому, что код был неправильным. А потому что реально запустилась офчейн-проверка. Политика оценила мой кошелёк по данным о рисках Magic Labs, решила, что всё в порядке, но потом я понял кое-что.
Большинство «автоматизаций» в крипто — это просто… выполнение. Вы задаёте лимитный ордер, бот его исполняет. Вы задаёте ребаланс, он происходит. Но у вас нет доказательства, что он соблюдал ваши правила. Вы просто доверяете исполнителю.
Ньютон делает по-другому. Он доказывает, что проверка произошла до транзакции.
Почему это важнее, чем AI-хайп
Об этом все говорят: «маркетплейс AI-агентов Ньютон». Похоже, он выйдет в Q4 2025. Но сейчас это не то, что уже работает. Работает на самом деле слой политик.
Я залез в их GitHub. Они форкнули Regorus от Microsoft. Это Rust-реализация языка Rego из Open Policy Agent. Корпоративные команды инфраструктуры используют такие штуки. Это проверено боями.
Инсайт пришёл, когда я прочитал их README: «Статические аудиты подтверждают намерение, но атакующие эксплуатируют исполнение в пограничных случаях».
Подумайте об этом. Каждый крупный хак DeFi проходил аудит. Euler. Curve. Nomad. Код не был очевидно сломан. Но был неправильный контекст исполнения. Цены двигались слишком быстро. Оракулы отставали. Валидаторы были скомпрометированы.
Ньютон не предотвращает всё это. Но он меняет место, где происходит проверка. От «надеемся, что код с этим справится» к «проверяем контекст перед выполнением».
Архитектура, которая действительно имеет смысл
Я потратил время, чтобы понять, почему они сделали это именно так.
TEE выполняют оценку политик. Не потому что TEE идеальны — они не идеальны. Intel или AWS теоретически могли бы их скомпрометировать. Но TEE позволяют сделать то, что не умеет чистая криптография: доступ к реальным offchain-данным в реальном времени приватно, а затем доказать, что вы их корректно оценили.
Часть с нулевым знанием появляется потом. TEE создаёт аттестацию. Она проверяется в ончейне. Так вы получаете приватность для проверки данных и при этом публичную проверяемость того, что проверка действительно произошла.
Их Keystore Rollup не пытается быть универсальным L2. Он специально для управления разрешениями. Их называют zkPermissions. Гранулярные, отзываемые, кроссчейн.
Я всё время спрашивал: почему EigenLayer? Почему ресейк ETH, чтобы обеспечить безопасность policy engine?
Ответ — экономическая безопасность. Если операторы лгут о результатах оценок политик, их штрафуют (slashed). Ставки реальные деньги. Атаковать дорого, потому что нужно скомпрометировать и инфраструктуру TEE, И экономическую долю.
Токеномику я проверял на практике.
NEWT имеет фиксированное предложение в 1 миллиард. Ничего особенно. Но распределение интересное: 60% — сообществу, 40% — внутренним. Это более сильный перекос в сторону сообщества, чем у большинства проектов.
14-дневный кулдаун на анстейкинг раздражает, если вы пытаетесь выйти быстро. Но я понимаю, почему они так сделали. Это предотвращает флэш-атаки на набор операторов.
8,5% от предложения идёт на «Network Rewards». Это субсидирует валидаторов прямо сейчас, ещё до того, как протокол сгенерирует достаточно комиссий, чтобы их поддерживать. Классическая проблема бутстрапа.
Что реально работает против того, что это маркетинг
Вот где я начал сомневаться.
Маркетплейс AI-агентов? Не запущен. Документация об этом говорит. В дорожной карте это есть на Q4 2025. Но прямо сейчас вы строите инфраструктуру политик для будущего, которого пока ещё нет.
Я искал реальные интеграции. Magic Labs использует это для оценки рисков кошельков. Polymarket, похоже, имеет некоторую надстройку 2FA, встроенную поверх Ньютона. Но я не смог найти длинный список DeFi-протоколов, которые действительно применяют политики через Newton в продакшене.
Вот в чём риск. Вы ставите на то, что институциональный DeFi действительно хочет криптографическое доказательство соблюдения требований. Не просто проверки на фронтенде и юридические соглашения. Настоящее доказательство, которое можно аудитировать ончейн.
Они за это заплатят? Они примут задержки? Пока не знаю.
Конкуренты, с которыми никто сравнивает корректно
Gelato, Keep3r, Chainlink Keepers. Люди смешивают Newton с ними. Неправильная категория.
Это и есть выполнение автоматизаций. Newton проверяет ограничения. Другая задача.
Gelato выполнит ваш ребаланс в 2 часа ночи. Он не докажет, что ребаланс соблюдал ваши лимиты по волатильности, ваш санкционный скрининг, ваши лимиты концентрации. Он просто выполняет.
Ньютон сначала оценивает. Потом доказывает. Затем выполняет.
Компромисс — скорость. Оценка в TEE + генерация ZK-доказательства + верификация в ончейне занимают время. Это не для высокочастотного трейдинга. Для институциональных казначейств, которым нужны квитанции. Для эмитентов стейблкоинов, которым нужны доказательства соответствия требованиям. Для протоколов RWA, которым нужно подтверждение инвесторам.
Что я думаю сейчас
После того как я попробовал демо, прочитал контракты, разобрался с архитектурой, я думаю, что Newton решает реальную проблему. Но это узкая проблема. Не «сделать DeFi безопаснее» в каком-то туманном смысле.
Это вопрос: как принудительно соблюдать правила, если само правило зависит от offchain-контекста?
Списки санкций. Цены оракулов. Оценки риска кошельков. Всё это меняется. Это нельзя захардкодить. Но и нельзя доверять централизованному API, который скажет вашему контракту, что делать.
Ответ Ньютона: вычислять в TEE, криптографически подтверждать, проверять в ончейне. Это не идеально. У TEE есть допущения по доверию. Задержка реальная. Есть кривая обучения для языка политик Rego.
Но это первый подход, который я видел и который не заставляет вас выбирать между «довериться централизованному сервису» и «использовать только данные из ончейна».
Честный итог
Newton не остановит следующий хак на реэнтранси. Это проблема кода. Аудиты это ловят.
Это может остановить следующий эксплойт моста, когда кто-то заставляет валидаторов подписывать недействительные состояния. Или следующую протокольную обработку транзакций во время заморозки оракула. Или следующий казначейский контракт, который случайно нарушит лимиты концентрации на волатильных рынках.
Вопрос в том, достаточно ли протоколов вообще заботятся о проверке во время выполнения, чтобы оправдать инфраструктуру. Технология интересная. Сценарий использования реальный. Принятие пока раннее.
Я наблюдаю, кто реально интегрирует это для производственных сценариев использования. Не демо. Реальные объёмы. Тогда я пойму, стоило ли решать проблему инварианта во время выполнения именно таким способом.
