shareyouropinion

Найшёл прошлой ночью более ранний отчёт о прозрачности, который я раньше не читал, и это изменило то, как я понимаю, что такое Newton на самом деле. Newton изначально вообще не был разработан как движок соблюдения требований (compliance).

В раскрытии за октябрь 2025 года исходная задумка описывается как rollup для управления ключами (keystore rollup), созданный для управления ключами и ориентированный прежде всего на проверяемую автоматизацию и делегированную авторизацию для AI-агентов.

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

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

Keystore rollup стал фундаментом для более масштабного: для движка политик (policy engine), который определяет, какие действия могут происходить, при каких условиях и с какими аттестациями.
То, с чего всё начиналось, существенно отличается от того, что предполагалось в whitepaper, который я изначально читал.

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

То, что я ещё не проработал, — насколько текущая архитектура до сих пор несёт допущения из исходного дизайна keystore rollup, которые могут быть не оптимальными для policy engine в подходе compliance-first: было ли это чистой переработкой или расширением исходной технической основы.
#ShareYourOpinion
$EVAA $LAB
Как вы думаете, как развивалась архитектура Newton?
@NewtonProtocol $NEWT #Newt

Традиционная операционная реальность KYC/AML против разрыва ответственности в модели учётных данных Newton

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

Традиционный KYC/AML: при онбординге клиента собирают документы, сверяют с базами санкций, оценивают риск и сохраняют запись. Транзакцию выявляют постфактум: достают файл, смотрят историю, пишут отчёт и подают SAR.

Ручной документально насыщенный бумажный след аудиторы принимают. Ответственность несёт банк. Он сделал проверку. Он владеет исходом.

Модель Newton: учётные данные, выпущенные третьей стороной — KYC-провайдером, хранятся у пользователя; их оценивают операторы в TEE-изолированном окружении по политике за секунды. Полученная комплаенсом квитанция — это аудиторский след.

Скорость и автоматизация — реальны. Первый вопрос, который мой знакомый офицер комплаенса задал: кто несёт ответственность, когда Newton говорит, что учётные данные действительны, но данные эмитента оказались неверными. В модели Newton эмитент выпустил их, операторы оценили, смарт-контракт обеспечил соблюдение. Цепочка ответственности длиннее и менее понятна.

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

То, что я пока не выяснил: выполняют ли комплаенс-квитанции Newton требования регуляторной ответственности или просто подтверждают, что проверка была выполнена — и являются ли это одним и тем же.
$LAB $HMSTR #shareyouropinion
@NewtonProtocol $NEWT #Newt

программы очков и вознаграждений в DeFi создают пограничные случаи соблюдения требований; тождество Ньютона и домены соблюдения требований неясно спроектированы для решения.

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

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

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

ответа на это в текущей документации нет. пограничный случай достаточно реален, чтобы быть важным для любого DeFi-протокола, который ведет активные программы вознаграждений.
@NewtonProtocol $NEWT $LAB $HMSTR #ShareYourOpinion
#Newt #NEWT
Нужны ли проверки для вознаграждений?

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

Жизненный цикл предложения, который описывает Ньютон, имеет пять стадий. Идея — неформальное обсуждение, без формального процесса. RFC — Request for Comments (Запрос комментариев), структурированный документ, предлагающий изменения. NIP — Newton Improvement Proposal (Предложение по улучшению Ньютона), формализованная версия RFC, готовая к рассмотрению.

Обсуждение сообщества — открытый период для отзывов перед голосованием. Голосование Token House — проводится внечейн через Snapshot, где держатели NEWT голосуют за NIP.

Это весь конвейер в том виде, в каком он задуман.

То, что я упустил при первом чтении: этот конвейер существует в документе, но сам Token House — орган, который действительно голосует, — пока еще не существует как работающая структура. Сейчас в том, что документ называет «Фаза 0», решения принимает Фондовый совет. Жизненный цикл предложения — это целевое состояние, а не текущее.

Эта деталь меняет то, как я читаю любые заявления об управлении в материалах Newton.

Мне, кстати, нравится, что документ явно проводит это различие — формулировки «Фазы 0», а не расплывчатый маркетинг про управление сообществом. Редко увидишь, чтобы название проекта прямо отражало стадию его собственной текущей централизации столь непосредственно.

Что я еще не выяснил: что именно запускает переход с Фазы 0 на Фазу 1 — фиксированный ли это график, метрика децентрализации или всецело по усмотрению Фондового совета.
$TAC $LAB #ShareYourOpinion
@NewtonProtocol $NEWT #Newt

