Rokyo

Мне хотелось понять, какой именно доступ dApp получает от «Connect Wallet», поэтому я проверил реальный сценарий на Dario и Pieswap в Dusk testnet. В обоих случаях при первом подключении возвращались только profile ID и общедоступный аккаунт. Всплывающее окно было прямым: «Сайт сможет использовать только публичный аккаунт выбранного профиля». Только когда я запросил защищённый адрес получения (shielded receive address), появлялся второй шаг согласия, и только тогда в ответе появлялся shieldedAddress. Также изменялось само всплывающее окно — в нём упоминался «подлежащий распространению защищённый адрес получения». Обе интеграции показали одну и ту же последовательность.

Перевёрнутый вывод: я воспринимал «Connect Wallet» как одно событие предоставления разрешения. Это не так. В контролируемом тесте доступ к публичному аккаунту был отделён от передачи защищённого адреса получения именно в момент согласия.

Это разделение переносит часть границы минимального раскрытия в сам сценарий согласия кошелька, а не полностью оставляет её пользователю на управление. В обоих тестах нажатие «Connect» само по себе никогда не выдавало область (scope) защищённого адреса; dApp должен был пройти отдельный шаг согласия, чтобы получить её.

Я ещё один момент неправильно понял при исследовании. Я думал, что строка аккаунта длиной 132 символа может намекать на защищённый доступ. Нет. Оба dApp возвращали одинаковый формат аккаунта на базовом уровне, при этом shieldedAddress оставался отсутствующим, пока не был сделан явный запрос.

Остался один вопрос без ответа. Ранее сессия на Dario mainnet вела себя иначе, но я не смог воспроизвести это при тех же контролируемых условиях, так что я не называю это утечкой. Я могу лишь сказать, что граница разрешения «только публичное» сохранялась в двух проверенных интеграциях на testnet, но не утверждать, что она гарантирована для любой среды.

«Подключение кошелька должно показывать область, которую вы одобрили, а не заставлять вас догадываться».

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

#dusk $DUSK @Dusk

Я предположил, что если я хочу сделать три действия в сети — одобрить, обменять, а затем застейкать, — то блокчейн будет считать это одним действием или не считать вовсе. Открытый issue в репозитории Rusk от Dusk говорит, что сегодня это работает иначе.

Транзакция Dusk сегодня несёт одну единственную необязательную операцию: один вызов контракта, один deploy или одну memo — с одним значением, одним получателем, одним nonce и одной подписью. Поэтому approve, swap и stake превращаются в три отдельных транзакции, каждая из которых независимо может быть включена или отброшена. Issue Dusk формулирует это прямо: нет гарантии атомарности между ними. Одобрил и обменял, но не застейкал — и ты остаёшься посередине процесса без отката на уровне протокола.

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

Контракт batcher делает всю последовательность атомарной, потому что неудачный sub-call откатывает внешнюю транзакцию. Но контракт-цель, который проверяет, кто вызывает его напрямую, увидит batcher, а не тебя — если только сам этот контракт не написан так, чтобы смотреть дальше непосредственного вызывающего. Протокольная batch-транзакция сохраняет тебя как вызывающего на каждом шаге, но она не появляется без нового формата транзакций, изменений в консенсусе, хардфорка и обновлений в каждом wallet SDK.

Добавление batching не убирает компромисс. Оно решает, где лежит бремя совместимости — в авторизации приложений или в стеке протокола.

«Исправление атомарности не убирает компромисс; оно определяет, куда перемещаются бремя совместимости и граница доверия».

За чем я бы на самом деле хотел наблюдать: выбирает ли Dusk batcher на уровне приложения или транзакцию на уровне протокола, и какие существующие предположения об авторизации вынуждает сделать этот выбор разработчиков.

#dusk $DUSK @Dusk

Я предположил, что смысл транзакции зафиксирован в тот момент, когда появились её байты: декодируешь один раз — и везде получаешь одинаковый результат. Собственный changelog Dusk для обновления Boreas по сути рассматривает это как нечто, что нужно специально спроектировать, а не просто считать по умолчанию.

