B A S I L KHAN

#dusk $DUSK @Dusk Сегодня я вернулся к истории объявлений NPEX/Dusk по порядку, вместо того чтобы сначала читать самый свежий хайповый пост, и фактическая хронология выглядит иначе, если выстроить всё по времени.
Декабрь 2025: Dusk и NPEX объединяются, чтобы запустить то, что описывается как первый в Европе блокчейн-ориентированный рынок ценных бумаг, при этом NPEX работает как лицензированная нидерландская MTF. Февраль 2025: Cordial Systems подключается как слой кастоди (хранения). Ноябрь 2025: Dusk и NPEX принимают стандарты Chainlink CCIP и DataLink именно для того, чтобы официальный обмен данными NPEX можно было публиковать on-chain. Сам dApp Dusk Trade описывается как работающий на DuskEVM, начиная с токенизированных активов от NPEX, 21X и других институциональных игроков; при этом в более раннем освещении упоминаются цифры вроде €300M в активах.
Это по-настоящему серьёзный регуляторный стек — MTF, лицензии брокера, ECSP, и в описании упоминается, что лицензия DLT-TSS будет выдана в будущем. Это не бумажное партнёрство; NPEX уже ведёт реальный, лицензированный вторичный рынок ценных бумаг в Нидерландах.
Но, просмотрев каждый источник, который смог найти за последние несколько месяцев, я не смог обнаружить ни одного подтверждённого числа о том, сколько активов на самом деле уже запущены и торгуются на Dusk Trade сегодня, в сравнении с тем, сколько активов существует лишь как названные партнёры в анонсах. В каждой найденной ссылке описывались возможности, лицензирование и работы по интеграции — но не текущий подсчёт листингов. Относиться к «€300M в активах» как к уже токенизированным и торгующимся было бы прочтением желаемого результата, а доказательств этому у меня пока нет.
Что я буду проверять дальше: публикует ли Dusk Trade публичный, доступный для запросов счётчик листингов, как это обычно делают биржи; ссылается ли инвесторский сайт NPEX на реальную торговлю на базе Dusk, а не только на само партнёрство; и действительно ли канал Chainlink DataLink прямо сейчас отправляет on-chain живые рыночные данные по NPEX, или же это всё ещё тестирование интеграции.

#dusk $DUSK @Dusk Сегодня я попытался напрямую получить актуальные данные (live numbers) с тестовой сети DuskEVM через обозреватель вместо того, чтобы доверять темам с объявлением, и столкнулся с вещью, которая изменила то, что я в итоге искал.
Тестовый обозреватель работает на Blockscout и обычно предоставляет данные через API, который можно запрашивать — но сама страница рендерится на стороне клиента, поэтому я не смог извлечь текущие числа транзакций/контрактов при прямом запросе. Это реальное ограничение проверки «снаружи браузера», и я не хочу называть цифру, которую на самом деле не проверял.
Но то, что я всё же нашёл, оказалось интереснее простой «сводки по числам». Публичный тестнет DuskEVM был запущен 5 декабря 2025 года — тогда это описывали как «последний шаг перед запуском mainnet». Отдельный экземпляр Blockscout для DuskEVM Mainnet уже существует и индексирует данные начиная с сегодняшнего дня. Этот таймлайн строже, чем формулировка «последний шаг перед mainnet», которая звучала восемь месяцев назад — и при этом пост с тегом Dusk от 10 августа 2026 года всё ещё продвигал тестнет для Solidity/Hardhat-тестирования. Это поднимает реальный вопрос, на какую среду разработчиков сейчас в действительности направляют.
Я также заметил архитектурную особенность DuskEVM, которую стоит отметить: сейчас она работает в режиме sequencer-only, без публичного mempool. Это нормально для rollup на OP Stack на этой стадии, но это означает, что «активность» здесь измеряется иначе, чем на L1 — низкое число транзакций в тестнете не обязательно говорит о низком интересе разработчиков, потому что sequencer-only цепочки не показывают «ожидающую активность» так, как это делает mempool Ethereum.
Вместо того чтобы гадать цифру, которую я не могу подтвердить, сейчас я отслеживаю следующее: начнут ли собственные каналы Dusk направлять разработчиков на обозреватель mainnet вместо testnet, будет ли тестнет явно де-прекейчен (deprecated) или продолжит работать параллельно, и начнут ли по экземпляру Blockscout для mainnet расти числа верифицированных контрактов — не за счёт тестовых скриптов, а благодаря реальным развертываниям.

