东京小姐

в руководстве по миграции docs.dusk.network есть одна деталь про округление, зарытая в faq, которую я не видел больше нигде. если вы мигрируете сумму erc20 или bep20 dusk, которая не является точным кратным 1 lux, контракт просто округляет её вниз — и мне пришлось прогнать их же пример дважды у себя в голове, прежде чем это наконец дошло: мигрирую 1234567890 wei dusk, и она округляется ровно до 1000000000 wei, то есть до одного целого lux, без частичного зачёта остального.
поэтому остаток не возвращается, не ставится в очередь для последующего пополнения — он просто исчезает из того, что вы получаете на нативной стороне. это реальная стоимость, заложенная прямо в механике миграции, а не баг, потому что нативный dusk использует 9 знаков после запятой, а erc20/bep20 — 18, так что какое-то округление математически неизбежно где-то в процессе конвертации.
для большинства людей, которые мигрируют обычный баланс кошелька, это, скорее всего, доли цента и в реальности не имеет значения. но никто, кто мигрирует впервые, не ожидает, что «округление вниз и потеря разницы» станет поведением по умолчанию в сети, построенной вокруг детерминированной точности расчётов.
показывает ли миграционный ui людям точную округлённую сумму перед тем, как они подтвердят, или они узнают об этом только постфактум? 🧐

#dusk $DUSK @Dusk

@Dusk
a я пошёл проверить, что именно означает «zero-trust custody» в анонсе dusk-cordial-npex, потому что обычно этот термин подразумевает вполне конкретную криптографическую архитектуру, и мне показалось, что пресс-релиз использует его вольно — в смысле «самостоятельный хостинг вместо стороннего saas». я ошибся, и честно говоря, я почти написал весь этот пост, опираясь на то неправильное предположение, прежде чем действительно заглянуть в собственные технические документы Cordial — их продукт treasury реально использует mpc threshold signing, FROST для ed25519, слой консенсуса bft поверх независимых узлов и доли ключей, которые никогда не реконструируются в одном месте. это настоящая распределённая криптография с доверием, а не маркетинг, переодетый под «одну коробку».
так что выбор NPEX самохостинга и получение по-настоящему zero-trust архитектуры на самом деле не противоречат друг другу так, как я предполагал перед входом в тему; весь месседж Cordial в том, чтобы учреждения могли запускать эту архитектуру у себя, а не доверять облаку SaaS-вендора.
то, чего я всё ещё не знаю: NPEX запускает полный многонодовый bft-конфиг или что-то ближе к развёртыванию в рамках одного узла, потому что в документации Cordial упомянуты оба варианта — технически они доступны. в практике это не одно и то же по уровню «zero-trust», даже если базовое ПО одно и то же.
кто-нибудь знает, реальная развертка Cordial у NPEX — это single-node или настоящий multi-node threshold setup? 🧐

#dusk $DUSK

стандартный для chainlink CCT для перемещения dusk между ethereum и solana был объявлен еще в ноябре 2025 года — за месяцы до январского инцидента с мостом, о котором нам уже известно как о случившемся на другом кроссчейн-пути dusk. я решил проверить, действительно ли это один и тот же мост под двумя названиями — честно говоря, я наполовину ожидал, что это окажется одним и тем же, просто с разным брендингом — но нет. собственная страница архитектуры dusk описывает отдельный нативный мост, управляемый валидаторами, который перемещает ценность между внутренними слоями dusk, тогда как chainlink CCT работает поверх собственной децентрализованной оракульной сети chainlink для внешних переводов eth–solana. два действительно разных механизма.
поэтому январский инцидент, который ударил именно по нативному мосту, вообще не должен был затрагивать цепочку chainlink — исходя из того, насколько по-разному они спроектированы. это, пожалуй, успокаивает в каком-то смысле больше, чем я ожидал.
но вот что по-прежнему не сходится — никто не объяснил это различие нигде, когда публиковали уведомление об инциденте. если вы просто знаете: «в январе у dusk была проблема с мостом», то у вас нет никаких указаний на то, что это затронуло только один из двух отдельных механизмов бриджа — и выяснять это пришлось целиком через сопоставление двух несвязанных анонсов, что я и сделал.
есть ли вообще одна страница, где кто-то прямо расписывает, что делает каждый из мостов для dusk, или чтобы подтвердить это, нужно собирать отдельные пресс-релизы, как я только что? 🧐
#dusk $DUSK @Dusk

