林木森Woody

#币安夏令营 冲呀

На этой неделе я снова посмотрел tokenomics @Dusk и раньше помнил только «потолок 1 млрд и халвинг каждые четыре года». Но, проследив за распределением наград, я понял, что производитель блока не забирает всю эмиссию каждого блока. В текущем первом цикле по плану за блок выпускается около 19.8574 DUSK, плюс комиссии за транзакции в этом блоке; создатель блока получает базово 70%, ещё до 10% может получить в зависимости от credits в сертификате, фонд разработчиков — 10%, комитет валидации и комитет утверждения — по 5%, а нераспределённая часть сжигается.

Эта схема призвана решать не просто вопрос одного APR, а сделать так, чтобы три действия консенсуса — предложение, валидация и утверждение — тоже приносили доход. И из этого следуют новые вопросы: если on-chain комиссии низкие, бюджет безопасности в основном зависит от постоянной эмиссии; если качество участия узлов недостаточно, дополнительные награды будут выплачиваться не полностью, и фактический прирост предложения окажется ниже номинальной кривой. Поэтому на $DUSK нельзя смотреть так: просто умножить «19.8574 за блок» на число блоков и считать это фиксированным доходом, доступным всем.

Официальная долгосрочная модель такова: сначала 500 млн, затем ещё 500 млн выпускаются примерно за 36 лет, а максимальное предложение составляет 1 млрд; каждые четыре года скорость эмиссии блока уменьшается вдвое. Этот потолок ясен, но «есть потолок» не значит, что в краткосрочной перспективе нет размывания доли: первые четыре года — это как раз период самой концентрированной эмиссии. С другой стороны, ранняя эмиссия действительно покупает безопасность для узлов и комитетов, и её не стоит просто списывать одним словом «инфляция».

Когда я смотрю #dusk на предложение, я одновременно слежу за тремя вещами: фактической чеканкой, долей активного стейкинга и долей комиссий в вознаграждении. Только когда комиссии и реальное использование постепенно берут на себя бюджет безопасности, сокращение эмиссии перестаёт быть простым урезанием дохода узлов. Что для вас важнее: жёстко зафиксированный максимальный supply или способность сети после снижения эмиссии по-прежнему оплачивать стоимость безопасности?

Я разобрал анонс о сотрудничестве @Dusk , NPEX и Chainlink и понял, что по-настоящему реализуются не просто «RWA между цепочками», а три совершенно разных канала данных и активов. CCIP отвечает за межцепочные сообщения и перемещение активов, CCT даёт таким токенам, как $DUSK , контролируемый путь burn/mint; DataLink выводит на блокчейн официальные биржевые данные NPEX, а Data Streams дополнительно обрабатывает обновления цен с меньшей задержкой.

Почему этот слой данных сложнее, чем просто «выпустить облигацию в виде токена»? Потому что регулируемый актив должен подтверждать не только наличие некоторого количества долей в контракте. Вторичному рынку нужно знать, откуда берётся цена, сохраняет ли эмитент контроль, кому принадлежат лимиты скорости и права на обновление при межцепочечной передаче, и как при аномальных данных приостанавливать операции. В анонсе подчёркивается, что Dusk и NPEX сохраняют право собственности на токенный контракт и могут задавать rate limit и upgrade path; для институциональных игроков это вопрос контроля, а для обычных пользователей — обязательные к отслеживанию права управления.

С позитивной стороны, NPEX предоставляет реальные сценарии выпуска и торговли, Chainlink закрывает вопросы интероперабельности и доступа к официальным котировкам, а у Dusk появляется шанс связать выпуск, торговлю, расчёты и раскрытие информации в единую цепочку. Но и обратная сторона ясна: сотрудничество, принятие стандарта и реальная активность актива — это три разные вещи. Без проверяемых данных о выпуске, сделках, держателях и погашении любые разговоры о «массовом выводе институциональных активов на блокчейн» пока остаются лишь на этапе строительства.

Так что я дальше буду следить за #dusk не просто по количеству partner logo, а в ожидании трёх типов доказательств: контракта с реальным активом, непрерывных рыночных данных и проверяемого потока расчётов. А как вы думаете, в RWA самое сложное — это перенос актива между цепочками или то, чтобы цена на блокчейне, юридические права и офлайн-выкуп всегда совпадали?

