Sattar Chaqer

Добро пожаловать

Я всё чаще замечаю, что onchain-«vault» (хранилища) перемещают капитал onchain гораздо быстрее, чем меняются правила вокруг этого капитала.

«Vault» может хранить активы onchain, ребалансировать позиции и маршрутизировать средства между рынками, при этом фактический мандат всё ещё живёт в документах управления, инструкциях казначейству или playbook’ах аллокатора. Активы программируемы, но правила часто остаются операционными рекомендациями для менеджера.

Именно поэтому модель vault от Newton выделяется для меня.

Вместо того чтобы относиться к правилам vault как к offchain-инструкциям, Newton приближает их к самой транзакции. Ребаланс, изменение комиссии за пределы (cap change fee adjustment) или включение рынка можно проверить на соответствие политике ещё до того, как это попадёт в vault. Если действие соответствует мандату — оно выполняется. Если нет — на этом всё и останавливается.

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

action в vault выполняется только если правила соблюдены.

@NewtonProtocol $NEWT #Newt $EVAA $KAITO

Я просто хочу искренне поблагодарить Binance Square за эти награды 🤍

Со временем я присоединялся к разным кампаниям: проводил часы, читая, писая, редактируя, публикуя и иногда даже сомневаясь, стоит ли это усилий. Поэтому видеть, как награды приходят из кампаний вроде GENIUS OpenLedger SIGN NIGHT и XPL, — правда очень приятно.

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

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

Такие небольшие моменты действительно напоминают мне, что важна стабильность.

Спасибо, Binance Square. 🙏

#BinanceSquare #creatorpad #Binance @Binance Square Official

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

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

Но финансовым системам обычно нужен второй тест.

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

Для меня это один из самых ясных способов понять протокол.

Newton не заменяет расчёты блокчейна. Он добавляет слой перед расчётами, который задаёт другой вопрос — не только «может ли эта транзакция выполниться», но и «разрешена ли эта транзакция фактически в соответствии с правилами, которые к ней привязаны?»

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

@NewtonProtocol $NEWT #Newt $TAC $LAB

#BinanceTurns9 Binance исполняется 9 — создавайте вместе

2,1 года на Binance, и путешествие становится только лучше. С 9-й годовщиной платформу, которая никогда не перестаёт строить!

То, что особенно выделяется во мне в Ньютоне, это то, что он рассматривает авторизацию как реальный транзакционный процесс, а не как нечто туманное вроде шага «одобрения» где-то до расчетов. В обычном ончейн-процессе пользователь подписывает транзакцию, отправляет её в блокчейн, а сеть проверяет, действительна ли она в рамках правил протокола. Если всё проходит, выполняется, а записи расчетов фиксируют результат. Основная логика сосредоточена на уровне выполнения. Ньютон добавляет ещё один слой в жизненный цикл. Транзакция не движется напрямую от пользовательского намерения к расчетам. Сначала она проходит через процесс авторизации: действие предлагается, оценивается на соответствие политике, согласованной сетью, превращается в подписанный результат и затем снова проверяется до того, как выполнение будет разрешено. Эта последовательность важна, потому что она придаёт авторизации реальную структуру. Предлагаемое действие входит как намерение (intent). Затем это намерение проходит оценку относительно соответствующих правил. Сеть достигает консенсуса относительно исхода. Результат становится подписанным подтверждением. После этого механизм принуждения (enforcement) решает, может ли транзакция быть выполнена. Интересно, что Ньютон говорит не только о том, что транзакции нужно проверять прежде чем значение начнёт двигаться. Он определяет, как именно происходит эта проверка и как выглядит результат этого процесса до того, как вообще начнутся расчеты. Благодаря этому авторизация воспринимается не просто как общий тезис о соблюдении требований (compliance), а как инфраструктура со своим собственным рабочим процессом внутри жизненного цикла транзакции.

@NewtonProtocol $NEWT #Newt $TLM $VANRY

Что Ньютон добавляет onchain?

Всем добро пожаловать

Всем добро пожаловать

Одна вещь, которая выделяется для меня в onchain-финансах, — это то, как часто комплаенс описывают как процесс, а не как доказанный результат. Платформа говорит, что она отсканировала кошелёк. Менеджер сейфа заявляет, что он выполнил мандат. Протокол утверждает, что он проверил соответствующие правила перед тем, как разрешить действие. В каждом случае пользователя всё равно просят довериться тому, что нужные контроли существовали где-то в рамках рабочего процесса. Вот к чему я снова и снова возвращаюсь. Обещание комплаенса сообщает вам о том, что говорит команда: что произошло. Оно не обязательно доказывает, что правило действительно было применено к транзакции, которая передвинула стоимость. Подход Ньютона ощущается иначе, потому что он приближает комплаенс к самой транзакции. Вместо того чтобы просто говорить, что проверки были выполнены, Newton создан так, чтобы выдать подписанный результат авторизации, привязанный к конкретному намерению транзакции до выполнения. Иными словами, система не только описывает контроли вокруг транзакции. Она создаёт верифицируемую запись того, что политика была оценена до того, как стоимость переместилась. Эта разница важнее, чем может показаться. Обычно обещание живёт в процессном документе, внутреннем рабочем процессе или на дэшборде. Чек/квитанция живёт намного ближе к реальному пути транзакции. Она становится доказательством того, что транзакцию проверили по заданной политике в заданный момент. Для меня именно это — ключевой сдвиг, который делает Newton. Он переводит комплаенс из того, что «платформа заявляет, что сделала», в то, что инфраструктура действительно может показать. И в системе, построенной вокруг перемещения стоимости без требования доверия, это выглядит как гораздо более жёсткий стандарт, чем просто «мы провели проверки».