#dusk $DUSK @Dusk Сегодня я прошёл по реальным репозиториям GitHub, стоящим за Citadel, а не просто прочитал страницу с анонсом, и разрыв между тем и другим оказался больше, чем я ожидал.
Citadel официально представили ещё в январе 2023 года: полный научный труд, рабочий дизайн протокола, три определённые стороны (пользователь, поставщик лицензий, поставщик сервиса) и приватная NFT-модель, созданная специально для решения реальной проблемы, с которой другие системы SSI справлялись хуже: даже когда доказательства с нулевым разглашением скрывают содержимое учётной записи/атрибута, сам он обычно хранится как публичное, отслеживаемое значение в блокчейне. Вклад Citadel целиком заключался в устранении этой утечки.
Инструментарий тоже есть — Moat, Citadel SDK, уже работает: он живёт на GitHub, содержит CLI и API удалённого доступа для разработки поверх протокола, требуя запущенный Rusk-ноду и подключённый кошелёк. Это не «пустые обещания»; код существует, он реальный и открытый.
Но, проверяя текущий центр документации, я наткнулся на замечание, которое меня остановило: SDK «существует, но требует обновлений для актуальной модели Rusk». Это существенный разрыв между тем, что «протокол был разработан и опубликован», и тем, что «протокол активно поддерживается в соответствии с текущей реализацией сети». То, что трёхлетний криптографический дизайн технически корректен, не говорит вам о том, что слой интеграции идёт в ногу с цепочкой, которая с тех пор прошла через многослойный архитектурный сдвиг.
Я не думаю, что это означает, будто Citadel заброшен — privacy-инструменты уровня исследований часто простаивают между всплесками работы по интеграции, особенно пока внимание команды было сосредоточено на DuskDS/DuskEVM/DuskVM. Но это означает, что прямо сейчас, когда говорят о Citadel как об «живой системе комплаенса» (live compliance infrastructure), фактически это преувеличивает то, где SDK находится на самом деле.
За чем я слежу дальше: появится ли коммит, обновляющий Moat под текущую модель Rusk; действительно ли какое-либо названное учреждение или провайдер KYC разворачивает Citadel в продакшене, а не ссылается на него как на кейс; и будет ли Citadel явно включён в дорожную карту DuskEVM/DuskVM или останется отдельным артефактом 2023 года.

#dusk $DUSK @Dusk If someone tells you a payment on Dusk is "confirmed," would you actually release goods, sign a contract, or send a wire based on that word?
Went back through the finality states after realizing I'd been treating "confirmed" and "done" as interchangeable, which isn't actually accurate on this chain.
A block moves through four separate states: Accepted, Confirmed, Stable, and Final. Only Final is deterministic and cryptographically guaranteed genuinely irreversible. Stable is the state just before it, and it's explicitly probabilistic, not absolute. It means the block is buried deep enough that reversal is extremely unlikely, not that reversal is mathematically impossible.
That distinction matters a lot more once real money is involved. If you're accepting a Stable-but-not-yet-Final transaction as settlement releasing an asset, confirming a trade, treating funds as cleared you're accepting a probability, not a guarantee, even though the difference isn't obvious just from reading a status label on a wallet or explorer. The number of blocks needed to actually reach true Final status isn't fixed either; Dusk moved to a "rolling finality" model where the count varies round to round based on network conditions, which means there's no single "wait X blocks and you're safe" rule you can rely on blindly.
@Dusk _Foundation I haven't found a clear, published worst-case number for how long the gap between Stable and Final can actually stretch under real network conditions, only that it's variable by design.
If you're using Dusk for anything involving real settlement, are you actually checking for Final before treating funds as safe or stopping at Stable because the word sounds finished enough?