За последние два дня я заново перерисовал Core Components @Dusk , и только тогда смог развести по разным местам три названия — DuskVM, DuskEVM и DuskDS. Сначала я тоже думал, что это просто «одна цепь, совместимая с двумя виртуальными машинами», но на деле разделение ролей больше похоже на три слоя: DuskDS отвечает за консенсус, финальность и доступность данных; DuskVM позволяет контрактам Rust/WASM напрямую работать на L1; а DuskEVM — это EVM-эквивалентная среда исполнения на базе OP Stack, которая передаёт расчёты и публикацию данных в DuskDS.

Это означает, что разработчик не ограничен глупым выбором из двух вариантов. Если уже есть Solidity-контракты и вы зависите от EVM-кошельков и инструментов, то DuskEVM — более дешёвый по входу путь; если же нужно напрямую работать с активами L1, моделью конфиденциальности Phoenix, возможностями zero-knowledge или более низкоуровневым управлением протоколом, то DuskVM — это нативная точка входа. Два пути разделяют одну и ту же базу расчётов, но это не значит, что функциональность и предположения о безопасности полностью совпадают.

Я довольно настороженно отношусь к тезису «EVM compatible = экосистема сама переедет». Совместимость может лишь снизить порог развёртывания, но она не заменяет подключение кошельков, стабильный RPC, индексаторы, ликвидность и реальных пользователей. С другой стороны, одного лишь акцента на нативном Rust/ZK тоже недостаточно: инструменты слишком жёсткие, и разработчики не будут переписывать весь продукт ради технологической чистоты.

Поэтому, когда я смотрю на технический прогресс $DUSK , я разбиваю метрики по отдельности: есть ли у DuskEVM сторонние Solidity-приложения, есть ли у DuskVM неофициальные контракты, насколько стабилен путь их расчёта через DuskDS. Если #dusk действительно обладает защитным рвом, он должен выглядеть так: «знакомые инструменты могут войти, а когда нужна конфиденциальность — можно спуститься ниже», а не как просто три новых термина, сваленных вместе. Вы бы сначала выбрали совместимость или нативные возможности?

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

Moonlight — это модель публичного счёта: баланс, отправитель, получатель и сумма видны всем, поэтому проще подключать пополнение биржи, казначейство и сценарии, где нужен открытый аудит расчётов. Phoenix, напротив, хранит средства в зашифрованных note, использует доказательства с нулевым разглашением, чтобы подтвердить отсутствие двойной траты и достаточность средств, при этом не раскрывая наблюдателям конкретную сумму и связанный note; а при необходимости аудита можно выполнить выборочное раскрытие через viewing key.

Самое большое заблуждение здесь — это мысль: «раз есть приватность, значит браузер вообще ничего не видит». Официальный браузер по-прежнему видит блоки, тип транзакции, комиссию, gas и другую публичную метаинформацию; конкретный объём видимости зависит от модели транзакции и контракта. С другой стороны, биржа тоже не может просто сканировать Phoenix как Moonlight: в официальной документации по интеграции прямо рекомендуется использовать Moonlight для пополнений, а приватный баланс сначала нужно перевести в публичный счёт — логика кастодиального хранения и сканирования здесь совершенно разная.

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

На этой неделе я последовательно разобрался с документами по стейкингу для @Dusk — от активации до выхода — и только тогда понял, что две фразы «минимум 1000 DUSK, нет периода ожидания по соглашению» чаще всего приводят к недопониманию. Прямое стейкингование — это не просто «нажал на монеты и получил фиксированную ставку», а необходимость запускать постоянно онлайн и нормально функционирующий provisioner. Доход зависит от того, выберут ли вас для участия в консенсусе, и от доли эффективного стейка, а не от протокольного обещания фиксированной выплаты.

Есть и нюансы по таймлайну. Новый stake начинает работать только на границе «следующего epoch и дальше». Официальные оценки по целевому времени блока обычно дают примерно 6—12 часов, но самый точный ориентир — то, что указано в кошельке: active from block. Сам по себе выход не имеет протокольной блокировки, но он не «заберёт автоматически» накопленные награды вместе с этим действием; withdraw reward — это отдельная операция.

Ещё менее интуитивный момент — добавление (top-up) стейка. После того как исходная позиция уже стала active, добавленная часть поступает так: 90% сразу входят в active, а оставшиеся 10% учитываются как locked stake. Закреплённые монеты всё равно принадлежат вам, но они не участвуют в консенсусе; чтобы вернуть хвост, может потребоваться полностью unstake оставшуюся позицию. Это решение нельзя назвать плохим, но оно приводит в заблуждение тех, кто смотрит только на панельный APR — можно неверно оценить эффективность капитала.