начни с малого. ИИ-агенты, генерирующие сделки в DeFi, никогда затем не являются алгоритмической торговлей в традиционных финансах, а инфраструктура комплаенса вокруг них заметно менее развита.

если отдалиться, слой политики ньютона отвечает на вопрос комплаенса на уровне транзакций: эта конкретная транзакция соответствует заданным правилам — это один из уровней того, что требует комплаенс для традиционной алгоритмической торговли.
#NEWT
слои выше — разные. комплаенс для традиционной алгоритмической торговли требует документирования модели, аудит-следов и привязки исполненных сделок к конкретным решениям модели, а также наличия возможности отключения (killswitch) и вмешательства человека, когда модель ведет себя неожиданно.
#newt

ничего из этого не обеспечивается предпродажным (pre-settlement) принуждением на уровне отдельных транзакций.

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

#ShareYourOpinion $LAB $HMSTR

@NewtonProtocol $NEWT #Newt

$BTR Binance Btr usdt Карта ликвидаций
За левую сторону в BTR short ликвидации ничего нет
Ликвидация на 100k по цене 0.5223 Время покупать
Настройка входа в лонг 🚦 0.04800
Зона тейк-профит цены 🎯 0.05000
Следующая целевая зона цены 🎯 0.05100
Последняя целевая зона цены 🎯 0.05200

#BTR #ShareBuyback #shareyouropinion

$BTC Длинный вход: настройка ценового лимитного ордера 💫

#shareyouropinion #WarshSaysInflationIsFedTopFocus

Белая книга Trustless Bitcoin Vaults (TBV) в разделе 5 делает то, что стоит отдельно отметить: в ней указан «Открытый доступ» как заявленное преимущество, но при этом описывается, что фактическим механизмом являются «разрешённые» (whitelisted) ликвидаторы — также в том же разделе.@BabylonLabs_io

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

Не утверждаю, что включение ликвидаторов в белый список неразумно. Ликвидация означает быстрое удержание и перемещение реального капитала, и проверка участников для этой роли — стандартная практика в кредитных протоколах, как onchain, так и off.

Но и не говорю, что эти два утверждения хорошо согласуются друг с другом. Преимущество называет ликвидаторов «открытыми участниками», а механизм ставит для них условие доступа. Оба утверждения не могут быть одновременно полностью истинными: «открытость» в этом пункте имеет больший вес, чем то, что подтверждает белый список.#baby

Возможное решение может быть в том, что сам белый список легко получить: если k-из-n наборов со-подписей, то вход доступен всем, тогда минимальная подготовка и «whitelisted» могли бы означать одно и то же, просто увиденное с двух разных углов. Но в белой книге никогда не объясняется, как именно ликвидатор попадает в белый список.

Так может ли любой стать ликвидатором или же «открытый доступ» заканчивается на белом списке? В разделе 5 преимущество и ограничение названы на одной странице и не связываются между собой.

$UAI $BANK
#ShareYourOpinion
#ShareYourVote

На этой неделе я вернулся и на самом деле прошёл тестнетный сценарий шаг за шагом, а не просто почитал о нём из вторых рук. Я думал, что предполагаемого просмотра гайда-видео будет достаточно, чтобы понять механику. Но нет.

Публичный тестнет для нативного заимствования биткоина с обеспечением через Aave v4, работающий на Trustless Bitcoin Vaults (TBV), позволяет вам внести тестовые BTC в вальт, посмотреть, как он верифицируется onchain, и затем занять под него — тем же способом, который описан в whitepaper: minting и lending для collBTC. Сначала я запросил тестовые токены у faucet, а потом отследил депозит через проводник (explorer) — и абстрактное «вальт верифицируется, collBTC минтится» из документации превратилось в реальную последовательность действий, а не в схему.

Для меня всё щёлкнуло только после того, как я сделал шаг с верификацией light client: он не происходит мгновенно так, как это ощущается при обычном переводе токенов. Здесь есть реальная пауза между депозитом и появлением collBTC, которые становятся пригодными к использованию.

Я правда думаю, что если пройти это самому, то дальше whitepaper читается иначе: разделы про settlement и liquidation перестают быть абстрактными диаграммами, потому что вы уже видели, как один депозит проходит через те же шаги.

Но что я ещё не выяснил: совпадает ли тайминг тестнета с тем, как это будет ощущаться на mainnet, или же инфраструктура тестнета работает быстрее/медленнее, чем при реальном развёртывании.