#dusk $DUSK @Dusk Если отправить DUSK через мост DuskEVM, как именно вы узнаете, что ваши средства в безопасности и ими можно будет пользоваться на другой стороне — и что произойдет, если вы ошибетесь?
Я копал в этом вопросе после того, как почти сделал допущение, которое могло бы стоить мне денег. Мой инстинкт был таким: раз включение подтверждено в блок-эксплорере, значит средства должны быть пригодны для использования. Оказалось, что думать так — ровно неверный подход.
Собственная документация разработчиков Dusk прямо говорит об этом: включение и окончательное подтверждение (settlement) — это два разных этапа, и приложения, передающие ценность между уровнями DuskEVM и DuskDS, явно должны проверять статус протокола или кошелька напрямую — а не делать вывод о финальности просто потому, что прошло какое-то время. Включение транзакций в DuskEVM происходит быстро, потому что это L2 на базе секвенсора, но это не тот момент, когда ваши средства действительно зачислены и защищены от возможных изменений на базовом слое.
Вот что это означает на практике: если вы бриджите активы и отправляете или тратите их, исходя из фразы «скорее всего, уже все готово», вы полагаетесь на предположение, против которого протокол прямо предупреждает. Разрыв между «выглядит как включено» и «фактически окончательно подтверждено» — это именно тот временной промежуток, когда действия слишком рано создают реальный риск: использование средств, которые еще могут быть реорганизованы или признаны недействительными, прежде чем они станут действительно финальными.
@Dusk _Foundation — я не нашел опубликованного числа для реального типичного времени ожидания между включением на DuskEVM и окончательной финальностью settlement на DuskDS при нормальных условиях сети; есть только рекомендация проверять статус, а не считать прошедшее время.
Если сам протокол говорит не оценивать по времени, большинство кошельков и пользовательских интерфейсов мостов действительно показывают пользователям реальный статус settlement, или люди все еще просто следят за таймером и угадывают?

#dusk $DUSK @Dusk Тестирование сценариев выпуска активов на обоих слоях бок о бок: я заметил, что эти два протокола — не просто один и тот же инструмент, перенесённый на разные сети. Они решают проблему приватности с помощью принципиально разной криптографии под капотом.
Zedger работает нативно на DuskDS и построен на UTXO — это означает, что он может обеспечивать полную анонимность способом, который структурно сложно воспроизвести в аккаунтной системе. Hedger работает на DuskEVM: он сделан для полной совместимости с EVM и стандартными инструментами Ethereum. Но поскольку аккаунтная модель EVM не может поддерживать ту же анонимность, которую даёт Zedger, Hedger выбирает совершенно другой технический путь. Он сочетает гомоморфное шифрование (ElGamal по эллиптическим кривым) с доказательствами с нулевым разглашением: балансы и переводы остаются зашифрованными от начала до конца, при этом оставаясь вычисляемыми и поддающимися аудиту — а не просто скрытыми.
И вот что я не ожидал: доказательства Hedger генерируются на стороне клиента, прямо в браузере, менее чем за две секунды. Это реальный тезис по удобству использования, а не рекламная фраза — достаточно быстро, чтобы институциональным пользователям не нужна была выделенная инфраструктура для доказательств, чтобы совершать приватные транзакции на стороне EVM.
Так что реальный выбор между Zedger и Hedger — это не "что приватнее". Это то, какую модель доверия и инструментария нужен эмитенту. Zedger даёт анонимность на уровне UTXO, но требует нативных инструментов Dusk. Hedger даёт полную совместимость с Ethereum и быстрое доказательное вычисление в браузере, но при этом отказывается от того же «потолка» анонимности из‑за аккаунтной модели, на которой он построен.
Я пока не видел однозначного ответа на вопрос, как эмитенту на практике выбирать между двумя вариантами, когда ему нужно одновременно EVM‑совпадение по композиционности и анонимность на уровне Zedger в одном активе — возможно ли это вообще сегодня, или же это вынуждает идти на компромисс, который никто ещё полностью не решил.

#dusk $DUSK @Dusk
Запуская генерацию доказательства локально, чтобы оценить производительность схемы, я заметил кое-что, из-за чего мне пришлось вернуться и прочитать собственные материалы криптографической команды, а не маркетинговые страницы.
Реальные цифры PLONK — это то, что делает обоснование соответствия работоспособным, а не только «приватность» как таковая. Время верификации держится примерно на уровне 6–9 миллисекунд независимо от размера схемы — время генерации растёт в зависимости от сложности схемы (примерно 5,46 секунды для схемы на 2^16 гейтов на относительно скромном железе), но со стороны верификатора всё остаётся быстрым и константным. Эта асимметрия важнее для регулируемых финансов, чем многие думают: аудитору или контрагенту, проверяющему доказательство, не приходится каждый раз тратить значимые вычисления, даже когда логика базовой транзакции становится сложнее.
Чего я не ожидал, так это того, что у самого PLONK была реально раскрытая уязвимость, а не только теоретический риск. Исследовательская команда Dusk нашла критическую проблему в том, как была реализована трансформация Fiat–Shamir — тот элемент, который превращает интерактивное доказательство в неинтерактивное: вместо того, чтобы отправлять ему проверки «на лету», оно получает хэшируемые вызовы. В исходной реализации публичные входные данные хэшировались недостаточно рано, из-за чего ослаблялась гарантия корректности (soundness). Trail of Bits координировала раскрытие, Dusk успела исправить до мейннета и опубликовала исправление публично, а не оставила его «под сукном».
Эта деталь меня не отпускает — цепочка, ориентированная на соответствие требованиям и построенная на криптографической системе доказательств, в продакшн- или близком к нему коде которой был реальный баг по корректности. Его обнаружили и исправили до того, как это стало по-настоящему важно. Я не знаю, сколько ещё реализаций, использующих PLONK где-то в других проектах, оставались уязвимыми, когда это стало публичным, и как долго длился разрыв между раскрытием и тем, как другие команды закрывали патчами свои форки.