Сторонние пулы убирают порог по операционным настройкам, но при этом появляются другие риски: хранение, смарт-контракт, операционная сторона и правила выхода — всё это превращается в отдельную группу рисков. Поэтому, когда я смотрю на стейкинг $DUSK , я оцениваю не только «сколько будет дохода», но и кто управляет нодой, как распределяются награды и что делать с locked-частью. Пользователь #dusk , скорее всего, лучше подходит либо для самостоятельного запуска ноды, либо для принятия риска пула ради более простых действий?

Я посмотрел(а) вместе белую книгу TMX и документы по стимуляции для @TermMax и понял(а), что есть вопрос, который стоит задать раньше, чем «сколько будет airdrop»: можно ли время, указанное в дорожной карте, сразу считать уже произошедшим TGE?

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

В белой книге версии марта 2026 года TMX определяется как governance- и utility-токен, с фиксированным общим объёмом 1 миллиард, а первоначальный объём в обращении ожидается примерно на уровне 20%. В таблице распределения указано: 29% — экосистема, 28% — инвесторы, 15% — команда, 15% — сообщество, остальное — на ликвидность, фонд и консультантов. В дорожной карте TGE, ликвидность на биржах, распределение и стейкинг-пул отнесены ко второму кварталу 2026 года.

Но в параметрах той же белой книги дата TGE по-прежнему указана как To Be Announced. В документе о предварительном майнинге сказано лишь, что пользователи накапливают пока непродаваемый объём, который можно будет получить 1:1 после TGE. Официально уже указаны адреса токенов в Ethereum и BNB Chain, и это означает, что подготовка контракта раскрыта публично, но само по себе это не доказывает, что генерация, получение и ввод в обращение уже полностью завершены.

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

Я оцениваю прогресс TMX только по четырём сигналам: чётко объявленное время TGE; официальная страница и правила получения; данные блокчейн-эксплорера, соответствующие описанию распределения; а также собственные объявления биржи о листинге и вводе/выводе. Если хотя бы одного пункта не хватает, стадию нужно описывать честно, а не дописывать за проектом последующие шаги.

Есть риск не только в датах. В белой книге сказано, что у команды есть 12-месячный cliff, после которого идёт линейное высвобождение; у инвесторов — такой же 12-месячный cliff и затем 24 месяца вестинга. На рынок реально влияет не сам общий объём в 1 миллиард, а то, сколько высвобождается в каждом окне, на какие адреса это приходит и можно ли это сверить с публичной таблицей.

Поэтому я не считаю TMX «обязательно завершённым» только потому, что квартал в дорожной карте уже прошёл, как у #TermMax . Дорожная карта — это план, а ончейн-распределение и официальные объявления — это статус. Лучше не угадывать лишний день прогресса, чем лишний раз приписывать проекту воображаемую оценку.

Я сверил инструкцию по новому кошельку @Dusk и Dusk Connect, и только тогда понял, что они добавили не просто «ещё одну оболочку для кошелька», а недостающее для dApp связующее звено. Старый Web Wallet мог отдельно отправлять переводы и стейкать, но приложения не могли через единый интерфейс находить кошелёк, запрашивать аккаунт, подписывать и отправлять транзакции — разработчикам приходилось подстраиваться под каждый кошелёк отдельно.

То, что делает Dusk Connect, очень похоже на стандартизацию этого слоя “клея”: обнаружение кошелька заимствует идею EIP-6963, RPC по пространствам имён обрабатывает аккаунты, подпись, транзакции и сетевые запросы, а для реализующих кошельки предусмотрены тесты на согласованность. Новый собственный кошелёк с самого начала строится под этот интерфейс provider — для браузерных расширений, десктопа и мобильных устройств; публичные и приватные переводы, shield/unshield, стейкинг, получение наград, DRC-20 и DRC-721 — всё сводится в один путь взаимодействия.

Самое лёгкое место, где маркетинговый текст может сбить с толку, — это приравнять «репозиторий открыт» к «продукт зрелый». Сейчас официально его позиционируют лишь как developer preview. Локальное хранение ключей, PBKDF2 и AES-GCM на стороне расширения, Stronghold и Argon2 на нативной стороне — это правильная база безопасности, но по-настоящему опыт использования определяют восстановление после разрыва соединения, подсказки о правах, обратная связь по неудачным транзакциям и согласованность состояния между устройствами.

Именно поэтому я в последнее время смотрю #dusk не только на уровень терминов протокола: без стабильного слоя подключения кошелька даже самый красивый приватный контракт остаётся лишь демонстрацией для разработчиков. Следующий шаг для $DUSK — не ещё один скриншот интерфейса, а то, чтобы сторонний dApp реально подключался без боли. А вы, когда оцениваете новый кошелёк на пригодность, сначала смотрите на список функций или на то, как он ведёт себя в сценариях с ошибками?