Boreas добавила декодирование транзакций с учётом версии, привязанное к конкретному хардфорку, а также выбор формата, управляемый хардфорком: именно так определяется, как переигрываются старые блоки. В кодовой базе теперь явно разделены два типа — CanonicalTransaction и LedgerTransaction: они разводят представление транзакции в памяти и тот формат, в котором она реально сохраняется в реестре. Есть даже отдельный регрессионный тест, предназначенный исключительно для корректного декодирования транзакций до эпохи Aegis во время сериализации блоков.

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

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

«Транзакция надёжна только в том случае, если каждая стадия, которая с ней работает, согласна с тем, что она означает».

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

#dusk $DUSK @Dusk

Я предположил, что «DuskEVM поддерживает Solidity», значит разработчики смогут прийти с уже готовыми инструментами для Ethereum и просто закончить дело. Собственные материалы для быстрого старта Dusk незаметно добавляют шаг, который многие пропускают: верификацию исходников.

Развертывание — это простая часть. DuskEVM использует Blockscout в качестве обозревателя, и чтобы верифицировать там контракт, «Verify & Publish» означает, что нужно воспроизвести байткод, который фактически развернут: соответствующие настройки сборки, версию компилятора, конфигурацию оптимизации, исходные файлы, аргументы конструктора.

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

А значит, «EVM-совместимый» и «готовый для разработчиков» — не совсем одно и то же. Первое про то, будет ли ваш код работать здесь. Второе — про то, сможет ли аудитор, организация или пользователь реально подтвердить, что запущенное совпадает с заявленным.

«Цепочка может выполнять ваш Solidity-контракт и при этом оставить вас без возможности доказать, что это за контракт на самом деле».

Что хотелось бы увидеть дальше: можно ли надежно верифицировать контракт, развернутый по стандартному пути Solidity/Hardhat, сопоставив его с развернутым байткодом, а не просто проверив, что он успешно развернулся.

#dusk $DUSK @Dusk

Я предположил, что фракционирование — это большая часть истории ликвидности: дробишь актив на более мелкие доли, и круг потенциальных владельцев расширяется. Собственное письмо Dusk о токенизации для МСП, опубликованное на этой неделе, утверждает, что это лишь ограниченная часть картины, а независимое академическое исследование реальных токенизированных активов показывает, почему этот разрыв имеет значение.

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

В исследовании 2023 года, опубликованном в Financial Innovation, было проверено нечто близкое к этому на реальных 58 токенизированных жилых объектах в США. По владению результаты были однозначными: в среднем у объекта было 254 отдельных владельца. Но по торговле картина была иной. Владение переходило из рук в руки примерно раз в год в среднем; при этом объекты на децентрализованных биржах оборачивались чаще, чем те, что торговались peer-to-peer, хотя в любом случае годовая базовая величина оставалась низкой.

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

«Меньшая единица может расширить круг тех, кому разрешено владеть чем-то, не создавая рынок, где они в действительности могут это торговать».

Что я бы отслеживал в активах, связанных с NPEX, которые появятся у Dusk: не то, насколько мелко они дробятся при выпуске, а то, сохраняются ли торги на вторичном рынке после этого — тот же разрыв между широкой структурой владения и активной торговлей, который выявило исследование по 58 объектам.

#dusk $DUSK @Dusk

Я предположил, что взлом моста означал: кто-то нашёл ошибку в коде, уязвимость в криптографии, нечто, что не заметили в ходе проверки безопасности. Однако собственное послесловие Dusk о январском инциденте с мостом описывает совсем другое.

16 января злоумышленник скомпрометировал кошелёк для подписи, используемый мостом Dusk-to-EVM: он переместил средства непосредственно на Dusk, а часть из них далее направил на BNB Smart Chain. Dusk остановил работу моста по ходу атаки — из‑за этого не удалось выполнить финальную попытку перевода примерно 8,9 млн DUSK.

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