#dusk $DUSK Может ли блокчейн быть по-настоящему приватным и при этом позволять регуляторам видеть ровно то, что им законно нужно?
Я не ожидал, что ответ будет зависеть от шифрования ключа другим ключом. Большинство приватных монет решают вопрос приватности, полностью убирая видимость: никто ничего никогда не видит. @Dusk работает на другом допущении: приватность должна быть избирательной, а не абсолютной.
Полезная нагрузка транзакции пользователя шифруется пользовательским ключом, и сам этот ключ шифруется отдельным ключом аудитора, чтобы расшифровать её мог только авторизованный аудитор. Цепочка остаётся скрытой от публики, но доказательства с нулевым разглашением позволяют пользователям доказать, что ключ аудитора был использован корректно, и что полезная нагрузка следует правилам, не раскрывая содержимое никому другому. Это структурно отличается от анонимности: кто-то может видеть происходящее при определённых условиях, даже если публичная цепочка этого никогда не показывает.
Это распространяется и на идентичность. Citadel, слой идентичности Dusk, позволяет пройти KYC один раз, а затем подтверждать право на участие с помощью доказательств с нулевым разглашением, не раскрывая персональные данные заново каждый раз. Он также закрывает пробел в более ранних системах приватной идентификации: даже доказательства, которые якобы не раскрывают информацию, всё равно были привязаны к публичным, отслеживаемым on-chain значениям.
Вот противоречие, которое я не видел разрешённым: избирательное раскрытие защищает вас только в том случае, если ключ аудитора никогда не будет скомпрометирован или использован неправомерно. У приватной монеты нет такого ключа: её гарантия в том, что никто ничего не видит, вообще никогда. Dusk меняет эту абсолютную гарантию на удобство для регуляторов — это как раз ключевой момент для организаций, — но приватность в итоге опирается частично на то, насколько строго управляется доступ аудитора, а не только на математику.
Если приватность в Dusk частично зависит от того, кто держит ключи аудитора, то сколько “приватности в первую очередь” — это криптография, а сколько — институциональное доверие, облачённое в доказательство с нулевым разглашением?

#dusk $DUSK @Dusk Может ли миграция ваших собственных токенов между сетями реально стоить вам денег без всякого взлома?

Я провёл один вечер, изучая код контракта миграции Dusk, прежде чем написать это, потому что «native vs. wrapped» обычно объясняют так, будто это всего лишь косметическая разница. Это не так.
Вот что бросилось в глаза: нативный DUSK использует 9 знаков после запятой, но ERC20/BEP20 DUSK — 18. Контракт миграции конвертирует по фиксированному коэффициенту, и если сумма, которую вы переносите, не является точным кратным 1 LUX, контракт молча округляет вниз. Перенесите сумму с «пылью», которая ниже этого порога, и излишек не возвращается вам в виде нативного DUSK. Он просто исчезает — по замыслу, а не из‑за ошибки.
Отдельно стоит назвать и саму модель доверия. Нативный DUSK в мейннете — это реальный источник правды: когда вы бриджите нативный DUSK в BEP20, протокол сначала блокирует ваши токены в мейннете, и только затем запускает минт на BSC. Обёрнутый BEP20‑токен существует только благодаря этой блокировке; он не подкреплён независимо. Это принципиально иной профиль риска по сравнению с тем, чтобы держать нативный DUSK напрямую, даже если в вашем кошельке отображается один и тот же баланс.
Есть ещё и часть, которая вообще не является компромиссом дизайна — это операционный риск. Чтобы бриджить нативный DUSK в BEP20, нужно указать адрес назначения в поле memo. Если его не указать или указать неверно, документация предельно ясна: мост игнорирует транзакцию, а средства теряются. Никакого отката смарт‑контрактом, никакого автоматического возврата. Просто «пропадает», потому что минту на другой стороне некуда было идти.
Я не думаю, что большинство холдеров проверяют, какую именно версию они держат, прежде чем переводить средства между биржами и кошельками: они просто видят «DUSK» и считают, что это взаимозаменяемые вещи.