Прочитав объяснение о запуске V2 для @TermMax , я сначала посмотрел, как это соотносится с разбором V1. Проблема протокола с фиксированной ставкой, возможно, не в отсутствии котировок, а в том, что деньги разнесены по разным ордерам, рынкам и страницам цепочек: увидев одну ставку, нельзя быть уверенным, что весь объём получится исполнить именно по ней.

В V1 range order куратора и limit order пользователя размещались отдельно. Если нужно занять сумму побольше, приходилось по одному сравнивать ордера, а затем мириться с изменением цены на каждом участке глубины рынка. Ставка может называться «фиксированной», но стоимость входа не всегда очевидна с первого взгляда.

V2 меняет именно этот слой. Единый ордер читает range order куратора и персональные лимитные ордера, объединяя их в один маршрут исполнения; пользователь видит одну котировку, один раз подписывает, а система завершает комбинацию в ликвидности одного и того же рынка. Лимитные ордера также открыты для каждого рынка: кредитор может выставить минимально приемлемую ставку, заёмщик — максимальную готовую ставку, не нужно насильно брать текущую цену в тонкой глубине.

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

Но есть граница, которую нельзя замазывать походя. Официально речь идёт о том, что кроссчейн-рынки и хранилища отображаются, фильтруются и сравниваются в одном интерфейсе, но не о том, что средства на разных цепочках физически объединяются в один пул. Глубина Ethereum не станет автоматически доступной для сделки только потому, что её видно и на странице Base. Ликвидность в цепочке, Gas, время ожидания лимитного ордера и фактический объём исполнения по-прежнему считаются отдельно.

Ещё один важный момент — поведение крупных ордеров. Более плавный маршрут не означает, что по любой сумме можно получить ставку с главной страницы. Стоит следить за разницей котировок для разных сумм, временем ожидания лимитных ордеров и тем, сколько источников было объединено в одной сделке; это лучше, чем «сколько цепочек поддерживается», показывает качество исполнения.

Поэтому ценность #TermMax V2 не в том, что страница стала проще, а в том, что «ставка определена» и «исполнение определено» разделены. Первое задаётся FT и датой погашения, второе по-прежнему должно подтверждаться глубиной рынка. Интерфейс может ясно показать маршрут, но есть ли на нём достаточно машин, ещё нужно проверить по реальному исполнению.
$BOME $BTC

В последние два дня я разбирал анализ безопасности AEGIS для @Dusk и сначала запомнил только «39 исправлений, 7 critical», но после изучения деталей понял, что большой размер числа — не главное. В итоге 7 серьёзных проблем свелись к 4 категориям первопричин: проблема с псевдонимами в VM-песочнице, небезопасная десериализация на стороне хоста, отсутствие полной связки между комиссиями Phoenix и возвратами, а также путь подделки BLS-подписей.

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

Официально говорится, что на данный момент не обнаружено, чтобы эти critical были использованы до исправления; я готов воспринимать это как вывод расследования, но не буду превращать это в утверждение «абсолютно точно ничего не происходило». Для $DUSK положительный сигнал AEGIS в том, что команда открыто опубликовала внутренние находки вплоть до первопричин и логики исправлений; отрицательный сигнал столь же ясен: в основном стеке после запуска основной сети действительно возникали серьёзные пробелы, способные повлиять на исполнение, подтверждение консенсуса и доступность цепочки.

Поэтому я не стал бы просто ставить на #dusk «печать безопасности» только потому, что аудитов было много. Более полезное наблюдение такое: будет ли в следующем раунде продолжено раскрытие информации, будут ли тесты на регрессию по тем же типам границ, сможет ли внешний аудит охватить код после AEGIS. Что для вас важнее: чтобы у проекта вообще никогда не всплывали крупные проблемы, или чтобы после их обнаружения он мог чётко объяснить первопричину, влияние и цепочку исправлений?
$USELESS $BOME

Я перечитал документ по фиксированной ставке @TermMax . Сначала меня зацепило не то, как считать процент, а более базовый вопрос: стоимость средств по ончейн-кредитованию меняется каждый день. Почему же тогда ставка по долгу фиксируется заранее до даты погашения?

Если ответ сводится к «так устроен протокол, условия не меняются», то исследовать здесь нечего. Дальше становится интереснее: связи FT, XT и GT складываются в цельную логику.