Я пошёл проверить, действительно ли Boreas когда-либо добрался до мейннета, ведь его постоянно упоминают как большой вехой. Но вместо этого я нашёл два отдельных события в тестнете под одним и тем же названием, с разницей в две недели. Честно говоря, я почти остановился на дате 12 мая, предполагая, что на этом всё. Dusk активировал Boreas в тестнете 12 мая, позиционировав это как укрепление устойчивости и готовности DuskEVM. Затем 27 мая в тестнете вышел «Boreas release candidate 1», и это тоже было прямо названо финальным шагом валидации перед мейннетом.
То есть активация 12 мая была не финальной точкой, а более ранней фазой, и есть второй контрольный этап после неё, о котором я нигде не видел упоминаний, пока не начал искать целенаправленно. Я всё ещё не могу найти объявление, подтверждающее, что Boreas действительно дошёл до мейннета после этого release candidate.
Это обычный способ развернуть хардфорк: тестнет, затем RC, затем мейннет. С самой процедурой всё нормально. Просто мне кажется, что в материалах часто «Boreas activated» подаётся как одно цельное событие, хотя на деле это минимум два этапа в тестнете — и возможно, что последний ещё не пройден.
Boreas уже реально запущен в мейннете после 27 мая, или же release candidate всё ещё является самым последним подтверждённым шагом? 🧐
#dusk $DUSK @Dusk

@Dusk
i went to check exactly what the aegis upgrade touched, since march 3rd gets cited as a major milestone but different sources describe it differently — one says mandatory for all node operators, another calls it a testnet-only prep step. turns out both are just incomplete versions of the same thing, and honestly i almost stopped at "one of these is just wrong" before digging into dusk's actual github repo. their rusk release notes list separate aegis activation block heights for mainnet and testnet, 3,590,904 and 2,773,727, confirming it hit both networks, just not at the same block number.
so there wasn't actually a scope conflict, there was a coverage gap — nobody covering it in the press wrote it up as "mainnet and testnet, here are both activation heights," they each picked one network and called it the whole story.
it's a pretty normal way to roll out a hard fork, stagger testnet slightly differently from mainnet, that part isn't unusual or concerning on its own. i just think it's worth noticing how a genuinely simple two-network rollout got flattened into two competing, incomplete narratives once it passed through secondary coverage.
does anyone know if the two activation heights lined up in wall-clock time, or did testnet actually activate before mainnet? 🧐
#dusk $DUSK

я пошёл разбираться, действительно ли dusk pay запустили: его называли deliverable’ом в Q1 в roadmap за январь 2025 года, а потом, похоже, он исчез из большинства моих материалов за 2026. Оказалось, я просто смотрел не в том месте — на самом деле я почти пришёл к выводу, что его вообще не выпускали, пока не нашёл материал о разработке с отслеживанием за май 2026 года, где прямо сказано, что dusk pay запустили в период с конца января по апрель этого года, вместе с активацией двухстороннего моста и интеграцией cordial systems custody.
Так что запуск был, просто без того типа громкого освещения, которое получили duskevm или партнёрство с npex. Это, по сути, отдельный тезис — посадочная страница платёжного продукта, соответствующего требованиям mica, появилась именно в тот отрезок, когда правила по стабильным монетам в ЕС ужесточались, и почти нигде это не заметили, тогда как более «шумные» анонсы архитектуры подхватывали везде.
Я не думаю, что это обязательно плохо: тихий релиз — не то же самое, что провал с поставкой. Но для продукта, столь значимого с точки зрения регулирования, разрыв в покрытии между заголовками «duskevm уже работает» и молчанием «dusk pay уже работает» говорит больше о приоритетах криптомедиа, чем о том, как команда dusk справилась с задачей.
Есть ли хоть какие-то реальные данные об использовании dusk pay после запуска или его выпустили без того, чтобы кто-то отслеживал внедрение? 🧐
#dusk $DUSK @Dusk