Последующий редизайн сводится к одной фразе, спрятанной в послесловии: "ingestion is no longer equivalent to spending." Поскольку раньше само событие и наличие полномочий для выпуска средств из‑за него были одним и тем же шагом, теперь это не так. Поступление событий переводится в контрольные точки и ставится в очередь как задание; отдельный, явный процесс действительно перемещает средства.

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

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

#dusk $DUSK @Dusk

Я предположил, что фиксированная ставка по кредиту TermMax означает одно число: сколько бы ты ни взял, именно эту фиксированную сумму ты в итоге и отдаёшь обратно. Но это не вся картина.

Вот как это работает. Когда заёмщик берёт кредит, он получает долговые токены и может погасить долг, вернув ровно ту же номинальную стоимость. Но TermMax также позволяет выкупать FT — токен, представляющий тот же долг, — на открытом рынке. До погашения FT может торговаться ниже номинала, и в примере TermMax показано, как это может снизить стоимость погашения. В том примере заёмщик, который должен 800 FT, может выкупить их по $0.80 за штуку и урегулировать долг за $640, вместо того чтобы возвращать $800 напрямую. То же обязательство, две разные цены, чтобы его закрыть.

Это не погрешность округления. Это разрыв в 20% между суммой по контракту и тем, во сколько на самом деле может обойтись закрытие позиции — в зависимости от того, где в конкретный день торгуется FT.

Что это раскрывает: один и тот же токен FT одновременно является фиксированным требованием кредитора по процентному инструменту, удерживаемому до погашения, и инструментом заёмщика для досрочного урегулирования долга. Долг — это не число, которое «стоит на месте» между выдачей и погашением. У него может быть рыночная цена до погашения, и эта рыночная цена может двигаться независимо от ставки, указанной при выдаче.

Оговорка, которую стоит назвать: в собственной документации TermMax фигурирует эта цифра 20% как проработанный пример, а не как гарантированное рыночное условие. Реальный дисконт по FT меняется в зависимости от рыночной конъюнктуры и не всегда будет таким широким.

Так какое число должно фактически определять «кредит с фиксированной ставкой»: ставка, которую ты зафиксировал при выдаче, или рыночная цена инструмента, который тебе нужно купить, чтобы закрыть позицию?

#termmax @TermMax

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

Ликвидация запускается, когда показатель LTV по займу превышает порог LLTV, или когда заемщик пропускает платеж по фиксированному сроку погашения, после чего открывается двухчасовое окно для ликвидации. Однако в сам механизм встроен лимит: если непогашенный долг превышает $10,000, ликвидатор может ликвидировать только до 50% от общей стоимости долга в рамках этого прохода.

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

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

Размер позиции влияет не только на то, насколько много находится под риском. Он также может влиять на то, сможет ли процесс ликвидации полностью разрешить позицию в пределах доступного окна.

Так стоит ли оценивать эффективность ликвидации по тому, появился ли ликвидатор, или по тому, сколько из позиции механизм способен реально урегулировать до закрытия окна?

#termmax @TermMax

Ответы KYC для тех, кто прошёл отбор при онбординге. Контроль переводов — это ответ на вопрос, остаётся ли участник подходящим, когда актив перемещается. Модель рыночной инфраструктуры Dusk рассматривает это как отдельные этапы, и именно этот разрыв самое интересное.

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

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

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

"Прохождение проверки соответствия и сохранение допустимости — это два разных утверждения."

Это меняет фактический вопрос оценки. Не "есть ли у этого актива проверки допустимости". Реальный вопрос — применяется ли текущее состояние допустимости, когда актив перемещается, или же исходный статус онбординга просто переносится дальше.

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

#dusk $DUSK @Dusk

Я предположил, что «рынок с фиксированной ставкой» означает одну ставку: вы знаете значение до того, как совершите сделку, точка. Если присмотреться к тому, как TermMax на самом деле ценообразует заем, это предположение не подтверждается.