FT — это документ, подтверждающий, что к моменту погашения долг можно обменять по номиналу на долговой актив. Кредитор покупает FT со скидкой, а при наступлении срока выкупает по номиналу; разница и есть доход, зафиксированный заранее. XT — взаимодополняющая часть. В документации сказано: в любой момент 1 FT + 1 XT соответствует 1 единице долгового актива. Заёмщик превращает будущую сумму к погашению в FT, а процентную часть продаёт рынку через ордера: сегодня получает ликвидность, а стоимость фиксируется в момент сделки.

GT больше похож на оболочку позиции. Это ERC-721, который фиксирует залог и долг, а не создаёт ещё одну «монету дохода», которую можно свободно торговать. Сколько залога нужно, сколько FT в долгу, когда наступает погашение — всё это упаковано в одну и ту же ончейн-позицию.

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

Есть и одна граница, которую легко затушевать рекламными лозунгами. Фиксированная ставка не означает «без ликвидации». Официальный Market-документ всё равно задаёт MLTV и LLTV. Если цена залога падает или долговой актив дорожает так, что LTV достигает LLTV, позиция всё равно попадёт под ликвидацию. Устраняют только неопределённость, связанную с внезапным «скачком» ставки; при этом не убирают колебания залога, риски оракула и риск погашения на срок.

Поэтому, когда я сейчас смотрю на #TermMax , я не начинаю с вопроса «высокий ли APY?». Сначала смотрю дату погашения у FT, глубину на сделке и насколько GT ещё далеко от линии ликвидации. Если воспринимать «фиксированную ставку» как гарантию, что «ничего не случится», направление мыслей будет неверным; фиксируется лишь самая трудно прогнозируемая часть цены внутри долга.
$CLO $ETH

Я ещё раз разобрал тот обзор кроссчейн-моста про @Dusk этого года и понял: самое важное — не слово «украдено», а то, на каком именно уровне произошёл сбой. Проблема 16 января возникла в кошельке для подписи, который использовал мост-сервис: после того как злоумышленник получил право на выпуск средств, он вывел активы со стороны Dusk, а затем часть перевёл в BSC. Официально было прямо сказано, что это не отказ консенсуса и не взлом протокола L1.

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

Раньше и я легко воспринимал фразу «мост — это не протокол» как форму снятия ответственности, а теперь мне больше хочется смотреть на это наоборот: как только пользователь воспринимает мост как точку входа ликвидности, он уже входит в $DUSK реальную зону безопасности. Безопасность консенсуса в цепи и безопасность входа-выхода активов — это два экзамена, которые нужно сдавать одновременно.

Направление исправления на этот раз правильное, но риск никуда не исчез: нужно и дальше следить, действительно ли долго соблюдается изоляция ключей, насколько разумны пороговые значения, и можно ли аудитировать остановку сервиса и ручное пополнение. #dusk Сообществу важнее спрашивать не «взломали ли цепь», а «какой ключ всё ещё обладает властью, выходящей за пределы необходимого». Когда вы смотрите на кроссчейн-мост, вы сначала смотрите на аудит кода или сначала на то, как разделены операционные полномочия?
$TREE $ETH

Сегодня я, следуя документации с номером @TermMax , нарисовал схему движения средств: FT, XT, GT. Дошёл до третьей стрелки — и меня просто рассмешило. Одна сделка фиксированного срочного займа — как её умудрились разложить на три разных токена? Дизайн правда изящный, но как рядовому пользователю понять, на какой именно он должен смотреть?

Сначала я разложил логику по полочкам. FT — это по сути бескупонная облигация: по наступлении срока её можно выкупить обратно по номиналу в обмен на долговой актив. XT дополняет часть со скидкой относительно FT — в определениях протокола всё постоянно сводится к одному FT плюс один XT, что соответствует одной единице долгового актива. А GT — это ERC-721, который содержит в себе залог и долговую позицию. Заёмщик блокирует залог, чеканит FT, затем из FT выкупает на основе разделения главную сумму и процентную часть, превращая их в XT — после чего собирает обратно тот актив, который хотел занять. На бумаге контур выглядит очень красиво — признаю, что это куда более проверяемо, чем «ставка процентов просто написана на странице».

Но чем дальше читаю, тем больше у меня сомнений. Цена FT будет меняться в зависимости от оставшегося срока и рыночной кривой. Срок XT наступает — и его стоимость уходит в ноль. А GT снова принимает на себя риск ликвидации. Три токена по отдельности фиксируют срок, проценты и залоговую долговую экспозицию. TermMax делает разбиение займа максимально прозрачным — и одновременно разбивает на более мелкие состояния то, что пользователю нужно понимать. Одна кнопка «купить» на странице не означает, что мозг вне цепочки тоже сможет понять всё в один клик, правда?

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