Есть форма обратной связи, ссылка на которую размещена рядом с приложением тестнета — стоит ей воспользоваться, если заметите что-то, что не соответствует документации.
$EUL $ON #shareyouropinion
@BabylonLabs_io $BABY #baby

Динамика власти в управлении: кто контролирует кворумные пороги, разделение комиссий, допуск операторов

Часть, о которой никто не спрашивает в управлении Newton, — это то, кто фактически контролирует параметры, которые имеют наибольшее значение.

Три трека управления: стандарты политики, допуск операторов, обновления протокола. Самое важное, чего не хватает в обсуждении, — это то, что именно эти треки реально регулируют.

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

Разделение комиссий: настраивается, устанавливается управлением и определяет экономику операторов.
Допуск операторов: регулируется рамками управления протокола и определяет, кто вообще получает комиссии.
Теперь посмотрите, кто держит NEWT.

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

Не утверждаю, что это необычно. В любом управлении proof of stake есть какая-то версия этой проблемы: валидаторы в других сетях голосуют по параметрам, которые влияют на экономику валидаторов.
#newt
И не говорю, что это обязательно недостаток. Наличие «шкуры в игре» у операторов через их холдинги NEWT может согласовать их интересы с долгосрочным здоровьем сети, а не с краткосрочной извлекаемостью.
#NEWT
То, что я пока не выяснил, — есть ли в Newton разработан какой-то конкретный механизм, который препятствует операторам совместно голосовать за снижение кворумных порогов — уменьшая собственную операционную нагрузку — так, чтобы незаметно ухудшать безопасность сети.
#shareyouropinion $HMSTR $LAB
@NewtonProtocol $NEWT #Newt

В whitepaper есть набор данных, который большинство людей пропускают: обзор 166 блокчейн-сетей. Шестнадцать из них имеют встроенную возможность заморозки активов.

Еще девятнадцать потенциально могут включить это с минимальными изменениями.

Тридцать пять сетей, где permissionless (разрешениеless) является условным.

Newton использует это, чтобы сформулировать ключевую проблему: элементы контроля на уровне UI недостаточны, но так же недостаточна и предпосылка о том, что блокчейн-«рельсы» нейтральны.

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

Ответ Newton — принуждение на уровне политик, а не на уровне протокола. Логика авторизации поддаётся аудиту в Rego. Операторский набор децентрализован. Доказательства соответствия (compliance receipts) — onchain. Это не предотвращает заморозку активов в сети, но делает решения о соответствии требованиям отделёнными от протокола и поддающимися аудиту, даже когда сама цепь не нейтральна.

Не полное решение. Нужен другой уровень подотчетности поверх этой проблемы.
#NEWT
Я правда думаю, что данные о заморозке по-новому формулируют задачу, которую решает Newton: меньше добавления комплаенса к permissionless-«рельсам» и больше — сделать комплаенс прозрачным, когда сами «рельсы» могут быть и не нейтральными.
#newt
Вопрос в том, даёт ли policy layer Newton осмысленную подотчетность, если лежащая в основе цепь сохраняет односторонние полномочия на заморозку, или же доказательство комплаенса становится несущественным, если активы всё равно можно заморозить.
#ShareYourOpinion
@NewtonProtocol $NEWT #Newt
$LAB $HMSTR

Babylon's fee routing section имеет одну конкретную строку, которую стоит прочитать дважды
Автоматизированный on-chain аукцион, где комиссии в BTC выставляются на аукцион за BABY, а победившие участники, потратившие BABY, получают программно сожжённые.

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

Это конкретное дизайнерское решение, а не общее утверждение о дефляционной токеномике. По мере роста активности Trustless Bitcoin Vaults (TBV) создаётся больше вольтов, выдаётся больше BTC-backed займов, делается больше выкупов — комиссии, генерируемые в BTC, направляются через этот аукцион, и BABY удаляется из обращения как прямом функция реального использования, а не фиксированного графика эмиссии.

Я не утверждаю, что это что-то гарантирует по стоимости токена. Сжигания, связанные с использованием, всё ещё зависят от того, что использование действительно происходит в значимых масштабах, и в whitepaper явно указано, что структуры комиссий и правила стейкинга остаются предметом активного проектирования и подлежат одобрению governance.

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

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

@BabylonLabs_io $BABY #baby
#ShareYourOpinion
$BANK
$DEXE