Ставки не объявляются одним числом. Они задаются через кривые. В диапазонном ордере Lending Range Order кривая может начинаться с более низкой ставки и повышаться по мере того, как исполняется больше объема ордера — примерно так же, как AMM проходит разные уровни цен вместо того, чтобы предлагать одну фиксированную цену. Рынок может одновременно удерживать несколько диапазонных ордеров, поэтому разные участники могут закрывать позиции в разных точках кривой.

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

Кривая задается не наугад и во время исполнения. Действия куратора встраиваются в ограничения протокола, такие как разрешенные (whitelisted) рынки и изменения с временной блокировкой.

Поэтому, когда TermMax называет это «рынком с фиксированной ставкой», интересный вопрос заключается не просто в том, какая именно фиксированная ставка? Важно: какая часть этой ставки определяется кривой и какая — тем, где именно фактически исполнится ваша ликвидность?

#termmax @TermMax

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

Zedger — нативный протокол приватности Dusk — может обеспечивать полную анонимность. Hedger, созданный для DuskEVM, — не может. Dusk говорит об этом прямо: модель счетов EVM не позволяет обеспечить полную анонимность, тогда как Hedger сохраняет детали транзакций зашифрованными с помощью гомоморфного шифрования и доказательств с нулевым разглашением, но без той же гарантии полной анонимности.

Это не баг, который Dusk скрывает. Это компромисс, который архитектура делает явным: совместимость с EVM предполагает другой уровень гарантии приватности, чем полная анонимность у Zedger.

Вот что на самом деле меняется, когда этот компромисс принимается. Важное различие — не просто в том, шифруются ли детали транзакций. Различие в гарантии анонимности. Выбираете путь Zedger — и доступна полная анонимность. Выбираете совместимый с EVM путь Hedger — и та же гарантия недоступна. Один и тот же бренд, то же слово «конфиденциальный», но гарантия «под капотом» разная.

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

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

Что я бы на самом деле хотел увидеть: какой путь приватности реально использует регулируемая ценная бумага внутри Dusk Trade и какие требования к тому рабочему процессу заставляют данный путь сохранять скрытым.

#dusk $DUSK @Dusk

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

Официальные документы оператора Dusk разделяют это на две части.

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

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

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

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

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

#dusk $DUSK @Dusk

Я предположил, что зафиксированная позиция на строго определённый срок означает ровно это: зафиксирована и точка, до погашения. Затем я нашёл Smart Unwind от TermMax и предположил, что он просто решает эту проблему. Но он работает не так, как я ожидал.

Smart Unwind не «вытягивает» ликвидность выхода из пула. Он работает иначе: делает вашу позицию достаточно привлекательной, чтобы кто-то другой захотел забрать её у вас. Леверэйжер устанавливает целевую APR или цену. Если залог достаточно вырастает в цене, арбитражник покупает вашу позицию по этой фиксированной цене и продаёт залог на открытом рынке с прибылью. Если ставки по заимствованиям растут, новый леверэйжер может перехватить позицию с премией, вместо того чтобы открывать новую.

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

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

Smart Unwind также ещё не запущен в режиме реального времени, так что пока ничто из этого не наблюдается; это лишь то, что подразумевает дизайн.

Механизм выхода, который зависит от чьей-то мотивации, действительно решает неликвидность позиций с фиксированным сроком, или он просто переносит ту же проблему на того, кого нужно будет найти на другой стороне?

#termmax @TermMax

Я посмотрел за ярлык TermMax «кредитование по фиксированной ставке», чтобы понять, что происходит на самом деле.

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

В январе та же модель с фиксированной ставкой вышла за рамки крипто-нативного обеспечения и распространилась на токенизированные ценные бумаги: были запущены заимствования под фиксированную ставку на базе токенизированных акций Ondo Global Markets.