Я ещё раз сверил конец на дату погашения. FT в норме выкупается по номиналу. Но если заёмщик просрочит, а ликвидация не обработается в окне корректно, пул выкупа может «смешаться» с залогом. То есть, FT действительно ведёт себя как облигация, но кредитная защита — это не обещание конкретной организации выплатить. Её обеспечивают в очереди ставка по залогу, оракулы, ликвидаторы и рыночная ликвидность. Не посмотришь на одну «эстафетную палочку» — и выводы могут уехать в сторону.

Поэтому после того, как я исследовал #TermMax , мне больше всего хочется видеть не очередной плакат про «фиксированный APY», а понятное человеческим языком объяснение: как меняются FT, XT и GT в каждой позиции и какой путь наихудшего выхода наиболее вероятен. Сложный механизм можно спрятать за одним кликом — но если риск тоже прячется вместе с упрощением, то кому на самом деле служит эта «простота»: пользователю или только факту сделки?
$PRL $CLO

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

Модель Dusk: 500 миллионов — начальное предложение, а оставшиеся ещё 500 миллионов высвобождаются в течение 36 лет как сетевые награды. Эмиссия снижается по геометрическому графику с уменьшением вдвое каждые четыре года. Назначение токенов сейчас весьма прямое: оплата Gas, участие в стейкинге и защита консенсуса. Чтобы стать Provisioner напрямую, минимум нужно застейкать 1000 DUSK, и при этом узел должен постоянно быть онлайн и синхронизироваться. Официальные базовые настройки не выглядят чем-то чрезмерным, но награды формируются за счёт участия в консенсусе и вероятности эффективного стейкинга — это не «положил и фиксированно забираешь проценты».

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

Но риски тоже очевидны. То, что 36 лет идёт эмиссия, означает, что долгосрочному размытию нельзя смотреть только на общий лозунг по сумме. Минимум 1000 монет плюс требования к операционной работе отсечёт часть небольших держателей от прямого стейкинга; а награды вероятностны, из‑за чего их легко ошибочно воспринимать как стабильную годовую доходность. И главное: если доходы от on-chain‑транзакций и приложений не взлетят, комиссии не смогут подхватить роль эмиссии — в итоге безопасность сети всё равно в основном будет держаться на выпуске субсидий.

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

Как ты думаешь, на ранней стадии новой сети что приоритетнее: сначала повышать участие в стейкинге, или вначале наладить реальные комиссии? Оставь свой порядок.
$ETH $RED

Я перепроверил с фиксированной ставкой механизм @TermMax : чем больше читаю, тем яснее вижу, что два слова «фиксированная» очень легко усыпляют бдительность. Да, ставка действительно может быть зафиксирована на момент сделки, но фиксируется ли в итоге «по-настоящему» мой результат?

Сначала про займ. TermMax на каждом рынке заранее определяет долговой актив, залог и дату погашения: заемщик фиксирует залог в GT, а затем чеканит FT — токен, представляющий задолженность к погашению. Стоимость не скачет из‑за использования, с этим я согласен: по крайней мере не нужно сидеть и в полночь караулить плавающую ставку по заимствованиям. Но как только LTV доходит до LLTV, позиция всё равно уходит в процесс ликвидации. Фиксируется цена капитала, а не цена залога — и точно не безопасность основной суммы. Когда эти три вещи смешивают в рекламе, мне кажется, это легко вводит в заблуждение.

Дальше — про дату погашения. В документах всё расписано: просрочка приводит к ликвидации, плюс даётся окно на два часа для ликвидации. Если долг не был полностью обработан, наступает physical delivery: держатель FT получает выкупной пул, который может одновременно включать базовые активы и залог. Изначально я думал, что покупая FT, я просто дожидаюсь срока и получаю тот же самый долговой актив. Но в предельных случаях у меня на руках может оказаться целая «корзина» залогов, с которой мне уже придётся разбираться самому. Это всё ещё обычные «фиксированные доходы», которые ожидает понять обычный человек?

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

И стоимость ликвидации тоже нельзя списать одной фразой «избыточный залог». По открытым правилам за ликвидируемый долг начисляется 10% штраф: половина — ликвидатору, половина — в резерв протокола. Когда долг превышает 10 000 долларов, обычно за один раз максимум приходится обрабатывать 50%. Это помогает не «отрезать» сразу весь большой объём одним махом. Но если рынок реально начнёт непрерывно падать, успеют ли обработки порциями — или нет — зависит от того, как всё исполняется on-chain, и от ликвидности.