Если нативный DUSK — это реальный источник правды, а обёрнутые версии существуют только из‑за механизма «блокировка и минт по доказательству», то почему экосистема делает настолько легко потерять средства из‑за одной пропущенной записи memo?

#dusk $DUSK @Dusk
Что на самом деле означает «без доверия» (trustless), когда мост перемещает ваши активы между двумя разными уровнями исполнения?
Я снова и снова возвращался к этому вопросу после того, как прочитал, как Dusk соединяет DuskDS с DuskEVM, потому что «trustless bridge» используется как маркетинговая фраза почти везде и редко выдерживает внимательное чтение.
Вот что на самом деле происходит: DuskDS — это уровень расчетов и консенсуса; именно там живут окончательность (finality), безопасность и доступность данных. DuskEVM располагается поверх него как отдельная среда исполнения для смарт-контрактов Solidity. Перемещение актива между ними — это не то же самое, что перемещение актива внутри собственного состояния одной цепочки. Это означает, что одному уровню нужно доказать другому, что изменение состояния действительно произошло, без того чтобы какая-либо сторона просто принимала слова другой.
«Нативная» часть — вот что здесь по-настоящему важно. Вместо того чтобы полагаться на внешнюю валидаторную группу или на мультисиг-кастодиана, который хранит обернутые активы — классический дизайн мостов, из-за которого в этой индустрии случалось большинство кроссчейн-эксплойтов — мост встроен прямо в собственные гарантия расчетного протокола. Окончательность DuskDS (состояние «Final», криптографически гарантированное и необратимое) — это то, на чем мост основывается, чтобы подтвердить, что передача действительно безопасно распознается на другой стороне.
Это означает существенно другую модель доверия, чем мост, защищенный отдельным набором подписантов. Но это также означает, что безопасность моста зависит лишь настолько, насколько сильны собственные допущения консенсуса DuskDS: если когда-либо возникнет сценарий, в котором окончательность на основе комитета будет оспорена или задержана, мост унаследует ту же неопределенность, а не получит отдельный риск.
Я пока не нашел четкого ответа: какова фактическая задержка между тем, как DuskDS достигает состояния «Final», и тем, когда актив становится пригодным для использования на DuskEVM, и создается ли этот разрыв окно, в котором рациональный участник может эксплуатировать именно тайминг, а не пытаться сломать криптографию как таковую?
Мост «без доверия» ровно настолько, насколько без доверия уровень расчетов под ним, или DuskEVM добавляет поверх этого собственный независимый риск?

#baby @BabylonLabs_io Если валидатор становится злонамеренным, наказывают всех, кто делегировал ему, вместе, или только тех людей, которых он действительно пытается атаковать?
Не ожидал, что ответ будет включать криптографические трюки с шифрованием, а не просто «да, все теряют свою долю». Наивно предполагал, что слэшинг работает как в большинстве PoS-цепочек: один плохой валидатор — одна коллективная пеня для всех, кто делегировал ему.
Babylon делает иначе, используя адаптерные подписи (adaptor signatures). Когда стейкер делегирует, и сам стейкер, и комитет-«ковенант» предварительно одобряют соглашение, но позже для фактического запуска slashing нужна только собственная подпись делегированного валидатора. Чтобы помешать мошенническому валидатору в одностороннем порядке слэшить средства невиновного стейкера, стейкер шифрует своё предварительное одобрение, используя публичный ключ EOTS самого валидатора. Это означает: если валидатор когда-либо попытается злонамеренно воздействовать именно на этого конкретного стейкера, попытка расшифровать подпись для этого заставляет валидатора «утечь» своей приватной ключ — после чего слэш-ответ становится возможен уже для всего его самоделегированного стейка и для стейка каждого другого делегатора, который к нему привязан.
Иными словами, попытка атаковать одного человека приводит к раскрытию самого валидатора для всех, кто к нему подключён. Это не «изоляция по политике» — это изоляция, принудительно обеспечиваемая тем, что атака становится самоуничтожающей для атакующего.
На что я пока не нашёл удовлетворительного ответа: создаёт ли такая конструкция порочную мотивацию, при которой, будучи скомпрометированным, у валидатора уже «не остаётся потерь», и он скорее постарается максимизировать ущерб для каждого делегатора сразу, а не целиться только в одного?
Если слэшинг одного человека всё равно может каскадно затронуть всех под этим валидатором, насколько в реальности оправдано само описание «изолированного слэшинга»?
#baby $BABY