@NewtonProtocol $NEWT #Newt $LAB $VANRY

Что важнее всего в комплаенсе?

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

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

Чем больше я смотрю на архитектуру Newton, тем больше я думаю, что такое разделение — структурная слабость.

Важно не только то, проверила ли платформа пользователя раньше по маршруту. Важно, может ли транзакция оценить релевантные условия пользователя в момент, когда она вот-вот будет выполнена. Именно этот сдвиг я вижу в Identity Oracle от Newton.

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

Это меняет роль этих проверок внутри onchain-финансов.

Они перестают быть просто «воротами» для приложения.

Они становятся частью решения по транзакции.

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

Это делает модель намного более полезной.

Не потому, что это превращает крипто в систему идентификации.

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

@NewtonProtocol $NEWT #Newt $HMSTR $LAB

Где условия доступности пользователя должны значить больше всего в on-chain финансах?

Давай, займём его

Я всё ещё замечаю, что криптоприложения путают ограничения интерфейса с реальным исполнением. Фронтенд может скрыть кнопку, заблокировать регион или запретить кошельку использовать функцию. На поверхности это выглядит как соблюдение требований. Пользователь видит ограничение, а приложение может указать на видимый слой управления, и продукт может сказать, что у него есть проверки. Но всё это не означает, что сама по себе транзакция действительно регулируется. Если смарт-контракт всё ещё можно вызвать напрямую, то правило по сути не находится там, где движется ценность. Оно живёт на уровне приложения поверх контракта. Это может уменьшить случайные злоупотребления, но не создаёт реальное принуждение на уровне транзакций.

Это слабое место, которое пытается решить Newton. В логике Newton соответствие требованиям не должно зависеть от того, остаётся ли пользователь внутри одобренного интерфейса. Оно должно применяться до расчётов — в тот момент, когда транзакция авторизуется. Именно поэтому для меня важна интеграция Persona. Дело не только в том, чтобы подтвердить личность или место проживания. Важно взять эти атрибуты и использовать их прямо в пути авторизации, чтобы транзакцию можно было оценить до выполнения, а не просто отфильтровать на фронтенде.

И это полностью меняет стандарт. Контроль только на фронтенде говорит: «Мы попытались остановить это действие в приложении». Контроль на уровне транзакций говорит: «Это действие не может выполниться, пока не удовлетворит политике». Это гораздо более сильное утверждение.

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

@NewtonProtocol $NEWT #Newt $TLM $ARPA
Где именно должно обеспечиваться соблюдение требований в крипто?

Я всё чаще замечаю, что комплаенс в крипто по-прежнему воспринимают как бумажную процедуру вокруг транзакции, а не как логику, встроенную прямо в саму транзакцию.

Эта модель имела смысл в более старых финансовых системах, где ограничения на одобрения и проверки могли находиться в отдельных операционных слоях. Но ончейн-финансы работают иначе. Смарт-контракты исполняются автоматически, ценность переводится быстро, и транзакции не «замирают», чтобы команда комплаенса вручную интерпретировала политику постфактум.

Если расчёты уже программируемы, то комплаенс, вероятно, тоже должен стать программируемым.

И именно это я нахожу особенно интересным в Newton Protocol.

Newton не рассматривает комплаенс как внешнюю чек-лист-проверку, прикреплённую к транзакции. Он превращает политику в то, что система может оценивать до исполнения. Используя policy as code с инструментами вроде Rego и Open Policy Agent, правила транзакций можно записывать как машинно-читаемую логику — вместо того, чтобы прятать их в PDF внутренних процедурах или «зашивать» в жёсткую логику продукта.

Это полностью меняет роль комплаенса.

Лимит на перевод становится программируемой логикой.

Ограничение по юрисдикции становится программируемой логикой.

Требование к допустимости инвестора становится программируемой логикой.

Проверка санкций становится программируемой логикой.

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

Для меня это и есть главный сдвиг, который продвигает Newton.

Смарт-контракты сделали расчёты программируемыми.

Newton пытается сделать то же самое для политики.

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

@NewtonProtocol $NEWT #Newt $M $US

Что является самым большим узким местом для комплаентного ончейн-финансирования?