Поэтому я смотрю на #TermMax и не могу ограничиться вопросом: «заперт ли APY на странице?» Важно спрашивать другое: что именно является залогом, где проходит LLTV, кто отвечает за погашение долга к моменту срока, и что именно я получу после physical delivery. Ставка закреплена — но риски не закреплены там же, где ставка. Разве не так?
$GPS $ETH

Я ещё раз просмотрел(а) руководство по миграции в основную сеть для @Dusk и заметил(а) одну очень легко упускаемую деталь: то, что вы нажали Approve в кошельке, ещё не означает, что $DUSK уже переведён в основную сеть Dusk. Настоящий запуск миграции происходит на следующем шаге — Execute transaction. Любая остановка между этими двумя действиями может создать у пользователя ощущение, что активы «застряли».

Официальный процесс такой: ERC-20 в сети Ethereum или BEP-20 DUSK в BNB Chain блокируются в миграционном контракте, а затем соответствующие нативные монеты выдаются на указанный адрес в основной сети Dusk. Пользователю нужно подготовить самостоятельный EVM-кошелёк, аккаунт Dusk, а также ETH или BNB для оплаты комиссий в исходной сети; после подтверждения транзакции обычно ещё требуется подождать обработки. Аккаунты на бирже, как правило, не могут напрямую выполнить эту операцию через WalletConnect — сначала средства нужно вывести в кошелёк, который вы контролируете.

Сам механизм несложный, настоящие подводные камни — в границах операции. Во-первых, разрешение — это лишь выдача лимита контракту, оно не переводит токены автоматически; во-вторых, токены в исходной сети имеют 18 знаков после запятой, а DUSK в основной сети — 9, поэтому сумма миграции округляется вниз до минимальной единицы LUX, а остаток меньше 1 LUX остаётся в исходном кошельке; в-третьих, если баланс не пришёл, сначала нужно проверить, успешно ли прошла транзакция Execute, а не повторно выдавать разрешение.

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

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

А вас при миграции активов больше всего пугает что: разрешение, выбор неверной сети или непрозрачный статус зачисления? Расскажите, на каких операциях вы уже спотыкались.
$ACE $BTC

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

DuskVM позволяет запускать смарт-контракты на Rust/WASM прямо в L1, ближе к Phoenix: скрытым транзакциям, возможностям zero-knowledge и нативной модели активов. DuskEVM же построен на OP Stack, так что разработчики могут и дальше использовать Solidity, Hardhat, Foundry и привычные кошельки, а результаты выполнения затем проходят расчёт и обеспечение доступности данных через DuskDS. Проще говоря, первая среда — как специализированная лаборатория: возможности глубокие, но порог входа высокий; вторая — как стандартный интерфейс: подключение быстрое, но приходится решать вопросы кросс-слойной координации.

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

Но две среды — это не бесплатный бонус. Где разворачивать контракт, как перемещать активы между слоями, какой слой отвечает при сбоях — всё это увеличивает инженерную сложность. Особенно DuskEVM зависит от расчёта и доступности данных через DuskDS: пользователю виден знакомый интерфейс EVM, но под ним не обычная сайдчейн Ethereum. Если документация, обозреватели и подсказки по состоянию между слоями не будут успевать за реализацией, совместимость может, наоборот, породить новые издержки на понимание.

Сейчас я бы не делал вывод о росте разработчиков #dusk только на том основании, что поддерживается Solidity. Дальше важнее наблюдать за тем, сколько смарт-контрактов реально работает в мейннете, насколько плавно проходят маршруты активов между слоями и когда такие функции конфиденциальности, как Hedger, станут переиспользуемыми компонентами. $DUSK как Gas и безопасный актив для обеих сред в конечном счёте тоже должен подтвердить свою ценность реальным объёмом использования, а не замыкаться в самоподтверждающейся архитектурной схеме.

Как вам кажется, двухисполнительная среда — это умное разделение ролей или способ лишь сильнее усложнить поддержку? Делитесь мнением.
$BTW $ETH

Я снова посмотрел(а) разбор кроссчейн-моста от марта этого года про @Dusk , и самое важное, что стоит запомнить, — не «с консенсусом основной сети всё было в порядке», а куда более болезненный факт: полномочий одного кошелька для подписи однажды оказалось достаточно, чтобы потянуть ко дну весь мост.