терминмакс специализируется на токенизированном долге с фиксированной ставкой, и на этом поле он не один — pendle, notional и term finance все обходят одну и ту же проблему с разных сторон. pendle разделяет приносящие доход активы на токены основного долга и токены дохода. notional прогоняет fcash через пулы ликвидности. собственное решение termmax — это range order amm: кураторы публикуют сегментированные ценовые кривые, с которыми заемщики и кредиторы сопоставляются напрямую.
я ходил туда-сюда, разбираясь, почему именно этот подход лучше, чем модель аукциона, или чем чистое разбиение дохода, и мне кажется, что дело в контроле — сеттер range order может точно формировать, где именно расположена ликвидность на кривой, а не просто соглашаться с ценой клиринга. это более «ручной» вариант для маркетмейкеров, и у этого два эффекта: более выгодные ставки, когда кто-то действительно грамотно управляет кривой, и худшие — если никто не обновляет ее по мере изменения условий.
я не запускал один и тот же размер сделки параллельно на pendle и termmax, чтобы сравнить реальное исполнение, так что это скорее структурное наблюдение, а не результат бэктеста 📐
#termmax @TermMax

в сейфе Edge Capital сейчас всё уже запущено — и это как раз тот случай, где проявляется разрыв в раскрытии информации. кураторам выплачивается комиссия за результат в размере 10–20 процентов от любой прибыли, которую генерирует их сейф — прямо указано в документации по механике сейфа, без обиняков и прямо сказано. а вот что не попадает в ту же самую ясность — точнее, почти не отражается вообще — это то, на что в действительности подвергаются депозиторы, если такой сейф попадёт в тяжёлый период: отложенные (в очереди) выводы, пока ордера разматываются, или, что хуже, ситуация, когда в итоге приходится удерживать предоставленное обеспечительное имущество, а не токен долга, который они изначально внесли, если рынок проходит через физическую поставку.
так что у куратора всё просто: его «плюс» — понятный и раскрытый процент. у депозитора «минус» — место в очереди и, возможно, другой актив, отличный от того, что он вносил. я не называю это скандалом — просто именно тому, кто несёт риск ликвидности в активно управляемом сейфе, приходится отвечать, и это никогда не должно было быть человек, который им управляет. мне просто не кажется симметричным то, что «комиссия за результат до 20%» и «возможно, вы получите поставленное обеспечительное имущество вместо вашего депозита» читаются как равнозначные вещи, когда они находятся в одном абзаце в одном и том же разделе документации.
честно говоря, я не уверен(а), это справедливый обмен за профессиональное управление или просто так, что в итоге разворачивается любая структура сейфов — будь то DeFi или нет 🤷

#termmax @TermMax

Я пошёл проверить Zedger, потому что люди до сих пор называют его “живой инфраструктурой”, и на самом деле он всё ещё таким и является — в текущей документации Dusk указаны Phoenix и Zedger как две доступные на данный момент модели транзакций, так что моё первое предположение о том, что он тихо исчез, было ошибочным.

Что реально другое — это Dusk Trade: прикладной уровень, который должен был располагаться поверх этого и дать пользователям реальное место для торговли токенизированными активами. Я напрямую проверил trade.dusk.network — сейчас это по-прежнему только лист ожидания; фраза “Join the waitlist” (“вступить в лист ожидания”) — это единственный призыв к действию на странице прямо сейчас.

Это другой разрыв, чем я сначала думал, и, честно говоря, более конкретный: в финальной фазе дорожной карты после мейннета было обещано “full zedger” — полностью работающая эмиссия активов, клиринг и расчёты, позиционированные как часть видения Dusk на 2025 год. Базовая транзакционная модель существует, но фактическая торговая площадка, построенная на ней, всё ещё находится в стадии, предзапуска, и на самой странице с листом ожидания нет видимых сроков.

Кто-нибудь знает, есть ли у Dusk Trade где-то привязанная дата запуска, или он всё ещё находится в недатированной фазе ожидания? 🧐

#dusk $DUSK @Dusk

я пошёл проверить сторонний показатель безопасности Dusk, потому что они довольно активно рекламируют «десять аудитов перед мейннетом», и скоринговый показатель CertiK Skynet для Dusk составляет 62 из 100. я ожидал, что эта цифра примерно будет соотноситься с количеством аудитов — но мне пришлось остановиться и перечитать страницу методологии CertiK, потому что я предположил, что «оценка безопасности» по сути является просто подсчётом аудитов; однако это не так — она складывается из шести отдельных категорий.

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