Фиксированная ставка убирает неопределенность по ставке на срок. Она не убирает необходимость рефинансирования, когда срок заканчивается. У TermMax уже есть однокликовый ролловер — либо на более позднюю фиксированную дату погашения, либо в рынки с переменной ставкой Morpho, поэтому протокол явно предусмотрел этот шаг рефинансирования. Хорошо задокументировано, как устроена архитектура; дефицит данных в том, как по этому пути работает система, когда под стрессом одновременно нужно «прокатывать» много позиций.

При $90M+ TVL на 10 EVM-цепочках и TGE токена $TMX, назначенном на 25 августа, именно это я бы стал отслеживать дальше.

#termmax @TermMax

Я ожидал, что «проверки соответствия» за Dusk Trade окажутся чем-то, специально созданным для трейдинга. Модуль комплаенса, «прикрученный» поверх слоя биржи — так, как большинство брокеров встраивают KYC прямо в платформу.

Но дело обстоит не так.

Слой идентификации, на который опирается Dusk Trade, называется Citadel, и он не начинался как торговая функция. Dusk запустила его в январе 2023 года как протокол KYC/идентификации с нулевым разглашением: вы доказываете, что у вас есть действительный аттестат, не раскрывая содержимое, а затем используете это доказательство в разных сервисах вместо того, чтобы каждый раз заново отправлять свои данные.

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

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

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

Что бы я на самом деле хотел увидеть: один и тот же аттестат, подтверждённый через Citadel и принятый другим провайдером услуг за пределами Dusk Trade — те самые свидетельства, которые превращают «общий примитив идентичности» из архитектурного описания в продемонстрированное повторное использование между сервисами.

#dusk $DUSK @Dusk

Я ожидал, что «Dusk партнерится с Chainlink» означает стандартный питч: мост. Токены перемещаются между цепочками. Обычная история про интероперабельность, которую в итоге объявляет практически каждый проект.

Но это лишь меньшая часть.

Сделка, объявленная еще в ноябре, объединяет Chainlink CCIP как слой интероперабельности для токенизированных ценных бумаг NPEX с чем-то, мимо чего легко проскочить: Chainlink DataLink становится эксклюзивным on-chain дата-оракулом для NPEX. Не одним из нескольких прайс-фидов. А единственным. То же соглашение также позволяет самой DUSK нативно перемещаться между Ethereum и Solana через стандарт Chainlink CCT — так что токен получает и «историю про мост».

Девять месяцев спустя, именно это и стоит выделить отдельно. CCIP позволяет активу перемещаться между экосистемами. DataLink поставляет рыночные данные NPEX, на которые принимающая система может положиться. Одна история — про охват. Другая — про то, кому позволено быть «доверенным». Любая цепочка, которая потребляет эти данные NPEX, строится на том же официальном источнике рыночной информации.

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

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

А что бы я на самом деле хотел выяснить через девять месяцев: что произойдет в других сетях, если этот эксклюзивный источник данных NPEX станет недоступен или ему начнут спорить, и подразумевает ли «композабельность» тихо и незаметно «зависимость от одной эксклюзивной линии обратно к NPEX».

#dusk $DUSK @Dusk

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

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

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

Вот где все становится условным. В собственном сравнении Dusk говорится, что нативная эмиссия может снижать зависимость от отдельных уровней хранения и реестра — «в зависимости от правовой структуры». Этот оговорочный момент делает большую часть работы в этом тезисе. Аргумент про эффективность не про то, что технология существует. Он зависит от того, позволит ли на деле правовая структура ончейной записи нести этот вес, а не оставаться просто еще одной копией «реальной» версии.

«Токен, который представляет актив, и актив, который существует как токен, — это две разные сделки, даже когда оба продаются как токенизация».

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

#dusk $DUSK @Dusk

Я поймал себя на том, что смотрю на тестнет-эксплорер DuskEVM, и число, которое бросается в глаза — 845,113 транзакций против 282 адресов кошельков — почти наверняка не то, на чем стоит сосредоточиться. Это примерно 3,000 транзакций на адрес, соотношение, которое говорит меньше об уровне принятия, чем заголовок намекает.