#baby $BABY Как урезать/«слэшить» валидатора на Bitcoin, если в самом Bitcoin нет встроенной логики слэшинга?
Мне потребовалось дольше, чем ожидал, чтобы реально понять этот момент, потому что ответ — не умный контракт, а схема подписи, которая делает кое-что хитрое с математикой вместо кода.
@BabylonLabs_io использует то, что называется Extractable One-Time Signature (EOTS) — извлекаемую одноразовую подпись, построенную на нативных подписьмах Schnorr в Bitcoin. Вот ключевой трюк: поставщик финальности генерирует уникальную пару ключей для каждой высоты блока, за которую он голосует. Пока он подписывает только один блок на каждую высоту, подпись остается полностью безопасной — ничего не утечёт. Но если он подпишет два конфликтующих блока на одной и той же высоте, математика рушится. Повторное использование этого ключа на уровне высоты, чтобы подписать два разных сообщения, напрямую раскрывает их приватный ключ — потому что так работает математика подписи Schnorr, когда повторно используется одноразовое значение (nonce).
Сама раунда финальности требует подписей более чем от двух третей от веса застейканного BTC, чтобы блок действительно финализировался; значит, любое нарушение безопасности по определению требует, чтобы более чем треть стейка дважды подписала. Именно поэтому гарантия «полностью подлежащая слэшингу» обеспечивается математически, а не является обещанием политики: как только ключ утек, любой — не только Babylon, не только валидатор — может построить и транслировать транзакцию на слэшинг. На этой стадии не нужно голосование комитета, нет процедуры апелляций — только раскрытая математика.
Чего я не видел внятного ответа на: создаёт ли генерация ключей для каждой высоты блока сколько-то значимую операционную нагрузку для провайдеров финальности, которые параллельно работают с несколькими BSN, и может ли сама эта нагрузка стать поверхностью для атаки — например, если провайдер под нагрузкой по ошибке повторно использует случайность, а не делает это из злого умысла?
Безопасность EOTS — это чисто математическая гарантия, или она тихо зависит ещё и от того, что у провайдеров финальности есть надёжная инфраструктура управления ключами?
$BABY

#baby $BABY Раньше я думал, что «неактивный» (idle) запас Биткоина — это фиксированное ограничение: актив, который всегда будет ценнее, если хранить его без движения, чем использовать. Потом я посмотрел, во что на самом деле суммарно превращается «idle».

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

Вот что заставило меня по-другому это увидеть: у любой другой крупной сети безопасность создавалась с нуля — ей приходилось конкурировать за размещённый (staked) капитал, который нужно было создавать, стимулировать и наращивать с нуля годами. У Биткоина этой проблемы нет. Капитал уже существует. Он уже является самым доверенным хранилищем стоимости в этом сегменте. Единственное, чего не хватало, — механизма, который позволит пустить его в работу, не нарушая гарантий кастоди (custody), благодаря которым он изначально и заслужил доверие.

Вот на что ставка — @BabylonLabs_io — и сделана: не в том, что Биткоину нужен новый сценарий применения, а в том, что этот сценарий всё время был «под рукой» и простаивал, заблокированный техническим разрывом, а не отсутствием спроса.

Я не думаю, что это произойдёт в одночасье. Реальное внедрение зависит от того, сколько BSN запустится, от того, что конечные поставщики (finality providers) докажут свою надёжность, и от того, что достаточно делегаторов действительно проделают ту тщательную работу, о которой я писал все эти кампании. Механизм уже работает. Вопрос, сможет ли он масштабироваться хотя бы до значимой доли из этого триллиона долларов, всё ещё открыт — и это не предрешено.

То, за чем я слежу на входе в следующую фазу, — это не общее количество объявленных BSN. Меня интересует, какой процент от этого бездействующего 99% реально начнёт движение.
$1000RATS $IDOL
@BabylonLabs_io #1000sats

#HedgeFundsAddBullishOilBets #OpenAIFindsMoreAgentsEscapedContainment #AmazonRaises2026CapexTo$220B

Сколько бездействующего Биткоина перейдёт в Babylon?

#baby $BABY @BabylonLabs_io

Раньше я думал, что «стейкинг» автоматически означает передачу своих монет кому-то другому до момента вывода. Но потом я разобрался, что на самом деле происходит с моим BTC в тот самый момент, когда он попадает в стейкинг Babylon.

Он никогда не выходит из-под моего контроля.

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

По факту используется Taproot-скрипт с двумя заложенными сценариями расходования. Один позволяет мне вернуть мой BTC, как только истечёт время блокировки (timelock). Другой активируется только в том случае, если делегированный мной валидатор нарушит протокол — это сценарий слэшинга, и это единственный случай, когда мои средства могут выйти за пределы моего изначально задуманный маршрута.

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

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