честно говоря, у меня нет надёжного ориентира, как должен выглядеть «хороший» показатель Skynet для L1 на стадии Dusk, поэтому я не могу сказать, что 62 — это плохо; могу лишь сказать, что это не очевидно объясняется одной лишь историей аудитов.

знает ли кто-нибудь, какая из шести категорий Skynet именно в случае Dusk снижает этот показатель? 🧐

#dusk $DUSK @Dusk

termmax запускает двойные оракулы — chainlink и redstone — и в документации это подают как защиту на случай отказа одного-единственного фида. в целом логично. но я просмотрел реальный список oracle-активов в их документации, и там уже десятки отдельных pt-токенов, lrts и производных стейблкоинов; каждый из них нужно настроить со своей собственной ценовой подачей корректно, причем новые добавляются довольно регулярно.
— на самом деле реальный риск не в самой идее dual-oracle, а в том, что избыточность защищает вас, если один фид перестал работать, а не если оба фида одновременно ошибаются относительно тонкого, недавно добавленного в листинг актива. больше типов залога — это хорошо для эффективности капитала, я понимаю. просто выходит, что раздел про риск оракула не статичен: он расширяется каждый раз, когда новый актив вносится в белый список.
что бы для меня реально прояснило ситуацию, так это увидеть, какой именно провайдер покрывает какой именно конкретный актив, где-то опубликованную таблицу/список, а не фразу «chainlink и redstone» как одну универсальную строку, покрывающую всё 🔍

#termmax @TermMax

Я пошёл посмотреть, как именно делятся награды блока за сумеречный блок, и там есть механизм сжигания, который я раньше не замечал. Генераторы блоков получают базовые 70% плюс ещё до 10% в зависимости от того, сколько кредитов включено в сертификат — но какая бы часть этих дополнительных 10% ни не была распределена, она не переносится и не перераспределяется, а просто сжигается. И мне пришлось перечитать эту строку второй раз, потому что я предположил, что «не распределённое» означает, что это просто перейдёт в пул следующего блока.
Так что, в отличие от большинства PoS-цепочек, где весь пул наград выплачивается независимо от качества участия, Dusk тихо дефляционный на марже — каждый блок, в зависимости от полноты сертификата генератора. Цепочка с графиком эмиссии, основанным на делении пополам в течение 36 лет, тоже сжигает небольшие суммы на другом конце в зависимости от качества выполнения, и я не видел, чтобы это как-то оформляли как реальный фактор чистого предложения где-либо.
Это небольшой процент за блок — я не утверждаю, что он радикально меняет кривую предложения. Но фраза «график эмиссии на 36 лет» подразумевает предсказуемую, добавочную кривую, а этот механизм сжигания означает, что фактическая чистая эмиссия немного ниже и чуть менее предсказуема, чем предполагает заголовочный график.
Кто-нибудь отслеживает, сколько Dusk реально было сожжено таким образом с момента mainnet, или это число где-то не публикуется? 🧐#dusk $DUSK @Dusk

есть функция, о которой Termmax говорит так, будто она уже работает — smart unwind. Её позиционируют как способ, с помощью которого леверейджеры могут выйти из своих GT-позиций раньше, задав целевую APR или целевую цену, чтобы арбитражеры или новые леверейджеры могли забрать позицию у вас ещё до наступления срока. На бумаге звучит отлично. Но фактическая страница документации по ней имеет внизу одну строку, где прямо отмечено, что «ещё не запущено».
поэтому прямо сейчас, если вы в леверидже и хотите выйти досрочно, вы застряли с теми же вариантами, которые существовали до того, как эта функция вообще была анонсирована: закрывать вручную, принимая любые проскальзывания, которые даст рынок. Понимаю, почему её продвигают заранее: команды делают так, чтобы разогреть интерес к v2. Но всё же есть реальный разрыв между тем, что подразумевает под собой месседжинг, и тем, что контракты реально позволяют сделать сегодня.
моё реальное прочтение: это выходит вместе с остальными релизами v2 во 2 квартале 2026 года — не раньше и не сильно позже. Такие функции редко запускают отдельно. Могу ошибаться во времени, но именно туда я бы это и поставил 🎯
#termmax @TermMax

