@Newton Protocol впервые привлек мое внимание, потому что его описывали как безопасный роллап для автоматизированных торговых стратегий и маркетплейс, где разработчики могут публиковать собственные агенты. Звучало амбициозно, но это также заставило меня насторожиться. Я видел много криптопроектов, которые используют автоматизацию как главный аргумент, но при этом недостаточно прорабатывают, что происходит, когда эта автоматизация ошибается.

Вопрос, который меня зацепил, был прост: если я разрешаю программному обеспечению торговать или перемещать активы за меня, как мне не дать ему делать больше, чем я задумал?

Сначала я ожидал, что Newton в основном про торговых ботов и автоматизированные стратегии портфеля. После прочтения его текущего сайта, документации, белой книги, информации о токене и публичных репозиториев я понял, что проект сместился к более широкой идее. Теперь Newton описывает себя как слой авторизации для onchain-финансов.

Сначала это изменение меня сбило с толку, потому что это не совсем то описание проекта, с которого я начинал. Ранее материалы больше говорили о верифицируемых агентах, безопасной среде выполнения, разрешениях с нулевым знанием и маркетплейсе для разработчиков. Текущие материалы фокусируются на программируемых политиках, которые проверяются до того, как выполняется onchain-транзакция. Чем больше я размышлял об этом, тем больше смысла находил в этом направлении.

Блокчейн может проверить, есть ли у транзакции действительная подпись и хватает ли у кошелька средств. Но он не может автоматически знать, нарушает ли транзакция лимит на расходы, использует ли подозрительный адрес, нарушает ли корпоративную политику или идет ли вразрез с инструкциями, данными автоматизированной стратегии.

Эти решения обычно обрабатываются веб-сайтом, частным сервером или администратором. Проблема в том, что веб-сайт можно обойти. Человек может взаимодействовать напрямую с смарт-контрактом, и другое приложение может использовать совершенно другой маршрут.

Newton пытается приблизить проверку политики к реальной транзакции. Прежде чем разрешить выполнение защищенного действия, контракт спрашивает, были ли выполнены определенные условия. Если эти условия нельзя подтвердить, транзакцию следует отклонить до того, как будут перемещены какие-либо средства.

Самое простое сравнение для меня — карточный платеж. Сеть карт не сразу проводит расчет по каждому запросу на платеж. Сначала она проверяет такие вещи, как статус счета, доступные лимиты, сигналы о мошенничестве и информацию о продавце. Newton пытается создать программируемую версию этого шага авторизации для onchain-транзакций.

Процесс начинается с политики. Разработчик или организация определяет, что должно быть истинным, прежде чем разрешить конкретное действие. Newton использует Rego — язык политик, связанный с экосистемой Open Policy Agent, — чтобы выражать эти правила. Базовая политика может запретить кошельку тратить больше фиксированной суммы в день. Более детальная политика может разрешать автоматизированную стратегию торговать только одобренными активами, использовать выбранные протоколы, оставаться ниже лимита по проскальзыванию и прекращать торговлю, когда рыночные цены выходят за приемлемый диапазон.

Когда запрашивается транзакция, операторская сеть Newton оценивает политику. Проверка может использовать информацию onchain, а также одобренные внешние данные, включая рыночные цены, сигналы риска для кошелька, статус идентичности, данные proof-of-reserve или ограничения по юрисдикции.

Если условия выполняются, сеть выдает результат, который смарт-контракт может верифицировать. Если условия не выполняются, защищенное действие не продолжается.

В документации разработчика Newton описывается как децентрализованный движок политик, построенный как активно валидационный сервис в EigenLayer. В белой книге за февраль 2026 года система представлена как слой авторизации для областей вроде стейблкоинов, токенизированных активов, институционального DeFi, платежей через границы и коммерции с участием автономных агентов.

Автоматизированная торговля — все еще полезный пример того, почему может понадобиться нечто подобное. Допустим, я хочу, чтобы автоматизированная стратегия делала ребалансировку моего портфеля. Возможно, я хочу, чтобы она торговала ETH, USDC и WBTC, но ничем больше. Я мог бы разрешить ей использовать две децентрализованные биржи, отклонять сделки выше определенного лимита по проскальзыванию и останавливать торговлю после того, как будет достигнут дневной лимит убытков.

Дать стратегии обычный доступ к кошельку может дать ей больше полномочий, чем требует задача. Политика Newton могла бы создать более узкую границу вокруг нее. Стратегия будет решать, когда проводить ребалансировку, а политика — определять, разрешена ли каждая предложенная транзакция на самом деле.