@BabylonLabs_io Я сравнивал модель Finality Provider от Babylon с обычной PoS-делегацией, и кое-что бросилось в глаза: структура стимулов не симметрична так, как обычно предполагают.
В большинстве делегированных PoS-систем, если ваш валидатор ведёт себя неправильно, вы разделяете наказание — вместе с ними у вас с делегированной доли тоже происходит срез (slashing). В этом весь смысл: это заставляет делегаторов реально проверять, кому они делегируют.
В setup Babylon сохраняется та же базовая идея для Bitcoin: ваш BTC подвергается риску slashing в зависимости от того, какого Finality Provider вы выбираете, хотя вы никогда не передаёте кастодиальные права на монеты напрямую.
Почему это важно: self-custody обычно продают как «безопасность» — и всё. Но self-custody не убирает вашу зависимость от плохого поведения других — она лишь убирает именно кастодиальный риск. Вы можете сохранить полный контроль над своим BTC и всё равно потерять его из‑за slashing, если делегировали небрежно. Это существенно другой риск, чем «мою биржу взломали», но он не равен нулю — и, мне кажется, в сообщениях вокруг стейкинга биткоина иногда эта грань размывается.
Торговая/компромиссная часть, которую стоит проговорить: эта схема перекладывает реальную due diligence на стейкеров. Выбор Finality Provider — это не косметическое решение: это активное решение по риску. Uptime, поведение при подписи и операционная безопасность становятся вашей проблемой по сути тоже. Многие держатели BTC, которые стейкают впервые, не привыкли мыслить так, потому что сам BTC натренировал людей думать в основном о кастодиальном риске и ни о чём больше.
Так что дизайн стимулов на бумаге корректен — теоретически он должен создать рынок, где надёжные Finality Providers зарабатывают доверие, а плохие остаются без делегаций. Сформируется ли этот рынок в реальности, зависит от того, будут ли стейкеры делать due diligence, которое дизайн предполагает.#baby $BABY

Потратил время сегодня на @BabylonLabs_io документов, пытаясь понять, что на самом деле делают Finality Providers (поставщики финальности). Эта роль менее очевидна, чем кажется на первый взгляд.

В обычной PoS-сети валидаторы ставят (стейкают) нативный токен сети, чтобы получить право на голосование. Finality Providers делают иначе. Они получают делегирования BTC от стейкеров и используют это делегированное биткоин-значение как экономический вес для своих голосов за финализацию блоков.

Стейкер никогда не передает свой BTC. Никакие приватные ключи не перемещаются. BTC остается заблокированным в self-custodial-скрипте на Bitcoin. Делегируется не сам BTC, а только представляемая им голосовая сила. Finality Provider отдает голос. Биткоин поддерживает этот голос экономически, не покидая контроля стейкера.

Мое понимание изменилось из-за того, что это означает для PoS-сетей, которые полагаются на такую безопасность. Их защищенность больше не зависит только от того, сколько стоит их нативный токен. Она зависит от экономического веса Bitcoin, стоящего за каждым голосом за финальность. Это принципиально иная основа безопасности, которой сегодня большинство PoS-сетей не имеют.
Сторона со slashing (штрафами) дополняет картину. Если Finality Provider делает двойную подпись, EOTS раскрывает его приватный ключ, а условия slashing выполняются автоматически. Делегированная им голосовая сила имела реальные последствия.

То, на чем я продолжаю задерживаться, — позиция стейкера во всем этом. Вы делегируете Finality Provider, чье поведение вы не можете напрямую контролировать. Криптография защищает ваш принципал. Но ваш выбор провайдера все равно имеет значение для здоровья сетей, которые обеспечиваются его безопасностью.
Если голосовая сила делегирована, но BTC так и не перемещается, как выглядит реальная подотчетность стейкера при выборе того, куда делегировать?

#baby $BABY

#baby $BABY / @BabylonLabs_io
Читая сегодня документацию Babylon, я постоянно останавливался на одном вопросе.

У Биткоина нет смарт-контрактов. Так как же протокол обеспечивает слэшинг для BTC, который так и не покинул биткоин-цепочку?
Ответ — Ковенантный комитет, но не так, как я изначально предполагал.

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