keyrock и hardcoded lab прямо сейчас запустили live vault’ы, и есть один нюанс в том, как termmax обрабатывает неиспользуемый капитал, о котором я не вижу, чтобы кто-то вообще говорил — любой капитал по ордерам на кредитование, который еще не был заимствован, автоматически перенаправляется в aave, morpho или venus, чтобы он не лежал мертвым грузом. умный ход со стороны treasury, честно.
но это значит, что вся подача про «фиксированную ставку» тихо опирается на протоколы с плавающей ставкой — на то время, пока ваши деньги ждут, пока их сопоставят. я не называю это недостатком: это явно лучший вариант вместо того, чтобы usdc зарабатывал ноль — но при двух активных кураторах, которые сейчас выполняют стратегии, я не могу понять, какая часть их заявленного apy приходится на реально сопоставленное фиксированно-ставочное кредитование, а какая — на этот плавающий слой, который тянет основную нагрузку в медленные дни 📊
интересно, видел ли кто-нибудь где-то реальную разбивку этого соотношения.
#termmax @TermMax

@Dusk
i went digging into how dusk's committee size actually works, since "64 credits per round" gets repeated everywhere as fixed. found a github issue describing something different — committee size caps at 64 but drops below that when there aren't enough eligible provisioners, with quorum computed off that smaller number. except when i went to check which codebase that issue was filed against, it's dusk-blockchain, the old golang client, archived by its own team back in june 2025.
so this was documented behavior in the pre-mainnet implementation, not necessarily what's running now — actually wait, i should be more precise, it's not that it's necessarily different now, it's that i genuinely can't find anything either way. mainnet uses rusk, a full rust rewrite, and whether this exact sortition logic carried over or got redesigned along the way isn't something i could confirm.
that's a weirdly specific gap for a network this deep into public docs — the historical behavior is real and traceable, but nothing i've found actually confirms or denies it in the current live codebase.
has anyone actually checked the current rusk sortition code for this, or is everyone just repeating the old go client's behavior as if it's still true? 🧐
#dusk $DUSK

Я читал инженерные обновления Dusk по штрафам и заметил, что проценты накапливаются: сначала стоимость приостановки составляет 10% от суммы ставки, вторая — 20%, затем 30% и так далее, каждый раз увеличиваясь. Это не плоская (фиксированная) величина — это нарастающий эффект.
Это значит, что валидатор/провайдер, работающий близко к минимальному порогу Dusk 1000, имеет куда меньше пространства, чтобы восстановиться. Два или три подряд сбоя — и небольшого стейкера могут в буквальном смысле вытолкнуть ниже минимума. Тогда по документации ставка «замирает» и нужно полностью снять (разстейкнуть) и затем заново застейкнуть, чтобы вернуться — то есть это не просто ожидание окончания приостановки, а реальный сброс.
Большой провайдер, который «съедает» ту же последовательность 10–20–30%, почти не замечает её относительно своего общего стейка. Поэтому то же самое расписание штрафов, предназначенное для равномерного наказания плохого поведения, в итоге сильнее бьёт по небольшим валидаторам — я даже вернулся и перечитал проценты дважды, потому что всё время ожидал, что неправильно понял «увеличивается на 10%» как некую плоскую повторяющуюся величину в 10% вместо наращивания.
Подскажите, где-нибудь вообще рекомендуют минимальный буфер по размеру ставки, чтобы меньшие провайдеры случайно не попадали в этот цикл сброса? 🧐
#dusk $DUSK @Dusk

@Dusk я вернулся прочитать, как на самом деле работает «цитадель сумерек», вместо того чтобы просто повторять питч «privacy plus selective disclosure», и что-то не сходится. «цитадель» описывает пользователя как полностью контролирующего свои данные — он сам выбирает, чем делиться, с кем, и даже может отозвать доступ к ним позже. эта подача всё ещё актуальна — только вот я ожидал, что это будет какая-то отложенная идея 2023 года, но она прямо находится в roadmap'е «цитадели» после mainnet как актуальный элемент zk-kyc/aml.
но регуляторы в целом не хотят опционального доступа. требования к аудиту и отчетности обычно означают обязательную, ничьим отзывом не отменяемую видимость — а не что-то такое, с чем пользователь соглашается один раз и потом может отозвать позже. если «цитадель» даёт пользователям возможность отзывать раскрытие, я не уверен, как это стыкуется с тем, что в других местах использует «цитадель»: «регулятор может увидеть то, что ему нужно» — разве что под этим не лежит отдельный слой комплаенса, который я пока не нашёл.
стоит сказать: пользовательский контроль над данными — это действительно сильная функция приватности для «цитадели», я не спорю с этим. я просто не думаю, что «отзыв раскрытия пользователем» и «гарантированная регулятором» могут одновременно быть правдой для одного и того же раскрытия.
кто-нибудь видел документацию о том, что происходит, если пользователь «цитадели» отзывает доступ после того, как регулятор уже запросил его? 🧐
#dusk $DUSK