Это не означает, что Newton может превратить плохую стратегию в прибыльную. Если торговая логика плохая, идеальное следование политике не улучшит результаты. Newton главным образом интересует, оставалась ли стратегия в рамках своих инструкций.

Я нашел это различие полезным. Верификация может показать, что правила соблюдались. Она не может доказать, что сами правила были разумными изначально.

Эту же модель можно применить к onchain-сейфу. Роль куратора может быть ограничена разрешением перемещать внесенные активы между разными рынками кредитования, но вкладчикам не стоит полностью полагаться на обещание куратора следовать риск-фреймворку. Политика может ограничивать, какие рынки разрешены, устанавливать лимиты на экспозицию, требовать минимальную ликвидность или блокировать действие, когда оракульная цена меняется слишком резко. Еще один практический пример — казначейство DAO. Казначейство могло бы разрешать рутинные платежи одобренным получателям, применяя более строгие условия к необычно крупным переводам. Даже после прохождения голосования по управлению финальная транзакция все равно должна удовлетворять активной политике.

Newton также обсуждает стейблкоины и токенизированные реальные активы. В таких случаях политики могли бы проверять требования к идентификации, ограничения на переводы, информацию о санкциях, лимиты транзакций или правила юрисдикции.

Понятно, почему учреждения могут счесть это полезным. Правило комплаенса, размещенное только на веб-сайте, слабо, потому что кто-то может обойти веб-сайт. Правило, проверяемое контрактом перед каждой защищенной операцией, гораздо сложнее обойти.

В то же время эта часть Newton поднимает неприятные вопросы. Движок политик можно использовать, чтобы обеспечивать разумные лимиты безопасности, но его также можно использовать, чтобы ограничивать транзакции на основе офчейн-идентичности и информации о рисках. Некоторые сочтут это необходимым для регулируемых активов. Другие увидят в этом отход от открытого характера публичных блокчейнов.

Newton предоставляет механизм для обеспечения политик, но сам механизм не решает, является ли конкретная политика справедливой. Моё исследование основывалось на доступной документации, материалах белой книги, объявлении о токене, текущем сайте и публичных репозиториях GitHub. Я не подключал финансируемый кошелек, не разворачивал policy production, не управлял валидатором и не запускал реальную торговую стратегию через Newton.

Это ограничивает то, что я честно могу сказать о полученном опыте. Я могу изучить, как система должна работать, но я не могу подтвердить ее реальные затраты на транзакции, скорость, надежность или простоту интеграции без тестирования живой реализации.

[Добавьте детали здесь, если вы лично использовали демо, подключали кошелек, делали стейкинг NEWT, разворачивали политику или пробовали пример разработки.]

Одна вещь, которую я заметил, — это разница между более ранними и более новыми материалами Newton.

Информация о проекте за 2025 год описывала верифицируемую onchain-автоматизацию с использованием доверенных сред выполнения и доказательств с нулевым знанием. Также обсуждался Newton Model Registry, где разработчики могли перечислять модели или агентов, чтобы операторы могли их обслуживать.

Текущая версия проекта гораздо больше говорит об авторизации, комплаенсе, безопасности сейфов, стейблкоинах и токенизированных активах. Маркетплейс агентов больше не так заметен на главном сайте. Эти идеи все еще могут складываться вместе. Слой авторизации со временем мог бы стать основой безопасности для автоматизированных агентов и стратегий, созданных разработчиками. Однако Newton не объясняет эту связь так ясно, как мне хотелось бы.

Меня оставило ощущение, что проект расширил фокус, сменил направление или просто изменил способ, которым он себя представляет. Четкая шкала времени с тем, что изменилось и почему, сделала бы проект легче понять.

Роль NEWT тоже заслуживает более пристального взгляда. Согласно официальному объявлению Foundation о токене, NEWT имеет фиксированный объем в один миллиард токенов. Его первоначальный обращающийся объем был установлен на 215 миллионов, что составляет 21,5% от общего.

Анонсированное распределение отдало 60% категориям, связанным с сообществом, и 40% внутренним категориям. Внутренняя часть включала выделения для основных участников, ранних бэckеров и Magic Labs, при этом условия отдельного блокирования и вестинга были разными.

Изначально NEWT было задано четыре предполагаемые функции: стейкинг для безопасности сети, оплата комиссий протокола, участие в реестре моделей и в конечном итоге — участие в управлении (governance).