Этот момент с предварительным подписанием изменил то, как я понял всю модель. Комитет не наблюдает за недобросовестным поведением и не реагирует на него. Они подписывают всё заранее. После этого единственная недостающая подпись для исполнения слэшинга — это собственная подпись Финалити-провайдера. И она становится доступной только если провайдер дважды подписывает, а именно это и предназначен выявлять EOTS.

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

Я постоянно видел повсюду «бездоверительное биткоин‑стейкинг‑размещение» и воспринимал это буквально. Потом я действительно прочитал документацию по скриптам стейкинга.

Там есть комитет по кворуму/ковенантам.

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

Без них весь механизм не работает — анбандинг не был бы быстрым, слэшинг нельзя было бы надёжно принудить.

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

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

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

Я проверил. Это стоит сделать до того, как вы заблокируете BTC во что бы то ни было.

Бездоверительность — не бинарная величина. Это шкала, и Babylon продвинулся по ней дальше, чем кастодиальные мосты — но не довёл до конца.

#baby $BABY @BabylonLabs_io

#baby $BABY сегодня я просмотрел @BabylonLabs_io staking доки сегодня, и одна деталь изменила то, как я думаю о том, что здесь на самом деле означает «native».

Любой существующий путь к получению доходности в биткоинах в какой-то момент требует обмена активов. Обёртка превращает ваш BTC в синтетический дериватив, стоимость которого зависит от моста, который его удерживает. Бриджинг перемещает то, что представляет ваш BTC, в другую сеть, пока исходный актив где-то ещё заблокирован. В обоих случаях вы в итоге держите требование (claim) на биткоин, а не сам биткоин.

Механизм стейкинга Babylon работает иначе. Ваш BTC напрямую блокируется в сети Bitcoin с использованием собственного скриптового языка Bitcoin, таймлоков и агрегации подписей — без необходимости какой-либо системы смарт-контрактов на стороне Bitcoin. BTC никогда не становится чем-то другим. Он остаётся ровно тем, что есть: Bitcoin UTXO, внутри самокастодиального скрипта, которым управляет стейкер.

То, что именно делает этот BTC, пока он заблокирован, — вот интересная часть. Он обеспечивает экономическую безопасность сетям proof of stake как делегированный стейк за провайдерами Finality Providers. Если Finality Provider делает двойную подпись, стоящий за ним стейк можно слэшнуть. Наличие Bitcoin в виде реального экономического обеспечения (collateral) — это то, что делает такую безопасность убедительной для сетей, которые на неё опираются.

Деталь про разматывание (unbonding) запомнилась сильнее всего. Обычный вывод (withdrawal) по истечении таймлока не требует никакого сотрудничества со стороны Babylon или какого-либо внешнего оператора вообще. Раннее разматывание требует со-подписи Covenant Committee, затем нужно подождать 7 дней, прежде чем средства станут доступными для вывода. Стейкер всегда может выйти по стандартному пути даже в том случае, если исчезнут все внешние стороны.

Эта независимость — свойство, которое большинство подходов к wrapped BTC не могут воспроизвести. Путь выхода зашит в скрипт Bitcoin при создании vault, а не хранится в чьей-то чужой кастоди.

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

#baby $BABY
Сегодня я просмотрел документацию Babylon, и один номер постоянно меня останавливал. В DeFi используется только 1% биткоина.

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

То, что @BabylonLabs_io создает вокруг, — это другая отправная точка. BTC никогда не покидает биткоин. Он «запирается» в Taproot-скрипт, который подписант-депозитарий соавторски подписывает при создании vault (хранилища). Каждая законная траектория расходования заранее подписывается до того, как vault выходит в онлайн. После этого ни одна сторона не может сфабриковать новый расход. Протокол не может переместить BTC наружу, выдать его в кредит где-то еще или переиспользовать. Обеспечение делает только то, что разрешает скрипт.

Со стороны Ethereum смарт-контракт протокола отслеживает каждый vault и позволяет интегрированному DeFi-приложению рассматривать его как обеспечение. Переходы состояния между цепочками принудительно обеспечиваются криптографией, а не доверенным посредником. Допущение о доверии смещается с платежеспособности кастодиана на криптографию протокола и две лежащие в основе сети.
Тот акцент, который остался со мной, — это то, что Babylon называет vault в его первоначальном смысле. Не контракт на пуллинг капитала, в котором многие пользователи разделяют риск вместе. Это изолированный биткоин-вывод, принадлежащий депозитарию. Ближе к защищенному сейфу в банке, чем к DeFi-ликвидити-пулу.

Если 99% биткоина лежит вне DeFi, потому что каждый существующий путь требует отдавать что-то взамен, как будет выглядеть пространство, если эта цена входа исчезнет???