@Dusk
я перепроверял(а) график эмиссии по совершенно другому поводу и заметил(а), что два собственных домена dusk вообще не согласуются друг с другом. docs.dusk.network — это реальная страница с токеномикой — говорит о фиксированном 36-летнем окне эмиссии, геометрическом затухании, сокращении вдвое каждые 4 года, всё просто и однозначно. wiki.dusk.network, которая находится на их же поддомене, а не на каком-то случайном стороннем зеркале, утверждает более размытое: диапазон от 18 до 36 лет в зависимости от условий сети.
это не просто погрешность округления — это примерно двукратный разброс по тому, как долго тянется хвост вознаграждений; и я почти списал(а) это на фан-вики, пока не заметил(а), что страница буквально размещена под dusk.network, а не где-то снаружи.
я понимаю, что вариативность блока по времени сдвигает реальную длину календаря немного — с этим всё понятно. но документ под названием "tokenomics" с одним зафиксированным числом, тогда как страница на домене команды приводит диапазон — это не вопрос округления; это два разных ответа на вопрос "когда прекращается эмиссия". для проекта, который построен на точности уровня регуляторных требований, такой разрыв между двумя страницами, которые они оба контролируют, я не ожидаю.
кто-нибудь знает, какой из вариантов сейчас актуален, или же обе страницы просто устарели в разные стороны? 🧐

#dusk $DUSK

@Dusk
я подтянул github dusk вместе с его графиком цены сегодня днем, чтобы проверить, совпадают ли цифры с историей, и они не совпадают — даже близко. десять независимых проверок безопасности до mainnet, chainlink ccip live, cordial systems подключили для институционального хранения, dusk pay отправлен, двухсторонний мост активирован. это не «тихий» квартал для любого l1.
цена сейчас держится около $0.10, сильно в стороне от своего ATH — будто ничего из этого не происходило.
я понимаю, что одни лишь счётчики коммитов не так уж много значат — репозиторий можно «докачать» изменениями в документации, обновлениями зависимостей и назвать это активностью. но десять аудитов и работающая интеграция по хранению — это не косметика; это то, что реально должно работать, прежде чем институции начнут трогать сеть. значит, либо рынок неправильно оценивает риск исполнения — и он уже списан/убран, либо в цене заложено что-то другое, чего я со стороны разработки просто не вижу.
что из этого верно, и если верно второе — что именно в этой github-истории так и не показано, но при этом оценивается? 🧐
#dusk $DUSK

@BabylonLabs_io
babylon mints примерно на 8% больше baby каждый год по фиксированному графику, без исключений. механизм, построенный чтобы компенсировать это, не следует никакому графику — он сжигает baby только тогда, когда bsns направляет реальные стейкинг-вознаграждения через аукцион genesis, а многоплатформенный стейкинг (multi-staking) в мейннете всё ещё не запущен, так что соответствующая часть реестра сейчас в основном пустует.
а аукцион, привязанный к фактической выручке, — это более удачный дизайн, чем произвольная цель по сжиганию, на бумаге. но прямо сейчас фраза «привязанный к фактической выручке» просто описывает формулу, в которую пока ничего ещё не подставлено.
я искал текущий общий объём сжигания и не нашёл опубликованных данных — вероятно, потому что пока их не так уж много, а не потому что кто-то это скрывает.
когда multi-staking ships и bsns начнут маршрутизировать реальный объём, сколько времени нужно, чтобы та «сжигательная» сторона догнала настолько, чтобы это стало реально значимо на фоне 8%? $BABY #baby 🔥