То, что я не мог четко определить, — это насколько большая часть этой полезности активна сегодня и как она сочетается с более новой дизайн-фокусировкой на авторизации. Если сейчас Newton — это в первую очередь сеть политик, я хочу знать, какие операции политики требуют NEWT, как стейкинг защищает оценку политик, кто может управлять сетью и остается ли реестр моделей активным приоритетом. Токен может иметь важное место в системе, но текущие и планируемые варианты использования стоит разделять более явно. Иначе читатели легко перепутают анонсированную функцию с тем, что уже работает.

Больше всего мне понравилась та часть Newton, которая делает акцент на проверке условий в момент, когда действие собираются совершить.

Аудит безопасности может проверить, работает ли контракт так, как задумано, но он не может предсказать каждое возможное будущее рыночное условие, сбой данных или необычную последовательность транзакций. Политики времени выполнения добавляют еще один слой: спрашивают, безопасна ли операция и разрешена ли она при текущих условиях.

Это не заменяет аудиты. Оно решает другую часть проблемы.

Мне также понравилось разделение между главным контрактом приложения и его логикой политики. Лимиты рисков и бизнес-требования меняются со временем. Если разместить каждое возможное правило навсегда внутри основного контракта, обновлять будет сложно. Отдельный слой политик может позволить менять некоторые условия без пересборки всего приложения.

Однако эта гибкость несет и собственные риски. Если один администратор сможет тайно заменить ограничивающую политику на разрешающую, децентрализованная оценка не обеспечит большой защиты. Мне хотелось бы знать, кто может обновлять политику, есть ли задержки при обновлениях, как пользователи уведомляются и остаются ли старые версии доступны для публичного просмотра.

Внешние данные — еще одно ограничение, к которому я постоянно возвращался. Newton может доказать, что политика была оценена корректно, но это не гарантирует, что информация, использованная при оценке, была точной. Если провайдер данных ошибочно помечает кошелек, политика может отклонить легитимную транзакцию. Если источник цены задержан или манипулируется, даже корректно оцененная политика может все равно привести к неправильному результату. Криптографическая верификация может доказать, как было принято решение, но она не может сделать ненадежные данные надежными.

Важна и доступность. Если операторы Newton не смогут отвечать, что произойдет с защищенным контрактом? Отклонение каждой транзакции может быть безопаснее, но это может заморозить легитимную активность. Разрешение транзакциям продолжаться без проверки политики ослабит всю модель безопасности.

Проект должен четко объяснить, как он обрабатывает простои операторов, аварийные ситуации, сбои провайдеров данных и спорные результаты по политике.

Я также хотел бы увидеть больше информации о стоимости и времени отклика. Добавление проверки авторизации для каждого чувствительного действия создает дополнительную работу. Это может быть приемлемо для крупного перевода из сейфа, но может стать дорогим или медленным для частых транзакций небольшой стоимости.

Вот где бы помогли реальные данные использования. Число активных политик, независимых операторов, защищенных контрактов, запросов на авторизацию, отклоненных транзакций, среднее время отклика и средняя стоимость рассказали бы мне больше, чем одни лишь объявления о партнерствах. После того как я провел время с проектом, мое понимание Newton изменилось. Сначала я думал, что это в основном платформа для автоматизированных торговых агентов. Теперь я вижу это как попытку определить и обеспечить границы, в рамках которых агентам, приложениям, кураторам и организациям разрешено действовать.

Это более интересная проблема, чем я ожидал изначально.

Главный вопрос не только в том, может ли автоматизированный агент принимать решения. Вопрос в том, следует ли разрешать агенту выполнять это решение в текущих обстоятельствах.

Ответ Newton — разместить программируемую политику между запросом и финальной транзакцией. Мне нравится логика такого подхода, но мне все еще нужно больше доказательств того, как это работает в реальных условиях.

Проект должен показать, что его сеть операторов действительно независима, политики можно безопасно управлять, внешние данные можно доверительно передавать (benwton trusted), а проверки авторизации достаточно доступны по цене для регулярного использования. Также нужно объяснить, как исходный маркетплейс агентов и видение роллапа связаны с продуктом, который они строят сейчас.

Я пока не готов относиться к Newton как к готовому решению. Я вижу развивающийся проект, работающий над реальным и все более сложным вопросом: когда программному обеспечению разрешают управлять onchain-ценностью, кто задает его ограничения и как эти ограничения можно обеспечить?

@NewtonProtocol #Newt $NEWT #newton #newtonprotocol