Две самые последние транзакции показали Value 0 DUSK: комиссии были уплачены, но собственная стоимость не перемещалась. Последняя запись была помечена как L1→L2 deposit. Это не доказательство того, как выглядят остальные 845K, но достаточно, чтобы заставить меня перестать воспринимать это как одно число. То, что эксплорер показывает в первую очередь, — это сетевая активность: цепочка обрабатывает транзакции. То, является ли эта активность экономической, и происходит ли реальная передача стоимости по какой-то причине, — отдельный вопрос, на который само по себе число транзакций не отвечает.

Эта разница важна, потому что в конечном итоге Dusk позиционирует эту инфраструктуру для регулируемых финансовых активов — и именно то, что в перспективе должно будет подтвердить план Dusk по выводу на чейн €300M активов NPEX. Активная сеть и сеть, несущая реальный объем расчетов, могут дать одинаково выглядящую страницу статистики.

«Сетевая активность — это не то же самое, что финансовая активность, даже если на эксплорере оба показателя сводятся в одно число».

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

#dusk $DUSK @Dusk

Собственный разбор Dusk о Hedger: генерация клиентского доказательства занимает меньше 2 секунд. Прочитал это дважды, прежде чем это осозналось. Это достаточно быстрое, чтобы фраза «confidential должно быть медленнее» перестала ощущаться безопасным предположением. Я пошёл копать, что именно доказывается так быстро. Публичная тестовая сеть DuskEVM работает с декабря, а несколько дней назад Фонд Dusk открыл её для тестирования на Solidity и Hardhat — это обновление я, собственно, и читал. Фраза, которая меня остановила: «пригодность проверяется до доступа или передачи». Сначала я думал, что это самая интересная часть по соответствию. Оставил открытым в одной вкладке, пока сходил за кофе, вернулся, перечитал и понял, что нет. Dusk говорит, что данные участников, балансы и суммы переводов могут оставаться зашифрованными. Вот что меня действительно зацепило — разрыв между доказательством того, что вам разрешено, и тем, что именно вы раскрываете, когда уже имеете право. Шаг проверки пригодности описан в документации — он чётко определён, а не просто расплывчатое заявление о комплаенсе. Но я всё равно не смог найти конкретный пример того, что именно видит авторизованный ревьюер, когда используется этот путь аудита. Проверял документацию дважды. Спустя несколько дней после открытия для Solidity/Hardhat стало интересно: появляется ли этот пример по мере того, как всё созревает, или слово «auditable» просто остаётся словом, которое пока никому не нужно демонстрировать — здесь или в любой другой сети, где делают то же самое утверждение.

#dusk $DUSK @Dusk

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

10 августа. До конца — пять дней. 136.11M токенов, примерно $1.43M, 1.2% от предложения — в основном на команду, советников и ранних инвесторов — те же цифры, которые любой, кто следит за этим, уже и так знает.

А вот семь дней перед этим я на самом деле не смотрел.

BABY просел примерно на 10.3% за эту неделю. Цена держится около $0.0105, капитализация — около $45M, при этом он отстает от более широкого рынка криптовалют, который за тот же промежуток в целом почти ровный.

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

Может и нет. Возможно, тут более широкие рыночные условия, которые не имеют никакого отношения к 10 августа. У меня нет способа отделить «людей, которые заранее разгоняют разблокировку», от «BABY просто переживает плохую неделю наряду со всем остальным».

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

Кто бы ни продал на этой неделе — продавал в тот спад. А тот, кто получает разблокировку — продает то, что останется после нее.

Разные стороны одних и тех же пяти дней, поглощающие разные половины движения.

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

Если цена уже сдвинулась до того, как наступил день разблокировки, что тогда сам день разблокировки все еще раскрывает?

@BabylonLabs_io #baby $BABY