16 января атакующий получил доступ к подписи кошелька сервиса моста Dusk: сначала он вывел средства на стороне Dusk, а затем часть из них отправил в BSC. В официально раскрытой последовательности были похищены 9,000, 89,700, 2,743,310 и 8,068,000 монет $DUSK ; ещё две операции успешно прошли через мост, а последняя попытка на 8,910,000 монет после остановки уже провалилась.

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

После разборa переделка, надо признать, попала точно в цель: подпись и обработка событий были разделены, события сначала превращаются в задачи, а затем выполняются независимым worker'ом; статус транзакции разбит на seen, submitted, completed, failed, stuck; в горячем кошельке остаётся только минимальный операционный баланс, при падении ниже порога система автоматически ставится на паузу, после чего холодный кошелёк пополняется вручную. Проще говоря, путь «одна дорога до конца» был разрезан на несколько ворот.

Но я не собираюсь считать, что после исправлений история уже закончилась. Самая сложная часть мостов в том, что безопасность протокола и операционная безопасность пользователи часто воспринимают как единое целое. Вы держите тот же DUSK, видите тот же бренд, но фактически можете иметь дело с совершенно другой моделью доверия. Внутри цепочки всё держится на консенсусе, а на шаге кроссчейна в тот момент опора была на путь подписи; как только актив пересёк границу, предпосылки безопасности уже пересели в другую машину.

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

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

Я открыл страницу токеномики @Dusk и понял, что меня остановил не лимит в миллиард монет, а одно неприметное правило: минимальный стейк для ноды — 1,000 монет $DUSK , а верхнего предела нет.

Сначала разберёмся с цифрами. Начальное предложение Dusk — 500 млн, и ещё 500 млн планируют выпускать в течение 36 лет; в первые четыре года каждый блок добавляет примерно 19.8574 монеты, а затем примерно каждые четыре года награда уменьшается вдвое. Из награды за блок 70% получает производитель блока, ещё до 10% он может получить сверху в зависимости от credits в сертификате; 10% идёт в фонд разработчиков, 5% — комитету верификации, 5% — комитету утверждения, а нераспределённая часть сжигается.

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

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

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

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

Не надо напрямую переводить лимит предложения в дефицит, и не надо напрямую переводить доходность стейкинга в безопасность. Отсутствие верхнего предела для веса ноды — это поощрение долгосрочных вложений или постепенно превращение случайного комитета в постоянную ложу для богатых? Давайте разберём это на площади.
$VELVET $SNXXB

Я дважды прочитал документ по торговой модели для @Dusk , и самым броским оказалось не слово «приватность», а то, что на одной и той же цепочке лежат две книги учёта: Moonlight — публичная, Phoenix — скрытая.

Если говорить по-человечески, Moonlight — как стеклянная стойка: адреса и переводы видны всем; Phoenix же упаковывает средства в зашифрованные билеты и с помощью доказательств с нулевым разглашением сообщает сети «деньги легальны, двойной траты нет», но не раскрывает отправителя, получателя и сумму целиком. Один профиль аккаунта может одновременно управлять этими двумя типами счетов. Звучит так, будто в одном кошельке есть и прозрачная карта, и потайной отсек: при оплате сам выбираешь, какую достать.

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

Но проблема тоже спрятана в этой «двухрельсовости». В документации по интеграции бирж прямо советуют использовать Moonlight для пополнения, потому что зашифрованные билеты Phoenix требуют другой логики кастодиального хранения и сканирования. Иными словами, протокол дал выход к приватности, но реальный вход ради совместимости может загнать всех обратно в прозрачный канал. Как если бы в отеле сделали скрытую VIP-дверь, а система на ресепшене признавала только паспорт у главного входа: дверь есть, но это не значит, что гость действительно туда попадёт.

А что здесь такое $DUSK ? Им оплачиваются оба вида переводов, и без него не обходится исполнение смарт-контрактов. Это не просто ярлык, приклеенный к истории приватности, а топливо, общее для двух книг учёта. Но будет ли у этого топлива реальный спрос, в конечном счёте зависит от того, захотят ли кошельки, биржи и приложения по-настоящему подключить Phoenix, а не просто красиво описать его в документации.

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

Так что не стоит успокаиваться одними словами «выборочная приватность». Эта пара рельсов Moonlight и Phoenix в итоге даст пользователю свободу выбора маршрута, или большинство входов просто оставят ту прозрачную колею, которая им проще и дешевле? Продолжаем разбор в комментариях.
$AKE $ACU