<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:tt="http://teletype.in/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:media="http://search.yahoo.com/mrss/"><channel><title>menaskop</title><generator>teletype.in</generator><description><![CDATA[Внимание! Этот блог содержит личные исследования menaskop и ничто в нём не является рекомендацией и/или побуждением к действию. Помните об этом. DYOR.]]></description><image><url>https://img2.teletype.in/files/18/63/1863c343-6c75-4454-944c-4baaaf68c3c9.png</url><title>menaskop</title><link>https://teletype.in/@menaskop</link></image><link>https://teletype.in/@menaskop?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop</link><atom:link rel="self" type="application/rss+xml" href="https://teletype.in/rss/menaskop?offset=0"></atom:link><atom:link rel="next" type="application/rss+xml" href="https://teletype.in/rss/menaskop?offset=10"></atom:link><atom:link rel="search" type="application/opensearchdescription+xml" title="Teletype" href="https://teletype.in/opensearch.xml"></atom:link><pubDate>Thu, 23 Jul 2026 07:07:49 GMT</pubDate><lastBuildDate>Thu, 23 Jul 2026 07:07:49 GMT</lastBuildDate><item><guid isPermaLink="true">https://teletype.in/@menaskop/myths-about-web3-lazarus</guid><link>https://teletype.in/@menaskop/myths-about-web3-lazarus?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop</link><comments>https://teletype.in/@menaskop/myths-about-web3-lazarus?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop#comments</comments><dc:creator>menaskop</dc:creator><title>Мифы против Web 3.0 &amp; Web. Кейс №03. Lazarus</title><pubDate>Sat, 18 Jul 2026 05:37:58 GMT</pubDate><media:content medium="image" url="https://img1.teletype.in/files/47/b0/47b0a7a6-3666-4999-93d1-abef6ec47766.png"></media:content><category>OSINT</category><description><![CDATA[<img src="https://img1.teletype.in/files/8d/0a/8d0a87bb-713c-4d98-8caa-3a94dfb6638d.png"></img>Публичная атрибуция операций Lazarus почти никогда не строится на одном индикаторе. Наиболее сильные выводы появляются там, где сходятся несколько независимых доказательств:]]></description><content:encoded><![CDATA[
  <figure id="7UcZ" class="m_column">
    <img src="https://img1.teletype.in/files/8d/0a/8d0a87bb-713c-4d98-8caa-3a94dfb6638d.png" width="1672" />
    <figcaption>Lazarus</figcaption>
  </figure>
  <h2 id="cdmt">Сразу - о главном </h2>
  <p id="8uDU">Публичная атрибуция операций Lazarus почти никогда не строится на одном индикаторе. Наиболее сильные выводы появляются там, где сходятся несколько независимых доказательств: </p>
  <ul id="2O3T">
    <li id="SJ56">верифицируемые вредоносные инструменты;</li>
    <li id="VRDS">повторяемые <a href="https://www.securitylab.ru/glossary/ttps/" target="_blank">TTPs</a>; </li>
    <li id="lqhJ">инфраструктурные пересечения;</li>
    <li id="WBwM">ончейн-практики (финансовые следы в блокчейне);</li>
    <li id="Bchr">человеческие и <a href="https://en.wikipedia.org/wiki/Operational_security" target="_blank">OPSEC</a>‑ошибки. </li>
  </ul>
  <p id="D0Kc">И всё же, официальные действия государств и правоохранителей в виде санкций, предупреждений, обвинительных актов и списков кошельков - стоя в этом списке особняком и на первом месте. </p>
  <p id="TTtg">При этом и <a href="https://attack.mitre.org" target="_blank">MITRE</a>, и <a href="https://cloud.google.com/security/mandiant" target="_blank">Mandiant</a>, и <a href="https://www.crowdstrike.com/en-us/" target="_blank">CrowdStrike</a> отдельно предупреждают, что Lazarus в открытых источниках часто используется как <strong>зонтичное название</strong> для нескольких северокорейских кластеров, которые делят людей, инфраструктуру, м <a href="https://ru.wikipedia.org/wiki/%D0%92%D1%80%D0%B5%D0%B4%D0%BE%D0%BD%D0%BE%D1%81%D0%BD%D0%B0%D1%8F_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0" target="_blank">малварь</a> и tradecraft (совокупность профессиональных навыков, методов, приемов и технологий, используемых в определенной сфере деятельности).  </p>
  <p id="l6by">Поэтому точность бывает высокой на уровне DPRK/RGB nexus (термин из киберразведки, означающий связь (nexus) между Северной Кореей (DPRK) и Reconnaissance General Bureau (RGB) - главным разведывательным управлением КНДР), но ниже - на уровне конкретного подподразделения.</p>
  <blockquote id="5TWH">По самым сильным публичным кейсам видно, что разные типы операций опираются на разные виды доказательств. </blockquote>
  <p id="W1BN"><a href="https://teletype.in/@menaskop/lazarus-03" target="_blank">Для Sony и WannaCry</a> ключевыми были кодовые пересечения, общие артефакты малвари, повторяющиеся инфраструктурные и операционные признаки, а затем... <strong>официальное обвинение США и союзников</strong>. </p>
  <p id="iwnv">Для <a href="https://teletype.in/@menaskop/lazarus-03" target="_blank">ЦБ Бангладеша</a> и более поздних банковских и крипто-хищений связующими элементами стали сочетания малвари,  пересечения по TTP, инфраструктуре, а также следам в SWIFT (банковской среде) и, позднее, on‑chain трассировки, в частности - списков адресов, миксеров и санкционных действий (<a href="https://en.wikipedia.org/wiki/Office_of_Foreign_Assets_Control" target="_blank">OFAC</a>/ФБР). </p>
  <p id="W1CI">Для <a href="https://teletype.in/@menaskop/lazarus-03" target="_blank">3CX/X_TRADER</a> связка строилась в основном на генеалогии малвари, совпадении инфраструктуры и цепочек поставок. </p>
  <p id="OV5S">Для <a href="https://teletype.in/@menaskop/lazarus-03" target="_blank">Ronin, Harmony, Atomic/Bybit</a> на первый план вышли блокчейн‑аналитика, поведенческие паттерны отмывания, кластеризация кошельков и перечисление конкретных адресов, дополненные официальными заявлениями.</p>
  <p id="98fX">Практический, но первичный вывод следующий: IP‑адрес или TTP‑совпадение сами по себе редко достаточны для индентификации Lazarus и/или любой группировки, кот. входит в это понятие, тогда как комбинация из уникальных артефактов, подтверждённого контролируемого кошелька/адреса, долгоживущего инфраструктурного перекрытия и независимого подтверждения от правоохранителей уже даёт высокую или очень высокую степень доверия. Со стороны самих правоохранителей и государств: и это - ключевая проблема. </p>
  <p id="BKgB">Наиболее слабые случаи, когда есть только TTP или только IP, или даже - только социальная инженерия, либо вообще - только похожее отмывание, потому что эти признаки подделываемы, заимствуемы и нередко разделяются несколькими кластерами.</p>
  <h2 id="какие-доказательства-используют-для-атрибуции-к-lazarus">Какие доказательства используют для атрибуции к Lazarus?</h2>
  <p id="I3ek">В открытой практике для Lazarus применяют шесть устойчивых семейств доказательств: ф</p>
  <ol id="80tJ">
    <li id="14rf">Финансовые следы;</li>
    <li id="kRwr">Инфраструктура; </li>
    <li id="idIT">Малварь и её кодовые признаки; </li>
    <li id="USG2">TTP;</li>
    <li id="c2Ve">Операционные (человеческие) признаки;</li>
    <li id="OXsq">Разведывательно‑правовые подтверждения. </li>
  </ol>
  <p id="2AUw">Эта классификация хорошо укладывается и в так называемую алмазную модель анализа вторжений (Diamond Model), которая представляет собой не что иное, как аналитическую платформу по кибер-безопасности, которая используется для обнаружения, расследования и отслеживания кибератак, а также для того, чтобы через расследование связать жертву, инфраструктуру и нападающих. Это если коротко :). </p>
  <p id="SjAJ">Рассмотрим теперь...</p>
  <h2 id="y3Wk">Семейства доказательств </h2>
  <h3 id="svlo">Финансовые следы</h3>
  <p id="ZZma">Сюда входит сразу несколько разноплановых историй:</p>
  <ol id="zMSH">
    <li id="fJip">Адреса кошельков; </li>
    <li id="u0ae">Кластеры адресов; </li>
    <li id="6RhU">Маршруты вывода;</li>
    <li id="ZRp5">Бриджевая активность (bridge activity, сhain‑hopping);</li>
    <li id="Zyks">Использование миксеров;</li>
    <li id="fguR">Время обналички (timing cash‑out). </li>
  </ol>
  <p id="4pk2">Подобный метод даёт наблюдаемую связь контроля денег. Но опять же: особенно сильный сигнал, когда адрес прямо назван гос. органами или когда поток денег консолидируется в уже известных DPRK‑кластерах (DPRK threat cluster - сеть связанных между собой хакерских группировок (например, Lazarus, Kimsuky), спонсируемых властями Северной Кореи (КНДР) для кибершпионажа, кражи криптовалюты и обхода международных санкций), т.е. основным доказательством всего остаётся отнесение со стороны кого-то, а значит - это всегда <strong>операция</strong> <strong>не</strong> <strong>беспристрастная</strong>. </p>
  <p id="iGJ1"><a href="https://home.treasury.gov/news/press-releases/jy0768" target="_blank">OFAC</a>, скажем, идентифицировал адрес Ronin-взлома как принадлежащий именно Lazarus и дополнительные адреса для отмывания (Axie/Ronin), а ФБР перечислил адреса для Bybit, допустим; в свою очередь Elliptic и Chainalysis показали типовые схемы Tornado/Blender/Sinbad, которые считаются как &quot;консолидация с предыдущими DPRK‑взломами&quot; из-за характерного поведения.</p>
  <p id="yDgb">Но что важно для меня? </p>
  <p id="UzM6">Что один поведенческий паттерн отмывания не является доказательством сам по себе: благо тот же <a href="https://www.elliptic.co/blog/analysis/the-100-million-horizon-hack-following-the-trail-through-tornado-cash-to-north-korea" target="_blank">Elliptic</a> прямо пишет, что, например, в Harmony ни один фактор по отдельности не доказывает участия Lazarus.</p>
  <h3 id="D0Bf">Инфраструктура </h3>
  <p id="P8sH">В этот перечень входят:</p>
  <ol id="81ai">
    <li id="PqyI">Домены;</li>
    <li id="wz4e">IP-адреса;</li>
    <li id="yhPY"><a href="https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BE%D1%82%D0%BD%D0%BE%D1%88%D0%B5%D0%BD%D0%B8%D0%B5_%D1%81%D1%82%D0%BE%D1%80%D0%BE%D0%BD_%D1%8D%D0%BA%D1%80%D0%B0%D0%BD%D0%B0" target="_blank">Параметры</a> экранов;</li>
    <li id="Degg">DNS-история;</li>
    <li id="E3Wb"><a href="https://ru.wikipedia.org/wiki/TLS" target="_blank">TLS</a> и сертификаты; </li>
    <li id="Xz6a">Хостинг;</li>
    <li id="MVIh"><a href="https://ru.wikipedia.org/wiki/%D0%96%D1%91%D1%81%D1%82%D0%BA%D0%BE%D0%B5_%D0%BA%D0%BE%D0%B4%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5" target="_blank">Жёсткое кодирование</a> (hardcoded C2);</li>
    <li id="dunc">Dead‑drop resolvers (техника кибератак, при которой вредоносное ПО скрывает адрес своего командного сервера (C2/C&amp;C) на легитимных, популярных интернет-ресурсах вместо того, чтобы жестко прописывать его в своем коде);</li>
    <li id="t0Te">Переменные окружения и проч. </li>
  </ol>
  <p id="FvcZ">Работает данная методология тогда, когда наблюдается устойчивое и нетривиальное перекрытие между разными (уже проведёнными и ещё проводимыми) кампанииями (по сути - взломами в самом широком смысле), а также когда надо сопоставить целые семейства марвари. </p>
  <p id="nfCu">Компания <a href="https://cloud.google.com/blog/topics/threat-intelligence/3cx-software-supply-chain-compromise" target="_blank">Mandiant</a>, расследовавшая атаку на разработчика программного обеспечения 3CX, пришла к выводу, что за ней, вероятнее всего, стояла группировка <strong>UNC4736</strong>, связанная с северокорейскими кибероперациями. </p>
  <p id="zFD8">Основанием для такого вывода стали несколько независимых технических совпадений с ранее известной операцией AppleJeus. Приведу несколько самых важных: </p>
  <ul id="sCy6">
    <li id="92bX"><strong>Во-первых</strong>, в обоих случаях использовался один и тот же тип вредоносной программы - <a href="https://malpedia.caad.fkie.fraunhofer.de/details/osx.poolrat" target="_blank">POOLRAT</a>. Это троян удалённого доступа (Remote Access Trojan, RAT), который позволяет злоумышленникам незаметно управлять заражённым компьютером: запускать команды, загружать и выгружать файлы, устанавливать дополнительное вредоносное ПО и выполнять другие действия.</li>
    <li id="7HBo"><strong>Во-вторых</strong>, исследователи обнаружили использование одного и того же доменного имени journalide[.]org. Под доменным именем здесь понимаю стандартный интернет-адрес, который используется для связи заражённого компьютера с сервером злоумышленников. Совпадение подобных доменов между различными кампаниями считается важным признаком того, что ими управляет один и тот же оператор или одна и та же инфраструктура. </li>
    <li id="XcRJ"><strong>В-третьих</strong>, в обеих операциях применялся одинаковый программный компонент под названием X_TRADER. Это внутреннее название одного из элементов вредоносного комплекса, который использовался атакующими. Повторное использование редко встречающихся компонентов является ещё одним аргументом в пользу связи между атаками.</li>
  </ul>
  <p id="evxj">Кроме того, специалисты обнаружили совпадения DNS- и IP-инфраструктуры (DNS/IP overlaps). Это означает, что различные вредоносные домены в разные периоды времени &quot;разрешались&quot; в одни и те же IP-адреса либо использовали одинаковые серверы, сетевые настройки или инфраструктуру управления. Подобные совпадения редко бывают случайными и часто свидетельствуют о повторном использовании злоумышленниками собственной инфраструктуры.</p>
  <p id="mIPi">Исследовательская компания <strong>ESET</strong> независимо пришла к схожим выводам. Она обнаружила связь между операциями DreamJob и 3CX благодаря анализу Linux-компонентов вредоносного программного обеспечения. Под Linux-компонентами здесь понимаю версии вредоносных программ, предназначенные для операционной системы Linux. Исследователи установили, что эти версии содержали одинаковые участки программного кода, схожую архитектуру и идентичные методы работы, что говорит о высокой вероятности их разработки одной и той же группой.</p>
  <p id="T1qi">Компания <strong>Kaspersky</strong> в свою очередь провела криминалистический анализ (forensic-анализ) одного из серверов управления злоумышленников (C2-сервера, Command-and-Control server). Такой сервер используется для передачи команд заражённым компьютерам и получения от них информации.</p>
  <p id="Xgm6">В ходе расследования было установлено, что оператор практически всегда подключался к этому серверу через прокси-серверы и VPN-сервисы, то есть использовал промежуточные узлы для сокрытия своего реального местоположения и IP-адреса. </p>
  <blockquote id="Yksy">Однако один раз была допущена операционная ошибка (<strong>OPSEC failure</strong>): подключение произошло напрямую из диапазона IP-адресов, принадлежащих Северной Корее. </blockquote>
  <p id="f9kc">Поскольку подобные диапазоны практически недоступны за пределами страны и находятся под государственным контролем, эта ошибка стала одним из наиболее сильных технических аргументов в пользу связи данной операции с северокорейскими государственными киберструктурами.</p>
  <section style="background-color:hsl(hsl(199, 50%, var(--autocolor-background-lightness, 95%)), 85%, 85%);">
    <p id="m67N"><strong>Прим. Menaskop</strong>: при этом никто из исследователей не берётся утверждать, что подобный &quot;след&quot; можно оставить намеренно! Да, представляете: ломают серверы государственны в РФ, США, Китае и т.д., а вот С. Кореи попросту не могут... Мне видится подобный подход, как минимум, странным. </p>
  </section>
  <h3 id="hXky">Малварь, код и артефакт сборки</h3>
  <p id="S3HL">Здесь в свою очередь используются такие параметры, как: </p>
  <ol id="hIVM">
    <li id="WX7X">Общие фрагменты кода;</li>
    <li id="qy53">YARA‑совпадения (т.е. результаты работы инструмента YARA - открытой программы для поиска угроз, который обнаруживает вредоносные программ, сравнивая их код с заранее заданными шаблонами); </li>
    <li id="bGgv">Генотипы малвари; </li>
    <li id="oGrx">Rich Header (скрытый и неофициальный блок метаданных в Windows-файлах формата PE (например, .exe и .dll)); </li>
    <li id="XrWX">Компилятор и/или <a href="https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%BE%D0%B2%D1%89%D0%B8%D0%BA" target="_blank">линкер</a>;</li>
    <li id="PiWi">Константы;</li>
    <li id="PbSB">Формат строк; </li>
    <li id="O67f">Уникальные пароли; </li>
    <li id="mCc1">Конфигурации. </li>
  </ol>
  <p id="b0RG">Это один из сильнейших путей к атрибуции, если совпадения касаются уникального, не библиотечного кода или редких конфигурационных признаков. </p>
  <p id="79Dx">Приведу примеры. </p>
  <p id="KNxP">Kaspersky связал ряд хаков Lazarus через кодовые фичи, перечислю несколько:</p>
  <ul id="dVV7">
    <li id="J10A">Юзер-агенту (User‑agent Mozillar);</li>
    <li id="0dw5">Самоуничтожающиеся <a href="https://habr.com/ru/sandbox/168937/" target="_blank">BAT</a>‑скрипты; </li>
    <li id="Y7Kg">Общий ZIP‑пароль;</li>
    <li id="WVIY">Корейские PE‑resources (данные, встроенные внутрь исполняемых файлов Windows (например, <code>.exe</code>, <code>.dll</code>, <code>.ocx</code>));</li>
    <li id="U3Pq">Метаданные по тайм-зоне. </li>
  </ul>
  <p id="nIDE">WannaCry с другой стороны связали с ранним Lazarus‑образцом по <strong>shared code</strong> (обозначает использование одних и тех же исходников, библиотек или логики в разных программах). </p>
  <p id="0QZr">ESET связал 3CX с Lazarus через сходство SimplexTea &amp; sysnetd&amp; BADCALL (это связанные между собой вредоносные программы (<a href="https://ru.wikipedia.org/wiki/%D0%91%D1%8D%D0%BA%D0%B4%D0%BE%D1%80" target="_blank">бэкдоры</a>) для Linux, которые используются северокорейской хакерской группировкой) и общие ключи. </p>
  <p id="BMzB">Mandiant по 3CX указал в свою очередь на общий <a href="https://ru.wikipedia.org/wiki/RC4" target="_blank">RC4</a>‑ключ, куки _tutma (один из основных служебных файлов системы веб-аналитики Google Analytics)и <a href="https://vaultaire.app/ru/rukovodstva/shifrovanie-aes-256-objasnenie/" target="_blank">AES‑256‑GCM‑поведение</a> (сочетает потоковое шифрование и аутентификацию, а главная особенность поведения - строгий запрет на повторное использование пары &quot;ключ-nonce&quot; (вектор инициализации), что ведёт к утечке ключа и компрометации данных). </p>
  <p id="3QHJ">Поэтому вывод о том, что IP сам по себе слаб - очевиден: <a href="https://unit42.paloaltonetworks.com/unit-42-attribution-framework/" target="_blank">Unit 42</a>, например, специально задаёт IP низкую базовую достоверность из‑за быстрой смены привязки. А вот другие параметры должны вкупе усиливать факторы положительной оценки. </p>
  <section style="background-color:hsl(hsl(199, 50%, var(--autocolor-background-lightness, 95%)), 85%, 85%);">
    <p id="7f1h"><strong>Прим. Menaskop</strong>: если вы внимательно их изучили (прочитали) выше, то поняли примерно то же, что и я: они все могут использоваться как подражателями, так и теми, кто хочет кого-то подставить, так и в целом - для запутывания следов больше, чем для распутывания. </p>
  </section>
  <p id="Cbzr">См. доп.: </p>
  <ul id="L6FB">
    <li id="43rh"><a href="https://securelist.com/big-threats-using-code-similarity-part-1/97239" target="_blank">https://securelist.com/big-threats-using-code-similarity-part-1/97239</a></li>
    <li id="W12l"><a href="https://securelist.com/operation-blockbuster-revealed/73914" target="_blank">https://securelist.com/operation-blockbuster-revealed/73914</a></li>
  </ul>
  <p id="TqcU"><strong>Важно!</strong> Семантика кода даёт направление, но не заменяет аналитика: те же Kaspersky отдельно предупреждают о ложных флагах и о том, что подобные подходы (технологии) можно сознательно отравлять. И да, здесь нет противоречия с тем, что я написал выше: Лаборатория высказалась лишь об одном векторе и осторожна, а я о совокупности ракурсов и куда более жёстко. </p>
  <h3 id="AGwZ">Тактика, методы и процедуры</h3>
  <p id="fZZV">На английском это звучит как TTP (Tactics, Techniques, and Procedures). О них и поговорим. </p>
  <p id="I2tv">Сюда входят параметры:</p>
  <ol id="vGda">
    <li id="qBEl">Техники атакующих; </li>
    <li id="pHJf">Связь первичного доступа с последующим проникновением в системы и вплоть до отмывания средств. </li>
  </ol>
  <p id="HizW">В частности, группировка Lazarus на протяжении многих лет использует схожий набор тактик, техник и процедур (TTP), которые неоднократно фиксировались в различных кампаниях. Именно повторяемость этих методов является одним из факторов, позволяющих исследователям связывать между собой разные атаки.</p>
  <ul id="uqDO">
    <li id="NyzR"><strong>DreamJob / атаки через LinkedIn.</strong> Злоумышленники создают поддельные аккаунты рекрутеров крупных компаний, инвестиционных фондов или криптовалютных проектов. Под видом привлекательной вакансии они устанавливают контакт с жертвой и убеждают открыть вредоносный документ или установить программу, которая заражает компьютер.</li>
    <li id="Dlz7"><strong>Троянизированные криптовалютные приложения.</strong> Нападающие распространяют модифицированные версии программ для торговли криптовалютами, управления кошельками или анализа рынка. Внешне такие приложения выглядят легитимными, однако содержат скрытый вредоносный код, который после установки получает доступ к системе.</li>
    <li id="8VbY"><strong>DLL Sideloading (подмена DLL-библиотек).</strong> Атакующие размещают вредоносную динамическую библиотеку (DLL) рядом с доверенным исполняемым файлом. При запуске легитимная программа автоматически загружает эту библиотеку, позволяя вредоносному коду выполняться под видом обычного приложения и обходить часть механизмов защиты.</li>
    <li id="oeEw"><strong>Многоэтапное заражение (Staged Implants).</strong> Вместо установки полноценного вредоносного ПО сразу злоумышленники сначала запускают небольшой загрузчик, который проверяет окружение и затем постепенно загружает дополнительные компоненты. Такой подход снижает вероятность обнаружения антивирусами и позволяет адаптировать атаку под конкретную цель.</li>
    <li id="gdyL"><strong>Безопасное удаление следов (Secure Deletion).</strong> После выполнения атаки вредоносное ПО может удалять временные файлы, журналы и собственные компоненты таким образом, чтобы максимально затруднить их восстановление и проведение последующей криминалистической экспертизы.</li>
    <li id="yOA0"><strong>Целевой фишинг (Spear Phishing) под видом предложений о работе.</strong> В отличие от массовых фишинговых рассылок, сообщения тщательно готовятся под конкретного человека. Жертве отправляют персонализированное письмо или сообщение с предложением работы, приглашением на интервью либо документами, содержащими вредоносные вложения.</li>
    <li id="YfAJ"><strong>Компрометация цепочки поставок (Supply Chain Attacks).</strong> Вместо прямой атаки на конечную организацию злоумышленники сначала взламывают разработчика программного обеспечения, поставщика услуг или подрядчика. Через обновления доверенного ПО вредоносный код затем распространяется сразу на большое количество клиентов. Одним из наиболее известных примеров такой тактики стала атака на компанию <strong>3CX</strong>.</li>
  </ul>
  <blockquote id="sTqJ">База знаний <strong>MITRE ATT&amp;CK</strong> отмечает, что именно сочетание этих техник регулярно встречается в различных операциях, которые аналитики связывают с группировкой <strong>Lazarus</strong>. Повторяемость инструментов, способов первоначального проникновения, методов закрепления в системе и сокрытия следов является важным элементом атрибуции подобных кибератак.</blockquote>
  <p id="C6eH">TTP‑перекрытие без уникальных артефактов часто даёт лишь умеренноедоверие, потому что методы могут копироваться и мигрировать между близкими DPRK‑кластерами.</p>
  <p id="DSlb">Доп.:</p>
  <ul id="Ngr0">
    <li id="mlZe"><a href="https://cloud.google.com/blog/topics/threat-intelligence/mapping-dprk-groups-to-government" target="_blank">https://cloud.google.com/blog/topics/threat-intelligence/mapping-dprk-groups-to-government</a></li>
    <li id="BqQr"><a href="https://www.welivesecurity.com/2020/06/17/operation-interception-aerospace-military-companies-cyberspies" target="_blank">https://www.welivesecurity.com/2020/06/17/operation-interception-aerospace-military-companies-cyberspies</a></li>
  </ul>
  <h3 id="vtnm">Человеческие и OPSEC‑признаки</h3>
  <p id="N5NN">Что сюда входит? Список следующий:</p>
  <ul id="JXZR">
    <li id="9zyL">Фальшивые аккаунты;</li>
    <li id="KJQd">Дропы;</li>
    <li id="kzay">Язык взломщиков; </li>
    <li id="n4r8">Часовые зоны; </li>
    <li id="k3fJ">Рабочие часы (и операционные дни); </li>
    <li id="Oe4B">Опечатки;</li>
    <li id="OX69">Ошибки операторов; </li>
    <li id="JdBo">Сессии и куки. </li>
  </ul>
  <p id="bny5">Часто это <strong>сшивающий</strong> (синтезирующий) слой между техникой и субъектом, особенно когда артефакты повторяются через годы. </p>
  <p id="oAjZ">DOJ описал повторное использование алиасов (aliases), акаунтов (collector accounts), емэйл и акаунтов в соц. сетях (email/social media accounts) и доступы с северокорейских и китайских IP как единое целое. </p>
  <p id="lAb4">Kaspersky показал рабочий график GMT+8/+9, локализацию корейскую (Korean locale в PE‑resource) и единичный коннект (к C2) из северокорейского диапазона. Kaspersky (по Andariel) описал команды с ошибками и операторские промахи.</p>
  <p id="LDnC">ESET и ФБР неоднократно документировали фальшивых LinkedIn‑рекрутеров. </p>
  <p id="4mtU">Эти признаки <strong>легко</strong> <strong>инсценировать</strong>, поэтому сами по себе они почти никогда не тянут на высокую атрибуцию</p>
  <p id="Bllu">Доп.: <a href="https://securelist.com/big-threats-using-code-similarity-part-1/97239" target="_blank">https://securelist.com/big-threats-using-code-similarity-part-1/97239</a>. </p>
  <h3 id="UaRS">Разведывательно‑правовые подтверждения</h3>
  <p id="7kDs">Этот список внушительный, но сокращу его до главного:</p>
  <ul id="X7Fh">
    <li id="DZtI">Санкции; </li>
    <li id="1lBg">Обвинительные акты; </li>
    <li id="BrPs">Системы или сообщения для информирования пользователей (PSA/alerts: PSA (Public Service Announcement) и Alerts (оповещения)); </li>
    <li id="k5lk">Многосторонние атрибуции; </li>
    <li id="m0Ml">Привязка к RGB/110th Research Center (акже известен как Лаборатория 110 или Отдел 110) - элитное северокорейское подразделение кибервойны.</li>
  </ul>
  <section style="background-color:hsl(hsl(199, 50%, var(--autocolor-background-lightness, 95%)), 85%, 85%);">
    <p id="9ntK"><strong>Прим. Menaskop</strong>: это самый сильный публичный слой: он показывает, что за технической атрибуцией стоит ещё и закрытый массив данных. Но с моей точки зрения - он же самый слабый с т.зр. доказательств. </p>
  </section>
  <p id="r56n">Не раз публично указалась подчинённость Lazarus (Bluenoroff/Andariel) структурам RGB. Скажем, DOJ связал Sony, ЦБ Бангладеша и WannaCry с Park Jin Hyok и Lazurus‑conspiracy. ФБРС многократно публиковал адреса по TraderTraitor (Stake/DMM/Bybit).</p>
  <p id="BOWB">Публичные версии таких кейсов часто короче закрытой доказательной базы, поэтому внешняя воспроизводимость бывает неполной. Это усиливает доверие к выводу, но не всегда раскрывает полную математику решения. Поэтому... </p>
  <p id="417w">Доп.: <a href="https://home.treasury.gov/news/press-releases/sm774" target="_blank">https://home.treasury.gov/news/press-releases/sm774</a></p>
  <h2 id="как-оценивают-надёжность-атрибуции">Как оценивают надёжность атрибуции?</h2>
  <p id="EuLM">Надёжная атрибуция к Lazarus обычно строится не как «да/нет», а как оценка доверия по нескольким осям. </p>
  <p id="DGdy">Базовые опоры здесь та самая Diamond Model, аттак-мэпинг (ATT&amp;CK‑mapping) и разведывательные стандарты по вероятности/уверенности. </p>
  <p id="JzRw">Суть:</p>
  <ul id="1zwO">
    <li id="5oUQ">Diamond Model рекомендует двигаться между &quot;capability, infrastructure, victim и adversary&quot; через аналитические пивоты. </li>
    <li id="8YSC">ATT&amp;CK помогает сравнивать технику и последовательность действий. </li>
    <li id="MRZX">ICD 203 (Intelligence Community Directive 203 - основополагающая директива Разведывательного сообщества США, устанавливающая строгие стандарты для подготовки и оценки всех аналитических продуктов) и практики <a href="https://ru.wikipedia.org/wiki/CIS" target="_blank">CIS</a> требуют отдельно выражать вероятность. </li>
  </ul>
  <p id="7ncq">В практических SOC/CTI‑процессах полезно разделять минимум семь метрик или наборов метрик, поэтому обозначу и их: </p>
  <ul id="QsjF">
    <li id="l7p1"><strong>IOC corroboration (подтверждение индикаторов компрометации)</strong> - показывает, сколько IOC (хэшей, доменов, IP-адресов, криптокошельков и т.д.) подтверждаются независимыми источниками и собственной телеметрией. Чем больше независимых подтверждений, тем выше доверие к индикатору. Методологии вроде <a href="https://www.paloaltonetworks.com/resources/webcasts/unit-42-by-palo-alto-networks" target="_blank">Palo Alto Unit 42</a> дополнительно отдельно оценивают надёжность источника и достоверность самого артефакта.</li>
    <li id="mCnr"><strong>TTP overlap (совпадение тактик, техник и процедур)</strong> - оценивает, насколько вся цепочка поведения злоумышленника совпадает с уже известными операциями. Совпадение полного набора техник (первичное проникновение, закрепление, управление, выполнение целей и т.д.) значительно сильнее, чем совпадение одной отдельной техники, например DLL sideloading.</li>
    <li id="AZL3"><strong>Code similarity score (степень сходства вредоносного кода)</strong> - измеряет количество уникальных общих фрагментов кода, конфигураций и артефактов сборки. Наиболее ценны уникальные участки, отсутствующие в стандартных библиотеках и легитимном ПО. Для оценки применяются YARA-правила (плюс <a href="https://en.wikipedia.org/wiki/Fuzzy_hashing" target="_blank">fuzzy hashing</a> и n-gram-анализ (метод обработки текстов, разбивающий их на последовательности из n элементов (слов, слогов или символов)), сравнение графов, Rich Header (см. выше) и другие методы.</li>
    <li id="Zsz5"><strong>Blockchain clustering confidence (уверенность в кластеризации блокчейн-адресов)</strong> - показывает вероятность того, что группа адресов принадлежит одному оператору или связана с уже известным кластером. Наиболее сильным доказательством считается совпадение с адресами, официально опубликованными FBI или OFAC. Ниже по силе - связи с известными кластерами и характерные схемы отмывания средств.</li>
    <li id="Ezwd"><strong>WHOIS/IP reuse frequency (повторное использование инфраструктуры)</strong> - оценивает, насколько часто домены, IP-адреса и серверная инфраструктура повторяются между различными атаками. Регулярное повторное использование C2-инфраструктуры, одинаковых доменов или IP-адресов существенно усиливает атрибуцию, тогда как единичное совпадение имеет небольшой вес.</li>
    <li id="P42O"><strong>Temporal correlation (временная корреляция)</strong> - анализирует совпадения по рабочему графику операторов, последовательности событий и временным паттернам вывода средств. Например, совпадение часов активности, пауз в отмывании средств или последовательности &quot;взлом =&gt; развёртывание инфраструктуры =&gt; вывод средств&quot; усиливает атрибуцию, хотя само по себе не является доказательством.</li>
    <li id="AiWq"><strong>Kill-chain mapping (сопоставление полной цепочки атаки)</strong> - показывает, насколько вся операция соответствует историческому сценарию действий конкретной группировки: от первоначального вектора атаки (например, фишинга, троянизированного приложения или компрометации цепочки поставок) до закрепления, кражи данных и последующего отмывания похищенных активов. Чем больше совпадений по всей цепочке, тем выше уверенность в атрибуции.</li>
  </ul>
  <p id="W4Os">Отмечу, что для обозначения доверия разумно использовать разведывательную шкалу, а не категоричное <strong>точно/не точно</strong>. </p>
  <p id="twbp">В ICD 203 и в практике CIS диапазоны вероятности выражаются словесно - от almost no chance до almost certain - а уверенность делится на high / moderate / low confidence в зависимости от качества, количества и согласованности источников. </p>
  <p id="jCqk">Поэтому на русском использую те же подходы. </p>
  <p id="HhCn">CIS, например, определяет высокую степень уверенности (high confidence) как оценку на основе качественной информации из нескольких надёжных источников с минимальным конфликтом; умеренную степень уверенности (moderate confidence) - как правдоподобную, но недостаточно подтверждённую; с низкой степенью уверенности (low confidence) - как фрагментарную и плохо подтверждённую (corroborated).</p>
  <p id="dRPw">Для прикладной оценки атрибуции именно к Lazarus полезна следующая операционная шкала как аналитический синтез на основе Diamond Model, Admiralty, ICD 203 и практики публичных кейсов Lazarus. Она не является отраслевым стандартом, но хорошо отражает то, как реально звучат качественные публичные выводы.</p>
  <p id="B6oO">Получаем следующую историю:</p>
  <ul id="cP6F">
    <li id="jy3S"><strong>Очень высокая</strong>. Есть официальное указание адресов/кошельков/операторов от ФБР/OFAC/<a href="https://www.justice.gov" target="_blank">DOJ</a>инезависимая техническая корреляция по малвари/инфраструктуре/поведению.</li>
    <li id="UVlO"><strong>Высокая</strong>. Есть минимум три различных семейства доказательств, включая хотя бы одно из следующих: &quot;co‑residency malware, hardcoded C2/keys&quot; и плюс адреса из санкционных/правоохранительных публикаций, повторяемое инфраструктурное перекрытие через время.</li>
    <li id="cy7v"><strong>Средняя</strong>. Есть два семейства доказательств, но без прямого правоохранительного артефакта; например, &quot;code overlap + TTP overlap&quot; или &quot;blockchain behavior + target profile&quot;.</li>
    <li id="rGVH"><strong>Низкая</strong>.Атрибуция основана в основном на TTP, географии жертвы, языке, IP или похожем паттерн отмыва (laundering pattern) без жёсткой &quot;сшивки&quot;. </li>
  </ul>
  <p id="CkRB">Отдельно важно учитывать вес отдельного артефакта. Unit 42 напрямую показывает, что IP‑адрес по умолчанию должен считаться слабым артефактом и может начинать с достоверности уровня 4 / Doubtfully True, пока не появятся hardcoded config и active C2 telemetry, тогда как телеметрия может стартовать с высокой надёжности источника. </p>
  <p id="ome1">В той же логике артефакт типа &quot;адрес из PSA FBI&quot; или &quot;ко‑резидентность Gopuram и AppleJeus на одной машине&quot; существенно тяжелее, чем &quot;похоже на прошлые приёмы Lazarus&quot;. </p>
  <h2 id="ключевые-инциденты-и-конкретные-доказательства">Ключевые инциденты и конкретные доказательства</h2>
  <p id="JJLq">Ниже приведены репрезентативные инциденты, по которым в открытых источниках наиболее хорошо виден механизм атрибуции. </p>
  <p id="oXWZ">Я сознательно смешиваю разрушительные атаки, банковские хищения, атаки на цепочки поставок и крипто‑операции: именно так лучше видно, что у Lazarus нет одного <strong>универсального</strong> <strong>отпечатка</strong>, а есть меняющийся набор доказательств, который собирается по‑разному в зависимости от цели операции.</p>
  <h3 id="QzZJ"><strong>Sony Pictures (2014)</strong></h3>
  <p id="Eyzv"><strong>Использованные доказательства:</strong> Министерство юстиции США (DOJ) связало атаку с Lazarus через участников группы, псевдонимы, связанные эл. почты и адреса в соц. сетях, кошельки, прокси-сервисы, общие библиотеки вредоносного ПО и инфраструктуру. Дополнительно Kaspersky (Operation Blockbuster) выявила повторное использование кода, одинаковые компоненты (Mozillar, BAT self-delete), общий пароль ZIP-архивов, корейскую локаль и совпадающие рабочие часы (GMT+8/+9). Оценка надёжности: Высокая.</p>
  <h3 id="OCIu"><strong>ЦБ Бангладеш (2016)</strong></h3>
  <p id="NKSc"><strong>Использованные доказательства:</strong> Kaspersky показала связь банковских атак (Bluenoroff) с более широким кластером Lazarus на основе вредоносного ПО и инфраструктуры. Позже Министерство финансов США официально указало, что Bluenoroff/Lazarus похитили около $80 млн, используя компрометацию SWIFT и вредоносное ПО, сходное с ранее известными образцами. Оценка надёжности: Высокая.</p>
  <h3 id="2rLR"><strong>WannaCry (2017)</strong></h3>
  <p id="7XcT"><strong>Использованные доказательства:</strong> Основным аргументом стало обнаружение уникальных общих фрагментов кода между ранними версиями WannaCry и образцами Lazarus 2015 года. Позже Kaspersky использовала этот кейс как пример эффективности анализа сходства кода, а правительства Великобритании и США (NCSC и Treasury) публично атрибутировали атаку Северной Корее/Lazarus. Оценка надёжности: Средне-высокая.</p>
  <h3 id="ZKqa"><strong>Operation DreamJob / In(ter)ception (2019-2020)</strong></h3>
  <p id="YTgz"><strong>Использованные доказательства:</strong> ESET выявила использование поддельных аккаунтов рекрутеров в LinkedIn, приманок в виде вакансий, техники Living-off-the-Land (тратегия кибератак, при которой злоумышленники используют легитимные, встроенные инструменты операционной системы и доверенное ПО для выполнения вредоносных действий), сходной среды разработки и антианалитических механизмов. При этом исследователи прямо указали, что<em> не располагают сильными доказательствами</em>, а лишь признаками возможной связи с Lazarus, включая пересечение с NukeSped. Оценка надёжности: Средняя.</p>
  <h3 id="qFN3"><strong>3CX и предшествующая атака X_TRADER (2022-2023)</strong></h3>
  <p id="vBQw">Использованные доказательства: Mandiant связала 3CX с AppleJeus/X_TRADER через совпадения в доставке полезной нагрузки, общий RC4-ключ, одинаковые криптографические реализации, POOLRAT, домен journalide[.]org и пересечения DNS/IP-инфраструктуры. Kaspersky обнаружила совместное использование Gopuram и AppleJeus, а ESET дополнила картину Linux-компонентами (SimplexTea, sysnetd, BADCALL, SIMPLESEA) и оценила связь с Lazarus как высоко достоверную. Оценка надёжности: Средне-высокая / высокая.</p>
  <h3 id="wok3"><strong>Ronin Bridge (2022)</strong></h3>
  <p id="ugeV"><strong>Использованные доказательства</strong>: OFAC официально санкционировало адрес эксплойтера как принадлежащий Lazarus. Elliptic показала типичную схему действий группировки: социальную инженерию против операторов валидаторов, обмен украденных USDC на ETH, использование централизованных бирж и Tornado Cash, а также сходство с предыдущими криптовалютными операциями Lazarus. Оценка надёжности: Высокая.</p>
  <h3 id="DSTR"><strong>Harmony Horizon (2022)</strong></h3>
  <p id="MJZ9">Использованные доказательства: FBI официально атрибутировало атаку Lazarus/APT38. Ещё до этого Elliptic отмечала, что отдельные признаки сами по себе ничего не доказывают, однако их совокупность - компрометация мультисиг-ключей, вероятная социальная инженерия против команды проекта, программное дробление средств через Tornado Cash, сходство с Ronin и характерные временные паттерны - указывает на Lazarus. Позже Chainalysis и OFAC также связали использование Sinbad, Tornado Cash и Blender с северокорейскими операциями. Оценка надёжности: Высокая.</p>
  <h3 id="glTU"><strong>Atomic Wallet, Alphapo, CoinsPaid и Stake (2023)</strong></h3>
  <p id="40io"><strong>Использованные доказательства:</strong> FBI объединило эти инциденты в серию TraderTraitor/Lazarus и опубликовало конкретные Bitcoin- и EVM-адреса злоумышленников. Chainalysis по Atomic Wallet показала &quot;chain-hopping&quot;, использование мостов, Sinbad и последующую консолидацию средств. По Stake FBI также опубликовало адреса и напрямую связало атаку с Lazarus/APT38. При этом первоначальный способ компрометации Atomic Wallet в открытых отчётах окончательно не установлен. Оценка надёжности: Высокая, однако первоначальный вектор атаки Atomic Wallet остаётся <em>неуточнённым</em>.</p>
  <h3 id="Fvvx"><strong>DMM Bitcoin (2024)</strong></h3>
  <p id="ttzi"><strong>Использованные доказательства:</strong> ФБР, DC3 и Национальное полицейское агентство Японии (NPA) восстановили полную цепочку атаки: поддельный рекрутер в LinkedIn =&gt; вредоносное тестовое задание на Python =&gt; компрометация сотрудника Ginco =&gt; кража сессионных кукисов =&gt; выдача себя за сотрудника =&gt; проведение легитимной транзакции DMM =&gt; вывод средств на известные кошельки TraderTraitor. Это один из наиболее полных примеров атрибуции по всей цепочке атаки. Оценка надёжности: Высокая.</p>
  <h3 id="jpZf"><strong>Bybit (2025)</strong></h3>
  <p id="BLYY"><strong>Использованные доказательства:</strong> ФБР официально связало кражу около $1,5 млрд с группировкой TraderTraitor и опубликовало адреса злоумышленников. Ещё до заявления FBI компания Elliptic атрибутировала атаку Северной Корее на основе анализа схем отмывания средств. Chainalysis показала, что похищенные активы консолидировались вместе со средствами из предыдущих атак КНДР, а сама операция соответствовала характерному сценарию Lazarus: социальная инженерия, манипуляция пользовательским интерфейсом и JavaScript, а затем многоступенчатое отмывание средств через различные сервисы. Оценка надёжности: Высокая.</p>
  <h2 id="ZJPU">Выводы</h2>
  <p id="OHWU">Если посмотреть на эти кейсы поперёк времени, видно, что для деструктивных/шпионских операций сильные сигналы чаще исходят из малварь‑генеалогии, инфраструктуры, подготовительных операций и OPSEC, а для финансовых - из ончейн-расследования и последующего государственного &quot;наименования&quot;. </p>
  <p id="dB4K">С 2018 года особенно заметно смещение части северокорейской экосистемы в сторону криптовалют (trojanized trading apps) и мостов/кошельков; CrowdStrike в 2026 году даже пересобрал старую схему и выделил отдельные линии GOLDEN CHOLLIMA и PRESSURE CHOLLIMA под финансовые цели при сохранении общего DPRK‑ядра.</p>
  <h2 id="связи-между-инцидентами-инфраструктурой-и-финансовыми-следами">Связи между инцидентами, инфраструктурой и финансовыми следами</h2>
  <p id="8PED">Ниже - аналитическая схема, составленная по публичным связям из отчётов Kaspersky, ESET, Mandiant, FBI, Treasury, Chainalysis и Elliptic. Она не претендует на полноту всех подкластеров и показывает именно опорные публично документированные мосты атрибуции.</p>
  <p id="uVGz">Публикую на английском языке, чтобы не было разночтений по наименованиям:</p>
  <ul id="fer9">
    <li id="4ykY">Lazarus[Lazarus umbrella]</li>
    <li id="Ciw8">RGB[RGB / государственная привязка]</li>
    <li id="WyUj">Lazarus =&gt; RGB</li>
  </ul>
  <p id="YFmc"></p>
  <ol id="kL6i">
    <li id="qpn9">Sony[Sony 2014]</li>
    <li id="jObE">Bangladesh[Bangladesh 2016]</li>
    <li id="ek8J">WannaCry[WannaCry 2017]</li>
    <li id="978h">DreamJob[DreamJob / In(ter)ception]</li>
    <li id="Mjk6">XTRADER[X_TRADER supply chain]</li>
    <li id="AG4X">ThreeCX[3CX supply chain]</li>
    <li id="dl1z">Ronin[Ronin 2022]</li>
    <li id="jF6P">Harmony[Harmony 2022]</li>
    <li id="sDBH">Atomic[Atomic / Alphapo / CoinsPaid / Stake 2023]</li>
    <li id="F2im">DMM[DMM Bitcoin 2024]</li>
    <li id="53bn">Bybit[Bybit 2025]</li>
  </ol>
  <p id="jW0n"></p>
  <ul id="B4mL">
    <li id="7uER">Destover[Destover / Hangman / Blockbuster traits]</li>
    <li id="RryA">Gopuram[Gopuram]</li>
    <li id="kt37">AppleJeus[AppleJeus / POOLRAT / CoinGoTrade]</li>
    <li id="BeQN">BADCALL[BADCALL / SimplexTea / SIMPLESEA]</li>
    <li id="VlCv">TraderTraitor[TraderTraitor]</li>
    <li id="9cJp">Swift[SWIFT access &amp; bank tooling]</li>
    <li id="N5vL">TCash[Tornado Cash]</li>
    <li id="QWOY">Blender[Blender]</li>
    <li id="agle">Sinbad[Sinbad]</li>
    <li id="jLWr">Railgun[Railgun]</li>
    <li id="As5G">CoinJoin[CoinJoin / chain-hopping]</li>
    <li id="5bIv">Wallets[FBI / OFAC wallet lists]</li>
  </ul>
  <p id="O0gE"></p>
  <ol id="aUlP">
    <li id="jBlp">Sony =&gt; Destover</li>
    <li id="8u9y">Bangladesh =&gt; Swift</li>
    <li id="9Jh7">Bangladesh =&gt; Destover</li>
    <li id="sDgO">WannaCry =&gt; Destover</li>
  </ol>
  <p id="6n1F"></p>
  <ul id="nvYD">
    <li id="UWoI">DreamJob =&gt; AppleJeus</li>
    <li id="Ao0w">DreamJob =&gt; BADCALL</li>
    <li id="Ux25">XTRADER =&gt; AppleJeus</li>
    <li id="Mocy">ThreeCX =&gt; Gopuram</li>
    <li id="Iuuh">ThreeCX =&gt; AppleJeus</li>
    <li id="z37T">ThreeCX =&gt; BADCALL</li>
    <li id="D1kj">XTRADER =&gt; ThreeCX</li>
  </ul>
  <p id="GUiB"></p>
  <ol id="9rFm">
    <li id="eccn">Ronin =&gt; TraderTraitor</li>
    <li id="MZMg">Ronin =&gt; Blender</li>
    <li id="yi5w">Ronin =&gt; TCash</li>
    <li id="d9Uu">Ronin =&gt; Wallets</li>
  </ol>
  <p id="HGOL"></p>
  <ul id="6G8y">
    <li id="EwHD">Harmony =&gt; TraderTraitor</li>
    <li id="pQIH">Harmony =&gt; TCash</li>
    <li id="1KQJ">Harmony =&gt; Railgun</li>
    <li id="zZbR">Harmony =&gt; Sinbad</li>
  </ul>
  <p id="vVCp"></p>
  <ol id="3qzI">
    <li id="PelA">Atomic =&gt; TraderTraitor</li>
    <li id="9OTt">Atomic =&gt; Sinbad</li>
    <li id="Nty2">Atomic =&gt; Wallets</li>
  </ol>
  <p id="iDHm"></p>
  <ul id="ZjTd">
    <li id="bIBW">DMM =&gt; TraderTraitor</li>
    <li id="Y5js">DMM =&gt; CoinJoin</li>
    <li id="KY4f">DMM =&gt; Wallets</li>
  </ul>
  <p id="ODaL"></p>
  <p id="JQJV">Bybit =&gt; TraderTraitor</p>
  <p id="pNP2">Bybit =&gt; Wallets</p>
  <p id="Skcg"></p>
  <p id="BX20">Эволюция поэтому выглядит так: сначала публичное ядро Lazarus ассоциировалось с разрушительными и саботажными кампаниями - Sony, DarkSeoul, Operation Troy и затем WannaCry; затем параллельно усилился финансовый контур через Bluenoroff / APT38 / AppleJeus и банковые SWIFT‑хищения; после 2021–2022 годов основной публично наблюдаемый денежный след сместился в криптобиржи, кошельки, бриджи и атаки на цепочки поставок. Именно поэтому для более новых кейсов роль ончейн и адресной публикации кошельков стала существенно выше, чем в ранних операциях.</p>
  <p id="R4lW">ИИ всё свёл вот в такую диаграмму:</p>
  <figure id="ZoDH" class="m_column">
    <img src="https://img3.teletype.in/files/ec/f0/ecf0c52a-1571-4b92-89a5-851488b6c345.png" width="2192" />
    <figcaption>Данные от ChatGPT</figcaption>
  </figure>
  <p id="E6eO">Эта шкала также показывает, почему старые и новые кейсы нельзя оценивать одной линейкой. В ранних кейсах преобладали forensic‑и malware‑свидетельства; в более поздних — <strong>адресная блокчейн‑аналитика и санкционные действия</strong>. Одновременно taxonomy усложнилась: чем больше публичных материалов, тем яснее, что «Lazarus» — это не одна стабильная команда, а система близкородственных операторов внутри DPRK‑экосистемы.</p>
  <h2 id="ограничения-ложные-совпадения-и-контратрибуция">Ограничения, ложные совпадения и контр‑атрибуция</h2>
  <p id="8GjT">Главное ограничение - <strong>терминологическое</strong>. В публичных отчётах под словом Lazarus могут скрываться разные связки: Lazarus как &quot;зонтик&quot; для многих групп, Bluenoroff как финансовое крыло, Andariel как отдельный кластер, APT38, TraderTraitor, AppleJeus и иные. </p>
  <p id="sAkh">Это означает, что публичное утверждение &quot;это Lazarus&quot; иногда корректно только в смысле связи с DPRK‑nexus, но не обязательно в смысле точного подразделения. </p>
  <p id="Nrzi">Mandiant и CrowdStrike прямо подчеркивают, что общие люди, фреймворки и инфраструктура затрудняют детальную развязку.</p>
  <p id="wWzE">Второе ограничение - <strong>ложные совпадения по коду</strong>. Kaspersky показывает две важные вещи одновременно: с одной стороны, общий код (shared code) реально даёт сильнейшие указания; с другой - схожие технологии могут ошибаться, если атакующий сознательно подмешивает заимствованный код (borrowed code), библиотечные фрагменты или устанавливает фальшивые флаги (false flags). </p>
  <p id="tCxt">Поэтому кодовые совпадения надо фильтровать на предмет &quot;уникального, не библиотечного&quot; материала и затем проверять дополнительными данными. Иначе можно перепутать заимствование техники с заимствованием авторства.</p>
  <p id="uc6g">Третье ограничение - <strong>слабость отдельных инфраструктурных</strong> данных. IP‑адреса, whois‑сведения и даже домены часто переиспользуются через общий хостинг (shared hosting), диапазоны (от) провайдеров, прокси, VPN и заранее скомпрометированные серверы. </p>
  <p id="m3qZ">Unit 42 специально отмечает, что IP по умолчанию заслуживает низкой оценки и должен повышаться только при наличии других данных (hardcoded config, active C2 telemetry) или другого контекста. Поэтому &quot;этот IP тоже мелькал рядом с Lazarus&quot; - слабый аргумент; &quot;этот IP сидит в конфиге малвари, виден в телеметрии и перекрывается с инфраструктурой AppleJeus&quot; - уже более сильный.</p>
  <p id="rkVf">Четвёртое ограничение - <strong>блокчейн‑паттерны сами по себе не абсолютны</strong>. Elliptic в кейсе Harmony прямо формулирует правильную оговорку: ни один фактор в отдельности не доказывает участие Lazarus; убеждает сочетание факторов - техника атаки, профиль жертвы, использование определённых инструментов (programmatic Tornado deposits, APAC‑timing), повторение схемы (Ronin) и последующее подтверждение ФБР. Это особенно важно потому, что миксеры, бридж‑маршруты, кроссчейн-транзакции могут копироваться другими преступниками.</p>
  <p id="1tCC">Пятое ограничение - <strong>контр‑атрибуция и скрытие следов</strong>. В публичных кейсах Lazarus регулярно использовал прокси/VPN, поддельные рекрутерские аккаунты, фальшивые компании и приложения, куки/сессии, троянизированные легитимные пакеты и др. (DLL sideloading, secure deletion), а при финансовых операциях - схожие инструменты (Tornado Cash, Blender, Sinbad, Railgun, мосты) и консолидирующие адреса. Всё это снижает точность одиночного наблюдения и требует многослойной проверки.</p>
  <h2 id="как-проверить-и-воспроизвести-выводы">Как проверить и воспроизвести выводы?</h2>
  <p id="NnS8">Если цель - воспроизвести публичную аргументацию по Lazarus максимально близко к исходникам, набор данных должен включать три параллельных слоя. </p>
  <p id="7h42">Первый - форензика и малварь: образцы, хэши, конфиги, память, логи (EDR/SIEM, PE/ELF/Mach‑O metadata, build artifacts, YARA‑совпадения). </p>
  <p id="5nEa">Второй - инфраструктура: в самом широком смысле (passive DNS, исторические A‑/AAAA‑/NS‑резолвы, TLS‑сертификаты, WHOIS, netflow/PCAP, URL history, sandbox telemetry). </p>
  <p id="yAru">Третий - финансовые сегмент: адреса из ФБР/OFAC/правоохранительных релизов, ончейн-графы, данные (об обменах и т.п.). Именно такое сочетание лежит под лучшими публичными кейсами Lazarus.</p>
  <p id="1Afc">Для малварь‑части основной рабочий набор - это YARA‑поиск, реверс-инжиниринг и сравнение кода. Kaspersky описывает полезные подход (sub‑checksums, CFG/graph comparison, n‑grams, fuzzy hashes, metadata analysis и поиск уникальных genotypes, не встречающихся в чистом ПО) - их тоже можно и нужно использовать. </p>
  <p id="KqQE">На практике это означает, что для проверки связей между инцидентами Lazarus нужно искать не просто похожие строки, а редкие фрагменты, конфигурационные ключи, пароли (hardcoded passwords), куки, константы, Rich Header и совместимость с уже известными наборами правил. </p>
  <p id="LKXB">Для инфраструктурой части воспроизведение должно идти через историческую корреляцию, а не &quot;снимок на сегодня&quot;. Нужно проверять, какие домены резолвились в те же IP в то же окно времени, какие сертификаты и хосты повторялись (доп.: были ли hardcoded C2 и active beacons, встречались ли одни и те же резолвер‑узлы между разными кампаниями). </p>
  <p id="jV42">Хороший пример - 3CX/X_TRADER, где атрибуция усиливалась не одним доменом, а цепочкой: компрометированный сайт, предыдущая версия ПО, POOLRAT, <code>journalide[.]org</code>, CoinGoTrade/JMT Trading  и др. </p>
  <p id="DfrZ">Для blockchain‑части ключевой принцип - строить граф контроля средств, а не только список переводов. </p>
  <p id="iun9">Надо отделять: адреса, прямо названные правоохранителями; адреса первого уровня от эксплоита и т.д. (&quot;consolidation nodes; bridge‑переходы; mixer exposure; cash‑out endpoints&quot;). </p>
  <p id="Cc9G">Chainalysis и Elliptic показывают, что именно графовые признаки  (wallet clustering, exposure through transaction graph, repeated laundering signatures, consolidation with previously known DPRK funds) превращают сырой блокчейн в атрибуционное доказательство. Для целого ряда свежих кейсов репликация без ончейн фактически невозможна.</p>
  <h3 id="fo7l">Практически воспроизводимый воркфлоу выглядит так</h3>
  <p id="Woh3">Сначала нужно собрать и нормализовать артефакты по Diamond Model: жертва (victim) - от неё уже связки (capability, infrastructure, possible adversary hypotheses). </p>
  <p id="F6s6">Затем - сделать ATT&amp;CK‑mapping и проверить полноту даных. После этого - оценить каждый артефакт (по reliability/credibility), используя логику Admiralty, где IP не равен вводным (malware sample), а телеметрия не равна блог‑сводке. </p>
  <p id="KsSv">Далее - построить корреляционную сетку (code overlap, infra overlap, temporal overlap, wallet overlap, victimology overlap). Только после этого разумно повышать вывод до высокого.</p>
  <p id="JPqT">Наконец, при проверке выводов по Lazarus важно фиксировать, какие детали всё ещё неуточнённы в открытых источниках. </p>
  <p id="KhkZ">Например, по Atomic Wallet сам начальный вектор в публичном отчёте Chainalysis остаётся нераскрытым; по Harmony и Ronin ключевой вектор описывается как вероятная компрометация через соц. инженерию, а не как полностью раскрытая техническая ошибка; по некоторым кейсам часть внутренней телеметрии остаётся за пределами публичных материалов. </p>
  <blockquote id="iWPi">Эти пробелы не отменяют атрибуцию, но должны честно ставиться в скобки при любой независимой перепроверке.</blockquote>
  <p id="jWOG">В сухом остатке, наиболее воспроизводимая и защищаемая публичная атрибуция к Lazarus получается тогда, когда можем  показать не один след, а целую связную историю: как жертву выбрали, как вошли, какую малварь принесли, на какой инфраструктуре он работал, как был сохранён доступ, куда вывели деньги или данные, и какой из этих узлов уже подтверждён независимыми расследованиями или государственными действиями. </p>
  <p id="uBud">Именно этот многослойный подход и отличает сильные кейсы Lazarus от слабых... Проблема в том, что их - крайне мало... </p>
  <p id="anM9">До!</p>

]]></content:encoded></item><item><guid isPermaLink="true">https://teletype.in/@menaskop/myths-about-web3-btc-bug-2010</guid><link>https://teletype.in/@menaskop/myths-about-web3-btc-bug-2010?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop</link><comments>https://teletype.in/@menaskop/myths-about-web3-btc-bug-2010?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop#comments</comments><dc:creator>menaskop</dc:creator><title>Мифы против Web 3.0 &amp; Web. Кейс №02. Самая главная ошибка Биткоина</title><pubDate>Wed, 15 Jul 2026 08:59:02 GMT</pubDate><media:content medium="image" url="https://img1.teletype.in/files/44/ee/44ee98c6-0436-4832-90d4-a2d418a8a455.png"></media:content><description><![CDATA[<img src="https://img3.teletype.in/files/2a/3e/2a3eecd8-dc56-4723-8c86-51b03017c908.png"></img>Многие биткоин-макси (попросту говоря - спекулянты на цене BTC) считают, что форк 2016 года в Эфире - это зло, чушь и нарушение децентрализации, но... почему-то забывают, что в самой сети Биткоина в 2010, 2013, 2016, 2018 гг. было не мало фейлов.]]></description><content:encoded><![CDATA[
  <figure id="lZE9" class="m_column" data-caption-align="center">
    <img src="https://img3.teletype.in/files/2a/3e/2a3eecd8-dc56-4723-8c86-51b03017c908.png" width="1672" />
    <figcaption>Ошибка Биткоина в 2010 году</figcaption>
  </figure>
  <h2 id="PrN2">The DAO форк vs. ошибка Биткоина 2010</h2>
  <p id="J4ei">Многие биткоин-макси (попросту говоря - спекулянты на цене BTC) считают, что форк 2016 года в Эфире - это зло, чушь и нарушение децентрализации, но... почему-то забывают, что в самой сети Биткоина в 2010, 2013, 2016, 2018 гг. было не мало фейлов.</p>
  <p id="5a8B">Нет, это не делает Биткоин плохим, но это делает его историю сопоставимой с эфировской. </p>
  <h2 id="Ql6b">Общее сравнение инцидентов</h2>
  <figure id="LMGf" class="m_column" data-caption-align="center">
    <img src="https://img3.teletype.in/files/a1/e3/a1e3e468-eeab-4311-86cb-f609c2b6ee54.png" width="1536" />
    <figcaption>Сравнительная таблица</figcaption>
  </figure>
  <p id="EwdB">А теперь давайте подробней и по шагам. </p>
  <h2 id="pFuE">Компьютерный счётчик не бесконечен</h2>
  <p id="rYse">Представим механический счётчик условного автомобиля с шестью барабанами:</p>
  <pre id="LTAu">000000
000001
000002
...
999998
999999</pre>
  <p id="cfwb">Что произойдёт, если к <code>999999</code> прибавить единицу?</p>
  <p id="VDOr">Он не покажет:</p>
  <pre id="AHt6">1000000</pre>
  <p id="e2uJ">Потому что седьмого барабана нет. Счётчик просто обнулится:</p>
  <pre id="si94">000000</pre>
  <p id="cbum">Это и есть простейшая аллегория <strong>переполнения</strong>, которая пришла мне в голову. Почему? </p>
  <p id="3RHl">Да потому что компьютерное число тоже хранится в ограниченном количестве ячеек - битов: когда результат оказывается больше максимально представимого числа, лишняя старшая часть теряется, а счётчик как бы начинает новый круг.</p>
  <hr />
  <p id="SOpT">И что? А то, что в Bitcoin суммы хранились на 2010 год не как дробные BTC. То есть данные не хранились в формате: </p>
  <pre id="TCzm">92 233 720 368,54277039 BTC</pre>
  <p id="t2xO">Она хранилась в сатоши (логично же?): </p>
  <pre id="WhbV">1 BTC = 100 000 000 сатоши</pre>
  <p id="iAvo">Следовательно, каждый из двух выходов <a href="https://www.blockchain.com/ru/explorer/blocks/btc/74638" target="_blank">транзакции</a>, которую тут разбираем с вами, был равен:</p>
  <pre id="keox">92 233 720 368,54277039 BTC
×
100 000 000
=
9 223 372 036 854 277 039 сатоши</pre>
  <p id="gNGn">Обозначим это число как <code>A</code>.</p>
  <pre id="yyMq">A = 9 223 372 036 854 277 039</pre>
  <p id="6leS">В транзакции было два одинаковых выхода:</p>
  <pre id="Nvbf">A + A</pre>
  <p id="Po85">То есть реальная сумма выходов:</p>
  <pre id="BAYP">18 446 744 073 708 554 078 сатоши</pre>
  <p id="dtr5">или:</p>
  <pre id="c05W">184 467 440 737,08554078 BTC</pre>
  <p id="xs5H">Занимательно, что то самое, я бы сказал, историческое, <a href="https://bitcointalk.org/index.php?topic=823.0" target="_blank">сообщение об ошибке</a> прямо описывало проблему так: &quot;сумма двух выходов переполнилась и превратилась в отрицательное значение&quot;.</p>
  <p id="AClD">Но почему именно такие странные числа? Думаю, что суммы были выбраны не случайно: ведь Bitcoin использовал 64-битное знаковое целое число - <code><strong>int64</strong></code>. У него, этого числа, есть ровно 64 двоичных позиции:</p>
  <pre id="38uP">[знак] [остальные 63 бита для числа]</pre>
  <p id="0yfc">Максимальное положительное значение поэтому для <code>int64</code>:</p>
  <pre id="vlFs">9 223 372 036 854 775 807</pre>
  <p id="M2Nv">Это примерно:</p>
  <pre id="rQzQ">92 233 720 368,54775807 BTC</pre>
  <p id="LzTp">А каждый мошеннический выход составлял:</p>
  <pre id="1lzW">9 223 372 036 854 277 039 сатоши</pre>
  <p id="V2i8">То есть был всего на:</p>
  <pre id="YJAD">498 768 сатоши</pre>
  <p id="NmPZ"><strong>Меньше</strong> максимального положительного <code>int64</code>.</p>
  <p id="CoEo">Иными словами, злоумышленник положил в каждый выход почти максимально возможное число, которое ещё помещалось в контейнер.</p>
  <p id="dajb">Приведу ещё одну аллегорию, чтобы стало понятней: представим два грузовика. Каждый из них рассчитан максимум на:</p>
  <pre id="sAqt">9 223 372 036 854 775 807 кг</pre>
  <p id="NNeL">В каждый загружают почти предельный вес:</p>
  <pre id="8364">9 223 372 036 854 277 039 кг</pre>
  <p id="OTsL">Каждый грузовик по отдельности ещё способен записать это значение в своей накладной и &quot;запихнуть&quot; в себя. Но потом бухгалтер складывает вес обоих грузовиков, используя калькулятор, который также не умеет считать числа больше определённой границы. И что? И калькулятор ломается не физически - он просто показывает совершенно другое число, не то, что загружено в кузовы. </p>
  <p id="JvG9">&quot;Ок. Допустим, но как положительное число превращается в отрицательное-то?&quot; - спросите вы меня. И я отвечу: дело в том, что для знакового 64-битного числа диапазон выглядит примерно так:</p>
  <pre id="hRXv">−9 223 372 036 854 775 808
...
−1
0
1
...
9 223 372 036 854 775 807</pre>
  <p id="1rLp">Можно представить этот диапазон не как прямую, а как... <strong>круг</strong>:</p>
  <pre id="n9Hv">            0
      положительные
         числа
            ↑
            |
отрицательные ← граница → положительные
            |
            ↓
       отрицательные
          числа</pre>
  <p id="bkzo">Или ещё проще - как часы: да, те самые, что нынешнее поколение упорно не понимает. Возьмём банальный пример: </p>
  <pre id="koRY">11 + 2 = 1</pre>
  <p id="rbE0">Почему 1-то? Не потому ведь, что в математике 11 + 2 действительно равно 1, а потому что циферблат замкнут и после 12 начинается<strong> новый круг</strong>.</p>
  <figure id="JlVh" class="m_column" data-caption-align="center">
    <img src="https://img1.teletype.in/files/07/ea/07ead54c-752b-415d-a3df-094635638f4f.png" width="1254" />
    <figcaption>Иллюстрация для зумеров :)</figcaption>
  </figure>
  <p id="3bnR">Так вот та же байда происходит и в 64-битном счётчике:</p>
  <pre id="zk2t">максимальное положительное число
+
1
=
минимальное отрицательное число</pre>
  <p id="istt">То есть:</p>
  <pre id="m9We">9 223 372 036 854 775 807
+
1
=
−9 223 372 036 854 775 808</pre>
  <p id="ysX3">Это не обычная математика, но это результат того, что контейнер имеет фиксированный размер.</p>
  <p id="8ACV">Давайте сделаем прямой расчёт именно той самой транзакции в том самом <a href="https://www.blockchain.com/ru/explorer/blocks/btc/74638" target="_blank">блоке</a> (точнее их было 2) - два выхода содержали:</p>
  <pre id="hgHk">9 223 372 036 854 277 039
+
9 223 372 036 854 277 039
=
18 446 744 073 708 554 078 сатоши</pre>
  <p id="OiGZ">Полный круг 64-битного счётчика содержит:</p>
  <pre id="1GiT">2⁶⁴ =
18 446 744 073 709 551 616</pre>
  <p id="BTBp">Посмотрим, насколько реальная сумма меньше полного круга:</p>
  <pre id="AiFO">18 446 744 073 709 551 616
−
18 446 744 073 708 554 078
=
997 538</pre>
  <p id="tanh">То есть сумма оказалась почти у самого конца 64-битного круга - всего за <code>997 538</code> единиц до нуля. И <s>когда</s> тогда те же биты интерпретировались как <strong>знаковое число</strong>, результат выглядел как:</p>
  <pre id="hsxn">−997 538 сатоши</pre>
  <p id="OVji">В биткоинах это:</p>
  <pre id="vAPW">−0,00997538 BTC</pre>
  <p id="wvui">Получается парадоксальная картина:</p>
  <pre id="R41s">Фактическая сумма выходов:

184 467 440 737,08554078 BTC</pre>
  <p id="kANA">Но переменная внутри программы могла увидеть:</p>
  <pre id="35PB">−0,00997538 BTC</pre>
  <p id="SJNc">Именно поэтому современники описывали атаку как транзакцию с <strong>отрицательной общей суммой</strong>.</p>
  <p id="mLTO">И всё дело было в том, что существовала упрощённая модель (старой) проверки. Представим, что код делает следующее:</p>
  <pre id="0ANH">int64 total = 0;

for (каждый выход) {
    total += значение_выхода;
}

if (total &gt; 21_000_000 BTC) {
    отклонить транзакцию;
}</pre>
  <p id="BADh">Ожидаемое поведение:</p>
  <pre id="5rKa">Выход 1: 92 млрд BTC
Выход 2: 92 млрд BTC
Итого: 184 млрд BTC

184 млрд &gt; 21 млн
→ отклонить</pre>
  <p id="cDZ0">Но из-за переполнения программа получила:</p>
  <pre id="EZ8c">Итого: −0,00997538 BTC</pre>
  <p id="aTQ9">Дальше проверка спрашивала:</p>
  <pre id="297r">−0,00997538 BTC &gt; 21 000 000 BTC?</pre>
  <p id="b3S2">Ответ:</p>
  <pre id="Kypi">Нет.</pre>
  <p id="eMQH">Следовательно? <strong>Конкретная проверка максимального значения НЕ срабатола</strong>!</p>
  <p id="I3gO">Давайте приведу ещё одну аллегорию. Представим склад, куда разрешено заносить не более 21 миллиона монет (на самом деле - ещё чуть меньше). </p>
  <p id="drEk">Охранник на этом складе (по не ведомой нам причине) смотрит не внутрь ящиков, а только на итоговую цифру в электронной системе учёта. Злоумышленник, зная это, заносит два гигантских ящика:</p>
  <pre id="QS6x">Ящик 1: 92 млрд монет
Ящик 2: 92 млрд монет</pre>
  <p id="7oiu">Система пытается сложить (а что ей ещё делать, если для этого она и была создана?):</p>
  <pre id="qDZd">92 млрд + 92 млрд</pre>
  <p id="vsbh">Но её табло слишком маленькое и после переполнения показывает:</p>
  <pre id="YQg8">−0,00997538 монеты</pre>
  <p id="XCQl">Охранник спрашивает:</p>
  <pre id="R85U">Число больше 21 миллиона?</pre>
  <p id="zpNA">Табло отвечает:</p>
  <pre id="MzMH">Нет, число вообще отрицательное.</pre>
  <p id="dv0N">Охранник пропускает груз. Почему? Одному Богу ведомо (и Сатоши). </p>
  <p id="pvaC">Проблема здесь не в том, что правило <strong>не более 21 миллиона</strong> отсутствовало. Проблема в том, что число, которое передали этому правилу, уже было испорчено. Совсем. К тому же - намеренно. </p>
  <p id="RTe0">Почему же первый огромный выход сразу не остановил проверку?! И да, это ключевой момент. Правильная реализация должна была бы проверить каждый выход <strong>до сложения</strong>:</p>
  <pre id="gqh9">for (каждый выход) {
    if (выход &lt; 0)
        reject;

    if (выход &gt; MAX_MONEY)
        reject;

    if (total &gt; MAX_MONEY - выход)
        reject;

    total += выход;
}</pre>
  <p id="zqRC">Но уязвимая логика фактически полагалась на итоговую сумму. <strong>Упрощённо</strong> это выглядит так: </p>
  <pre id="ruMN">total = output1 + output2;

проверить total;</pre>
  <p id="FUCv">Первый выход был огромным, но вычисление продолжалось. Когда добавили второй, произошло переполнение. Поэтому до окончательной проверки дошло уже не огромное положительное число, а маленькое отрицательное.</p>
  <p id="8xT3">Аналогия в рамках именно бухгалтерских инструкций (вспомним, что блокчейн - это в конечном счёте ближайший родственник гроссбуха и леджера): после внесения всех покупок проверьте итоговую сумму. А вот покупки были такими:</p>
  <pre id="n70T">Покупка 1: 92 млрд
Покупка 2: 92 млрд</pre>
  <p id="E9t0">Но никто не говорил ведь, что после каждой покупки надо было убедится, что число допустимо и сложение не переполнит калькулятор учёта? Вот именно - никто, поэтому бухгалтер сначала ломает итоговый счётчик и лишь затем проверяет уже неверный результат.</p>
  <p id="4TIu">Ок, допустим. Но почему тогда было два выхода, а не один? Всё просто: один выход на всю сумму выглядел бы так:</p>
  <pre id="Whx3">184 467 440 737 BTC</pre>
  <p id="wgJK">Но такое значение само по себе уже не помещалось бы в знаковое 64-битное поле!  Поэтому были использованы два выхода, каждый из которых:</p>
  <pre id="oNRG">помещался в int64 по отдельности;</pre>
  <p id="Z7EQ">но их сумма:</p>
  <pre id="WgtB">не помещалась в int64.</pre>
  <p id="BEdf">Это как пройти через дверь с двумя отдельными коробками:</p>
  <pre id="2nns">коробка №1 проходит;
коробка №2 проходит;</pre>
  <p id="HqYZ">А ошибка возникает уже внутри, когда система пытается записать их (коробок) общий вес в слишком маленькое поле.</p>
  <p id="qMCI">Тогда, что значит <strong>знак</strong> в двоичном числе, раз мы говорим про положительные и отрицательные числа? Опять же - упрощу: возьмём не 64 бита, а всего 4. Четыре бита могут иметь 16 комбинаций:</p>
  <pre id="Sra9">0000
0001
0010
...
1111</pre>
  <p id="b9oJ">Если считать число беззнаковым:</p>
  <pre id="8MYV">0000 = 0
0001 = 1
...
1111 = 15</pre>
  <p id="mxJT">Но если число знаковое, те же биты обычно читаются так:</p>
  <pre id="FrQP">0000 = 0
0001 = 1
...
0111 = 7
1000 = −8
1001 = −7
...
1111 = −1</pre>
  <p id="aYKi">Теперь прибавим:</p>
  <pre id="Sg8a">7 + 1</pre>
  <p id="fMIZ">В битах:</p>
  <pre id="amlU">0111
+
0001
=
1000</pre>
  <p id="Jf43">Но <code>1000</code> в знаковом формате означает не <code>8</code>, а:</p>
  <pre id="zuXE">−8</pre>
  <p id="EaF2">Получается:</p>
  <pre id="uA05">7 + 1 = −8</pre>
  <p id="18aF">Именно такой тип перехода и произошёл в Bitcoin, только не с четырьмя битами, а с 64: собственно, сложность тут решила многое. </p>
  <h2 id="6LSC">Миниатюрная версия атаки</h2>
  <p id="2vDD">Давайте теперь сложим 2+2 и получим... 555 :), как этого хотел Сатоши. Допустим, наш вымышленный коин использует 8-битные знаковые числа. Диапазон таков:</p>
  <pre id="rtqO">−128…127</pre>
  <p id="KHlF">Разрешено создать максимум:</p>
  <pre id="xLwa">100 монет</pre>
  <p id="3EGS">Злоумышленник делает два выхода:</p>
  <pre id="yVTI">Выход 1: 120
Выход 2: 120</pre>
  <p id="Gvwt">Реальная сумма:</p>
  <pre id="7MtJ">120 + 120 = 240</pre>
  <p id="rIf1">Но 8-битное знаковое число не может хранить <code>240</code>. Полный круг 8-битного счётчика (см. выше): </p>
  <pre id="Xbxy">2⁸ = 256</pre>
  <p id="j56L">Поэтому:</p>
  <pre id="bGDi">240 − 256 = −16</pre>
  <p id="jIgm">Программа видит:</p>
  <pre id="dkrh">Итого: −16 монет</pre>
  <p id="Mb8U">Проверка:</p>
  <pre id="Tn5z">−16 &gt; 100?</pre>
  <p id="onWZ">Ответ:</p>
  <pre id="q6HS">Нет.</pre>
  <p id="m2RR">Хотя реально было создано 240 монет. Bitcoin-инцидент был тем же самым, только числа были намного больше. И всё. </p>
  <p id="hDZ1">И здесь возникает логичный вопрос: &quot;Почему проверка формата &quot;выходы не должны превышать входы&quot; тоже могла сломаться? Возьмём опять же упрощённую схему - обычную транзакцию, которая должна соблюдать простое условие: </p>
  <pre id="4LTs">сумма входов ≥ сумма выходов</pre>
  <p id="gCQM">Например:</p>
  <pre id="foV0">Входы: 1 BTC
Выходы: 0,9 BTC
Комиссия: 0,1 BTC</pre>
  <p id="rIOk">Но после переполнения программа могла видеть:</p>
  <pre id="MgR2">Вход: около 0,5 BTC
Сумма выходов: −0,00997538 BTC</pre>
  <p id="faRL">Тогда вычисление комиссии выглядело примерно так:</p>
  <pre id="pJLN">комиссия =
входы − выходы</pre>
  <p id="B7BK">То есть:</p>
  <pre id="Q7zz">0,5 − (−0,00997538)
=
0,50997538 BTC</pre>
  <p id="Gcv7">Вместо того чтобы заметить выпуск 184 млрд BTC, система могла интерпретировать расчёт так, будто транзакция не только не создала деньги, но и заплатила майнеру примерно <code>0,51 BTC</code> комиссии.</p>
  <p id="o0SX">Это как если бухгалтерская система увидела отрицательную стоимость товаров:</p>
  <pre id="OQlu">покупатель принёс: 0,5 монеты;
товары стоят: −0,01 монеты;
магазину осталось: 0,51 монеты.</pre>
  <p id="yb27">Из-за неправильного знака экономический смысл расчёта полностью перевернулся.</p>
  <p id="2va5">Что именно следовало исправить? Не с моей точки зрения, а объективно. Во-первых, понять, что нельзя сначала выполнять потенциально опасное сложение, а потом проверять результат. А что тогда делать? Очевидно - нужно проверять, безопасно ли сложение <strong>до его выполнения</strong>:</p>
  <pre id="znRD">if (current_total &gt; MAX_VALUE - next_output) {
    reject;
}

current_total += next_output;</pre>
  <p id="DO5f">Почему это работает? Возьмём снова простейший пример:</p>
  <pre id="G8Cc">MAX = 100
current_total = 80
next_output = 30</pre>
  <p id="cDks">Вместо вычисления:</p>
  <pre id="VuiL">80 + 30 = 110</pre>
  <p id="F1SG">сначала проверяем:</p>
  <pre id="KDry">80 &gt; 100 − 30?
80 &gt; 70?
Да.</pre>
  <p id="rkGW">Значит, сложение переполнит допустимый предел - транзакция сразу отклоняется. Кроме этого, в подобных случаях необходимо проверять каждый выход отдельно:</p>
  <pre id="vYv4">выход не отрицательный;
выход не больше MAX_MONEY;
накопленная сумма не больше MAX_MONEY;
сложение не переполняет тип данных.</pre>
  <p id="3gcU">Версия Bitcoin 0.3.10 была опубликована как исправление переполнения в блоке 74638 и, собственно, пошла по похожей схеме. </p>
  <p id="NW7J">Теперь каждый из вас, понимая произошедшее, может самостоятельно вывести самую точную и короткую формулу произошедшего. Для начала определим, чего НЕ произошло: </p>
  <pre id="BC3I">Программа решила, что 184 млрд BTC разрешены.</pre>
  <p id="M8CI">А потом подумаем и определим, что же всё таки произошло? </p>
  <pre id="bImj">1. Программа получила два огромных выхода.
2. Каждый выход помещался в отдельное 64-битное число.
3. При сложении двух выходов 64-битного пространства не хватило.
4. Итоговые биты стали интерпретироваться как отрицательное число.
5. Проверка лимита получила уже неправильную сумму.
6. Маленькое отрицательное число не оказалось больше 21 млн BTC.
7. Транзакция была ошибочно признана допустимой.</pre>
  <p id="qbdV">Главная мысль моей статьи - фактически цитата. </p>
  <blockquote id="6c2K">Лимит Bitcoin был обойдён не потому, что отсутствовало правило, а потому, что арифметическая ошибка подменила число до того, как это правило это число проверило. </blockquote>
  <p id="nLHc">Вот такие пироги... </p>
  <p id="8HdP"><em>До!</em></p>

]]></content:encoded></item><item><guid isPermaLink="true">https://teletype.in/@menaskop/myths-about-web3-the-dao-fork</guid><link>https://teletype.in/@menaskop/myths-about-web3-the-dao-fork?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop</link><comments>https://teletype.in/@menaskop/myths-about-web3-the-dao-fork?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop#comments</comments><dc:creator>menaskop</dc:creator><title>Мифы против Web 3.0 &amp; Web. Кейс №01. The DAO форк</title><pubDate>Tue, 14 Jul 2026 17:40:10 GMT</pubDate><media:content medium="image" url="https://img4.teletype.in/files/35/92/35929116-58d7-4cfc-b6d6-8cff47fe2b32.png"></media:content><category>DAO</category><description><![CDATA[<img src="https://img4.teletype.in/files/b4/ff/b4ff735c-ee40-4aa1-aebc-905fa96468bb.png"></img>У каждой из сторон есть стимул представить себя сильнее, чтобы её победа казалась неизбежной. Виталик Бутерин]]></description><content:encoded><![CDATA[
  <figure id="wulo" class="m_column" data-caption-align="center">
    <img src="https://img4.teletype.in/files/b4/ff/b4ff735c-ee40-4aa1-aebc-905fa96468bb.png" width="1672" />
    <figcaption>The DAO форк</figcaption>
  </figure>
  <blockquote id="yZz4"><em>У каждой из сторон есть стимул представить себя сильнее, чтобы её победа казалась неизбежной. Виталик Бутерин</em></blockquote>
  <h2 id="PBJP">Введение</h2>
  <figure id="Yhmi" class="m_column" data-caption-align="center">
    <img src="https://img2.teletype.in/files/56/41/5641531d-ca17-4ca5-8ee1-fac07042459f.png" width="1576" />
    <figcaption>Хронология </figcaption>
  </figure>
  <p id="6wn0">В этой серии видео и текстов, связанных друг с другом (на одно видео - один текст), хочу рассказать о наиболее значимых мифах крипто-индустрии, которые до сих пор, хотя порой прошло 5-10 и даже 15 и более лет, оказывают влияние на не окрепшие умы неофитов. </p>
  <p id="6WWY">И начну с The DAO, но рассмотрю этот случай не с позиции, которая была описана в книгах, исследованиях, статьях, постах и комментариях множество раз, а с расстановки акцентов, исходя из ончейн-аналитики и веб-архивов.</p>
  <p id="5qCZ">Итак...</p>
  <h2 id="V5Fx">Нарочно не замечанные факты</h2>
  <p id="o9ZC">Давайте зададим себя простой вопрос: &quot;Какая доля майнеров реально поддержала DAO hard-fork к блоку <a href="https://blog.ethereum.org/2016/07/20/hard-fork-completed" target="_blank">1 920 000</a>?&quot; - и попробуем найти на него ответ. </p>
  <p id="qlQc">Первое, что стоит узнать, что порядка 54%-60% общего хешрейта было явно зафиксировано за про‑форк‑пулами (<strong>ПФП</strong>) ещё <strong>до</strong> учёта позднего присоединения/следования за большинством со стороны F2Pool и BW. </p>
  <h3 id="8qID">Пример №01. Reddit</h3>
  <p id="W7ee">Откуда эти данные? Скажем, в одной общедоступной <a href="https://www.reddit.com/r/ethereum/comments/4tffta/hard_fork_voting_and_node_adoption_results/" target="_blank">reddit</a>‑агрегации на базе EtherChain ПФП суммировались в 54%. И это не просто цифра из воздуха: она складывалась из многих мнений и ончейн-источников: приходили пулы и добавлялись, проводились голосования внутри них, etc. Поэтому данная ветка - ценная находка для любого нетсталкера. И это при том, что на &quot;... пулы приходилось более <strong>98%</strong> хешрейта, следовательно, доля соло-майнеров должна (была) быть менее <strong>2%</strong>&quot;, - т.е. резкий выход не согласных с любым пулом - был сразу заметен. <br /><br />Не забывайте, что всегда стоит искать веб-<a href="https://web.archive.org/web/20160724101518/https://www.reddit.com/r/ethereum/comments/4tffta/hard_fork_voting_and_node_adoption_results/" target="_blank">архивы</a>, потому что из них можно получить массу ценно информации. Например: </p>
  <figure id="Xcxp" class="m_column" data-caption-align="center">
    <img src="https://img3.teletype.in/files/ed/e5/ede52c4e-f147-4ed5-94d0-fc788ac802ec.png" width="1455" />
    <figcaption>Адаптированный скриншот из Reddit</figcaption>
  </figure>
  <p id="0Dsi">Как видим, таблица, составленная ДО реального голосования, УЖЕ объединяет сразу <strong>три</strong> <strong>разных</strong> <strong>источника</strong>:</p>
  <ul id="fACx">
    <li id="wj9K">мнение майнеров (через пулы);</li>
    <li id="Pm4V">обновление клиентских нод;</li>
    <li id="IHgd">заявления самих пулов.</li>
  </ul>
  <p id="35z3">То есть уже тогда все понимали, что простого голосования недостаточно - нужно смотреть <strong>на готовность всей инфраструктуры</strong>.</p>
  <p id="09Y9">Но самое интересное даже не в предварительных данных, а в том, что обсуждалось ниже:</p>
  <blockquote id="wfdz">Таким образом, было добавлено 261 + 26 = 287 обновлённых клиентов, но одновременно было добавлено 1 + 1 + 2 + 7 + 13 + 3 + 19 + 43 + 40 + 35 + 96 = 260 клиентов со старыми версиями. Особенно если сравнить число 261 с числом 260, складывается впечатление, что это скоординированная акция. </blockquote>
  <p id="bqfd"><strong>Кто-то добавляет ноды на старых версиях клиента практически на каждую ноду, которая обновляется, чтобы показатели НЕ демонстрировали наличие консенсуса.</strong></p>
  <blockquote id="6nG0">За последние три часа этот человек или группа добавили более 500 клиентов (в нормальной ситуации, судя по числу обновлений, 261 нода со старой версией должна была исчезнуть, однако вместо этого сверху было добавлено ещё 260 новых нод со старой версией)&quot;.</blockquote>
  <p id="qV40">Объяснение, конечно же нашлось: &quot;Похоже, Ethernodes запустил новый алгоритм сканирования сети и сообщил, что теперь обнаруживает ноды, которые раньше не удавалось найти. Это наиболее вероятная причина, почему общее количество нод выросло и почему старые версии клиентов тоже начали появляться в списке как &quot;новые&quot;... Но, как заметил один из участников форума: &quot;Конечно, за два дня до хардфорка - идеальный момент, чтобы тестировать новый алгоритм поиска нод&quot;.</p>
  <p id="cgH9">Не менее важно, что мы можем узнать и проверить, это то, что F2Pool и BW были готовы следовать за большинством: то есть фактически все шансы у тех, кто был против форка были, т.к. эти 2 пула составляли до 30%. </p>
  <blockquote id="A89K">Чтобы стало ещё понятнее: у <strong>EthPool было на тот момент всего ок. 7,1%</strong>! Более того: <strong>MiningPoolHub</strong> с <strong>1,8%</strong> вычислительной мощности сети тоже решил поддержать хардфорк. Там же был и пул: <strong>Alpereum</strong> с долей сети ок.<strong> 0,4%</strong>. <strong>Ethc.epool.io</strong> и их<strong> 0,1%</strong> хешрейта. Поэтому 30% - колоссальная цифра, как ни крути. </blockquote>
  <p id="5DA3">При этом у Ethpool к финалу возник раскол между внутрипуловым голосованием и реальным выбором цепи. Финальное сообщение Ethpool гласило, что 65% голосовавшей мощности были против поддержки форка, но сам оператор пула всё равно объявил, что будет майнить форк, потому что крупнейшие пулы уже уходят туда и майнить на вероятной проигрывающей цепи означало бы риск орфанов для участников пула. Поэтому и здесь у каждого не согласного было время, чтобы подумать и подключиться к сторонникам своей точки зрения. </p>
  <p id="Sxj4">Но не торопитесь делать выводы, потому что дальше узнаём следующее по ETHPool: &quot;Я до сих пор не могу понять, как так <a href="https://forum.ethereum.org/discussion/8382/dao-hard-fork-voting-on-ethpool-ethermine/p2" target="_blank">резко выросло число голосов</a> <strong>против хардфорка</strong>. Теперь они уже составляют большинство, и это совпало с внезапным скачком хешрейта пула. Подозреваю, что это арендованный хешрейт, возможно, со стороны эксплуататора(ов)&quot;.</p>
  <p id="TrUj">То есть манипуляций со стороны тех, кто хардфорка не желал - хватало? Конечно. </p>
  <p id="HRwX">Более того, ниже есть конкретные цифры: &quot;Скорее всего, это действительно арендованный хешрейт - целых<strong> 20 GH/s</strong>!!! Потом ещё два майнера по <strong>9 GH/s</strong>! Я вообще не понимаю, чего эти шутники пытаются добиться. Dr_pra совершенно ясно заявил, что в конечном итоге пулы будут следовать общему консенсусу сети, независимо от того, совпадает ли он с результатами голосования внутри конкретного пула. Поэтому пытаться повлиять на форк через голосование в одном пуле кажется мне просто нелепым&quot;. </p>
  <p id="3xsz">Самое важное, на чём сходятся обсуждения: &quot;В конечном счёте именно <strong>супербольшинство хешрейта</strong> определит, по какой цепочке пойдёт сеть. Нынешние опросы  это всего лишь неформальные предварительные голосования&quot;.</p>
  <p id="JvEk">И это - правда. </p>
  <p id="joDm">И очень чётко изложено, почему майнеры могли не голосовать предварительно:</p>
  <ul id="pzxT">
    <li id="mHp9">им это безразлично;</li>
    <li id="LvE2">они считают, что результаты голосования и так отражают их позицию;</li>
    <li id="t4Ht">они уверены, что голос против всё равно ничего не изменит;</li>
    <li id="Gk19">либо существует множество других причин, о которых мы даже не думаем.</li>
  </ul>
  <p id="ltNq">Поскольку я сам тогда майнил ETH, то следующий тейк считаю наиболее значимым: &quot;В конечном итоге майнеры выполнят свою основную функцию: будут <strong>защищать сеть своим хешрейтом независимо</strong> от того, насколько активно они интересуются вопросами изменения протокола. Даже если майнер не поддерживает ни одну из сторон, он всё равно проверяет транзакции и защищает сеть от атак. Именно в этом заключается роль майнеров&quot;.</p>
  <p id="McMF">Ещё один важный тезис звучит очень просто, но вдумайтесь в его содержание: &quot;Честно говоря, я всё ещё очень обеспокоен. Времени осталось совсем мало. Нам нужно, чтобы как минимум 60% нод работали на версии 1.4.10. Хотелось бы, чтобы майнинговые пулы обязали своих пользователей проголосовать и обновить программное обеспечение (либо за, либо против форка) и не принимали их блоки, пока они этого не сделают&quot;. </p>
  <p id="gJEn">Вроде, логично? </p>
  <p id="ABte">Но вот что ему отвечает другой участник: &quot;Это приведёт к очень <strong>централизованному</strong> <strong>механизму</strong> проведения хардфорка&quot;. </p>
  <p id="DPCK">Поэтому нейтральность пулов, кот. мы можем наблюдать в ходе подготовки и проведения хард-форка - ещё одно доказательство того, что сеть хотела оставить нейтральность как фундамент. </p>
  <figure id="MvZJ" class="m_column" data-caption-align="center">
    <img src="https://img3.teletype.in/files/ea/ab/eaab128d-1645-4df8-a301-0d34ec35d4f4.png" width="1029" />
    <figcaption>Один из скриншотов предварительного голосования. Данные: <a href="https://imgur.com/uiHohUb" target="_blank">https://imgur.com/uiHohUb</a></figcaption>
  </figure>
  <p id="vKU2">Интересно, что даже такие малые пулы как Alpereum уведомляли пользователей в течение 3 недель: говорить после этого, что всё лоббировалось и ни у кого не было права выбора и возможности его даже - как минимум, странно. </p>
  <p id="WtLe">При этом уже за 2-3 дня до форка &quot;... клиенты, готовые к хардфорку, составляли уже более 30% сети&quot;. И это по очень сырым подсчётам, где были не учтены те самые 30% (а это итак 60%). </p>
  <p id="MKyN">Таким образом, из одной этой ветки можно получить множество источников данных:</p>
  <ul id="4Izy">
    <li id="rmkK"><a href="https://www.ethernodes.org/network/1" target="_blank">https://www.ethernodes.org/network/1</a></li>
    <li id="3hU7"><a href="https://forum.ethereum.org/discussion/8382/dao-hard-fork-voting-on-ethpool-ethermine/p2" target="_blank">https://forum.ethereum.org/discussion/8382/dao-hard-fork-voting-on-ethpool-ethermine/p2</a></li>
    <li id="YjJd"><a href="http://ethpool.org/stats" target="_blank">http://ethpool.org/stats</a></li>
    <li id="qikr"><a href="https://docs.google.com/spreadsheets/d/160clbc6bFKEvar091iNYyg0zEJxhyAZTDoxcm7cF2II/edit#gid=0" target="_blank">https://docs.google.com/spreadsheets/d/160clbc6bFKEvar091iNYyg0zEJxhyAZTDoxcm7cF2II/edit#gid=0</a></li>
  </ul>
  <p id="5vnb">Также мы узнаём, что &quot;... операторы <strong>EthPool</strong>, <strong>Ethermine</strong> и <strong>Dwarfpool... поддержали</strong> хардфорк&quot; и, как заметил один из участинков: &quot;Это их пул - их правила&quot;. И, как написал выше, выход из таких пулов - был бы явным подтверждением позиции ПРОТИВ хардфорка, но даже этого не произошло по большей части.</p>
  <p id="Gt9D">Итоговые значения в его расчётах составляют:</p>
  <ul id="RYc2">
    <li id="OYsZ">За форк: 48,2% общего хешрейта (2,8% ещё не определились внутри этой группы);</li>
    <li id="3i3D">Против форка: 39,3% (11,7% - ожидают достижения порога или не выразили позицию);</li>
    <li id="SN9l">Всего учтено: 87,5% хешрейта сети;</li>
    <li id="xk9E">Неизвестно: 12,5%.</li>
  </ul>
  <p id="JrOm">Вот ещё одна сводная таблица, собранная через глубокое исследование с ChatGPT:</p>
  <figure id="p1FP" class="m_column" data-caption-align="center">
    <img src="https://img3.teletype.in/files/a5/8c/a58c0fe6-d57c-4ee2-97ba-30fd532b7443.png" width="1600" />
    <figcaption>Часть первая</figcaption>
  </figure>
  <p id="ZK9D">И доп.: </p>
  <figure id="2Vkr" class="m_column" data-caption-align="center">
    <img src="https://img3.teletype.in/files/a8/dd/a8ddc102-14f8-43a7-97bc-eb733820010b.png" width="1150" />
    <figcaption>Часть вторая</figcaption>
  </figure>
  <p id="qULg">И даже так:</p>
  <p id="W3B3">Г</p>
  <p id="qJpt">График выше показывает не долю всей сети, а только процент yes среди уже</p>
  <p id="wt1N">проголосовавшей мощности внутри соответствующего пула. Именно поэтому Ethpool мог</p>
  <p id="Ddoa">закончить с 35% yes / 65% no среди vote‑participants и все равно реально уйти на fork‑chain</p>
  <p id="W7VI">вместе с остальной сетью</p>
  <p id="VDgt">Гр </p>
  <p id="DUdj">График выше показывает не долю всей сети, а только процент yes среди уже</p>
  <p id="v2m8">проголосовавшей мощности внутри соответствующего пула. Именно поэтому Ethpool мог</p>
  <p id="Wjge">закончить с 35% yes / 65% no среди vote‑participants и все равно реально уйти на fork‑chain</p>
  <p id="wp8Z">вместе с остальной сетью</p>
  <figure id="uR6w" class="m_column" data-caption-align="center">
    <img src="https://img2.teletype.in/files/dc/75/dc75672f-9516-4c90-8d4d-80f70b09de88.png" width="1106" />
    <figcaption>График выше показывает не долю всей сети, а только процент yes среди уже  проголосовавшей мощности внутри соответствующего пула. Именно поэтому Ethpool мог  закончить с 35% yes / 65% no среди vote‑participants и все равно реально уйти на fork‑chain  вместе с остальной сетью</figcaption>
  </figure>
  <p id="1zLd">И вот выводы по нему (специально не акцентирую большого внимания, хотя там порядка 10 страниц текста, кода и др. данных, т.к. иных источников не мало): &quot;Если свести все имеющиеся данные воедино, получается следующая картина. До проведения хардфорка можно достаточно уверенно подтвердить лишь <strong>54–60%</strong> публично заявленного хешрейта, поддерживавшего форк. В момент активации форка наиболее достоверные оценки показывают, что около <strong>85% </strong>вычислительной мощности сети уже добывало блоки новой цепи. Спустя несколько дней, к 26 июля 2016 года, доля оставшейся цепи, впоследствии ставшей Ethereum Classic, по сохранившимся данным <strong>fork.ethstats</strong> составляла примерно<strong> 17,5%</strong> общего хешрейта. Именно эти цифры можно считать наиболее добросовестной реконструкцией распределения майнинговой мощности в период форка The DAO, поскольку они основаны на сохранившихся источниках того времени, а не на более поздних интерпретациях и пересказах&quot;.</p>
  <h3 id="Ry5v">Пример №02. Форум</h3>
  <p id="74ss">Теперь давайте обратимся непосредственно к Эфир-<a href="https://wayback.archive-it.org/16516/20210623042437/https://forum.ethereum.org/discussion/8382/dao-hard-fork-voting-on-ethpool-ethermine/p2" target="_blank">форуму</a>. </p>
  <p id="6Od8"><strong>Первое</strong> и очень важное: &quot;Мы по-прежнему оставляем за собой право не следовать результатам голосования, если в коде хардфорка будут обнаружены проблемы безопасности или если пул окажется на проигрывающей цепочке&quot;. То есть каждый отдавал себе отчёт в том, что он может проиграть и никакой 100%-й гарантии, как это преподносят СМИ и через 10 лет, не было. Да и быть не могло.</p>
  <p id="afR5"><strong>Второй</strong> важный тезис звучит так: &quot;Большинством вполне могла стать и цепочка без форка, и тогда пул последовал бы именно за ней. Это работает в обе стороны. Мне кажется, что сторонники NOHF просто не могут смириться с мыслью, что большинство людей с ними не согласно. Поэтому они начинают говорить о заговоре, манипуляциях, мошенничестве. Но на самом деле всё гораздо проще: <strong>большинство просто придерживается другой точки зрения</strong>... Это не охота на ведьм.Это просто ситуация, когда разные люди придерживаются разных взглядов&quot;.</p>
  <p id="BS4A">Самое интересное кроется даже не в самом ответе, а в том, кто его дал: &quot;Я такой же майнер, как и вы. И, кстати, у меня даже нет токенов DAO&quot;. И да, я был ровно в таком же положении: правда, немного токенов The DAO у меня всё же было. Но суть в том, что активность комьюнити майнеров - очевидна: все, кто хотел высказаться, делали это не только ончейн, через пулы, на реддите, но и на форуме эфировском непосредственно, и в чатах, и много где ещё. <strong>Все, кто хотел именно</strong>. </p>
  <blockquote id="a7IA">Но самый интересный тезис звучит ещё проще: &quot;Вполне возможно, что сам атакующий и его союзники действительно предпринимают скоординированные усилия, чтобы помешать проведению хардфорка. Помните, что атакующий публично заявлял, будто его главная цель - <strong>нанести ущерб Ethereum</strong>, поскольку он является большим сторонником <strong>Bitcoin</strong>?...&quot;. Выводы, как говорится, делайте сами. </blockquote>
  <p id="YVKH">Ещё один тезис, который пропускают (якобы) сторонники (якобы) позиции &quot;код - это закон&quot;, звучит так: &quot;Если вы читали комментарии к коду The DAO, то совершенно очевидно, что <strong>возможность рекурсивного вызова не была предусмотрена разработчиками</strong>. Более того, для проведения атаки потребовался существенно модифицированный клиент Ethereum, способный сформировать транзакцию, выводящую ETH из The DAO. С помощью <strong>обычного</strong> клиента Ethereum сделать это <strong>невозможно</strong>&quot;. Ведь, согласитесь, это 100% хак, а не просто &quot;фича&quot;? </p>
  <p id="TLIq">И, наконец, тезис, сторонником которого я являюсь на 100%, поэтому вынесу его тоже цитатой:</p>
  <blockquote id="ZuVe">Позвольте объяснить, почему ваши выводы ошибочны. <strong>Ethereum действительно остаётся децентрализованной системой</strong>. Более того, <strong>история с хардфорком The DAO как раз это и демонстрирует</strong>. Ни одна отдельная организация не может самостоятельно провести хардфорк. Для этого требуется децентрализованный консенсус участников сети... Обнаруженная во время подготовки Soft Fork атака типа DoS показывает, что Ethereum оказался даже<strong> более устойчивым к цензуре со стороны майнеров</strong>, чем другие криптовалюты.</blockquote>
  <p id="Unqw">Более того, в самом начале это было выражено иначе, но в той же коннотации: &quot;То, что происходит сейчас в Ethereum, называется <strong>консенсусом</strong>, а вовсе <strong>не</strong> <strong>сговором</strong>. Сговор по определению предполагает тайное соглашение. Здесь же всё происходит абсолютно <strong>публично</strong>. То, что вы не согласны с мнением большинства, ещё не означает существование какого-либо заговора. Это лишь означает, что <strong>ваша позиция находится в меньшинстве</strong>&quot;. И именно подобного взгляда придерживаюсь сам. </p>
  <p id="uI4h">Более того, уже в те дни тезисов очевидных накопилось много: в том числе - относительно сравнения с форком Биткоина в 2010 году: &quot;Мне действительно хотелось бы понять, на каком основании вы и многие другие противники хардфорка утверждаете как установленный факт, что после форка <strong>целостность блокчейна Ethereum будет утрачена</strong>. В первые годы существования Bitcoin тоже произошёл серьёзный хардфорк с откатом цепочки. И, насколько я вижу, Bitcoin после этого никуда не исчез. Поэтому хочу уточнить: Ваше утверждение основано исключительно на вашем предположении о том, как люди отреагируют на откат последствий мошенничества с The DAO? Или вы можете привести какие-либо реальные исторические прецеденты, подтверждающие такую точку зрения?&quot;. </p>
  <p id="Mg2D">Ещё один важный тезис, который ника мне приемлют критики, звучит следующим образом: &quot;В самом хардфорке нет ничего особенно сложного. И это далеко <strong>не первый</strong> и уж точно <strong>не последний</strong> хардфорк в истории Ethereum. Более того, вероятно, это <strong>одно из самых простых изменений консенсуса</strong>, которые когда-либо будет проходить сеть. Мне очень понравилось, как ситуацию сформулировал <strong>Гэвин Андресен</strong>. Если пересказать его мысль своими словами&quot;... Приведу цитату полностью: </p>
  <blockquote id="pWan">Если существует простой способ исправить ситуацию наиболее справедливым образом, то бездействие означает фактическое соучастие в действиях атакующего.</blockquote>
  <p id="YUpJ">Ещё в одной Reddit было <a href="https://www.reddit.com/r/ethereum/comments/4rv6k5/ethereum_reaches_unanimous_agreement_to_hardfork/?solution=ac8e7075b605a9b0ac8e7075b605a9b0&js_challenge=1&token=7afd7253fec22262ff1c52b1703fe9ecb7c1c421648d723a2bb50321b45b9980&jsc_orig_r=" target="_blank">сказано</a> в поддержку той же позиции буквально следующее: &quot; Любые обновления протокола, например <strong>Metropolis</strong>, также являются хардфорками. Иногда создаётся ощущение, что противники хардфорка относятся к нему почти как к религиозной ереси. Безусловно, применять его нужно крайне осторожно. Но <strong>хардфорк - это одна из предусмотренных возможностей любой блокчейн-системы</strong>&quot;. И вот это - факт. </p>
  <p id="P2tt">При этом в другой части того же форума была высказана ещё одна здравая <a href="https://www.reddit.com/r/ethereum/comments/4ti66h/update_dwarfpool_the_largest_eth_pool_will/" target="_blank">мысль</a>: &quot;Но сама идея о существовании «майнеров-зомби» противоречит базовому предположению любой децентрализованной сети: <strong>большинство участников должно действовать разумно и добросовестно</strong>&quot;. Сложно с ней не согласится. </p>
  <p id="TOFO">Что важно: на форуме даже тех, кто оскорблял других, старались не удалять, чтобы сохранить нейтралитет. Цитата: &quot; Вы получаете <strong>официальное предупреждение за оскорбительное поведение</strong>. Тем не менее пока я оставлю большинство ваших сообщений без удаления, чтобы все могли сами увидеть, почему было вынесено это предупреждение&quot;. И всё равно СМИ после этого твердят, что всё было подстроено... </p>
  <p id="jAk6">При этом здесь мы находим подтверждение, что сторонники НЕ принятия форка пытались манипулировать данными хешрейта (и голосованиями на его основе - соответственно): &quot;<a href="https://www.miningrigrentals.com/u/adaseb" target="_blank">https://www.miningrigrentals.com/u/adaseb</a> - сервис сдаёт свои майнинговые установки в аренду через MiningRigRentals. Их никто не взламывал. Их просто арендовали. По сути, мы уже и так пришли к выводу, что использовался именно арендованный хешрейт&quot;.</p>
  <p id="Ye9k">Но и это не всё - далее мы находим этому конкретное подтверждение: &quot;Я <strong>действительно сдал свои риги в аренду</strong>. Этот человек платил примерно на 50% больше, чем можно было заработать на обычном майнинге ETH. К концу дня все доступные риги были арендованы. Похоже, в итоге он сильно проиграл, поскольку так и не добился желаемого результата&quot;.</p>
  <p id="Pumv">Поэтому подобные факты - навсегда остаются в истории: их не просто порой разыскать, но почти всегда - возможно. </p>
  <p id="Bgra">И вот какой результат мы в итоге получаем из архива, <a href="https://web.archive.org/web/20160720132301/http://fork.ethstats.net/" target="_blank">ссылка</a> на который опубликована на этом форуме:</p>
  <figure id="Sipf" class="m_column" data-caption-align="center">
    <img src="https://img2.teletype.in/files/98/f2/98f244e0-b9f5-426f-bf9d-56ab9c8121c5.png" width="3252" />
    <figcaption>The DAO форк - результаты</figcaption>
  </figure>
  <p id="DFb7">Легко по <strong>сложности</strong> распознать мнение большинства. </p>
  <h3 id="ZmwK">Пример №03. СМИ </h3>
  <p id="cKWH">К слову, статье <a href="https://www.ccn.com/archive/2016/almost-60-ethereum-miners-upgraded-support-hardfork/" target="_blank">CCN</a> - накануне форка  - тот же лагерь (за форк) округлялся до “ок. 60%” и отдельно отмечалось, что F2Pool и BW (а это ок. 30%, ещё раз напомню) с высокой вероятностью тоже перейдут на хардфорк‑клиент.</p>
  <p id="PysM">Самое важное методологическое уточнение: &quot;сколько майнеров&quot; в смысле уникальных людей/риг‑операторов 2016‑источники почти не дают. Источники тех лет измеряют в основном долю хешрейта или долю голосовавшей мощности внутри пулов, а не количество уникальных субъектов. Поэтому точный ответ в общем виде - возможен, а точный вот точный ответ в форме привязки к субъектам - скорее, нет. Но это и не нужно, т.к. все данные в итоге были в ончейне. </p>
  <p id="DlKR">Найти др. источники в медиа не сложно, но я уделяю им мало внимания в силу того, что в них слишком много хайпа и чересчур мало фактологии. Впрочем, всегда готов обсудить любые примеры, кот. кажутся вам интересными. </p>
  <h3 id="TP2K">Пример №04. Ончейн</h3>
  <p id="uDN2">Сюда можно отнести данные:</p>
  <ol id="5egx">
    <li id="d2G3">Сканеров;</li>
    <li id="TeeZ">Ончейн-архивов;</li>
    <li id="wbvc">Работы нод;</li>
    <li id="ABik">Прочие подобные.</li>
  </ol>
  <p id="vXJM">Берём <a href="https://ethereum.stackexchange.com/questions/7832/give-a-summary-of-the-fork-state-changes-in-block-1920000" target="_blank">ссылку</a> на известный ресурс и читаем:&quot; Для проведения хардфорка программное обеспечение клиентов Ethereum было обновлено таким образом, чтобы при обработке блока <strong>№1 920 000</strong> применялись ... дополнительные правила&quot;. </p>
  <p id="YQOL">И отсюда мы узнаём, что в коде есть вполне конкретный параметр: var MainNetDAOForkBlock = big.NewInt(1920000).</p>
  <p id="id8o">И далее видим по уже вот этой <a href="https://go-mod-viewer.appspot.com/github.hscsec.cn/scroll-tech/go-ethereum@v1.9.7/params/dao.go" target="_blank">ссылке</a> следующее:</p>
  <ul id="pz2i">
    <li id="bCKh"><strong>DAOForkBlockExtra</strong> - значение поля ExtraData заголовка блока, которое устанавливается в момент хардфорка The DAO и ещё для нескольких последующих блоков, чтобы клиенты Fast Sync и Light Sync могли корректно определить, какую ветвь цепочки они должны выбрать (&quot;dao-hard-fork&quot;). </li>
    <li id="C5VF"><strong>DAOForkExtraRange</strong> - количество последовательных блоков, начиная с точки хардфорка The DAO, для которых поле ExtraData принудительно переопределяется, чтобы предотвратить атаки со стороны клиентов, не поддерживающих хардфорк (no-fork attacks).</li>
    <li id="vJ8r"><strong>DAORefundContract</strong> - адрес контракта возврата средств, на который будут переведены все балансы The DAO.</li>
    <li id="Gexl"><strong>DAODrainList</strong> - список аккаунтов, полные балансы которых будут перенесены  в контракт возврата средств в начале блока хардфорка The DAO.</li>
  </ul>
  <p id="z0Fr">Как видим, процесс не просто прозрачен, а полностью формализован. И весьма прост. Даже по-хорошему примитивен. Можно ли это назвать манипуляцией? Не думаю: манипуляторы стараются всегда запутать следы, &quot;навести туману&quot;, что называется. Прозрачность - не их конёк.</p>
  <p id="J28l">Подобной верификации на гите найти можно в <a href="https://ethereum.stackexchange.com/questions/16815/is-geth-rpc-support-dao-fork-still-valid" target="_blank">достаточном</a> количестве: пример <a href="https://gist.github.com/bas-vk/bbd75fcbcdd73b64cbb864f78fe49988" target="_blank">доп</a>. №01 и <a href="https://gist.github.com/gavofyork/856b27cf1a482585692359e28d3ae4cb" target="_blank">доп</a>. №02. </p>
  <p id="CZon">Но давайте посмотрим на самое известное <a href="https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/" target="_blank">голосование</a>: </p>
  <figure id="1NmO" class="m_column" data-caption-align="center">
    <img src="https://img1.teletype.in/files/05/e3/05e3441e-c62c-4e80-9ce0-25263e9e8256.png" width="3456" />
    <figcaption>Ончейн-голосование. <a href="https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/" target="_blank">Предварительное</a></figcaption>
  </figure>
  <p id="Jcvw">Самое важно, что даже в нём отфильтрованы адреса CEXs (Accounts filtered (Exchange&#x27;s withdraw address))% </p>
  <ul id="8peI">
    <li id="iKaQ">Yunbi: <a href="https://web.archive.org/web/20170620030820/http://etherscan.io/address/0xd94c9ff168dc6aebf9b6cc86deff54f3fb0afc33" target="_blank">0xd94c9ff168dc6aebf9b6cc86deff54f3fb0afc33</a></li>
    <li id="8Pgo">Kraken: <a href="https://web.archive.org/web/20170620030820/http://etherscan.io/address/0x2910543af39aba0cd09dbb2d50200b3e800a63d2" target="_blank">0x2910543af39aba0cd09dbb2d50200b3e800a63d2</a></li>
    <li id="VUou">Poloniex: <a href="https://web.archive.org/web/20170620030820/http://etherscan.io/address/0x32be343b94f860124dc4fee278fdcbd38c102d88" target="_blank">0x32be343b94f860124dc4fee278fdcbd38c102d88</a></li>
    <li id="93JO">Bitfinex: <a href="https://web.archive.org/web/20170620030820/http://etherscan.io/address/0xcafb10ee663f465f9d10588ac44ed20ed608c11e" target="_blank">0xcafb10ee663f465f9d10588ac44ed20ed608c11e</a></li>
    <li id="HNZs">BTC-e: <a href="https://web.archive.org/web/20170620030820/http://etherscan.io/address/0x91337a300e0361bddb2e377dd4e88ccb7796663d" target="_blank">0x91337a300e0361bddb2e377dd4e88ccb7796663d</a></li>
    <li id="wkRg">BitcoinToYou: <a href="https://web.archive.org/web/20170620030820/http://etherscan.io/address/0xf4fe90e63f2a90710bcc0c00f38812c4a882f2ff" target="_blank">0xf4fe90e63f2a90710bcc0c00f38812c4a882f2ff</a></li>
    <li id="a5Kz">Shapeshift1: <a href="https://web.archive.org/web/20170620030820/http://etherscan.io/address/0x120a270bbc009644e35f0bb6ab13f95b8199c4ad" target="_blank">0x120a270bbc009644e35f0bb6ab13f95b8199c4ad</a></li>
    <li id="1Ka5">Shapeshift2: <a href="https://web.archive.org/web/20170620030820/http://etherscan.io/address/0x9e6316f44baeeee5d41a1070516cc5fa47baf227" target="_blank">0x9e6316f44baeeee5d41a1070516cc5fa47baf227</a></li>
    <li id="Hfcn">f2pool: <a href="https://web.archive.org/web/20170620030820/http://etherscan.io/address/0x61c808d82a3ac53231750dadc13c777b59310bd9" target="_blank">0x61c808d82a3ac53231750dadc13c777b59310bd9</a></li>
    <li id="4LRC">DwarfPool1: <a href="https://web.archive.org/web/20170620030820/http://etherscan.io/address/0x2a65aca4d5fc5b5c859090a6c34d164135398226" target="_blank">0x2a65aca4d5fc5b5c859090a6c34d164135398226</a></li>
    <li id="RPLG">Gemini: <a href="https://web.archive.org/web/20170620030820/http://etherscan.io/address/0xd24400ae8bfebb18ca49be86258a3c749cf46853" target="_blank">0xd24400ae8bfebb18ca49be86258a3c749cf46853</a></li>
  </ul>
  <p id="nBcC">Поэтому транзакции навроде такой: <a href="https://etherscan.io/tx/0xc165ab5726c66bb3db50544981f20d143b46a3e990d7b424dbf81d5070dd6278" target="_blank">https://etherscan.io/tx/0xc165ab5726c66bb3db50544981f20d143b46a3e990d7b424dbf81d5070dd6278</a>: </p>
  <figure id="4VIY" class="m_column" data-caption-align="center">
    <img src="https://img4.teletype.in/files/b7/52/b752bc8e-8344-4543-85e2-eb4366f5ba0f.png" width="3456" />
    <figcaption>Пример <a href="https://etherscan.io/tx/0xc165ab5726c66bb3db50544981f20d143b46a3e990d7b424dbf81d5070dd6278" target="_blank">отфильтрованной</a> транзакции</figcaption>
  </figure>
  <p id="Beya">Вопрос логичный и простой: зачем так делать, если хочется манипулировать? Вот именно: незачем. </p>
  <p id="50MY">Тем более что давайте это оценим сквозь призму голосования:</p>
  <p id="y8aV">Дополнительное объяснение: как работала система Carbonvote</p>
  <ol id="irEI">
    <li id="ggng">Кто мог голосовать? Голосовать могли владельцы ETH.</li>
    <li id="71nv">Что являлось голосом? Голосом служили ETH: чем больше ETH находилось на адресе, тем больше был вес голоса.</li>
    <li id="B8Ar">Как (можно было) проголосовать? Чтобы проголосовать: необходимо было отправить транзакцию на адрес <a href="https://etherscan.io/address/0x3039d0a94d51c67a4f35e742b571874e53467804" target="_blank">YES</a>, если вы поддерживаете предложение; либо на адрес <a href="https://etherscan.io/txs?a=0x58dd96aa829353032a21c95733ce484b949b2849&ps=100" target="_blank">NO</a>, если вы выступаете против. При этом у участников оставалась возможность <strong>изменить своё решение</strong>. Если адрес хотя бы один раз отправил транзакцию на адрес <strong>YES</strong>, то <strong>весь объём ETH</strong>, находящийся на этом адресе, автоматически учитывался как голос &quot;ЗА&quot;. Если позже тот же адрес отправлял транзакцию на адрес <strong>NO</strong>, то весь этот объём ETH автоматически пересчитывался как голос &quot;Против&quot;. Если же после голосования владелец адреса решал <strong>воздержаться</strong>, он мог просто перевести свои ETH на другой адрес, который ещё не участвовал в голосовании.</li>
    <li id="it5f">Подсчёт голосовпроисходил динамически и в реальном времени. Система не считала количество отправленных транзакций. Она постоянно отслеживала, <strong>какой объём ETH находится на адресах, уже принявших участие в голосовании</strong>, и именно этот баланс учитывался при подсчёте.</li>
    <li id="nWKs">Безопасность средств. Никакие ETH не собирались и не блокировались. Поскольку система учитывала не количество ETH, отправленных на адреса YES или NO, а текущий баланс адресов, участвовавших в голосовании, пользователям рекомендовалось отправлять нулевую транзакцию (или минимально возможную сумму ETH, если кошелёк не поддерживал нулевые переводы) лишь для передачи сигнала о своём выборе. Например, кошелёк Mist не позволял отправлять транзакции с нулевой суммой, поэтому в нём требовалось отправить минимально возможное количество ETH. Если же по какой-либо причине смарт-контракт всё-таки получал от голосующего реальные средства, эти ETH автоматически возвращались на исходный адрес сразу после получения.</li>
  </ol>
  <p id="kunk">Поэтому когда говорят о 5.5% и подобных цифрах, то попросту забывают, что CEXs, на которых Эфира было очень много (в 2016-ом DeFi лишь зарождались) попросту сошли с дистанции, а ряд пользователей вообще хранили средства на холоде (скажем, у меня из всех кошельков было активен лишь 1). </p>
  <p id="lYwu">Ещё одна важная цитата звучит <a href="https://github.com/ethereum/go-ethereum/issues/2832" target="_blank">так</a>: &quot;.... технически это <strong>софтфорк</strong>. Однако <strong>если</strong> за ним не окажется <strong>51% хешрейта</strong>, то на практике он будет вести себя как <strong>хардфорк</strong>. Я не считаю справедливым предполагать, что это обновление обязательно получит поддержку 51% вычислительной мощности сети. Поэтому эти строки кода всё равно следует удалить&quot;. И зададим себе вопрос: если всё предопределено, то зачем же так заморачиваться? </p>
  <p id="Qfqz">Больше скажу вам, точнее - скажет один из участников обсуждения на Гитхабе: &quot;Следует учитывать, что режимы fast sync и light client не проверяют переходы состояния. Они проверяют только заголовки блоков и Proof-of-Work. Поэтому клиент, не знающий о форке (то есть не обновлённый), всегда будет синхронизироваться с самой длинной цепочкой, поскольку у него нет информации о том, какие значения искать в заголовках. <strong>Даже если вы выступаете против форка, рекомендуется обновить клиент, чтобы он знал</strong>, какую цепочку следует игнорировать&quot;. Опять же: зачем так делать, если кругом все лоббируют лишь хардфорк? </p>
  <h3 id="fgU9">Пример №05. Позиция Ethereum Classic</h3>
  <p id="X0aD">Возьмём большой <a href="https://ethereumclassic.org/why-classic/genesis" target="_blank">документ</a> и рассмотрим его тезисы:</p>
  <ul id="z6zm">
    <li id="80qP">Около 70% потерянных средств удалось вернуть, однако оставшиеся 30% оставались под контролем атакующего и не могли быть возвращены.</li>
    <li id="DqAD">Весьма спорное &quot;голосование монетами&quot; (coin vote) привело к тому, что Ethereum Foundation поддержала проведение хардфорка, отказавшись от своей прежней нейтральной позиции.</li>
    <li id="irXY">Будущие историки криптовалют, несомненно, будут рассматривать происхождение Ethereum Classic как уникальный пример, наглядно демонстрирующий социально-технологическую природу блокчейнов.</li>
    <li id="68yH">Все, кто внесли вклад в создание Ethereum — сторонники форка, противники форка, разработчики и участники сообщества — заслуживают уважения за свою роль в создании одного из наиболее значимых технологических достижений своего поколения.</li>
    <li id="6LhC">В этой истории можно увидеть обстоятельства, которые позволяют предположить наличие потенциальных финансовых конфликтов интересов. Однако подобные стимулы являются естественной частью практически любого блокчейн-проекта и потому скорее ожидаемы, чем удивительны. В любом случае невозможно достоверно определить, насколько такие стимулы действительно повлияли на принятие решений. Поэтому, по мнению авторов, все участники событий заслуживают <strong>презумпции добросовестности</strong>.</li>
    <li id="Y07A">The DAO быстро стала одной из главных тем в экосистеме Ethereum. Во многом это объяснялось тем, что проект получил заметную поддержку со стороны многих членов Ethereum Foundation. Помимо того что руководителем проекта являлся бывший директор по коммуникациям EF, The DAO назначила группу кураторов (curators). Кураторы обладали правом накладывать вето на отдельные действия и выступали в качестве своеобразного механизма аварийной защиты (<em>fail-safe</em>). Предполагалось, что это повысит доверие инвесторов, поскольку позволит защитить средства от некоторых видов атак. Все 11 кураторов ранее работали непосредственно в проекте Ethereum или в Ethereum Foundation, включая нескольких весьма известных представителей сообщества.</li>
    <li id="TR6u">Условия создания The DAO определяются кодом смарт-контракта, размещённого в блокчейне Ethereum по адресу <code>0xbb9bc244d798123fde783fcc1c72d3bb8c189413</code>. Никакие положения настоящего описания, а также никакие иные документы или сообщения не могут изменять либо дополнять обязательства и гарантии сверх тех, что содержатся в коде The DAO. Все пояснения и описания предоставляются исключительно в образовательных целях и не заменяют и не изменяют положения, закреплённые в коде The DAO. Если между настоящим описанием и фактической <strong>функциональностью кода The DAO существует какое-либо противоречие, приоритет всегда имеет код смарт-контракта</strong>.</li>
    <li id="iDUG">Сообщество Ethereum раскололось на два противостоящих лагеря: сторонников форка (forkers) и противников форка (anti-forkers).</li>
    <li id="c8g6">В ответ на... опасения сторонники форка, по мнению авторов, стремились преуменьшить риск раскола сети. Такие предупреждения зачастую сводились к утверждениям вроде: &quot;Не стоит об этом беспокоиться - это лишь теория заговора, придуманная биткоин-максималистами&quot;.  Более того, авторы отмечают, что <strong>никакой подготовки к возможному расколу сети практически не проводилось</strong>. В частности: не была реализована защита от replay-атак; криптовалютные биржи не были заранее предупреждены о возможном появлении двух цепочек, чтобы защититься от двойного расходования (double spending).</li>
    <li id="duWr">Кульминацией этой неприятной истории стали угрозы <strong>деанонимизации (doxxing)</strong> и иных форм давления в отношении противников хардфорка. В частности, представители<strong> slock.it </strong>призывали раскрывать личности тех, кто выступал против форка, что, по мнению авторов, создавало атмосферу запугивания и удерживало многих известных противников форка от публичных выступлений... &quot;Мне было бы ОЧЕНЬ интересно узнать личности тех, кто координирует сопротивление хардфорку. Напишите мне в личные сообщения [адрес скрыт]@slock.it&quot;. </li>
    <li id="G5l3">Если посмотреть на обсуждения форка The DAO на Reddit, можно заметить, что, судя по количеству голосов (<a href="https://old.reddit.com/r/ethereum/comments/4p7mhc/update_on_the_white_hat_attack/d4iqgx1/" target="_blank">upvotes</a>), значительная часть сообщества Ethereum выступала против хардфорка. По мнению авторов, причиной этого было опасение, что подобные меры сами по себе признали бы возможность раскола сети, а значит - сделали бы его более вероятным.</li>
    <li id="hS0o">Во время обсуждений <strong>Ethereum Foundation</strong> официально пыталась сохранять позицию нейтралитета. Предполагалось, что вопрос о том, как реагировать на взлом The DAO, должно решать само сообщество Ethereum, а не руководство фонда. Такой подход был важен, поскольку формально снимал с Ethereum Foundation ответственность за принятое решение. Однако, по мнению авторов, несмотря на заявления о нейтралитете, различные подразделения Ethereum Foundation своими действиями демонстрировали обратное.</li>
    <li id="1jAp">При этом авторы отмечают, что некоторые другие команды внутри Ethereum Foundation действительно пытались сохранить нейтральный подход. Например, браузер децентрализованных приложений Mist при запуске не выбирал цепочку автоматически, а требовал от пользователя явно указать, какую версию блокчейна он хочет использовать. Тем самым пользователь не оказывался по умолчанию на одной из сторон раскола.</li>
    <li id="N7al">Как выяснилось: один адрес обладал таким количеством ETH, что обеспечил около 25% всех поданных голосов; никакого минимального порога участия (<em>quorum</em>) предусмотрено не было; участие в голосовании приняли лишь около 6% всего объёма ETH; голосование было объявлено и завершено всего за 12 часов, что практически не оставило времени противникам форка организовать ответную кампанию и исключило возможность участия значительной части мирового сообщества, находившейся в это время в другом часовом поясе.</li>
  </ul>
  <p id="yCdx">И вот что интересно: ни один из доводов, к сожалению, я подтвердить не смог в результате обычной аналитики:</p>
  <ol id="uYU5">
    <li id="C4rS">На разных форумах нашёл больше сторонников форков.</li>
    <li id="m6gj">Никаких выходов ради подтверждения приверженности НЕ форка - тоже.</li>
    <li id="8uxF">А тезис про то, что запуск голосования - это не легально, совсем уж... мелко: создать подобное могла и другая сторона, но почему-то так и не сделала. Почему? На этот вопрос ответа до сих пор нет. </li>
    <li id="0jWT">То, что подготовки не было... Выше есть масса пруфов, доказывающих обратное. </li>
  </ol>
  <h2 id="YFiw">Виталик Бутерин и моральный риск</h2>
  <figure id="0cgx" class="m_column" data-caption-align="center">
    <img src="https://img2.teletype.in/files/98/30/9830ae01-efa0-4f25-a49c-b5c74caf3152.png" width="3456" />
    <figcaption>Пост В. Бутерина: <a href="https://x.com/VitalikButerin/status/1187854232398917632" target="_blank">https://x.com/VitalikButerin/status/1187854232398917632</a></figcaption>
  </figure>
  <p id="JiD7">Чтобы не ходить вокруг да около - сразу к сути: как видите, даже через 3 года после форка, когда у Виталика точно были все карты в руках, он не нашёл поддержки большинства на внедрения механизма того самого &quot;рычага&quot;, про кот. постоянно талдычат СМИ. </p>
  <p id="bzkg">Зачем же задавать вопрос, если такой механизм УЖЕ ЯКОБЫ БЫЛ в 2016 году? Вот именно: незачем. </p>
  <p id="2QUd">Поэтому т.н. <a href="true">моральный</a> риск, на кот. постоянно ссылаются противники хардфорка - это за уши притянутый тезис. Именно к The DAO форку. </p>
  <h2 id="4qBI">Выводы</h2>
  <p id="cW1D">Таким образом, как ни пытался я найти данные, подтверждающие позицию Ethereum Classic, которую в своё время (и до сих пор) так сильно зашилли СМИ, но ничего подобного не обнаружил:</p>
  <ol id="s1YH">
    <li id="PvM7">Голосования проходили на разных платформах и везде, где смог найти архивы и др. данные, они были в пользу форка. </li>
    <li id="90v2">На подготовку ушло не 12 часов и не 3, а достаточное количество дней: и противники форка были явно менее активны. </li>
    <li id="y8kK">Манипуляции были и с той и с другой стороны.</li>
    <li id="d7U6">The DAO команда вела себя плохо, т.к. не обратила внимания должного на уже найденные ошибки и недочёты. </li>
    <li id="vWlD">Но только речь шла не про форк контрактов The DAO, а всей сети Эфира и поэтому я так и не увидел в этом никакого нарушения децентрализации: комьюнити спросили - комьюнити ответило. </li>
  </ol>
  <p id="hB8V">В целом ещё много &quot;но&quot; находят критики: скажем, что майнеры... были финансово мотивированы! Но &quot;секрет&quot; в том, что майнеры ВСЕГДА финансово мотивированы. Абсолютно всегда. </p>
  <p id="vJ6c">Поэтому данные у вас в руках: как с ними поступать - решать вам, но я свои выводы сделали и итоги подвёл.</p>
  <h2 id="DNzR">Код - это закон?</h2>
  <p id="J8ha">Да. Но напомню банальные истины:</p>
  <ul id="LocV">
    <li id="XfgH">Рабство было законным;</li>
    <li id="1OB9">Крепостное право было законным;</li>
    <li id="0Cz5">Холокост был законным...</li>
  </ul>
  <p id="mcDU">Поэтому закон без легитимности - ничто, а легитимность должна исходить от народа, а народ в любом чейне - это его майнеры/валидаторы/etc., HODLs и др. участники. </p>
  <p id="vyKB">Поэтому для децентрализации важнее другое: это всё ещё блокчейн для людей или это люди, уже встроенные в блокчейн, который вне?..</p>
  <h2 id="MBxU">Базовые документы</h2>
  <p id="lO88">Список общий:</p>
  <ul id="XyQd">
    <li id="orgx">До форка: <a href="https://blog.ethereum.org/2016/07/15/to-fork-or-not-to-fork" target="_blank">https://blog.ethereum.org/2016/07/15/to-fork-or-not-to-fork</a></li>
    <li id="BZAj">После форка: <a href="https://blog.ethereum.org/2016/07/20/hard-fork-completed" target="_blank">https://blog.ethereum.org/2016/07/20/hard-fork-completed</a></li>
    <li id="lZhW">Блок форка: <a href="https://etherscan.io/block/1920000" target="_blank">https://etherscan.io/block/1920000</a></li>
    <li id="6TWI">EIP: <a href="https://eips.ethereum.org/EIPS/eip-779" target="_blank">https://eips.ethereum.org/EIPS/eip-779</a></li>
    <li id="VBSQ">Архив сообщений: <a href="https://roddie.digital/cryptopians/index.html" target="_blank">https://roddie.digital/cryptopians/index.html</a></li>
    <li id="C6BN">Форк-база: <a href="https://forklog.com/news/sostoyalsya-uspeshnyj-hardfork-ethereum" target="_blank">https://forklog.com/news/sostoyalsya-uspeshnyj-hardfork-ethereum</a></li>
  </ul>
  <p id="Pro9">История The DAO:</p>
  <ul id="oE5N">
    <li id="O80p">Основатели: <a href="https://web.archive.org/web/20151003053127/http://slock.it/" target="_blank">https://web.archive.org/web/20151003053127/http://slock.it/</a></li>
    <li id="CgiL">История на английском: <a href="https://medium.com/slock-it-blog/the-history-of-the-dao-and-lessons-learned-d06740f8cfa5" target="_blank">https://medium.com/slock-it-blog/the-history-of-the-dao-and-lessons-learned-d06740f8cfa5</a></li>
    <li id="utsm">Доп. к истории на англ.: <a href="https://www.ofnumbers.com/2016/05/15/whats-the-deal-with-daos" target="_blank">https://www.ofnumbers.com/2016/05/15/whats-the-deal-with-daos</a> </li>
    <li id="SZAp">История на русском: <a href="https://habr.com/ru/companies/wirex/articles/394903/" target="_blank">https://habr.com/ru/companies/wirex/articles/394903/</a></li>
    <li id="5tJw">Общие данные по истории: <a href="https://forklog.com/exclusive/zahvatyvayushhaya-istoriya-the-dao-rabota-nad-oshibkami" target="_blank">https://forklog.com/exclusive/zahvatyvayushhaya-istoriya-the-dao-rabota-nad-oshibkami</a></li>
    <li id="cUZM">Мораторий: <a href="https://forklog.com/exclusive/the-dao-moratorium" target="_blank">https://forklog.com/exclusive/the-dao-moratorium</a></li>
    <li id="UB2c">Письмо: <a href="https://forklog.com/news/vse-po-zakonu-atakovavshij-the-dao-obratilsya-k-soobshhestvu" target="_blank">https://forklog.com/news/vse-po-zakonu-atakovavshij-the-dao-obratilsya-k-soobshhestvu</a></li>
    <li id="sZb5">Оценка письма как подделки: <a href="https://forklog.com/news/mnenie-ekspertov-pismo-ot-imeni-atakovavshego-the-dao-poddelka" target="_blank">https://forklog.com/news/mnenie-ekspertov-pismo-ot-imeni-atakovavshego-the-dao-poddelka</a></li>
  </ul>
  <p id="FiNA">Хак The DAO:</p>
  <ul id="DjJ5">
    <li id="g4V1">Краткая сводка: <a href="https://xakep.ru/2016/06/17/splitdao-attack" target="_blank">https://xakep.ru/2016/06/17/splitdao-attack</a></li>
    <li id="nmSM">Уязвимости до взлома: <a href="https://web.archive.org/web/20201108090731/https://news.softpedia.com/news/researchers-find-security-flaws-in-dao-ethereum-vc-fund-on-the-eve-of-its-launch-504615.shtml" target="_blank">https://web.archive.org/web/20201108090731/https://news.softpedia.com/news/researchers-find-security-flaws-in-dao-ethereum-vc-fund-on-the-eve-of-its-launch-504615.shtml</a></li>
    <li id="JZj5">Перевод по уязвимостям: <a href="https://web.archive.org/web/20200814060232/https://xakep.ru/2016/06/01/dao-criticism/" target="_blank">https://web.archive.org/web/20200814060232/https://xakep.ru/2016/06/01/dao-criticism/</a></li>
    <li id="UN92">Атаки Влада: <a href="https://forklog.com/exclusive/ataki-vlada-obzor-osnovnyh-uyazvimostej-the-dao" target="_blank">https://forklog.com/exclusive/ataki-vlada-obzor-osnovnyh-uyazvimostej-the-dao</a></li>
    <li id="ysdZ">Влияние атак: <a href="https://forklog.com/exclusive/rekursivnyj-vyzov-the-dao-na-grani-smerti-i-hardfork-ethereum" target="_blank">https://forklog.com/exclusive/rekursivnyj-vyzov-the-dao-na-grani-smerti-i-hardfork-ethereum</a></li>
    <li id="MUrJ">Итоги: <a href="https://forklog.com/exclusive/uroki-dao-kuda-privodyat-mechty" target="_blank">https://forklog.com/exclusive/uroki-dao-kuda-privodyat-mechty</a></li>
  </ul>
  <p id="Sh2U"><em>До!</em></p>

]]></content:encoded></item><item><guid isPermaLink="true">https://teletype.in/@menaskop/defi-derivatives-26</guid><link>https://teletype.in/@menaskop/defi-derivatives-26?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop</link><comments>https://teletype.in/@menaskop/defi-derivatives-26?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop#comments</comments><dc:creator>menaskop</dc:creator><title>DeFi. Деривативы. Оптимальный коэффициент хеджирования для дельта-нейтральных LP под риском ликвидации</title><pubDate>Mon, 13 Jul 2026 06:26:15 GMT</pubDate><media:content medium="image" url="https://img4.teletype.in/files/75/48/754870ce-2f36-46ff-a7f4-bbf6cc2b25fc.png"></media:content><category>DeFi</category><description><![CDATA[<img src="https://img2.teletype.in/files/19/a0/19a0f024-c0c7-4022-9ec8-a8906986449f.png"></img>Это вольный и сокращённый перевод (без лишних формул):]]></description><content:encoded><![CDATA[
  <figure id="9SFU" class="m_column">
    <img src="https://img2.teletype.in/files/19/a0/19a0f024-c0c7-4022-9ec8-a8906986449f.png" width="1024" />
    <figcaption>Хедж</figcaption>
  </figure>
  <h2 id="XC8m">Перевод</h2>
  <p id="EIIu">Это вольный и сокращённый перевод (без лишних формул): <a href="https://arxiv.org/pdf/2603.19716" target="_blank">https://arxiv.org/pdf/2603.19716</a></p>
  <h2 id="g8wh">Обобщение</h2>
  <p id="vrNy">Статья исследует очень практичную, но до этого плохо формализованную задачу: как LP в (constant-product AMM) должен хеджировать ценовой риск, если сам хедж строится не через опционы, а через заём токенов под залог. </p>
  <p id="kEhU">Главная мысль автора проста: чем больше доля хеджа, тем меньше колебания PnL, но тем выше риск ликвидации, потому что растёт LTV. Поэтому полностью захеджировать LP - почти никогда не оптимально в реальной DeFi-среде, даже если без учёта ликвидации это выглядело бы лучшим решением. </p>
  <p id="msH3">Ключевой результат статьи: без ограничения по ликвидации - оптимум почти равен полному хеджу, h* ≈ 0.98, но такой режим даёт недопустимо высокий риск ликвидации. </p>
  <p id="8VbN">После учёта ограничения по вероятности ликвидации практический оптимум сдвигается в диапазон примерно 50-70%, а в базовой калибровке - к 60–65%. </p>
  <p id="Dldk">Именно это и есть основной вклад работы, кот. можно определить тезисом: &quot;Не хеджируй всё, а хеджируй частично, так чтобы выигрыш в дисперсии не съедался долгом и ликвидациями&quot;. </p>
  <p id="kvG2">Вклад статьи состоит не только в формуле для h*, но и в связке трёх уровней анализа: замкнутая аналитика для неограниченного оптимума (unconstrained optimum), приближение вероятности ликвидации через время первого прохождения (first-passage time) и метод Монте-Карло (Monte Carlo) (с калибровкой по ончейн-данным). Это делает работу ценной не как абстрактную математику, а как операционную инструкцию для LP-стратегий, вольт-менеджеров и риск-тулз в DeFi. </p>
  <h2 id="wlzv">Что именно моделирует статья?</h2>
  <p id="upON">Автор рассматривает LP-позицию (в constant-product AMM), где стоимость позиции без учёта комиссий и фарминга ведёт себя как функция от двух цен активов. Это соответствует механике Uniswap-подобных AMM, где пул двух токенов подчинён <a href="https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D0%BD%D1%82" target="_blank">инварианту</a> x⋅ y= k, а LP фактически держит пропорциональную долю резервов. В официальной документации Uniswap это описано именно как AMM с двумя резервами и ценообразованием через произведение с постоянным коэффициентом (constant-product). </p>
  <p id="Oyk4">Далее LP строит частично нейтральную к цене позицию: кладёт стейблкоин как обеспечение (collateral) в лендинговый протокол, занимает оба токена пула и шортит их относительно своей LP-экспозиции. </p>
  <p id="ZyLF">На практике эта логика хорошо соответствует тому, как работают сверх-коллатеризированные (overcollateralized) залоговые позиции (borrow) в AAVE-подобных системах: безопасность позиции определяется фактором здоровья (health factor / <strong>HF</strong>) и LTV, а при ухудшении HF наступает ликвидация. </p>
  <p id="TCwq">AAVE официально определяет HF как отношение стоимости залога (collateral) с поправкой на порог ликвидации (liquidation threshold) к стоимости долговой позиции; NAVI аналогично указывает, что ликвидация разрешена, когда HF падает ниже единицы (1). </p>
  <p id="jr3H">Именно здесь появляется новая для литературы развилка. В классических работах по IL и LP-риску исследуется потеря относительно HODL, либо через негативный отбор (adverse selection), либо <a href="true">репликация</a> LP через  деривативы. </p>
  <p id="pmOW">[Прим. Menaskop: репликация в финансах - инвестиционная стратегия или метод, целью которого является точное воспроизведение динамики базового индекса или актива].</p>
  <p id="2sdn">Но эта статья фокусируется на ином объекте: не просто на IL как выплате (payoﬀ), а на выборе непрерывной доли хеджа (h) при наличии протокольного риска ликвидации. Это и есть её предметная новизна. </p>
  <p id="6sJO">Ниже - разобрал логику модели в виде компактной схемы.</p>
  <figure id="hGoA" class="m_column">
    <img src="https://img2.teletype.in/files/d4/8e/d48efda4-3510-483c-a93c-e103ada1266e.png" width="3132" />
    <figcaption>Общая схема</figcaption>
  </figure>
  <p id="fuEB">Сильная сторона постановки (подобного вопроса) - связь AMM-механики с лендинговыми правилами. Слабая - модель ограничена двумя токенами, моделью (full-range constant-product AMM) и фиксированными ставками; концентрированной ликвидностью (concentrated liquidity), стохастическими (случайными) ставками (stochastic rates), тогда как эффекты микроструктуры рынка, зависящие от траектории движения цены (path-dependent microstructure eﬀects) оставлены за рамками материала. </p>
  <blockquote id="KbA8">Сам автор прямо пишет, что модель хеджирует ценовую экспозицию (price exposure), но не устраняет LVR и не охватывает всех нелинейных LP-издержек. </blockquote>
  <p id="5tTA">[Прим. Menaskop: LVR (Loss Versus Rebalancing) - потери LP относительно стратегии непрерывной ребалансировки.]</p>
  <h2 id="SUXJ">Формулы и визуализации</h2>
  <p id="82U0">Базовые формулы и их экономический смысл описаны мной ниже.  Ключевая формула стоимости LP-позиции в статье:</p>
  <figure id="lv9T" class="m_column">
    <img src="https://img4.teletype.in/files/fa/b4/fab415c6-057c-40a9-aafe-43c20fd9a578.png" width="264" />
    <figcaption>Формула №01</figcaption>
  </figure>
  <p id="j9rf">Интуитивное её прочтение таково: LP в (constant-product) пуле ведёт себя не как простой HODL двух токенов 50/50, а как их <a href="https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B5%D0%B4%D0%BD%D0%B5%D0%B5_%D0%B3%D0%B5%D0%BE%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5" target="_blank">геометрическое среднее</a>. </p>
  <p id="d4P3">Когда цены двух активов расходятся, геометрическое среднее растёт хуже арифметического - отсюда и структурная стоимость <strong>divergence</strong>/<strong>IL</strong>. Это полностью согласуется с классической литературой по Uniswap v2 LP. </p>
  <p id="NtrL">Полная PnL-структура у автора такова:</p>
  <figure id="TAhX" class="m_column">
    <img src="https://img4.teletype.in/files/b9/b5/b9b52d56-11d9-4e33-9402-2773fa7cdf2c.png" width="850" />
    <figcaption>Формула №02</figcaption>
  </figure>
  <p id="4R7h">Смысл по блокам такой:</p>
  <figure id="fCkM" class="m_column">
    <img src="https://img2.teletype.in/files/df/fc/dffc1d24-2b48-43d4-b27d-c53e3e2c4871.png" width="102" />
  </figure>
  <p id="ebqt">Это стоимость LP-позиции - она даёт экспозицию к двум токенам. </p>
  <figure id="7Bm5" class="m_original">
    <img src="https://img1.teletype.in/files/80/44/80443eed-2294-4726-8b7f-aed565c4c655.png" width="58" />
  </figure>
  <p id="YI39">Комиссии + доп. награды (fees + incentives) - основной источник доход от удержания позиции или текущая доходность позиции (carry) в статье. </p>
  <figure id="eK77" class="m_original">
    <img src="https://img1.teletype.in/files/8f/dc/8fdc2882-227e-405f-8bf8-476d011fdb4a.png" width="232" />
  </figure>
  <p id="SUww">Доход на залог (collateral) - <strong>не</strong>большой стабилизирующий вклад. </p>
  <figure id="TCyJ" class="m_original">
    <img src="https://img1.teletype.in/files/87/03/87038e52-70aa-4834-8169-1543e00b9230.png" width="372" />
  </figure>
  <p id="xPJR">Рост стоимости занятых токенов - главный канал риска при росте цен. Тут немного отойду в сторону и опишу следующее: автор называет это всё - debt MTM (Mark-to-Market).</p>
  <p id="bJYW">Что это действительно означает? Если коротко, то переоценку стоимости долга по текущим рыночным ценам.</p>
  <p id="ZL5O">Иными словами:</p>
  <ul id="iS58">
    <li id="by1P">Вы заняли токены A и B;</li>
    <li id="Gx6g">Их количество фиксировано;</li>
    <li id="0aef">Но их стоимость в долларах постоянно меняется;</li>
    <li id="L6EY">Именно это изменение стоимости долга и описывает данный член уравнения.</li>
  </ul>
  <p id="zr5l">То есть формулировка &quot;рост стоимости занятых токенов&quot; по сути верна, но она отражает частный случай. Более точно следует описать это как переоценка стоимости долга (<strong>MTM</strong>) и/или изменение рыночной стоимости занятых токенов, или даже Mark-to-Market долга (рост или снижение стоимости обязательств). </p>
  <p id="nEZf">Почему это важно?</p>
  <p id="A7YI">Потому что этот член уравнения может быть как отрицательным, так и положительным.</p>
  <p id="CUzT">Приведу пример</p>
  <ul id="ODRY">
    <li id="9DWu">Заняли 1 ETH по $2000;</li>
    <li id="6Jt3">ETH вырос до $3000 =&gt; долг увеличился на $1000 =&gt; PnL ухудшился;</li>
    <li id="j1aQ">ETH упал до $1500 =&gt; долг уменьшился на $500 =&gt; PnL улучшился.</li>
    <li id="qzR1">Поэтому debt MTM ≠ только рост (падение) стоимости долга.</li>
  </ul>
  <p id="Cgtt">Это именно рыночная переоценка обязательств.</p>
  <figure id="9Jke" class="m_original">
    <img src="https://img3.teletype.in/files/65/7c/657c739e-0352-42f1-925d-72f2b2e8472a.png" width="306" />
  </figure>
  <p id="LNEp">Процент по займу - линейно ухудшает стоимость обслуживания займа (expected return). Важно, что этот член уравнения описывает именно стоимость обслуживания займа, а не его рыночную переоценку.</p>
  <p id="nAw7">Разберём по частям:</p>
  <ul id="Aj12">
    <li id="kjdQ">rA​ - процентная ставка по займу токена A.</li>
    <li id="mpei">rB​ - процентная ставка по займу токена B.</li>
    <li id="3eRS">t - время.</li>
    <li id="qNvg">hVо/2 - величина каждого из двух займов (автор предполагает, что они симметричны).</li>
  </ul>
  <p id="V6AJ">Иными словами, вы заняли два актива, и каждый день платите проценты. Эти проценты не зависят от цены токенов.</p>
  <p id="5K1h">Пример приведу - допустим:</p>
  <ul id="IR9R">
    <li id="botZ">заняли ETH на $5 000;</li>
    <li id="Lijb">заняли USDC на $5 000;</li>
    <li id="hubD">ставка по ETH - 4% годовых;</li>
    <li id="VuIK">ставка по USDC - 6% годовых.</li>
  </ul>
  <p id="bEWR">Тогда стоимость обслуживания долга составляет примерно: 5000 × 4% + 5000 × 6% = 500 долларов в год .</p>
  <p id="UZiO">Если прошло полгода, то около $250. Именно этот расход описывает последний член формулы.</p>
  <p id="aOk0">Чем он отличается от debt MTM? Их часто путают, но это совершенно разные вещи. Debt MTM звучит так: &quot;Я занял 1 ETH. Он подорожал с $2000 до $3000. Теперь вернуть этот ETH стало дороже&quot;.  Это изменение <strong>стоимости самого долга</strong>.</p>
  <p id="bmqT">Borrow cost звучит иначе: &quot;Пока я держал этот долг, я платил 4% годовых&quot;.  Это <strong>стоимость пользования долгом</strong>, независимо от того, вырос ETH или упал.</p>
  <p id="1wnE">Давайте проведу аналогию с ипотекой? Давайте! Представьте, что вы взяли ипотеку. Есть две разные вещи:</p>
  <ol id="cc46">
    <li id="RVEk"><strong>Стоимость квартиры изменилась. </strong>Это аналог <strong>debt MTM</strong> (рыночная переоценка).</li>
    <ul id="475I">
      <li id="Gd1i">Купили за $300 000.</li>
      <li id="sVlC">Теперь она стоит $400 000.</li>
    </ul>
    <li id="bkyp"><strong>Каждый месяц вы платите банку проценты. </strong>Это аналог <strong>borrow cost</strong>. </li>
  </ol>
  <p id="Z0sQ">Это независимые источники изменения вашего PnL: вот в чём они пересекаются. </p>
  <p id="1tcL">Эта декомпозиция важна: хедж уменьшает волатильность, но не улучшает <strong>все структурные издержки LP (</strong>structural LP drag) сам по себе; его польза идёт главным образом через снижение дисперсии (variance reduction - ещё можно перевести как уменьшение разброса результатов, но я обычно выбираю первый вариант), а вред - через стоимость займа (borrow cost) и риск ликвидации (liquidation risk). Это один из самых содержательных выводов работы. </p>
  <p id="cVSm">Ограничение ликвидации задаётся через LTV:</p>
  <figure id="4BBt" class="m_original">
    <img src="https://img1.teletype.in/files/c7/c8/c7c8cb54-c73d-432b-8f7b-da4f8d77311b.png" width="438" />
  </figure>
  <p id="z2pa">Экономическая интуиция здесь предельно важна: при фиксированном стейблкоин коллетерале ликвидацию вызывают не падения, а рост цен занятых активов, потому что<strong> дорожает долг</strong>. </p>
  <p id="etgK">Это качественно отличается от привычной интуиции лендинга &quot;испугайся падения collateral&quot; и особенно критично для дельта-нейтральных LP, где short-leg финансируется за счёт займа.</p>
  <p id="YrFY">[Прим. Menaskop: short leg - короткая нога стратегии, то есть та часть многокомпонентной стратегии, где открыта короткая (проданная) позиция].</p>
  <p id="9vk5">AAVE и NAVI официально подтверждают ту же логику через HF и LT: риск ликвидации растёт, когда стоимость займа (borrow value) становится слишком велика относительно стоимости коллетерала. </p>
  <p id="Qv9E"><strong>Где возникает аналитический оптимум?</strong></p>
  <p id="jwh0">Автор выводит, что средняя прибыль по сути линейно убывает по h из-за стоимости займа (borrow cost), а дисперсия - квадратична по h. Из этого получается замкнутая формула для оптимума без ограничений (unconstrained optimum):</p>
  <figure id="jN3l" class="m_original">
    <img src="https://img2.teletype.in/files/d7/7b/d77b9ca4-7067-4ae9-aa0f-8bf089a1c589.png" width="260" />
  </figure>
  <p id="XfLv">Здесь важно не запоминать символы, а понимать смысл. Если бы ставки заимствования были малы, а ликвидации - невозможны, оптимум тяготел бы к почти полному хеджу, потому что <a href="https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D1%86%D0%B8%D1%8F" target="_blank">ковариационная</a> структура LP-позиции и шорт-баскет (short basket) даёт почти максимальное снижение <a href="https://ru.wikipedia.org/wiki/%D0%94%D0%B8%D1%81%D0%BF%D0%B5%D1%80%D1%81%D0%B8%D1%8F_%D1%81%D0%BB%D1%83%D1%87%D0%B0%D0%B9%D0%BD%D0%BE%D0%B9_%D0%B2%D0%B5%D0%BB%D0%B8%D1%87%D0%B8%D0%BD%D1%8B" target="_blank">дисперсии</a>. </p>
  <p id="LtmQ">В базовой калибровке статьи именно это и происходит:<strong> h* ≈ 0.977</strong>.</p>
  <p id="dxlB">Но это ложный оптимум для реальной DeFi. Поэтому автор вводит ограничение на вероятность первым касанием ликвидационного барьера и получает:</p>
  <figure id="UtpY" class="m_original">
    <img src="https://img2.teletype.in/files/1c/d0/1cd0f96d-79bf-4ba1-8ce2-e5c48a6f6822.png" width="264" />
  </figure>
  <p id="m6s4">То есть реальный оптимум - либо аналитический максимум <a href="https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D1%8D%D1%84%D1%84%D0%B8%D1%86%D0%B8%D0%B5%D0%BD%D1%82_%D0%A8%D0%B0%D1%80%D0%BF%D0%B0" target="_blank">Шарпа</a>, либо максимально допустимый по риску ликвидации (liquidation risk) хедж. Центральный вывод статьи: <strong>на реалистичных параметрах почти всегда срабатывает второй случай</strong>. </p>
  <p id="bbim">Почему время первого прохождения здесь уместно?</p>
  <p id="XVcf">Точная вероятность достижения порога ликвидации вычисляется сложно, поскольку отношение LTV зависит от суммы двух взаимосвязанных случайных процессов (<strong>GBM</strong>), описывающих динамику цен активов. Для такой суммы не существует простого аналитического выражения, позволяющего определить вероятность первого достижения критического уровня. </p>
  <p id="0iHy">Поэтому автор заменяет исходную сумму одним эквивалентным случайным процессом, параметры которого подбираются так, чтобы совпадали <a href="https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BE%D0%B6%D0%B8%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5" target="_blank">математическое ожидание</a> и дисперсия. </p>
  <p id="xf6k">После этого применяется известная формула для расчёта вероятности первого достижения заданного уровня. Такое приближение нельзя считать абсолютно точным, однако в задачах управления риском оно обычно оказывается достаточно надёжным. </p>
  <p id="fkoW">Причина в том, что для оценки вероятности ликвидации гораздо важнее правильно воспроизвести среднее поведение процесса, его изменчивость и расстояние до критического уровня, чем идеально описать крайне маловероятные события <a href="https://ru.wikipedia.org/wiki/%D0%A5%D0%B2%D0%BE%D1%81%D1%82_%D1%80%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F" target="_blank">на хвостах распределения</a>.</p>
  <p id="bjQI">Статья показывает, что это приближение хорошо попадает в Монте-Карло распределение: ошибка вероятности ликвидации в релевантном диапазоне хеджа до 70% составляет менее 0.2 п.п., а на полном хедже погрешность увеличивается, но остаётся консервативной.</p>
  <p id="n2hg">Для практики это хороший результат: риск-менеджер может получить быструю оценку допустимого колебания без тяжёлой симуляции.</p>
  <p id="0tQx">Ниже приведена реконструкция ключевого вывода по данным статьи. Вывод построен по таблице из первоисточника: он показывает именно то, что словами формулирует автор: Шарп растёт до зоны около 60–65%, а потом его убивает ускоряющийся риск ликвидации.</p>
  <p id="Pdok">При этом ожидаемый ROE снижается относительно медленно, а стандартное отклонение падает быстро до примерно 60–70% хеджа. Именно поэтому не полный хедж оказывается лучше полного отказа от хеджа и лучше почти полного хеджа.</p>
  <h2 id="78qE">Что дают численные результаты?</h2>
  <p id="5Buw">В базовой калибровке статьи используются волатильности , корреляция, ставки заимствования 3% и 15%, LP reward rate на уровне 54% годовых, supply rate по стейблкоину 4%, максимальный LTV 80%, collateral-to-LP ratio и горизонт 90 дней. Эти параметры откалиброваны по паре SUI/NS и lending/AMM-условиям экосистемы Sui. </p>
  <p id="N7pF">Главные численные выводы сводятся к следующему:</p>
  <figure id="6R9V" class="m_column">
    <img src="https://img3.teletype.in/files/21/29/2129408f-6846-47a1-bff8-ea045adceb9c.png" width="1122" />
    <figcaption>Данные из статьи</figcaption>
  </figure>
  <p id="KyjR">Это очень важный итог. В стратегии такого типа опаснее не переусердствовать, а перехеджироваться. Начиная примерно после 70% выводы статьи показывают не плавную, а уже довольно резкую деградацию риск-профиля.</p>
  <blockquote id="hbTc">Автор также показывает, что регулярное получение и использование накопленных вознаграждений снижает вероятность ликвидации позиции. </blockquote>
  <p id="6vsm">В полностью захеджированной стратегии получение вознаграждений каждые две недели уменьшает вероятность ликвидации примерно на 4 процентных пункта. Это объясняется тем, что полученные вознаграждения могут направляться на частичное погашение долга. В результате уменьшается отношение суммы долга к стоимости обеспечения, а показатель HF увеличивается, что снижает риск ликвидации. </p>
  <p id="KgfC">Такой вывод полностью соответствует механике лендинговых протоколов, таких как Aave и NAVI: частичное погашение задолженности повышает HF и делает позицию более устойчивой.</p>
  <p id="Egb7">Отдельный интерес представляет анализ чувствительности модели к изменению её основных параметров. </p>
  <p id="z2VD">Автор показывает, что увеличение доходности от вознаграждений приводит к росту оптимальной доли хеджирования. Напротив, повышение процентной ставки по займу одного из активов несколько снижает оптимальный объём хеджа, поскольку увеличивает стоимость поддержания позиции. </p>
  <p id="kzVp">При росте общей волатильности рынка оптимальная с точки зрения риска доля хеджирования смещается в диапазон около 50-60%, что позволяет сохранить более высокий показатель HF и снизить вероятность ликвидации. </p>
  <p id="eFcB">Наконец, увеличение коэффициента обеспечения позволяет использовать более высокий уровень хеджирования, однако одновременно снижает рентабельность собственного капитала, поскольку требует блокировки большего объёма средств в качестве залога. </p>
  <p id="fSAl">В результате автор приходит к важному практическому выводу: начальное отношение суммы долга к стоимости обеспечения (<strong>LTV</strong>) на уровне около 30% остаётся устойчивым ориентиром при самых разных рыночных условиях.</p>
  <p id="pURD">Автор также показывает, что при увеличении объёма обеспечения относительно стоимости LP-позиции оптимальная доля хеджирования возрастает. Однако даже в этом случае оптимальное начальное отношение суммы долга к стоимости обеспечения (LTV) остаётся в диапазоне около 20-33%. </p>
  <blockquote id="NRvf"><strong>Это позволяет сделать практический вывод</strong>: поддержание начального LTV на уровне примерно 30% является естественным и устойчивым ориентиром при построении подобных стратегий.</blockquote>
  <h2 id="CDgY">Наиболее значимые параметры</h2>
  <p id="vrvH">С практической точки зрения модель чувствительна не ко всему одинаково. Наиболее важны четыре параметра:</p>
  <ul id="Rfrq">
    <li id="XapA">R/Vо - reward APR: главный драйвер устойчивости (viability) - при низком APR стратегия может быть бессмысленна. </li>
    <li id="NWn6">C/Vо -  коллетерал - размер определяет буфер до ликвидации самый прямой рычаг управления риском. </li>
    <li id="bky3">borrow rates Ra, Rb - линейно режут ожидаемый результат (expectancy) особенно критичны для &quot;длинных&quot; (long-tail) токенов.</li>
    <li id="sWjj">volatility / correlation - меняют и выгоду от снижения дисперсии (variance benefit), и хвост распределения ликвидаций (liquidation tail). </li>
  </ul>
  <p id="ZD5X">В статье стратегия уже при APR около 10% становится экономически неинтересной, около 20% - едва жизнеспособной, а при 30%+ начинает работать устойчиво. Это означает, что документ скорее описывает режим incentivized DeFi LP, а не универсальную постоянную стратегию для любых зрелых пулов. </p>
  <h2 id="nw0w">Требования к данным и вычислительная сложность</h2>
  <p id="gqMV">Для аналитической части нужно немного данных: оценки волатильностей и корреляции и доп. параметры (напишу на англ., т.к. будет проще найти в документации: borrow/supply rates, reward APR, collateral ratio, liquidation threshold) и горизонт. </p>
  <p id="1o2K">В базовой калибровке документ оценивает параметры из 91 дня дневных доходностей CoinGecko и on-chain ставок;использует также 365-дневные окна для дополнительных пар. То есть минимальный снимок данных весьма умеренный. </p>
  <p id="vuyM">После оценки параметров h* и приближённая вероятность ликвидации (approximate liquidation probability) считаются в одну формулу. </p>
  <p id="F6kE">Отмечу, что в статье использует 30 000 траекторий с дневным шагом на 90 дней и перебирает несколько значений h по методу Монте-Карло: это соответствует миллионам LTV-checks. </p>
  <h2 id="GIoc">Сравнение с релевантной литературой</h2>
  <p id="Hgaw">Статья стоит на стыке трёх линий литературы: LP-risk/IL, LP-hedging и DeFi liquidation risk. При этом она не заменяет предыдущие работы, а заполняет пробел между ними.</p>
  <p id="oh5d">Ниже представляю ответ по глубинному исследованию от ChatGPT, кот. провёл по сложному промту, включающем различные аспекты из анализируемой статьи:</p>
  <figure id="LQzP" class="m_column">
    <img src="https://img1.teletype.in/files/08/d2/08d2ea11-4940-4099-89b3-bd363a9a80fd.png" width="916" />
    <figcaption>Данные для сравнения</figcaption>
  </figure>
  <p id="snCx">По сути, ближайший концептуальный родственник - работа Khakhar &amp; Chen, потому что там тоже стоит вопрос о дельта-хеджировании LP-позиций. Но у той постановки инструментом служат деривативы, а здесь - ончейн-займ, и именно из-за этого риск ликвидации становится центральной переменной. </p>
  <p id="CN2s">Поэтому текущая статья ближе к реальным DeFi-экосистемам.</p>
  <p id="KYZw">При этом документ корректно не смешивает хедж по цене с полной защитой LP. В терминах общеупотребимых: автор снижает часть рыночной экспозиции, но не отменяет неблагоприятный отбор, с которым сталкиваются арбитражёры (adverse selection against arbitrageurs). </p>
  <p id="WHGR">Если читать статью как<strong> решение проблемы LP</strong>, вывод будет слишком сильным; если читать как решение задачи частичного контроля ценового риска вкупе с риском ликвидации, то позиционирование будет куда более точное. </p>
  <h2 id="iPCk">Практические DeFi-сценарии</h2>
  <p id="5NG9">Самая важная часть! </p>
  <h3 id="6uc4">Первая стратегия </h3>
  <p id="gWqR">Наиболее очевидная область применения предложенного подхода - стратегии предоставления ликвидности в пулах, работающих по модели постоянного произведения, таких как Uniswap V2 и аналогичные автоматизированные маркет-мейкеры. </p>
  <p id="2hDK">Цель такой стратегии состоит в том, чтобы сохранить доход от комиссий и вознаграждений за предоставление ликвидности, одновременно уменьшив влияние колебаний рыночных цен на стоимость позиции. </p>
  <blockquote id="OAvY">Автор показывает, что для достижения этого не требуется полностью хеджировать ценовой риск. </blockquote>
  <p id="bboT">При стоимости обеспечения, примерно вдвое превышающей стоимость LP-позиции, и начальном отношении суммы долга к стоимости обеспечения (<strong>LTV</strong>) около 30% наиболее эффективным оказывается хеджирование примерно 60–65% ценовой экспозиции. Такой подход позволяет существенно снизить риск без заметного ухудшения общей доходности стратегии.</p>
  <p id="O4pf"><strong>Практическая значимость</strong>: это даёт LP-вольту простое правило размерности. Ограничение таково: модель, предложенная автором,  относится к &quot;full-range constant-product&quot; позиции; для концентрированной ликвидности поведение gamma/fee-flow другое, и перенос результата требует отдельной перекалибровки. </p>
  <h3 id="eAKO">Вторая стратегия</h3>
  <p id="4VXk">Второй сценарий относится к стратегиям, в которых короткая позиция формируется за счёт заимствования активов под избыточное обеспечение. </p>
  <p id="CZHv">В таких протоколах, как Aave и NAVI, безопасность позиции определяется показателем HF. Если значение HF опускается ниже единицы, позиция становится доступной для ликвидации. При этом ликвидаторы могут погасить часть задолженности и получить соответствующую часть залога с предусмотренной протоколом скидкой. </p>
  <p id="1H8A">Именно эта реальная механика работы лендинговых протоколов делает предложенную авторами модель практически применимой. Используемый в работе параметр <strong>штраф за ликвидацию </strong>представляет собой упрощённую оценку совокупных потерь, которые на практике складываются из скидки, предоставляемой ликвидатору, проскальзывания при продаже активов и рыночного воздействия крупных сделок.</p>
  <p id="ZxyW">С практической точки зрения предложенная модель может использоваться отделами управления рисками и автоматизированными торговыми системами для предварительной оценки максимально допустимого уровня хеджирования ещё до открытия позиции. </p>
  <p id="AqCJ">Вместе с тем следует учитывать, что принятое в статье значение совокупных потерь при ликвидации, равное 20%, не является фиксированным параметром какого-либо протокола. Это лишь допущение, принятое авторами для построения модели. Поэтому при использовании методики для конкретного лендингового протокола данный параметр необходимо определять заново с учётом его правил ликвидации, глубины ликвидности рынка и ожидаемых торговых издержек.</p>
  <h3 id="6l85">Третья стратегия</h3>
  <p id="9bln">Третий сценарий относится к стратегиям предоставления ликвидности, в которых значительная часть дохода формируется не только за счёт комиссий за обмен, но и за счёт вознаграждений, выплачиваемых протоколом. </p>
  <p id="hdAi">Автор показывает, что именно размер таких вознаграждений является одним из ключевых факторов, определяющих жизнеспособность стратегии. При низкой доходности от вознаграждений получаемого дохода зачастую недостаточно, чтобы компенсировать расходы на обслуживание займа и риск ликвидации. </p>
  <blockquote id="q4lF">По мере увеличения доходности стратегия становится всё более эффективной. </blockquote>
  <p id="VA4c">При доходности порядка <strong>30%</strong> годовых она уже может быть экономически оправданной, а при уровне около 50% и выше наиболее эффективным обычно оказывается хеджирование примерно 50–70% ценовой экспозиции. Подобные условия особенно характерны для молодых блокчейн-экосистем и новых протоколов, которые активно стимулируют поставщиков ликвидности за счёт дополнительной эмиссии собственных токенов.</p>
  <blockquote id="3Mvs">Практическая ценность работы заключается в том, что она позволяет определить ситуации, в которых построение дельта-нейтральной LP-стратегии изначально не имеет экономического смысла. </blockquote>
  <p id="78G8">Если ожидаемых вознаграждений недостаточно для покрытия стоимости заимствования и риска ликвидации, такая стратегия, вероятнее всего, окажется неэффективной. </p>
  <p id="C3ZF">Вместе с тем автор отмечает важное ограничение своей модели: в протоколах децентрализованных финансов высокая доходность от вознаграждений обычно сохраняется недолго. По мере роста объёма ликвидности и притока новых участников размер вознаграждения на единицу капитала постепенно уменьшается. Поэтому полученные выводы остаются справедливыми как метод оценки стратегии, однако не предполагают, что повышенная доходность будет сохраняться на протяжении длительного времени.</p>
  <h3 id="uf0h">Четвёртая стратегия </h3>
  <p id="ehdv">Хотя автор не рассматривает книгу лимитных ордеров как отдельный механизм формирования цены, выводы о пороговой ребалансировке легко применимы к выбору способа исполнения сделок. </p>
  <blockquote id="KGIG">Работа показывает, что достаточно корректировать хедж только тогда, когда его отклонение от целевого значения превышает примерно 15 процентных пунктов. </blockquote>
  <p id="rqjB">Такой подход позволяет получить почти весь эффект динамического хеджирования, значительно сократив количество операций. На практике это означает, что каждую очередную ребалансировку можно выполнять на той торговой площадке, где в данный момент ожидаются наименьшие торговые издержки, включая проскальзывание и комиссии. </p>
  <p id="eZ0U">Это может быть пул автоматического маркет-мейкера, агрегатор ликвидности или децентрализованная биржа с книгой лимитных ордеров. Такой подход полностью соответствует современной инфраструктуре децентрализованных финансов, где один и тот же хедж может исполняться через различные механизмы торговли в зависимости от их эффективности.</p>
  <p id="gkTy">Практическая ценность этого вывода заключается в том, что, хотя сама модель хеджирования в статье основана на использовании заимствования, выбор места исполнения сделок остаётся открытым и может быть оптимизирован. </p>
  <p id="G0um">Это позволяет дополнительно снизить торговые издержки без изменения логики самой стратегии. Вместе с тем необходимо отметить важное ограничение. Такой вывод представляет собой логическое развитие результатов статьи, а не её прямой вывод. </p>
  <p id="1jv2">Автор не проводил экспериментального сравнения различных способов исполнения сделок и не оценивали, какой из них обеспечивает лучшие результаты на практике. Следовательно, возможность выбора наиболее эффективной торговой инфраструктуры является обоснованной практической рекомендацией, но не подтверждена непосредственными расчётами, представленными в работе.</p>
  <h3 id="HDwA">Пятая стратегия </h3>
  <p id="oH2c">Ещё одной важной областью применения предложенной модели является управление казначейскими резервами децентрализованных организаций, которые одновременно поддерживают ликвидность собственного токена и стремятся снизить влияние высокой волатильности его цены. </p>
  <p id="Quyd">Автор показывает, что увеличение объёма обеспечения позволяет использовать более высокий уровень хеджирования. Однако одновременно уменьшается рентабельность собственного капитала, поскольку всё большая его часть оказывается заблокированной в низкодоходном обеспечении. </p>
  <p id="9kjB">Таким образом, задача сводится не только к управлению рыночным риском, но и к поиску оптимального распределения капитала.</p>
  <p id="Mx7n">Практическая ценность работы заключается в том, что она позволяет рассматривать уровень хеджирования и объём обеспечения как взаимосвязанные параметры, которые необходимо выбирать совместно при построении стратегии управления казначейскими резервами. </p>
  <p id="GPDA">Вместе с тем автор прямо указывает, что задача совместной оптимизации уровня хеджирования и объёма обеспечения не была полностью решена в данной работе и рассматривается как направление для дальнейших исследований. Поэтому предложенный подход следует рассматривать как основу для принятия решений, а не как завершённую систему управления.</p>
  <h2 id="34xO">Ограничения работы и итоговая оценка</h2>
  <p id="f36Q"><strong>Первое ограничение</strong>. Главное допущение (приведённой) аналитики - цены обоих токенов следуют &quot;correlated GBM&quot;, а в основном теоретическом разделе берётся нулевой дрейф. </p>
  <p id="8sW3">Это удобно и местами консервативно, но реальный DeFi живёт в мире постоянных изменений. Автор честно тестирует вводные и показывает, что оптимум хеджа почти не сдвигается при заданных условиях, но это ещё не проверка против тяжёлых шорт-сквиз событий, например, или внезапных оракульных расхождений или токен-специфических пампов/дампов.</p>
  <p id="sJPn"><strong>Второе ограничение </strong>- документ сознательно не моделирует концентрированную ликвидность. Для Uniswap v3/v4 это существенный пробел: диапазонная ликвидность усиливает и комиссионные сборы, но и гамма-риск, а потому оптимальный коэффициент хеджиования в такой среде не обязан совпадать с 60–65%. </p>
  <p id="mola">Литература по v3 показывает, что сама задача LP-управления намного сложнее и гораздо чувствительнее к активному менеджменту.</p>
  <p id="MQn1"><strong>Третьим ограничением</strong> модели является принятое допущение о совокупных потерях при ликвидации в размере 20%, а также предположение о низкой стоимости ребалансировки. </p>
  <p id="g3y6">В протоколах NAVI и Aave описаны механизмы предоставления скидки ликвидатору и ограничения на объём ликвидируемой задолженности, однако в своей модели автор дополнительно включает в совокупные потери проскальзывание и альтернативные издержки. </p>
  <p id="gL3w">На рынках с высокой ликвидностью такое допущение может оказаться излишне консервативным, тогда как на рынках с низкой ликвидностью, наоборот, может недооценивать реальные потери. </p>
  <p id="ppBM">Аналогичным образом вывод о практически бесплатной ребалансировке справедлив главным образом для блокчейн-сетей с низкой стоимостью транзакций. В сетях, где исполнение сделок обходится дорого, преимущества такой ребалансировки могут быть менее выраженными.</p>
  <blockquote id="RahP">По своему содержанию статья представляет собой сильную работу в области управления рисками. </blockquote>
  <p id="MFxZ">Она не рассматривает экономику предоставления ликвидности во всей её полноте, не устраняет потери, связанные с арбитражем, и не предлагает универсальную стратегию для всех автоматических маркет-мейкеров. </p>
  <p id="X3AS">Однако в рамках поставленной задачи - определения оптимального размера хеджа, построенного на основе заимствования, для поставщика ликвидности, находящегося под риском ликвидации, - работа выполнена на высоком уровне. </p>
  <p id="BFRT">Постановка задачи ясна, математическая модель изложена последовательно, использованное приближение проверено с помощью моделирования, а полученное практическое правило легко применять на практике. </p>
  <p id="CwxG">Наиболее важный вывод исследования можно сформулировать следующим образом:<strong> в децентрализованных финансах частичное хеджирование нередко оказывается эффективнее полного, поскольку риск ликвидации является не второстепенным, а определяющим ограничением стратегии</strong>.</p>
  <p id="FhoQ">Если мне поставили задачу кратко оценить работу, то можно сказать, что она решает одну конкретную задачу, но решает её качественно. Статья переводит обсуждение дельта-нейтральных стратегий предоставления ликвидности из области эмпирических рекомендаций и практического опыта в область формализованного анализа компромисса между снижением риска, доходом от использования заёмного капитала и риском достижения уровня ликвидации. </p>
  <p id="RgKi">Для разработчиков хранилищ ликвидности, специалистов по управлению рисками в децентрализованных финансах и исследователей составных инвестиционных стратегий эта работа представляет собой полезный и практически значимый вклад.</p>
  <h2 id="HRqn">Доп. ссылки</h2>
  <p id="1p6K">Список: </p>
  <ul id="Gpui">
    <li id="Ac1n"><a href="https://arxiv.org/abs/2603.19716" target="_blank">https://arxiv.org/abs/2603.19716</a> </li>
    <li id="O5P5"><a href="https://docs.uniswap.org/contracts/v2/concepts/protocol-overview/how-uniswap-works" target="_blank">https://docs.uniswap.org/contracts/v2/concepts/protocol-overview/how-uniswap-works</a></li>
    <li id="xj26"><a href="https://aave.com/help/borrowing/liquidations" target="_blank">https://aave.com/help/borrowing/liquidations</a></li>
    <li id="FKiu"><a href="https://arxiv.org/abs/2106.14404" target="_blank">https://arxiv.org/abs/2106.14404</a> </li>
    <li id="S2Kb"><a href="https://arxiv.org/abs/2208.06046" target="_blank">https://arxiv.org/abs/2208.06046</a> </li>
    <li id="Pzxk"><a href="https://arxiv.org/abs/1911.03380" target="_blank">https://arxiv.org/abs/1911.03380</a></li>
    <li id="uj6t"><a href="https://arxiv.org/abs/2208.03318" target="_blank">https://arxiv.org/abs/2208.03318</a></li>
    <li id="GxBZ"><a href="https://arxiv.org/abs/2407.05146" target="_blank">https://arxiv.org/abs/2407.05146</a> </li>
    <li id="93gM"><a href="https://arxiv.org/abs/2111.09192" target="_blank">https://arxiv.org/abs/2111.09192</a> </li>
    <li id="fIFU"><a href="https://docs.naviprotocol.io/technical/technical-docs/technical-reference/liquidation-mechanics-and-walkthrough" target="_blank">https://docs.naviprotocol.io/technical/technical-docs/technical-reference/liquidation-mechanics-and-walkthrough</a></li>
  </ul>
  <p id="PAaU"><em>До!</em></p>

]]></content:encoded></item><item><guid isPermaLink="true">https://teletype.in/@menaskop/defi-derivatives-25</guid><link>https://teletype.in/@menaskop/defi-derivatives-25?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop</link><comments>https://teletype.in/@menaskop/defi-derivatives-25?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop#comments</comments><dc:creator>menaskop</dc:creator><title>DeFi. Деривативы. Ончейн-опционы. Перевод</title><pubDate>Wed, 08 Jul 2026 12:27:35 GMT</pubDate><media:content medium="image" url="https://img4.teletype.in/files/75/48/754870ce-2f36-46ff-a7f4-bbf6cc2b25fc.png"></media:content><category>DeFi</category><description><![CDATA[<img src="https://img2.teletype.in/files/19/a0/19a0f024-c0c7-4022-9ec8-a8906986449f.png"></img>Это вольный перевод: https://research.castlelabs.io/p/the-rebirth-of-onchain-options-an.]]></description><content:encoded><![CDATA[
  <figure id="M3zD" class="m_column">
    <img src="https://img2.teletype.in/files/19/a0/19a0f024-c0c7-4022-9ec8-a8906986449f.png" width="1024" />
    <figcaption>Опционы</figcaption>
  </figure>
  <h1 id="Ibv1">Перевод</h1>
  <p id="Kxjp">Это вольный перевод: <a href="https://research.castlelabs.io/p/the-rebirth-of-onchain-options-an" target="_blank">https://research.castlelabs.io/p/the-rebirth-of-onchain-options-an</a>. </p>
  <h2 id="yvIJ">Возрождение ончейн-опционов: взгляд на экосистему</h2>
  <p id="grFZ">Эта статья представляет собой выдержку из нашего исследования &quot;Ренессанс ончейн-опционов&quot;, посвящённого стремительному развитию опционов (и рынков предсказаний) как торгового инструмента, а также волатильности, лежащей в основе их ценообразования. Исследование подготовлено совместно с Block Scholes.</p>
  <p id="XRDg">Скачайте полную версию отчёта <a href="https://docsend.com/view/ic97x7dpnu42n9wg" target="_blank">здесь</a>.</p>
  <h1 id="0vhm">Опционы на финансовых рынках</h1>
  <blockquote id="Gm8L">Большинство людей даже не подозревают, что фактически пользуются опционами всю свою жизнь.</blockquote>
  <p id="bVWJ">Если вы когда-либо покупали страховой полис, то платили премию за право получить выплату при наступлении определённого события в будущем. По своей экономической сути это аналог пут-опциона, поскольку вы защищены от снижения стоимости застрахованного имущества.</p>
  <p id="qvOS">Если же вы оформляли ипотеку, то, как правило, получали право досрочно её рефинансировать. Это аналог колл-опциона, поскольку именно вы обладаете исключительным правом (но не обязанностью) <strong>отозвать</strong> или <strong>заменить</strong> действующий долговой контракт на более выгодный.</p>
  <p id="feaw">Сегодня объём торговли опционами значительно превосходит объём торговли фьючерсами на мировых биржевых рынках деривативов. В 2024 году количество заключённых опционных контрактов превысило объём фьючерсных более чем в четыре раза. А в 2025 году опционы, торгуемые на биржах США, шестой год подряд обновили исторический рекорд: было заключено около 15,2 млрд контрактов, что эквивалентно примерно 36 млрд долларов США ежедневно выплачиваемых опционных премий.</p>
  <figure id="Qvbx" class="m_column" data-caption-align="center">
    <img src="https://img2.teletype.in/files/16/1d/161dda54-5e18-4aaa-92eb-f6cc55637b68.png" width="2048" />
    <figcaption>Опционный рынок vs. спотовый: Рисунок 1 (CL). Состояние индустрии опционов</figcaption>
  </figure>
  <p id="63DM">Объём торгов опционами с экспирацией в день заключения сделки (Zero-Day-to-Expiry, <strong>0DTE</strong>) на индекс SPX в пиковые моменты превышал 1 трлн долларов номинальной стоимости в день. В среднем ежедневно торговалось около 2,3 млн контрактов, что составляло 59% общего объёма торгов данным инструментом в 2025 году.</p>
  <p id="ox01">Опционы 0DTE истекают в тот же день, когда были куплены или проданы. Их используют для получения высокой прибыли на краткосрочных внутридневных движениях рынка, однако они сопряжены с крайне высоким риском: инвестор может потерять 100% вложенных средств буквально за несколько часов.</p>
  <p id="Tm3B">В 2024 году Национальная фондовая биржа Индии (NSE) обеспечила около 84% всех мировых контрактов на опционы на акции. </p>
  <p id="jmBL">Однако в денежном выражении суммарные премии, уплаченные покупателями опционов в США, всё равно были примерно в четыре раза выше, чем в Индии. Это говорит о том, что индийские розничные инвесторы совершают огромное количество сделок небольшого размера, тогда как участники американского рынка торгуют значительно меньшим числом контрактов, но гораздо большего номинала и стоимости.</p>
  <blockquote id="WNJJ">Популярность опционов постепенно распространяется и на криптовалютный рынок, хотя пока главным образом со стороны институциональных участников.</blockquote>
  <p id="lLwN">CME, крупнейшая регулируемая биржа деривативов в США, уже предлагает круглосуточную (24/7) торговлю криптовалютными опционами. Это беспрецедентный шаг для традиционной биржи, стремящейся сохранить свою клиентскую базу и признающей привлекательность крипторынков, которые работают без перерывов.</p>
  <p id="VKqI">Кроме того, в апреле открытый интерес по опционам на IBIT от BlackRock, запущенным чуть более двух лет назад, превысил открытый интерес по BTC-опционам на Deribit: показатель вырос с 26,9 млрд до 27,6 млрд долларов, несмотря на то что Deribit существует уже более десяти лет.</p>
  <h2 id="NmGw">Опционы - чрезвычайно гибкий финансовый инструмент, который применяется во множестве сценариев:</h2>
  <h3 id="GGhS"><strong>Хеджирование</strong></h3>
  <p id="XQ25">Использование опционов в качестве страхования ценового риска. Например, покупка пут-опциона позволяет зафиксировать минимальную цену продажи актива и защититься от падения рынка, а покупка колл-опциона - избежать риска упустить резкий рост цены.</p>
  <h3 id="0G1C"><strong>Получение дохода</strong></h3>
  <p id="eAtd">Продажа опционов для регулярного получения премий. Такая стратегия особенно подходит инвесторам без выраженного рыночного прогноза: можно получать пассивный доход на уже имеющихся активах (Covered Call) либо получать премию заранее, ожидая возможности купить актив дешевле (Cash-Secured Put).</p>
  <h3 id="9KQu"><strong>Спекуляции</strong></h3>
  <p id="R2a4">Выражение взгляда на направление движения цены или ожидаемую волатильность без необходимости покупать сам базовый актив. Это может реализовываться с помощью самых разных опционных стратегий.</p>
  <h3 id="Cdbv"><strong>Индивидуальные структурные решения</strong></h3>
  <p id="uDJD">Комбинирование нескольких опционов в единый структурный продукт. Подобные конструкции широко используются банками и управляющими активами для создания инвестиционных продуктов с повышенной доходностью или встроенной защитой капитала.</p>
  <p id="NBCH">Спектр пользователей опционов чрезвычайно широк. Среди них - институциональные маркет-мейкеры, хеджирующие свои риски; банки, создающие структурные продукты; фонды, специализирующиеся на торговле волатильностью; а также частные инвесторы, спекулирующие на недорогих опционах 0DTE с экспирацией в тот же день.</p>
  <h2 id="z6F5">Первые попытки создания ончейн-опционов</h2>
  <p id="0FDv">Учитывая огромную роль опционов на традиционных финансовых рынках, ожидалось, что они станут одним из наиболее востребованных инструментов и на волатильном криптовалютном рынке. </p>
  <blockquote id="6Vy5">Однако на практике опционы оказались одной из самых неоднозначных и неоднократно терпевших неудачу категорий продуктов в DeFi.</blockquote>
  <p id="9Wn1">При этом проблема заключалась вовсе не в отсутствии экспериментов. Напротив, в предыдущих рыночных циклах было запущено множество различных проектов:</p>
  <ul id="tFL1">
    <li id="hHwg"><strong>Opyn (2019)</strong> токенизировал классические (vanilla) опционы на Ethereum. Однако развитию протокола помешали низкая ликвидность, высокие требования к обеспечению и дорогие комиссии сети Ethereum.</li>
    <li id="m5hU"><strong>Hegic (2020)</strong> предложил модель peer-to-pool, упростив процесс покупки опционов для пользователей. Но поставщики ликвидности (LP) брали на себя риск, который было крайне сложно эффективно хеджировать.</li>
    <li id="muRI"><strong>Ribbon, Friktion и Dopex (2021)</strong> запустили опционные хранилища (vaults), создав простые структурные продукты по принципу &quot;внеси средства и получай доход&quot;. Они были ориентированы на пользователей, не желающих самостоятельно управлять позициями. Однако стратегия фактически сводилась к продаже волатильности на рынке с ограниченным и цикличным спросом. По мере роста конкуренции премии снижались, и в какой-то момент перестали компенсировать принимаемый риск.</li>
    <li id="auJW"><strong>Lyra, Premia, Pods и Siren</strong> экспериментировали с автоматизированными маркет-мейкерами (AMM) для опционов, стремясь обеспечить непрерывную ликвидность для различных страйков и сроков экспирации. Однако проекты столкнулись с серьёзными трудностями в области ценообразования и хеджирования. В результате LP принимали на себя сложные риски волатильности и управления запасами (inventory risk), тогда как естественный поток пользователей оставался слишком небольшим.</li>
    <li id="p2WX"><strong>В 2022 году Opyn представил Squeet</strong>h - бессрочный производный инструмент, отслеживающий квадратичную зависимость доходности от цены ETH (ETH²). Это позволяло инвесторам получать выпуклый (convex) профиль доходности без необходимости работать с опционами фиксированного срока действия. Однако продукт был запущен в сети Ethereum в период чрезвычайно высоких комиссий, отличался сложной для понимания механикой и становился дорогостоящим в удержании при высоких ставках финансирования (funding).</li>
  </ul>
  <figure id="6ipF" class="m_column" data-caption-align="center">
    <img src="https://img4.teletype.in/files/bb/fc/bbfc5479-e12e-4bf0-a89e-354356cf60fc.png" width="2048" />
    <figcaption>Рисунок 2 (CL). TVL опционных хранилищ (Vaults) - DefiLlama</figcaption>
  </figure>
  <p id="h9Gc">Развитие сектора долгое время сдерживалось главным образом структурными ограничениями.</p>
  <p id="Nnwc">Недостаточное участие профессиональных маркет-мейкеров приводило к низкой двусторонней ликвидности торговых площадок, а значительная часть труднохеджируемых рисков перекладывалась на пассивных поставщиков ликвидности (LP).</p>
  <p id="yuAG">Низкая эффективность использования капитала сочеталась с несовершенными моделями оценки волатильности (volatility surfaces), тогда как пользовательский опыт оказался «между двух миров»: продукты были слишком сложными для розничных инвесторов, но при этом не обладали той профессиональной инфраструктурой, которая необходима институциональным участникам.</p>
  <h2 id="fFHV">Новая инфраструктура и эволюция рынка</h2>
  <p id="ueAG">После первых попыток ситуация начала постепенно меняться.</p>
  <ul id="cVGm">
    <li id="Wx41"><strong>Rollups</strong> и масштабирование Ethereum значительно снизили комиссии (gas fees), сделав сложные ончейн-операции экономически оправданными и одновременно повысив качество исполнения сделок и расчётов.</li>
    <li id="Qrd2"><strong>Книги лимитных заявок (CLOB)</strong> и <strong>системы запроса котировок (RFQ)</strong> начали постепенно вытеснять AMM-модели. Это создало более естественную среду для профессиональных трейдеров и маркет-мейкеров, которые получили возможность выставлять котировки для конкретных страйков и сроков экспирации, обновлять цены в режиме реального времени и гораздо эффективнее управлять своими рисками.</li>
    <li id="bFcW"><strong>Появились</strong> <strong>более простые продукты</strong>, ориентированные на узкие категории пользователей. Вместо универсальных платформ протоколы стали разрабатывать специализированные решения под конкретные сценарии использования.</li>
    <li id="yA2L"><strong>Рынки предсказаний (Prediction Markets)</strong> сделали выплаты, напоминающие опционы, доступными для массовой аудитории. Благодаря бинарным исходам пользователи постепенно привыкли к торговле инструментами с условными выплатами (conditional payoff).</li>
    <li id="bq76"><strong>Институциональный спрос</strong> на криптовалютные опционы продолжает устойчиво расти. Первоначально этот рост обеспечивал главным образом <strong>Deribit</strong>, а в последнее время к нему присоединились <strong>IBIT</strong> и <strong>CME</strong>, что свидетельствует о возрастающем интересе крупных участников рынка к данному классу активов.</li>
  </ul>
  <figure id="Ywb4" class="m_column" data-caption-align="center">
    <img src="https://img1.teletype.in/files/48/05/48059d96-f7ab-483b-9481-8874ba4d5991.png" width="2048" />
    <figcaption>Рисунок 3 (CL). BTC-опционы: Deribit vs IBIT vs CME</figcaption>
  </figure>
  <p id="hH1N">Условия для развития опционов значительно улучшились и непосредственно в ончейн-среде. Здесь начинают формироваться более зрелые и ликвидные рынки опционов.</p>
  <p id="4stY">За последние 30 дней номинальный объём торгов (30d notional volume) достиг примерно 1,44 млрд долларов США, а объём уплаченных опционных премий в текущем году обновил исторический максимум (All-Time High).</p>
  <figure id="rPZs" class="m_column" data-caption-align="center">
    <img src="https://img3.teletype.in/files/e2/a4/e2a407d6-8390-4ccb-8c02-b3c37a11d7f2.png" width="2048" />
    <figcaption>Рисунок 4 (CL). Объём опционных премий</figcaption>
  </figure>
  <p id="GlxE">Современный рынок опционов в DeFi выглядит совершенно иначе, чем во время первого цикла развития ончейн-опционов.</p>
  <p id="WkwM">Протоколы больше не пытаются просто создать &quot;Deribit в ончейне&quot;. Вместо этого формируется полноценная экосистема, охватывающая широкий спектр участников и продуктов: от институциональных торговых площадок и ETF-обёрток (wrappers) до классических ончейн-опционов (vanilla), новых экзотических производных инструментов и бинарных опционов, реализованных через рынки предсказаний.</p>
  <p id="0vmI">В следующих разделах подробнее рассмотрим современный рынок криптовалютных опционов, уделив особое внимание тому, что происходит именно в ончейн-сегменте.</p>
  <h2 id="KGFa">Экосистема криптовалютных опционов</h2>
  <p id="t8TW">Современный рынок криптовалютных опционов представляет собой совокупность взаимосвязанных сегментов, отличающихся механизмами расчётов и структурой выплат.</p>
  <p id="1xzI">На приведённой ниже схеме экосистема классифицируется по двум ключевым параметрам:</p>
  <ul id="vVIJ">
    <li id="rQJ0"><strong>Способ расчётов (Settlement):</strong> от полностью ончейн-решений до офчейн-платформ.</li>
    <li id="CTok"><strong>Тип выплат (Payoff):</strong> от классических (vanilla) опционов до экзотических (exotic) производных инструментов.</li>
  </ul>
  <figure id="D2r9" class="m_column" data-caption-align="center">
    <img src="https://img3.teletype.in/files/25/9c/259c7b72-89d3-4169-b78e-e41d2dc33cec.jpeg" width="2048" />
    <figcaption>Рисунок 5 (CL). Сравнение экосистемы опционов</figcaption>
  </figure>
  <p id="Iife">Офчейн-рынок классических (vanilla) опционов по-прежнему остаётся безусловным лидером. Его основными участниками являются Deribit, IBIT и CME, а также централизованные криптобиржи (CEX), такие как Binance и OKX.</p>
  <p id="cNvz">В то же время ончейн-площадки для vanilla-опционов постепенно заново формируют ликвидность, опираясь на централизованные книги заявок (<strong>CLOB</strong>), системы запроса котировок (<strong>RFQ</strong>) и более простые продукты, ориентированные на конкретные категории пользователей, при этом расчёты по сделкам происходят непосредственно в блокчейне.</p>
  <p id="z4Yt">Более экспериментальные решения относятся к категории ончейн-экзотических опционов (<strong>Onchain</strong> <strong>Exotics</strong>). Здесь опционы или структуры с опционоподобными выплатами используются как строительные блоки для создания новых финансовых инструментов, а не ограничиваются традиционными колл- и пут-опционами либо стандартными спредами.</p>
  <p id="7LC8">К таким продуктам относятся...</p>
  <h3 id="Du7X">Бессрочные опционы (Perpetual Options)</h3>
  <p id="N8zM">Вместо фиксированной даты экспирации используется механизм непрерывной выплаты премии (<strong>streaming</strong> <strong>premium</strong>). Благодаря этому трейдеры могут удерживать позиции на волатильность неограниченно долго, избегая необходимости регулярно переносить (roll over) контракты и оплачивать связанные с этим комиссии сети.</p>
  <h3 id="42qU">AMM-native опционы</h3>
  <p id="KJRW">Подобные решения формируют опционоподобную доходность непосредственно из позиций поставщиков ликвидности в <strong>AMM</strong>, а не из классических листингов колл- и пут-опционов.</p>
  <p id="W8R5">Это позволяет опытным доходным фермерам (yield farmers) хеджировать риск непостоянных потерь (<strong>Impermanent Loss</strong>), а спекулянтам - покупать коллы и путы на новые или ещё не прошедшие листинг токены с низкой капитализацией (long-tail assets).</p>
  <h3 id="RGip">Краткосрочные Touch-опционы (Short-Dated Touch Options)</h3>
  <p id="JuWI">Эти инструменты выплачивают заранее определённую фиксированную сумму в тот момент, когда цена актива достигает или пересекает заранее заданный уровень.</p>
  <p id="4tSv">Подобная структура особенно популярна среди розничных дейтрейдеров, скальперов и трейдеров, работающих на новостях, которым важны быстрые результаты во время краткосрочных всплесков внутридневной волатильности.</p>
  <h3 id="tlYs">Офчейн-экзотические опционы (Offchain Exotics)</h3>
  <p id="5pOa">Четвёртый сектор экосистемы значительно менее прозрачен. Здесь доминируют <strong>OTC-дески</strong>, профессиональные маркет-мейкеры и поставщики структурных продуктов, а не публичные торговые площадки с открытым рынком.</p>
  <p id="kE4G">В данном исследовании основное внимание уделяется ончейн-сегменту рынка. Рассматриваются как площадки для торговли классическими (vanilla) опционами, так и экзотические ончейн-инструменты, после чего анализ переходит к бинарным опционоподобным рынкам, которые сегодня чаще всего реализуются через рынки предсказаний (Prediction Markets).</p>
  <h1 id="mC7B">Ончейн-площадки для торговли классическими опционами (Vanilla Options)</h1>
  <p id="d6e1">В последние годы рынок ончейн-опционов заметно продвинулся вперёд. При этом изменения произошли не столько в самих механиках выплат (<strong>payoff</strong>), сколько в окружающей инфраструктуре, архитектуре продуктов и пользовательском опыте.</p>
  <p id="aSZY">Большинство современных площадок постепенно отказались от модели пассивных пулов ликвидности (<strong>LP</strong>) в пользу централизованных книг заявок (<strong>CLOB</strong>) и систем запроса котировок (<strong>RFQ</strong>). </p>
  <p id="4XIH">Это позволило внедрить такие возможности, как портфельная маржа (portfolio margin), использование доходного обеспечения (yield-bearing collateral), а также создание специализированных продуктов для получения доходности с более понятными для пользователей сценариями.</p>
  <p id="DSkq">Ниже рассмотрены наиболее значимые площадки в их современном виде.</p>
  <h3 id="gy6S">Derive</h3>
  <p id="QSBM">Derive - один из наиболее наглядных примеров такой архитектурной эволюции.</p>
  <p id="6Gsh">Протокол вырос из Lyra, которая изначально представляла собой AMM для торговли опционами, и со временем превратился в современную площадку с централизованной книгой заявок (CLOB).</p>
  <p id="8DXt">Сегодня Derive работает на собственной сети <strong>OP Stack Layer 2</strong>, предоставляя пользователям торговлю кросс-маржинальными опционами и бессрочными контрактами (Perpetuals) через профессиональный интерфейс книги ордеров.</p>
  <p id="fmkS">В отличие от многих других проектов, Derive не пытается скрыть сложность опционной торговли. Поэтому платформа ориентирована прежде всего на:</p>
  <ul id="6stk">
    <li id="SLpc">профессиональных трейдеров;</li>
    <li id="oLPO">маркет-мейкеров;</li>
    <li id="cSkG">институциональных участников;</li>
    <li id="UQ8x">специалистов по торговле волатильностью.</li>
  </ul>
  <p id="KrSV">По своему устройству Derive очень напоминает классическую биржу опционов: пользователям доступны многочисленные базовые активы, различные страйки и даты экспирации, которые можно комбинировать, создавая практически любые структуры выплат (payoff).</p>
  <p id="8MXm">Использование внецепочечного (off-chain) движка сопоставления заявок обеспечивает практически мгновенное исполнение сделок, тогда как окончательные расчёты происходят в Layer 2. Благодаря этому институциональные инвесторы получают скорость работы централизованных бирж вроде Deribit, одновременно сохраняя полный некостодиальный контроль над своими активами.</p>
  <p id="0kFh">Кроме торговой площадки, Derive предлагает линейку Vault-продуктов. В отличие от предыдущего поколения опционных хранилищ, они используют саму биржу для автоматического исполнения заранее определённых опционных стратегий с целью получения доходности на размещённый капитал.</p>
  <p id="Cqrm">На сегодняшний день Derive занимает лидирующие позиции среди всех ончейн-опционных платформ:</p>
  <ul id="VCqR">
    <li id="nFdl">30-дневный номинальный объём торгов (Notional Volume): 1,142 млрд долларов;</li>
    <li id="eW2N">30-дневный объём опционных премий: 44,3 млн долларов.</li>
  </ul>
  <p id="xXUu">Это соответствует:</p>
  <ul id="M1K2">
    <li id="E23O">79,2% всего номинального объёма торгов в сегменте ончейн-опционов;</li>
    <li id="V056">87,2% совокупного объёма уплаченных премий.</li>
  </ul>
  <p id="pfMZ">Однако авторы отмечают важную оговорку: столь высокая ликвидность частично поддерживается программами стимулирования. Derive использует вознаграждения маркет-мейкерам, стимулы Optimism (OP), награды в токенах DRV и различные программы ребейтов (rebates) для привлечения участников рынка и поддержания активности.</p>
  <figure id="Fh8p" class="m_column" data-caption-align="center">
    <img src="https://img1.teletype.in/files/05/2a/052a995e-dd16-458d-ba43-d19c3063fda4.png" width="2048" />
    <figcaption>Рисунок 6 (CL). Объём опционных премий Derive</figcaption>
  </figure>
  <p id="5a3u">Несмотря на активное стимулирование ликвидности и участие пользователей через различные программы вознаграждений, Derive хорошо демонстрирует, насколько сильно эволюционировала индустрия. Сегодня полноценные опционные биржи уже работают на высокопроизводительных специализированных блокчейнах (<strong>appchains</strong>), предоставляя инфраструктуру, способную удовлетворить требования как институциональных инвесторов, так и профессиональных маркет-мейкеров.</p>
  <h3 id="Ixs8">Rysk</h3>
  <p id="0feL">Rysk придерживается принципиально иной концепции по сравнению с Derive.</p>
  <p id="RwUM">Основой протокола являются стратегии Covered Call и Cash-Secured Put. Здесь опционы используются прежде всего как инструмент получения регулярного дохода, при этом пользователи самостоятельно выбирают страйки и даты экспирации - в отличие от классических опционных Vault-продуктов предыдущего поколения, где параметры стратегии были заранее фиксированы.</p>
  <p id="eJHy">Все пользовательские заявки направляются через систему RFQ (Request for Quote). Маркет-мейкеры получают конкретные запросы, выставляют по ним котировки, покупают поток опционных сделок и затем самостоятельно управляют возникающими рисками на других площадках.</p>
  <p id="vs0u">Главная цель Rysk - максимально скрыть сложность опционной торговли за простым пользовательским интерфейсом. Благодаря этому платформа становится привлекательной как для частных инвесторов, так и для институциональных клиентов. </p>
  <p id="5YAE">Этому способствуют:</p>
  <ul id="PKv5">
    <li id="GUvJ">качественный выбор базовых активов;</li>
    <li id="hpxR">понятные сценарии результата;</li>
    <li id="fSH6">максимально простой пользовательский опыт.</li>
  </ul>
  <p id="0a8m"><strong>Как выглядит продукт для пользователя?</strong></p>
  <p id="HMNq">Концепция максимально проста:</p>
  <blockquote id="GSpz">Получайте доходность на своих активах, одновременно заранее определяя цену, по которой вы готовы их купить или продать.</blockquote>
  <p id="wIl2">Эта модель подходит самым разным категориям участников рынка.</p>
  <p id="rP3Z">Все они стремятся получать дополнительную доходность, однако используют разные стратегии.</p>
  <ul id="yDU1">
    <li id="Pguy"><strong>Казначейства (Treasuries), DAO и инвестиционные фонды</strong> обычно являются долгосрочными держателями активов. Они заранее понимают, по каким ценам готовы покупать или продавать активы. Даже если исполнять сделки они не планируют, можно продавать опционы с более удалёнными страйками и получать дополнительную премию.</li>
    <li id="Uwvg"><strong>Институциональные инвестор</strong>ы используют инфраструктуру Rysk иначе. Например, компания Hyperion - казначейская компания, управляющая резервами токена HYPE и торгующаяся на Nasdaq, - строит собственные Vault-стратегии поверх инфраструктуры Rysk. Поскольку её задача заключается в постепенном накоплении HYPE, стратегия Cash-Secured Put оказывается практически идеальной: компания получает премию за продажу пут-опционов, одновременно размещая заявки на покупку актива по более низким ценам.</li>
  </ul>
  <p id="9hxa"><strong>(Каковы) текущие показатели Rysk?</strong></p>
  <p id="hKKP">За последние 30 дней платформа достигла следующих результатов:</p>
  <ul id="n3Pq">
    <li id="ISlA">Номинальный объём торгов (Notional Volume): 136,3 млн долларов;</li>
    <li id="nBCw">Объём полученных опционных премий: 1,94 млн долларов.</li>
  </ul>
  <p id="eZym">Это составляет примерно 9,5% всего рынка ончейн-опционов по номинальному объёму.</p>
  <p id="Q12l">При этом динамика роста выглядит весьма показательно:</p>
  <ul id="l4uU">
    <li id="BTyJ">январь - около 50 млн долларов номинального объёма;</li>
    <li id="4P6F">март - более 175 млн долларов;</li>
    <li id="OqLs">апрель - более 175 млн долларов;</li>
    <li id="nimw">май - около 182 млн долларов.</li>
  </ul>
  <p id="K3Oh">Таким образом, Rysk демонстрирует устойчивый рост активности и постепенно занимает всё более заметное место среди современных ончейн-платформ для торговли опционами.</p>
  <figure id="t9Gk" class="m_column" data-caption-align="center">
    <img src="https://img1.teletype.in/files/43/3e/433e2d83-e43e-4760-b41b-045cd1055db4.png" width="2048" />
    <figcaption>Рисунок 7 (CL). Объём опционных премий Rysk Finance</figcaption>
  </figure>
  <p id="lKEu">В отличие от Derive, для Rysk показатель TVL (Total Value Locked) имеет значительно большее значение, поскольку вся модель протокола построена вокруг стратегий продажи полностью обеспеченных опционов.</p>
  <p id="Bv6f">Чтобы получать опционную премию в Rysk, пользователь должен заранее внести полное обеспечение (collateral) под продаваемый опцион. Иными словами, капитал блокируется целиком, а доход формируется за счёт полученной премии.</p>
  <p id="OG3u">В Derive ситуация принципиально иная. Пользователи могут покупать опционы, уплачивая лишь относительно небольшую премию, чтобы получить потенциально значительно более высокую выплату при благоприятном движении рынка.</p>
  <p id="2FNo">Именно поэтому для Derive показатель TVL менее информативен: платформа в основном обслуживает торговлю опционами, тогда как для Rysk объём заблокированного капитала напрямую отражает масштаб стратегий по продаже обеспеченных опционов и, соответственно, активность пользователей.</p>
  <figure id="6KVT" class="m_column" data-caption-align="center">
    <img src="https://img2.teletype.in/files/9a/6f/9a6fe54c-884f-42b3-bb83-7a305813629c.png" width="2048" />
    <figcaption>Рисунок 8 (CL). TVL Rysk V12 по классам активов (среднее за неделю)</figcaption>
  </figure>
  <p id="nhz9">Rysk удалось найти собственный Product-Market Fit (<strong>PMF</strong>) для рынка опционов, переосмыслив их не как инструмент активной торговли, а как источник регулярного дохода за счёт продажи волатильности.</p>
  <p id="zOVj">На фоне общего снижения доходностей (yield compression) в индустрии подобный подход оказался весьма конкурентоспособным по сравнению с традиционными инструментами DeFi - кредитованием (lending), стейкингом и стратегиями извлечения базиса (basis trading). Это подтверждается устойчивым и продолжительным ростом протокола с момента его запуска.</p>
  <h3 id="QfAK">Aevo</h3>
  <p id="Uj0i">Подобно Derive, платформа Aevo эволюционировала от первоначального опционного продукта к полноценной бирже с книгой заявок.</p>
  <p id="N3Pc">Aevo выросла из Ribbon Finance - одного из первых крупных протоколов DeFi Options Vault (DOV), — после чего постепенно превратилась в универсальную площадку для торговли деривативами.</p>
  <p id="4XNa">Сегодня Aevo объединяет в единой инфраструктуре:</p>
  <ul id="rKsM">
    <li id="5MvJ">классические опционы;</li>
    <li id="DG05">бессрочные контракты (Perpetuals);</li>
    <li id="BpM2">рынки токенов до листинга (Pre-Launch Markets);</li>
    <li id="ntKq">OTC-сделки;</li>
    <li id="20Te">автоматизированные торговые стратегии.</li>
  </ul>
  <p id="1XMB">Платформа работает на собственной сети Layer 2, построенной на OP Stack.</p>
  <p id="Cylq">Архитектура аналогична Derive:</p>
  <ul id="xrwb">
    <li id="oJZp">сопоставление заявок происходит вне блокчейна (off-chain);</li>
    <li id="yoTl">окончательные расчёты выполняются ончейн.</li>
  </ul>
  <p id="1dkR">Заявки сопоставляются через оффчейн-книгу лимитных заявок (<strong>Central Limit Order Book, CLOB</strong>) всего за несколько микросекунд, обеспечивая пользовательский опыт, сопоставимый с централизованными биржами (CEX). При этом средства пользователей продолжают храниться в некостодиальных смарт-контрактах собственной сети Ethereum Layer 2.</p>
  <p id="LI6h">Развитие платформы.  Aevo была запущена в 2023 году, а пик активности на рынке опционов пришёлся на 2024 год.</p>
  <p id="9o8O">Впоследствии показатели TVL и видимая торговая активность снизились по сравнению с максимальными значениями, хотя в последнее время объём собираемых опционных премий вновь начал постепенно расти.</p>
  <p id="vKhU">Главное конкурентное преимущество. Основная особенность Aevo заключается в том, что множество различных продуктов объединены в рамках единого маржинального счёта (<strong>Unified Margin Account</strong>). </p>
  <p id="CK4q">В частности, пользователям доступны Pre-Launch Markets - рынки токенов до их официального выхода на спотовые биржи. Это позволяет открывать высоколевериджные позиции как в опционах, так и в бессрочных контрактах на популярные, но ещё не выпущенные токены.</p>
  <p id="mkh5">Основные показатели. За последние 30 дней Aevo показала следующие результаты:</p>
  <ul id="6Tgw">
    <li id="I23v">Номинальный объём торгов (Notional Volume): 45,1 млн долларов;</li>
    <li id="0J3j">Объём опционных премий: 2,52 млн долларов.</li>
  </ul>
  <p id="WI4o">Это соответствует примерно 3,1% всего рынка ончейн-опционов по номинальному объёму.</p>
  <p id="QHza">Динамика роста выглядела следующим образом:</p>
  <ul id="U4HV">
    <li id="KMcF">январь - около 20 млн долларов;</li>
    <li id="EMTC">май - около 50 млн долларов.</li>
  </ul>
  <p id="uKR1">Однако текущий открытый интерес (<strong>Open Interest</strong>) по опционам составляет лишь около 3,6 млн долларов, что значительно ниже аналогичных показателей Derive и также уступает расчётной оценке открытого номинала (open-notional proxy) у Rysk.</p>
  <figure id="Hg7G" class="m_column" data-caption-align="center">
    <img src="https://img4.teletype.in/files/74/58/74585a02-ba6e-4bcd-9712-e90074cc7988.png" width="2048" />
    <figcaption>Рисунок 9 (CL). Объём опционных премий Aevo - DefiLlama</figcaption>
  </figure>
  <p id="dAHN">Вероятно, часть текущей активности на Aevo поддерживается системой стимулов.</p>
  <p id="4XqJ">Платформа еженедельно распределяет 1 млн токенов AEVO в рамках программы вознаграждений за торговлю, причём 30% этого объёма предназначено именно для участников рынка опционов. Именно этим, по всей видимости, можно частично объяснить недавний рост объёма торгов опционами.</p>
  <p id="ySfN">Несмотря на то что команда <strong>Ribbon</strong> была одним из первых коллективов в DeFi, сосредоточенных на развитии опционных Vault-продуктов, <strong>после</strong> <strong>трансформации</strong> проекта в <strong>Aevo</strong> основной акцент постепенно сместился на универсальную платформу для торговли деривативами.</p>
  <p id="IMAq">Сегодня гораздо больше внимания уделяется:</p>
  <ul id="VjzN">
    <li id="CsNa">бессрочным контрактам (Perpetuals);</li>
    <li id="zjKI">рынкам токенов до листинга (Pre-Launch Markets);</li>
    <li id="2p4M">торговым соревнованиям и стимулирующим кампаниям.</li>
  </ul>
  <p id="X2oh">В результате опционы постепенно превратились скорее во второстепенный продукт, а не в основное направление развития платформы.</p>
  <p id="sp7u">Хотя команда явно пытается вернуть интерес к этому сегменту посредством различных программ стимулирования, пока остаётся открытым вопрос, смогут ли подобные меры действительно возродить рынок опционов внутри экосистемы Aevo.</p>
  <h3 id="NdUR">Другие проекты</h3>
  <p id="ZVzZ">Помимо Derive, Rysk и Aevo, остальная часть рынка значительно меньше по масштабу и весьма фрагментирована.</p>
  <h3 id="vsyH">Paradex</h3>
  <p id="LGiC">Paradex - ещё одна универсальная площадка для торговли деривативами, созданная командой Paradigm.co, специализирующейся на институциональной ликвидности для криптовалютных производных инструментов.</p>
  <p id="IEpX">В настоящее время платформа предлагает:</p>
  <ul id="EsX9">
    <li id="d9dl">бессрочные контракты (Perpetuals);</li>
    <li id="79I4">опционы;</li>
    <li id="mGOt">различные Vault Traded Funds (VTF).</li>
  </ul>
  <p id="wbGK">Ранее Paradex поддерживал бессрочные опционы (Perpetual Options), однако недавно отказался от этого направления, сосредоточившись на классических опционах с фиксированной датой экспирации, торговля которыми была запущена в апреле текущего года.</p>
  <p id="2mQk">Для привлечения пользователей и увеличения своей доли рынка Paradex вновь ввёл нулевые комиссии как для мейкеров, так и для тейкеров при торговле спотом, бессрочными контрактами и опционами.</p>
  <h3 id="LJ5K">Hypersurface</h3>
  <p id="z9wD">По своей модели Hypersurface ближе всего к Rysk.</p>
  <p id="mFn8">Платформа использует стратегии Covered Call и Cash-Secured Put, превращая продажу опционов в инструмент получения доходности внутри экосистемы HyperEVM.</p>
  <p id="kBcx"><strong>CallPut</strong> отличается от большинства конкурентов тем, что не ограничивается криптовалютными активами.</p>
  <p id="NyCw">Платформа предлагает классические колл- и пут-опционы не только на криптовалюты, но и на акции, включая:</p>
  <ul id="ZOqT">
    <li id="Cvtc">SPCX;</li>
    <li id="o2PR">TSLA;</li>
    <li id="paTl">NVDA;</li>
    <li id="6RvW">COIN.</li>
  </ul>
  <p id="gHRH">Исполнение сделок осуществляется через систему запросов котировок (request-based execution), а ликвидностью управляет сам протокол.</p>
  <h3 id="U9q4">Kyan</h3>
  <p id="ywsz">Kyan вырос из проекта <strong>Premia</strong>, превратившись в полноценную платформу для торговли деривативами.</p>
  <p id="Mo2o">Площадка использует модель книги заявок с поддержкой RFQ, а также предлагает:</p>
  <ul id="hRZr">
    <li id="9TAF">портфельную маржу (Portfolio Margin);</li>
    <li id="IGHo">комбинированные многоногие стратегии (Multi-Leg Combo Trades), позволяющие создавать более сложные индивидуальные позиции.</li>
  </ul>
  <h3 id="1Iw8">Ithaca</h3>
  <p id="Wn8F">Ithaca предоставляет широкий набор:</p>
  <ul id="uT1T">
    <li id="cfM2">опционных инструментов;</li>
    <li id="LwVn">готовых стратегий;</li>
    <li id="9oBt">структурных продуктов.</li>
  </ul>
  <p id="Obun">Недавно протокол также интегрировал ИИ-агентов (AI Agents) для автоматического управления опционными стратегиями.</p>
  <h3 id="XGmO">SOFA.org</h3>
  <p id="ohcB">SOFA.org ориентируется не на прямую торговлю опционами, а на создание структурных инвестиционных продуктов.</p>
  <p id="AVUg">Опционоподобные выплаты упаковываются в готовые решения, такие как Earn и Surge, благодаря чему пользователям не требуется самостоятельно покупать или продавать опционы.</p>
  <figure id="dG3e" class="m_column" data-caption-align="center">
    <img src="https://img3.teletype.in/files/21/73/21733399-78ca-4218-82b2-78ba7f1fb6fc.png" width="2048" />
    <figcaption>Рисунок 10 (CL). Объём опционных премий в 2026 году (без учёта Derive, Rysk и Aevo)</figcaption>
  </figure>
  <p id="A0d7">На нижнем уровне рынка становится заметно больше разнообразия. В последние месяцы такие новые проекты, как Kyan, Paradex и CallPut, постепенно начинают занимать свою долю рынка по объёму собираемых опционных премий.</p>
  <blockquote id="SIKo">Однако одной лишь качественной инфраструктуры недостаточно.</blockquote>
  <p id="emEG">Сегодня многие протоколы предлагают современные книги заявок (<strong>Order</strong> <strong>Books</strong>), RFQ, кросс-маржу и портфельную маржу. Но сами по себе эти технологии не создают спрос.</p>
  <p id="yB3E">Пользователям всё ещё необходима причина, по которой они предпочтут опционы бессрочным контрактам (Perpetuals) при торговле направлением рынка или рынкам предсказаний при ставках на события.</p>
  <p id="XQzy">Наиболее очевидный спрос возникает тогда, когда опционный продукт решает конкретную задачу владельца актива.</p>
  <p id="6EWX">Авторы приводят в пример Rysk и HYPE. Владельцы токена HYPE получили возможность:</p>
  <ul id="UWf4">
    <li id="dATE"><strong>получать</strong> дополнительную <strong>доходность</strong>;</li>
    <li id="H110"><strong>гибко</strong> управлять <strong>уровнями</strong> покупки и продажи;</li>
    <li id="NkIK"><strong>монетизировать</strong> свою <strong>позицию</strong> без необходимости продавать сам актив.</li>
  </ul>
  <p id="a7kk">Именно такие решения, ориентированные на конкретный сценарий использования, способны обеспечить дальнейший рост рынка. Авторы считают, что новым протоколам необходимо создавать продукты, которые невозможно легко заменить бессрочными контрактами или рынками предсказаний.</p>
  <h2 id="PYLY">Экзотические и краткосрочные ончейн-опционные примитивы</h2>
  <p id="3DHv">Под экзотическими и краткосрочными опционными примитивами понимаются продукты, напоминающие опционы, но выходящие далеко за рамки классических коллов, путов и стандартных спредов.</p>
  <p id="zKCl">Подобные инструменты могут:</p>
  <ul id="Ui8M">
    <li id="OLnb">полностью отказаться от фиксированной даты экспирации;</li>
    <li id="XIjb">строить опционную доходность на основе AMM-позиций;</li>
    <li id="9ZtX">рассчитывать выплаты в зависимости от того, достигла ли цена определённой области за короткий промежуток времени.</li>
  </ul>
  <p id="iF4k">Хотя классические ончейн-опционы становятся всё более профессиональными, по своей сути они в значительной степени повторяют традиционные офчейн-продукты.</p>
  <p id="GRSR">Экзотические же конструкции существенно расширяют пространство для проектирования финансовых инструментов. Они экспериментируют с новыми типами выплат, которые сложно реализовать через стандартные опционы:</p>
  <ul id="uvSN">
    <li id="uyp9">бессрочная выпуклая доходность (perpetual convexity);</li>
    <li id="L8Qf">AMM-native конструкции;</li>
    <li id="rWTK">сверхкраткосрочные Touch-опционы.</li>
  </ul>
  <p id="Txc1">При этом большинство подобных решений пока ещё не доказали свою коммерческую жизнеспособность. Во многих случаях разработчики сначала решают интересную задачу проектирования выплат (payoff design), а уже затем начинают искать реальную пользовательскую потребность.</p>
  <h2 id="W5zj">Бессрочные опционы (Perpetual Options)</h2>
  <p id="sSu9">Бессрочные опционы полностью исключают из уравнения дату экспирации.</p>
  <p id="qUjL">Вместо выбора конкретного срока действия трейдер получает непрерывную выпуклую экспозицию (continuous convex exposure), финансируемую во времени. По своей механике это напоминает бессрочные фьючерсы, но потенциальная прибыль остаётся нелинейной, как у классических опционов.</p>
  <p id="ewzu">Историческим примером является <strong>Squeeth</strong>, предоставлявший экспозицию к ETH².</p>
  <p id="cZbn">Позднее Paradex также экспериментировал с бессрочными опционами, однако сегодня на платформе доступны лишь опционы с фиксированными сроками экспирации.</p>
  <p id="cgA4">Главная проблема подобных продуктов заключается в том, что исчезновение даты экспирации вовсе не означает исчезновение сложности.</p>
  <p id="zVYv">Пользователю по-прежнему необходимо понимать природу выпуклости (<strong>convexity</strong>), а дополнительно ещё и контролировать постоянные расходы на финансирование (<strong>funding</strong>) или непрерывно выплачиваемую премию. Кроме того, приходится самостоятельно решать, когда дальнейшее удержание позиции уже перестаёт оправдывать потенциальную прибыль.</p>
  <p id="nHm8">В результате исчезает одно из важнейших преимуществ классического опциона - заранее известная максимальная стоимость владения и заранее определённая структура выплат.</p>
  <p id="fZJr">Поэтому бессрочные опционы остаются интересным экспериментом, однако пока не смогли сделать опционные продукты проще и массовее.</p>
  <h2 id="OKhu">AMM-native опционы</h2>
  <p id="YJyD">На традиционных опционных биржах ликвидность распределяется между огромным количеством страйков и дат экспирации. После каждого изменения цены маркет-мейкеры вынуждены обновлять котировки.</p>
  <p id="tJD8">Даже несмотря на появление более быстрых и дешёвых блокчейнов, эта задача остаётся крайне сложной, особенно в основной сети Ethereum, и зачастую требует внецепочечного сопоставления заявок.</p>
  <p id="GJRA">Panoptic и GammaSwap предлагают совершенно иной подход, формируя опционную экспозицию непосредственно из ликвидности автоматизированных маркет-мейкеров (AMM).</p>
  <h3 id="nbNJ">Panoptic</h3>
  <p id="RuwX">Panoptic использует диапазоны ликвидности по модели Uniswap V3 для создания бессрочных опционов.</p>
  <p id="NV2y">Вместо единовременной оплаты премии за опцион с фиксированной датой экспирации покупатели выплачивают непрерывную премию (streaming premium), а сами диапазоны ликвидности становятся аналогом страйков и определяют параметры опционной позиции.</p>
  <p id="BewW">Такой подход позволяет создавать опционы даже для низколиквидных (long-tail) токенов, уже торгующихся в AMM, без необходимости строить отдельную книгу заявок.</p>
  <p id="NgCL">Недавно был запущен Panoptic V2, предлагающий бессрочные опционы на ETH и SPCX.</p>
  <p id="Aebv">Поставщикам капитала доступны две основные стратегии:</p>
  <ul id="cmzN">
    <li id="1cQp">Unicorn Vault - сохраняет дельта-нейтральную позицию и извлекает прибыль за счёт гамма-скальпинга (gamma scalping);</li>
    <li id="NMGr">PLP Vault - использует внесённую ликвидность ETH для одновременного получения комиссий Uniswap, премий Panoptic и дохода от кредитования (lending fees).</li>
  </ul>
  <figure id="Loeq" class="m_column" data-caption-align="center">
    <img src="https://img1.teletype.in/files/0c/2a/0c2a44aa-7571-4bb5-a7b5-3ea24c5e42fd.png" width="2048" />
    <figcaption>Рисунок 11 (CL). TVL Panoptic V2</figcaption>
  </figure>
  <p id="nvWI">GammaSwap выбрал иной подход в своей первой версии (V1), позволив пользователям занимать ликвидность из AMM и создавать бессрочную опционную экспозицию.</p>
  <p id="MQrb">Благодаря этому появилась возможность:</p>
  <ul id="zBwS">
    <li id="sd9t"><strong>хеджировать</strong> непостоянные потери (Impermanent Loss);</li>
    <li id="rCLo"><strong>спекулировать</strong> на волатильности токенов;</li>
    <li id="MeIm"><strong>делать</strong> это без использования ценовых оракулов.</li>
  </ul>
  <p id="cN9K">Эти продукты относятся к числу наиболее сложных нативных конструкций в DeFi.</p>
  <p id="xOEZ">Например, Panoptic, устраняя проблему фрагментации ликвидности между сроками экспирации, одновременно вводит целый набор новых понятий:</p>
  <ul id="Wd4b">
    <li id="RaxL">непрерывно начисляемые премии (streaming premia);</li>
    <li id="5A0W">ширину диапазонов ликвидности (liquidity widths);</li>
    <li id="N2uv">механику диапазонов AMM.</li>
  </ul>
  <p id="3l6s">Поэтому пользователям необходимо хорошо понимать принципы работы Uniswap V3 и особенности предоставления ликвидности.</p>
  <p id="H5fC"><strong>GammaSwap</strong>, напротив, полностью сменил направление развития. Проект отказался от первоначальной модели, стремясь решить проблемы капиталоэффективности и высокой сложности за счёт создания криптовалютных бинарных рынков, работающих через книгу заявок.</p>
  <p id="UB2u">Такой подход предоставляет пользователям простую выпуклую (convex) структуру выплат без риска ликвидации.</p>
  <p id="3yJN">На подобных рынках результат максимально понятен:</p>
  <ul id="m3LM">
    <li id="4OGQ">либо прогноз оказался верным - пользователь получает прибыль;</li>
    <li id="4MUg">либо прогноз оказался неверным - пользователь теряет вложенные средства.</li>
  </ul>
  <h1 id="6C06">Краткосрочные Touch-опционы</h1>
  <p id="p9SO">Эта категория находится, пожалуй, дальше всего от классических колл- и пут-опционов.</p>
  <p id="SwrD">Вместо покупки права купить или продать актив по фиксированному страйку к определённой дате пользователь выбирает простое условие, которое должно выполниться за очень короткий промежуток времени.</p>
  <p id="6wX7">Например:</p>
  <ul id="Pa7w">
    <li id="lrNF">войдёт ли цена в заданную область;</li>
    <li id="KLWz">завершится ли выше определённого уровня;</li>
    <li id="MRxj">окажется ли позиция &quot;в деньгах&quot; (In-the-Money) в течение ближайших минут.</li>
  </ul>
  <blockquote id="rYKm">Одним из самых свежих примеров такой архитектуры является Tap Trading от <strong>Euphoria</strong>.</blockquote>
  <p id="onos">Пользователь выбирает ячейку сетки, соответствующую определённому ценовому диапазону на протяжении пятисекундного интервала.</p>
  <p id="MIwY">Размер потенциальной выплаты заранее рассчитывается профессиональными маркет-мейкерами и зависит от нескольких факторов:</p>
  <ul id="T0Sr">
    <li id="xWmB">расстояния до текущей цены (Spot);</li>
    <li id="8GWr">оставшегося времени до окончания сделки;</li>
    <li id="kAF5">ожидаемой волатильности.</li>
  </ul>
  <p id="oExe">Если до истечения времени цена хотя бы один раз входит в выбранную область, сделка считается успешной и пользователь получает выплату. Если этого не происходит, контракт истекает без стоимости (<strong>expires</strong> <strong>worthless</strong>), а уплаченная премия полностью теряется.</p>
  <figure id="SSOm" class="m_column" data-caption-align="center">
    <img src="https://img2.teletype.in/files/98/bf/98bf087b-5f8d-43ce-bebd-b17a7df66135.png" width="2048" />
    <figcaption>Рисунок 12 (CL). Объём торговли бессрочными контрактами (Perps) и TVL Euphoria Finance</figcaption>
  </figure>
  <p id="4iru">Этот продукт развивается в том же направлении, что и бинарные рынки GammaSwap V2.</p>
  <p id="Dl9o">Целевая аудитория подобных решений - пользователи, желающие делать ставки на движение цены криптовалют в течение всё более коротких временных интервалов.</p>
  <p id="VFZa">Поэтому такие продукты конкурируют уже не столько с классическими опционными биржами, сколько:</p>
  <ul id="8i2Y">
    <li id="t8Zn">с бессрочными контрактами (Perpetuals);</li>
    <li id="JXO9">рынками предсказаний (Prediction Markets);</li>
    <li id="7sLH">мобильными платформами для ставок.</li>
  </ul>
  <p id="jhny">Главное преимущество подобных решений - простота.</p>
  <p id="MVzI">Пользователь практически мгновенно понимает условия сделки и получает выпуклую (нелинейную) структуру выплат без необходимости разбираться в:</p>
  <ul id="0xmo">
    <li id="P68S">ставках финансирования (<strong>Funding</strong>);</li>
    <li id="dlCe">риске ликвидации;</li>
    <li id="Ny5u">греческих параметрах опциона (<strong>Greeks</strong>);</li>
    <li id="4njR">временном распаде стоимости (<strong>Theta</strong> <strong>Decay</strong>).</li>
  </ul>
  <h2 id="wD81">Почему опционы и рынки предсказаний - это один и тот же финансовый инструмент?</h2>
  <p id="aEbL">Растущая популярность рынков предсказаний среди розничных инвесторов стала первым по-настоящему успешным примером массового распространения нелинейных финансовых инструментов в ончейн-среде.</p>
  <p id="VG6d">Однако большинство пользователей даже не подозревают, что финансовые рынки предсказаний - например, контракты BTC Up/Down - по своей структуре практически полностью совпадают с бинарными опционами (Binary Options), давно известными и подробно изученными в традиционных финансах.</p>
  <p id="VFKb">Механика одинакова:</p>
  <ul id="VXFR">
    <li id="AHdh">если к моменту экспирации выполняется заранее заданное условие - контракт выплачивает фиксированную сумму;</li>
    <li id="91xg">если условие не выполнено - выплата составляет 0 долларов.</li>
  </ul>
  <p id="aT9s">Иными словами, с точки зрения структуры выплат (payoff) финансовый рынок предсказаний представляет собой не что иное, как разновидность бинарного опциона.</p>
  <p id="3u5l">Данная статья является выдержкой из нашего исследования &quot;Ренессанс ончейн-опционов&quot;, посвящённого развитию рынка опционов (и рынков предсказаний) как торговых инструментов и анализу волатильности, лежащей в основе их ценообразования. Исследование подготовлено совместно с Block Scholes.</p>
  <p id="hzun">В следующей статье будет подробно рассмотрена экосистема рынков предсказаний. Авторы проанализируют крупнейшие платформы для торговли бинарными исходами - Kalshi, Polymarket и Hyperliquid - сравнив их по объёмам торгов и спредам на рынках BTC с однодневной экспирацией.</p>
  <p id="5wax">Полную версию исследования можно скачать <a href="https://docsend.com/view/ic97x7dpnu42n9wg" target="_blank">по ссылке</a>, приведённой в оригинальной публикации.</p>
  <p id="gJyG"><em>До!</em></p>

]]></content:encoded></item><item><guid isPermaLink="true">https://teletype.in/@menaskop/defi-derivatives-24</guid><link>https://teletype.in/@menaskop/defi-derivatives-24?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop</link><comments>https://teletype.in/@menaskop/defi-derivatives-24?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop#comments</comments><dc:creator>menaskop</dc:creator><title>DeFi. Деривативы. Бессрочные опционы. Перевод</title><pubDate>Thu, 25 Jun 2026 08:41:35 GMT</pubDate><media:content medium="image" url="https://img4.teletype.in/files/75/48/754870ce-2f36-46ff-a7f4-bbf6cc2b25fc.png"></media:content><category>DeFi</category><description><![CDATA[<img src="https://img2.teletype.in/files/19/a0/19a0f024-c0c7-4022-9ec8-a8906986449f.png"></img>Это вольный перевод: paradigm.xyz/2021/05/everlasting-options. Предыдущие части - уменьшайте на 1 итеративно: teletype.in/@menaskop/defi-derivatives-23.]]></description><content:encoded><![CDATA[
  <figure id="isWl" class="m_column">
    <img src="https://img2.teletype.in/files/19/a0/19a0f024-c0c7-4022-9ec8-a8906986449f.png" width="1024" />
    <figcaption>Деривативы</figcaption>
  </figure>
  <h2 id="Tw5O">Перевод</h2>
  <p id="SdZ9">Это вольный перевод: <a href="https://www.paradigm.xyz/2021/05/everlasting-options" target="_blank">paradigm.xyz/2021/05/everlasting-options</a>. Предыдущие части - уменьшайте на 1 итеративно: <a href="https://teletype.in/@menaskop/defi-derivatives-23" target="_blank">teletype.in/@menaskop/defi-derivatives-<strong>23</strong></a>.</p>
  <h2 id="HS9N">Введение</h2>
  <p id="nM5b">В этой работе представлен новый тип производного финансового инструмента - <strong>бессрочный опцион (everlasting option)</strong>.</p>
  <p id="hLBk">Бессрочные опционы позволяют трейдерам получать долгосрочную экспозицию к опционам без необходимости постоянно переносить (роллировать) позиции, а также без связанных с этим затрат, рисков и усилий.</p>
  <p id="7ZI7">В статье выводится простая модель ценообразования, основанная на отсутствии арбитража (no-arbitrage pricing model), которая применима не только к бессрочным опционам, но и ко всем бессрочным производным инструментам, использующим механизм <strong>funding fee</strong>, включая бессрочные фьючерсы (perpetual futures).</p>
  <h2 id="FgJ7">Основы опционов</h2>
  <h3 id="o44n">Типы опционов</h3>
  <p id="zd9R">Для начала кратко рассмотрим наиболее простой вид опционов - <strong>европейские опционы</strong>. Существует два типа европейских опционов:</p>
  <ul id="ml55">
    <li id="VE6u"><strong>Call (колл)</strong>. Колл предоставляет владельцу право купить определённый актив (базовый актив, underlier) по заранее установленной цене (страйк) в определённый момент времени в дату экспирации.</li>
    <li id="Yguz"><strong>Put (пут)</strong>. Пут предоставляет владельцу право продать базовый актив по страйковой цене в момент экспирации.</li>
  </ul>
  <h3 id="iUZ1">Примеры</h3>
  <p id="A8s4">Например, пут-опцион на ETH со страйком 3000 долларов и датой экспирации 15 мая даёт владельцу право продать 1 ETH за 3000 долларов в заранее установленное время 15 мая. </p>
  <p id="r0Pf">Предположим, что в день экспирации рыночная цена ETH (спотовая цена, <em>spot</em>) составляет 2900 долларов. В этом случае трейдер может:</p>
  <ul id="UwGt">
    <li id="8VLO">купить 1 ETH на рынке за 2900 долларов;</li>
    <li id="4Qvn">сразу же продать его по опциону за 3000 долларов.</li>
  </ul>
  <p id="fMTe">Таким образом фиксируется прибыль в размере 100 долларов. Эта величина называется выплатой (<strong>payoff</strong>).</p>
  <p id="rmgX">Рассмотрим обратную ситуацию. Если трейдер держит пут со страйком 3000 долларов, а в день экспирации ETH стоит 3100 долларов, то продать ETH выгоднее непосредственно на рынке, чем использовать опцион. Следовательно, использовать пут не имеет смысла, и его выплата (payoff) будет равна нулю.</p>
  <h3 id="X0aw">Расчёт выплаты (Payoff)</h3>
  <p id="02e4">Хотя европейский опцион может быть исполнен (<strong>exercised</strong>) только один раз - в строго определённый момент времени в дату экспирации, величину его выплаты можно вычислить в любой момент. По сути, это показывает, сколько стоил бы опцион, если бы его можно было исполнить прямо сейчас.</p>
  <p id="vGkW">Для пут-опциона выплата рассчитывается по формуле:</p>
  <p id="JYUR" data-align="center"><strong>Payoff = max(Strike − Spot, 0)</strong></p>
  <p id="1OKX">То есть:</p>
  <ul id="dWfJ">
    <li id="kHRC">чем сильнее цена ETH опускается ниже страйка, тем выше прибыль от продажи ETH через пут;</li>
    <li id="RwE4">если же цена ETH на момент экспирации выше страйка, то продавать ETH на открытом рынке выгоднее, чем использовать пут;</li>
    <li id="DjwQ">пут становится бесполезным<strong> (worthless)</strong>, а его выплата равна <strong>0</strong>.</li>
  </ul>
  <figure id="ngwG" class="m_column" data-caption-align="center">
    <img src="https://img3.teletype.in/files/66/26/66264e20-f490-43de-8b72-28794d95b3bc.png" width="1441" />
    <figcaption>График 01. Данные: <a href="https://colab.research.google.com/drive/1nehkZjTh_Kloz_vC--e1h7W_s-yGzh9b?usp=sharing" target="_blank">https://colab.research.google.com/drive/1nehkZjTh_Kloz_vC--e1h7W_s-yGzh9b?usp=sharing</a></figcaption>
  </figure>
  <h3 id="Y4K8">Выплата по колл-опциону</h3>
  <p id="bJda">Аналогично, выплата по колл-опциону (call) рассчитывается по формуле:</p>
  <p id="hTSs" data-align="center"><strong>Payoff = max(Spot − Strike, 0)</strong></p>
  <p id="YCfa">Если ETH торгуется по 3100 долларов, а у нас есть колл-опцион на ETH со страйком 3000 долларов, срок действия которого истекает сегодня, то мы можем купить 1 ETH за 3000 долларов по опциону и сразу же продать его на рынке за 3100 долларов, получив выплату (payoff) в размере 100 долларов.</p>
  <p id="1U5N">Однако если ETH торгуется по 2900 долларов, а страйк колл-опциона составляет 3000 долларов, то использовать опцион невыгодно, поэтому его выплата будет равна 0.</p>
  <h3 id="pCNy">Ценообразование опционов</h3>
  <p id="qPGY">Как правило, до момента экспирации стоимость опциона выше, чем его текущая выплата (payoff), за исключением некоторых особых случаев.</p>
  <p id="M1ZM">Рассмотрим пут-опцион на ETH со страйком 3000 долларов, срок действия которого истекает завтра. Предположим, что сейчас цена ETH составляет 3000 долларов. В данный момент выплата по этому путу равна 0.</p>
  <p id="vehs">Однако до завтрашней экспирации цена ETH может снизиться. Если это произойдёт, то к моменту истечения срока действия опцион будет иметь положительную стоимость.</p>
  <blockquote id="jmJ5">Следовательно, уже сейчас этот пут должен стоить больше нуля, поскольку существует вероятность того, что до экспирации он станет прибыльным.</blockquote>
  <p id="G3eY">Одной из наиболее известных и широко используемых моделей оценки стоимости опционов является модель <a href="https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%91%D0%BB%D1%8D%D0%BA%D0%B0_%E2%80%94_%D0%A8%D0%BE%D1%83%D0%BB%D0%B7%D0%B0" target="_blank">Блэка-Шоулза</a> (Black-Scholes).</p>
  <p id="Mkp3">На графике ниже показана цена пут-опциона на ETH со страйком 3000 долларов, рассчитанная по модели Блэка-Шоулза, в сравнении с его выплатой (payoff) при различных значениях спотовой цены ETH за один день до экспирации:</p>
  <figure id="ASzs" class="m_column" data-caption-align="center">
    <img src="https://img3.teletype.in/files/6e/69/6e69a731-88a7-4b9e-99dd-dd72c76a27fc.png" width="1447" />
    <figcaption>График 02. Данные: <a href="https://colab.research.google.com/drive/1nehkZjTh_Kloz_vC--e1h7W_s-yGzh9b?usp=sharing" target="_blank">https://colab.research.google.com/drive/1nehkZjTh_Kloz_vC--e1h7W_s-yGzh9b?usp=sharing</a></figcaption>
  </figure>
  <h2 id="T4GQ">Роллирование позиций (Rolling Positions)</h2>
  <h3 id="Xh4K">Определение</h3>
  <p id="DIwH">Одно из основных применений опционов - <strong>хеджирование</strong>, то есть защита от рыночного риска.</p>
  <p id="ge1n">Например, если инвестор владеет крупным портфелем ETH, он может купить достаточное количество пут-опционов на ETH со страйком 3000 долларов, чтобы гарантировать себе возможность продать свои ETH не дешевле 3000 долларов за монету, независимо от того, как изменится рыночная цена ETH.</p>
  <p id="y9CI">Однако срок действия этих пут-опционов однажды истечёт. Если инвестор хочет сохранить свою защиту, ему придётся роллировать (перекатывать) опционную позицию.</p>
  <p id="DYUS">В данном случае это означает:</p>
  <ul id="TgAT">
    <li id="3lmg">закрыть позицию по опционам, срок действия которых скоро истекает;</li>
    <li id="3XqB">одновременно открыть новую позицию по опционам с тем же страйком, но более поздней датой экспирации.</li>
  </ul>
  <h3 id="FWlL">Пример</h3>
  <p id="g3XU">Предположим, инвестор первоначально приобрёл пут-опционы на ETH со страйком 3000 долларов и экспирацией 15 мая.</p>
  <p id="hwUQ">Когда до экспирации остаётся совсем немного времени, он может:</p>
  <ul id="UYy3">
    <li id="6tY1">продать эти опционы;</li>
    <li id="jyEj">купить такое же количество пут-опционов со страйком 3000 долларов, но уже с экспирацией 15 июня.</li>
  </ul>
  <p id="GGYJ">Если инвестор хочет сохранять хеджирование постоянно, ему придётся повторять эту процедуру каждый месяц.</p>
  <h3 id="7GaR">Недостатки</h3>
  <p id="g89K">Когда инвестор выходит на рынок для роллирования позиции, его контрагентом почти всегда становится участник рынка, называемый маркет-мейкером(<strong>market</strong> <strong>maker</strong>).</p>
  <p id="4IMu">Маркет-мейкеры зарабатывают деньги тогда, когда с ними торгуют неосведомлённые участники рынка, например инвесторы, которые просто перекатывают свои опционные позиции. Однако маркет-мейкеры теряют деньги, когда торгуют против осведомлённых участников, например тех, кто заранее знает важные новости, способные повлиять на цену ETH.</p>
  <p id="eIWs">Поскольку маркет-мейкер не знает, кто перед ним - информированный или неинформированный участник, - он вынужден включать в каждую сделку специальную комиссию, называемую спредом<strong> (spread). </strong>На рынке опционов спреды обычно особенно велики, поскольку сделки информированных участников могут приносить маркет-мейкерам значительные убытки.</p>
  <blockquote id="PVWi">Поэтому роллирование позиций оказывается достаточно дорогой процедурой.</blockquote>
  <p id="BKvy">Кроме того, роллирование связано не только с дополнительными расходами, но и с работой и рисками.</p>
  <p id="OEAm">Трейдер может:</p>
  <ul id="EtNf">
    <li id="6gHU">просто забыть вовремя перекатить позицию и остаться без хеджирования;</li>
    <li id="Burd">случайно нажать не ту кнопку;</li>
    <li id="eDp4">исполнить сделку с ошибкой.</li>
  </ul>
  <p id="8ZQp">Подобные ошибки могут дорого обойтись. Даже если всё проходит идеально, сама процедура требует времени и вызывает стресс, отвлекая внимание трейдера от более важных и продуктивных задач.</p>
  <h3 id="ssWS">Существующие решения</h3>
  <p id="a2Xq">Уже существует инструмент под названием бессрочный американский опцион (<strong>Perpetual American Option</strong>).</p>
  <p id="MgMX">Это опцион, который:</p>
  <ul id="Mmua">
    <li id="ikJI">не имеет даты экспирации;</li>
    <li id="B3F4">может быть исполнен в любой момент времени.</li>
  </ul>
  <p id="sMXy">Однако продажа такого опциона требует от маркет-мейкера принятия на себя чрезвычайно большого объёма риска и неопределённости уже в момент открытия позиции.</p>
  <p id="KG0m">Из-за этого бессрочные американские опционы:</p>
  <ul id="Nf2m">
    <li id="vjjf">стоят очень дорого;</li>
    <li id="gskZ">крайне сложны в оценке;</li>
    <li id="TKrV">практически не торгуются на рынке.</li>
  </ul>
  <p id="a1ZD">Именно существование этого инструмента объясняет, почему авторы называют предложенный ими новый тип опциона <strong>Everlasting Option</strong> (&quot;вечный&quot; или бессрочный опцион), подчёркивая, что это альтернативный подход к созданию опциона без срока действия.</p>
  <h2 id="C789">Фрагментация ликвидности (Liquidity Fragmentation)</h2>
  <p id="9LT7">Существование большого количества различных дат экспирации опционов приводит ещё к одной серьёзной проблеме - <strong>фрагментации ликвидности</strong>.</p>
  <p id="zxuz">Если маркет-мейкеры вынуждены поддерживать котировки не только для опционов, истекающих на этой неделе, но и для контрактов с экспирацией каждую неделю в течение следующих нескольких месяцев, им приходится распределять свой капитал между множеством разных рынков.</p>
  <p id="CYjg">В результате:</p>
  <ul id="6CbF">
    <li id="Jx45">ликвидность каждого отдельного контракта становится ниже;</li>
    <li id="emrG">участникам рынка сложнее исполнять крупные сделки;</li>
    <li id="mROf">становится труднее определить справедливую рыночную цену.</li>
  </ul>
  <p id="HFg7">Кроме того, такой раздробленный рынок делает торговлю опционами более сложной, поскольку трейдеру приходится выбирать, с какой именно датой экспирации совершать сделку.</p>
  <h3 id="FjRu">Аналогия с рынком фьючерсов</h3>
  <p id="dBUo">Традиционные фьючерсные контракты, которые также имеют фиксированную дату экспирации, сталкиваются с теми же проблемами.</p>
  <p id="O2Vm">Если трейдер хочет получить долгосрочную экспозицию к ETH при помощи обычных фьючерсов с датой исполнения, ему также придётся регулярно роллировать позицию.</p>
  <p id="KP6Z">Например:</p>
  <ul id="T16d">
    <li id="kWTR">сначала он покупает фьючерс на ETH с экспирацией 15 мая;</li>
    <li id="myd6">затем, когда срок его действия подходит к концу, продаёт этот контракт;</li>
    <li id="1ipy">после чего покупает аналогичный контракт с экспирацией 15 июня;</li>
    <li id="yZyA">затем повторяет эту процедуру снова и снова.</li>
  </ul>
  <p id="aepG">Как и в случае с опционами, роллирование фьючерсной позиции:</p>
  <ul id="mQVB">
    <li id="V87n">требует <strong>времени</strong>;</li>
    <li id="d1rX">создаёт дополнительные <strong>риски</strong>;</li>
    <li id="z6AF">вынуждает постоянно платить <strong>спред</strong> маркет-мейкерам.</li>
  </ul>
  <p id="Wkq6">Наличие множества различных дат экспирации также приводит к фрагментации ликвидности на рынке фьючерсов.</p>
  <h2 id="b4ed">Бессрочные фьючерсы (Perpetual Futures)</h2>
  <p id="uARG">Бессрочные фьючерсы (Perpetual Futures, или сокращённо <strong>Perps</strong>), впервые представленные криптовалютному рынку биржей BitMEX в 2016 году, решают перечисленные выше проблемы.</p>
  <p id="jYpf">Они позволяют трейдерам сохранять фьючерсную позицию столько времени, сколько потребуется, без необходимости регулярно роллировать контракт. Кроме того, бессрочные фьючерсы объединяют всю ликвидность по одному базовому активу на конкретной бирже в одном инструменте. В результате бессрочные фьючерсы стали чрезвычайно популярными.</p>
  <p id="GBjR">Сегодня объём торгов ими достигает десятков, а иногда и сотен миллиардов долларов в сутки.</p>
  <h3 id="9UUy">Механизм работы</h3>
  <p id="vpUI">В упрощённом виде механизм бессрочных фьючерсов выглядит следующим образом.</p>
  <p id="djZP">Каждый день участники, удерживающие длинную позицию (<strong>Long</strong>) по бессрочному фьючерсу, выплачивают комиссию за финансирование (<strong>Funding</strong> <strong>Fee</strong>) участникам, находящимся в короткой позиции (<strong>Short</strong>).</p>
  <p id="1Nxk">Размер этой комиссии рассчитывается как:</p>
  <p id="KnNl" data-align="center"><strong>Funding Fee = Mark Price - Index Price</strong></p>
  <p id="31Jk">где:</p>
  <ul id="rVpB">
    <li id="ggG5"><strong>Mark</strong> <strong>Price</strong> - расчётная (маркированная) цена бессрочного фьючерса;</li>
    <li id="v3fC"><strong>Index</strong> <strong>Price</strong> - цена базового актива (например, ETH).</li>
  </ul>
  <p id="4O9L">Этот механизм финансирования удерживает цену бессрочного фьючерса близкой к цене базового актива. Если цена бессрочного фьючерса становится значительно выше цены ETH, держатели длинных позиций начинают платить высокие комиссии за финансирование. Это стимулирует их продавать бессрочный фьючерс, что снижает его цену и возвращает её ближе к стоимости базового актива. Авторы отмечают, что данное объяснение является упрощённым.</p>
  <p id="cKGE">Более подробное описание механики бессрочных фьючерсов приведено в работе <strong>The Cartoon Guide to Perps</strong>, а ниже в статье представлена строгая <a href="https://www.paradigm.xyz/2021/05/everlasting-options" target="_blank">математическая модель их оценки</a>.</p>
  <h3 id="AKDr">Примеры</h3>
  <p id="Eqr4">Предположим, бессрочный фьючерс на ETH торгуется по 3100 долларов, тогда как спотовая цена ETH составляет 3000 долларов. В этом случае: Mark − Index = 3100 − 3000 = 100 долларов.</p>
  <p id="0fRo">Следовательно, держатели длинных позиций (Long) должны выплачивать держателям коротких позиций (Short) 100 долларов в день (в расчёте на один контракт).</p>
  <p id="HfDR">Теперь предположим обратную ситуацию. Бессрочный фьючерс на ETH торгуется по 2900 долларов, а спотовая цена ETH остаётся 3000 долларов. Тогда: Mark − Index = 2900 − 3000 = −100 долларов.</p>
  <p id="inxN">Отрицательное значение означает, что теперь уже держатели коротких позиций выплачивают держателям длинных позиций 100 долларов в день.</p>
  <h2 id="PWwB">Бессрочные опционы (Everlasting Options)</h2>
  <p id="HAWa">Бессрочные опционы являются аналогом бессрочных фьючерсов (Perpetual Futures), но для рынка опционов.</p>
  <p id="MDPW">Трейдер, владеющий бессрочным пут-опционом на ETH со страйком 3000 долларов, фактически всегда сохраняет возможность продать свой ETH по цене 3000 долларов. Для поддержания этой позиции он регулярно выплачивает комиссию за финансирование (Funding Fee).</p>
  <p id="xiRX">Однако, поскольку ему не приходится постоянно взаимодействовать с маркет-мейкерами для роллирования позиции, он:</p>
  <ul id="YlFa">
    <li id="0TNv"><strong>не</strong> <strong>платит</strong> <strong>спреды</strong> при каждом продлении позиции;</li>
    <li id="mR37"><strong>не</strong> <strong>несёт</strong> операционных <strong>рисков</strong>, связанных с роллированием;</li>
    <li id="yMXb"><strong>сталкивается</strong> с <strong>торговыми</strong> <strong>издержками</strong> только при открытии и окончательном закрытии позиции.</li>
  </ul>
  <p id="1k2d">Кроме того, поскольку необходимость в многочисленных датах экспирации исчезает, ликвидность становится значительно менее фрагментированной. Правда, в базовой версии инструмента по-прежнему существуют отдельные бессрочные опционы для различных страйков.</p>
  <h3 id="dqOm">Механизм работы</h3>
  <p id="q9r2">Бессрочные опционы работают практически так же, как бессрочные фьючерсы. Отличие заключается лишь в способе расчёта комиссии за финансирование. Если для бессрочных фьючерсов используется формула:</p>
  <p id="CH5g" data-align="center"><strong>Funding Fee = Mark − Index,</strong></p>
  <p id="xOR3">то для бессрочных опционов она принимает вид:</p>
  <p id="J9MR" data-align="center"><strong>Funding Fee = Mark − Payoff,</strong></p>
  <p id="JaLj">где:</p>
  <ul id="ta9t">
    <li id="FMmz"><strong>Mark</strong> - расчётная (маркированная) цена бессрочного опциона;</li>
    <li id="zpjc"><strong>Payoff</strong> - текущая внутренняя стоимость (выплата) опциона.</li>
  </ul>
  <p id="Qa1y">Иными словами, вместо цены базового актива используется текущая выплата опциона.</p>
  <h3 id="8JXp">Примеры</h3>
  <p id="ZdhU">Рассмотрим бессрочный пут-опцион на ETH со страйком 3000 долларов, по которому комиссия за финансирование начисляется один раз в день.</p>
  <p id="cJHi"><strong>Пример №01</strong>. Пусть текущая цена ETH составляет 2900 долларов. Тогда текущая выплата по путу равна: 3000 − 2900 = 100 долларов.</p>
  <p id="5MIc">Предположим, непосредственно перед начислением Funding Fee бессрочный пут торгуется по цене 150 долларов. Тогда комиссия за финансирование составит:</p>
  <p id="xoDd" data-align="center">Mark − Payoff = 150 − 100 = 50 долларов в день.</p>
  <p id="6ix5">Следовательно, держатели длинных позиций (<strong>Long</strong>) выплачивают держателям коротких позиций (<strong>Short</strong>) 50 долларов в день.</p>
  <p id="jlGN"><strong>Пример №02</strong>. Теперь предположим, что ETH торгуется по 3100 долларов, то есть выше страйка. В этом случае выплата по пут-опциону равна: 0 долларов.</p>
  <p id="kLm1">Если непосредственно перед начислением Funding Fee бессрочный пут стоит 50 долларов, то: </p>
  <p id="A7wE" data-align="center">Mark − Payoff = 50 − 0 = 50 долларов в день.</p>
  <p id="BE8Q">Следовательно, держатели длинных позиций снова выплачивают держателям коротких позиций 50 долларов в день.</p>
  <p id="oMP5">Интересно отметить ещё один важный факт. Выплата по колл-опциону со страйком 0 долларов всегда равна текущей цене ETH. То есть:</p>
  <p id="2gpv" data-align="center"><strong>Payoff = Index.</strong></p>
  <p id="vlvq">Иными словами, колл-опцион со страйком 0 долларов эквивалентен обычному фьючерсу на ETH. Соответственно, комиссия за финансирование по бессрочному колл-опциону со страйком 0 долларов будет рассчитываться как:</p>
  <p id="HZjq" data-align="center"><strong>Mark − Payoff = Mark − Index,</strong></p>
  <p id="vmMX">то есть <strong>точно так же</strong>, как и для обычного бессрочного фьючерса.</p>
  <h3 id="g3qX">Ценообразование</h3>
  <p id="M6Dw">Бессрочные опционы были бы мало полезны, если бы невозможно было определить их справедливую стоимость. К счастью, благодаря приведённому далее в статье доказательству, основанному на отсутствии арбитража (No-Arbitrage), такая стоимость определяется достаточно точно.</p>
  <p id="6J0I">Авторы показывают, что бессрочный опцион эквивалентен определённому портфелю обычных опционов, который непрерывно роллируется. Следовательно, цена бессрочного опциона должна совпадать со стоимостью этого портфеля. Если цены начинают существенно расходиться, в дело вступают арбитражёры, возвращая их к справедливому уровню.</p>
  <p id="UAzt">Если комиссия за финансирование начисляется один раз в день, эквивалентный портфель состоит из:</p>
  <ul id="pDXk">
    <li id="w48a">1/2 опциона с экспирацией сегодня;</li>
    <li id="SNqk">1/4 опциона с экспирацией завтра;</li>
    <li id="5yYZ">1/8 опциона с экспирацией послезавтра;</li>
    <li id="tgNV">и так далее.</li>
  </ul>
  <p id="h978">Все эти опционы имеют тот же страйк, что и соответствующий бессрочный опцион.</p>
  <p id="5HjY">Можно также создать бессрочный опцион с более частыми начислениями комиссии за финансирование. Например, если финансирование выплачивается каждый час, то каждый час списывается лишь 1/24 суточной комиссии. В этом случае состав эквивалентного портфеля изменяется. Подробные вычисления приведены авторами в <a href="https://www.paradigm.xyz/2021/05/everlasting-options" target="_blank">Приложении B (Appendix B)</a>.</p>
  <p id="ZFJz">Независимо от выбранной схемы начисления Funding Fee стоимость бессрочного опциона определяется как стоимость этого эквивалентного портфеля. Практически это делается достаточно просто: нужно вычислить взвешенную сумму цен всех входящих в него обычных опционов (при необходимости оценивая вклад очень маленьких долей - например, менее 1/1024 всего портфеля).</p>
  <p id="LDhy">Авторы отмечают, что маркет-мейкеры на рынке опционов уже умеют достаточно точно оценивать стоимость отдельных срочных опционов, поэтому вычисление цены бессрочного опциона не представляет принципиальной сложности.</p>
  <p id="En70">Если использовать классические предположения модели Блэка-Шоулза, которые хотя и не полностью соответствуют реальному рынку, но дают хорошее приближение, то бессрочный опцион с начислением Funding Fee два раза в день будет вести себя почти так же, как обычный опцион с тем же страйком и сроком экспирации через один день.</p>
  <figure id="fJ7Z" class="m_column">
    <img src="https://img1.teletype.in/files/4e/d3/4ed327ef-1253-42fd-8677-47175ee47d3b.png" width="1447" />
    <figcaption>График 03. Данные: переводимая статяь</figcaption>
  </figure>
  <h2 id="W8L0">Эквивалентный портфель (Equivalent Portfolio)</h2>
  <h3 id="oA79">Динамика цены в момент выплаты Funding Fee</h3>
  <p id="wSeB">Понимание бессрочных производных инструментов с механизмом Funding Fee, таких как бессрочные опционы (<strong>Everlasting Options</strong>), представляет определённую сложность, поскольку их цена имеет естественный разрыв (<strong>дискретность</strong>).</p>
  <p id="NUuf">Причина заключается в том, что комиссия за финансирование начисляется в строго определённый момент времени, например ровно в полночь. Точно так же, как цена акции изменяется сразу после выплаты дивиденда, цена бессрочного производного инструмента должна скачкообразно измениться сразу после выплаты Funding Fee.</p>
  <blockquote id="mRvd">Поэтому, хотя естественно рассуждать о событиях, происходящих &quot;в момент выплаты Funding Fee&quot;, такой подход только создаёт путаницу. </blockquote>
  <p id="kCWq">При анализе бессрочных производных инструментов гораздо правильнее рассматривать два отдельных состояния:</p>
  <ul id="Zrnl">
    <li id="3n3q">непосредственно <strong>перед</strong> выплатой Funding Fee;</li>
    <li id="62qY">непосредственно <strong>после</strong> выплаты Funding Fee.</li>
  </ul>
  <p id="Sgdm">Такое разделение позволяет избежать неоднозначностей и корректно описывать динамику цены.</p>
  <p id="KlW2">Авторы делают интересное замечание. На многих современных биржах бессрочных фьючерсов книги заявок (order books) автоматически не пересчитываются после выплаты Funding Fee, в отличие от фондовых бирж, где после выплаты дивидендов цены автоматически корректируются.</p>
  <p id="X6hj">Из-за этого маркет-мейкеры могут становиться жертвами арбитража.</p>
  <p id="UC0D">Например, если держатели длинных позиций (<strong>Long</strong>) должны выплатить Funding Fee держателям коротких позиций (<strong>Short</strong>), рациональный арбитражёр может:</p>
  <ol id="UUDi">
    <li id="lX2I">открыть короткую позицию буквально за микросекунду до выплаты Funding Fee;</li>
    <li id="bOom">получить выплату;</li>
    <li id="tFCL">закрыть позицию спустя микросекунду после начисления Funding Fee.</li>
  </ol>
  <p id="yKv8">Таким образом можно получить практически безрисковую прибыль.</p>
  <h3 id="S1UK">Интуиция эквивалентного портфеля</h3>
  <p id="lXoQ">Как уже отмечалось ранее, бессрочный опцион, по которому комиссия за финансирование начисляется один раз в день, эквивалентен определённому портфелю обычных срочных опционов.</p>
  <p id="yPAv">Этот портфель состоит из:</p>
  <ul id="LD7k">
    <li id="rUrs">1/2 опциона с экспирацией в момент ближайшей выплаты Funding Fee;</li>
    <li id="ZwQm">1/4 опциона с экспирацией в момент следующей выплаты Funding Fee;</li>
    <li id="HqTd">1/8 опциона с экспирацией ещё через один период;</li>
    <li id="LSd4">и так далее.</li>
  </ul>
  <p id="nuKf">Суммарное количество всех долей опционов в этом портфеле равно:</p>
  <p id="BYx7" data-align="center">1/2 + 1/4 + 1/8 + 1/16 + … = 1.</p>
  <p id="crkg">То есть весь портфель эквивалентен одному полному опционному контракту.</p>
  <p id="qVPW">Это означает, что в момент очередной выплаты Funding Fee половина портфеля (то есть 1/2 опциона) только что истекла. В этом смысле выплата Funding Fee соответствует стоимости роллирования портфеля.</p>
  <p id="ffla">Другими словами, полученная или уплаченная комиссия используется для покупки новой половины опциона взамен той, которая только что завершила своё существование.</p>
  <p id="xbWK">Однако по сравнению с обычным ручным роллированием здесь имеется несколько важных преимуществ. Новые опционы:</p>
  <ul id="N9Po">
    <li id="4Evd"><strong>автоматически</strong> <strong>распределяются</strong> между множеством будущих дат экспирации;</li>
    <li id="iQGi"><strong>не</strong> <strong>требуют</strong> <strong>уплаты</strong> спредов маркет-мейкерам;</li>
    <li id="3Ufh"><strong>не</strong> <strong>создают</strong> <strong>риска</strong> ошибочного исполнения сделки;</li>
    <li id="IeFc"><strong>не</strong> <strong>требуют</strong> <strong>постоянного</strong> <strong>ручного</strong> &quot;перекатывания&quot; позиции.</li>
  </ul>
  <p id="VxPZ">Именно поэтому бессрочные опционы позволяют воспроизводить эффект непрерывного роллирования, устраняя практически все связанные с ним недостатки.</p>
  <figure id="Emv5" class="m_column">
    <img src="https://img2.teletype.in/files/d6/93/d6932510-35a1-4a21-9eae-8c7d03cd1549.png" width="1446" />
    <figcaption>График 04. Данные: переводимая статья</figcaption>
  </figure>
  <p id="Upoj">См. также:</p>
  <figure id="NrtH" class="m_column">
    <img src="https://img2.teletype.in/files/59/da/59daeae3-5480-47ef-a225-6aac9dd72ff1.png" width="1446" />
    <figcaption>График 05. Данные: переводимая статья</figcaption>
  </figure>
  <h2 id="dAi3">Аргументация (Argument)</h2>
  <p id="jZrt">Предположим, Алиса удерживает один контракт бессрочного опциона (Everlasting Option), по которому Funding Fee выплачивается один раз в день - ровно в полночь.</p>
  <p id="Jrsp">Сегодня ночью, в полночь, Алиса должна выплатить комиссию за финансирование, равную:</p>
  <p id="aYwZ" data-align="center"><strong>Mark − Payoff</strong>.</p>
  <p id="pZTI">Давайте разберёмся, что означает этот денежный поток. Цена Mark - это стоимость покупки бессрочного опциона непосредственно перед моментом выплаты Funding Fee. Следовательно, Алиса фактически платит сумму, необходимую для того, чтобы удвоить свою позицию.</p>
  <p id="ud5z">С другой стороны, поскольку член Payoff входит в формулу <strong>со</strong> <strong>знаком</strong> <strong>минус</strong>, Алиса одновременно получает выплату (Payoff) - ровно такую, какую получила бы, если бы владела одним контрактом обычного опциона, истекающего в полночь.</p>
  <p id="RkU5">Другими словами, если владение бессрочным опционом эквивалентно владению некоторым портфелем обычных срочных опционов, то непосредственно перед экспирацией Алиса удваивает свою позицию по каждому из этих опционов, а затем в момент экспирации получает выплату, соответствующую одному полному контракту.</p>
  <p id="a5xa">Это означает, что до момента удвоения позиции Алиса должна владеть ровно половиной контракта опциона, срок действия которого истекает сегодня в полночь.</p>
  <p id="KUyG">Продолжая эти рассуждения, если мы хотим, чтобы эквивалентный портфель бессрочного опциона продолжал существовать и после сегодняшней ночи, то после сегодняшнего удвоения позиция Алисы в обычном опционе, истекающем завтра в полночь, должна составлять ровно половину контракта.</p>
  <p id="pKaT">Это возможно только в том случае, если до удвоения эта позиция составляла одну четверть контракта.</p>
  <p id="pEwx">Аналогично:</p>
  <ul id="7yiZ">
    <li id="Fv3o">затем - одну восьмую;</li>
    <li id="T0UP">затем - одну шестнадцатую;</li>
    <li id="j9PX">и так далее.</li>
  </ul>
  <p id="iT9F">Обратите внимание, что этот аргумент применим к любому срочному производному инструменту с определённой выплатой (Payoff), а не только к европейским опционам.</p>
  <h3 id="HlEU">Формальное доказательство (Formal Proof)</h3>
  <p id="zaM5">См. Приложение B (Appendix B) - в оригинальной статье. </p>
  <h2 id="iQxz">Дальнейшие применения (Further Applications)</h2>
  <p id="zhir">Предложенная авторами конструкция может использоваться для оценки любого бессрочного производного инструмента с механизмом Funding Fee, если существует возможность оценить соответствующий ему срочный инструмент.</p>
  <p id="aCal">Это относится не только к европейским колл- и пут-опционам. Сюда также входят:</p>
  <ul id="41J2">
    <li id="thN8">бессрочные фьючерсы (Perpetual Futures);</li>
    <li id="a9hI">другие производные инструменты с аналогичной структурой выплат.</li>
  </ul>
  <p id="avvZ">Кроме того, эта методика применима к бинарным пут-опционам (<strong>Binary</strong> <strong>Puts</strong>). Такие опционы выплачивают:</p>
  <ul id="2o5n">
    <li id="a4Vl">0 долларов, если цена базового актива выше заданного страйка;</li>
    <li id="4A9G">1 доллар, если цена оказывается ниже страйка.</li>
  </ul>
  <p id="B4Ac">Благодаря этому бинарные путы могут использоваться в качестве прокси-инструмента для оценки вероятности отказа (или сбоя) протокола.</p>
  <h2 id="qLyj">Бессрочные опционы с плавающим страйком (Floating Strike Everlasting Options)</h2>
  <p id="FzLD">Предложенный подход можно использовать и для оценки бессрочного опциона, страйк которого определяется как экспоненциально-взвешенное скользящее среднее (EWMA) цены базового актива.</p>
  <p id="0nrB">Это возможно потому, что существует соответствующий срочный аналог - азиатский опцион с плавающим страйком (Floating-Strike Asian Option). Хотя оценка такого опциона является достаточно сложной задачей, она всё же возможна.</p>
  <p id="V1xB">Владение подобным бессрочным пут-опционом фактически позволило бы владельцу ETH в любой момент продать свои монеты по экспоненциально-взвешенной средней цене ETH.</p>
  <p id="LsbO">Например, если период полураспада такого среднего составляет один день, то подобный инструмент защищал бы инвестора от резких краткосрочных падений цены ETH.</p>
  <p id="aHkd">Поскольку страйк автоматически следует за рыночной ценой ETH, вполне возможно, что одного такого инструмента окажется достаточно для удовлетворения потребностей большинства держателей ETH в хеджировании.</p>
  <p id="jWYa">Это, в свою очередь, потенциально позволит сосредоточить значительную часть ликвидности и объёма торгов опционами на ETH в одном рынке, устранив проблему фрагментации ликвидности.</p>
  <h2 id="qM3m">Будущие исследования (Future Work)</h2>
  <p id="q4Cy">По мнению авторов, дальнейшая работа должна быть сосредоточена прежде всего на практических применениях предложенной модели.</p>
  <p id="Ua43">Открытыми остаются следующие вопросы:</p>
  <ul id="JTDO">
    <li id="3bEA"><strong>Существует</strong> ли достаточный рыночный <strong>спрос</strong> на бессрочные опционы и другие бессрочные производные инструменты с механизмом Funding Fee?</li>
    <li id="CfOp"><strong>Какие</strong> <strong>типы</strong> подобных <strong>инструментов</strong> окажутся наиболее востребованными?</li>
    <li id="6hZC"><strong>Как</strong> следует <strong>выбирать</strong> их <strong>параметры</strong> для достижения максимальной эффективности?</li>
    <li id="5lNi"><strong>Каким</strong> образом биржи и трейдеры <strong>должны</strong> <strong>управлять</strong> <strong>рисками</strong> таких инструментов?</li>
    <li id="IDS1"><strong>Какие</strong> <strong>критерии</strong> ликвидации следует применять при торговле ими с использованием кредитного плеча?</li>
  </ul>
  <p id="psPp"><em>Если у вас есть идеи по этим вопросам или собственные предложения и замечания, авторы будут рады их услышать.</em></p>
  <h2 id="C9wS">P.S.</h2>
  <p id="CB6Z">Посмотрите внимательно на автора статьи-оригинала :)... </p>
  <p id="59pc"><em>До!</em></p>

]]></content:encoded></item><item><guid isPermaLink="true">https://teletype.in/@menaskop/defi-derivatives-23</guid><link>https://teletype.in/@menaskop/defi-derivatives-23?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop</link><comments>https://teletype.in/@menaskop/defi-derivatives-23?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop#comments</comments><dc:creator>menaskop</dc:creator><title>DeFi. Деривативы. Глубокое погружение. Перевод MixBytes</title><pubDate>Wed, 24 Jun 2026 07:25:21 GMT</pubDate><media:content medium="image" url="https://img4.teletype.in/files/75/48/754870ce-2f36-46ff-a7f4-bbf6cc2b25fc.png"></media:content><category>DeFi</category><description><![CDATA[<img src="https://img2.teletype.in/files/19/a0/19a0f024-c0c7-4022-9ec8-a8906986449f.png"></img>Web3-деривативы. Глубокое погружение. Перевод MixBytes]]></description><content:encoded><![CDATA[
  <figure id="ptoc" class="m_column">
    <img src="https://img2.teletype.in/files/19/a0/19a0f024-c0c7-4022-9ec8-a8906986449f.png" width="1024" />
    <figcaption>Деривативы</figcaption>
  </figure>
  <p id="gn3E">Web3-деривативы. Глубокое погружение. Перевод MixBytes</p>
  <h2 id="4bqc">Перевод</h2>
  <blockquote id="kvyd">Это вольный перевод: <a href="https://mixbytes.io/blog/deep-dive-into-defi-derivatives" target="_blank">mixbytes.io/blog/deep-dive-into-defi-derivatives</a>.</blockquote>
  <h2 id="hm1k">Аннотация</h2>
  <p id="8cpN">Деривативы в DeFi прошли долгий путь развития. Ранние ончейн-проекты были медленными и дорогими в использовании, однако новые rollup-решения второго уровня (Layer 2) теперь обеспечивают трейдерам скорость, практически сопоставимую с крупными централизованными биржами, при этом позволяя сохранять полный контроль над собственными средствами. </p>
  <p id="smdC">В этой статье  рассмотрим эту эволюцию, разберём, что действительно требуется профессиональным трейдерам, сравним ведущие современные платформы и рассмотрим реальные риски - например, убыток на Hyperliquid в марте 2025 года - чтобы показать, какие проблемы всё ещё остаются. </p>
  <p id="WCD0"><strong>Главный вывод прост</strong>: как только механизмы ценовых оракулов и риск-модели станут ещё немного совершеннее, децентрализованные биржи смогут конкурировать с централизованными площадками или даже превзойти их, не требуя от пользователей передачи контроля над своими ключами.</p>
  <h2 id="SfMO">Что такое деривативы и почему это важно?</h2>
  <p id="G7lP">Деривативы - финансовые инструменты, стоимость которых зависит от другого актива: биткоина, эфира, фондового индекса или даже показателя волатильности.</p>
  <p id="86Xn">Централизованные криптовалютные биржи - такие как Binance, OKX и Bybit - по-прежнему доминируют на рынке криптовалютных деривативов. На их долю приходится около <strong>95%</strong> всего объёма торговли производными инструментами на цифровые активы. Ежемесячно через них проходит от 3 до 4 триллионов долларов торгового оборота. Вся эта активность происходит внутри централизованных систем, которые контролируют пользовательские средства и требуют высокого уровня доверия со стороны клиентов.</p>
  <p id="NlXU">В криптовалютной индустрии основными инструментами являются фьючерсы и опционы. В профессиональных торговых портфелях они обычно используются совместно.</p>
  <h2 id="tAnk">Фьючерсы</h2>
  <p id="wAWm"><u><a href="https://ru.wikipedia.org/wiki/%D0%A4%D1%8C%D1%8E%D1%87%D0%B5%D1%80%D1%81" target="_blank">Фьючерсы</a></u> бывают двух основных видов.</p>
  <p id="6yL7">Срочный (<strong>dated</strong>) фьючерс имеет фиксированную дату исполнения. Если покупаете декабрьский BTC-фьючерс по цене $100 000, вы обязаны принять поставку актива (или произвести денежный расчёт) по этой цене в конце декабря.</p>
  <p id="363I">Бессрочный фьючерс (perpetual future, <strong>perp</strong>) гораздо популярнее на криптобиржах. Он не имеет даты экспирации, но каждые восемь часов между участниками выплачивается ставка финансирования (funding rate), которая удерживает цену контракта близкой к спотовой цене актива. Перпетуалы создают удобную иллюзию бесконечного плеча без необходимости регулярно переносить позиции на новые контракты.</p>
  <h2 id="adCJ">Опционы</h2>
  <p id="40va">Опционы обеспечивают большую гибкость, но и значительно сложнее в использовании:</p>
  <ul id="Oo2O">
    <li id="H9vk"><strong>Call-опцион</strong> даёт право (но не обязанность) купить актив по заранее установленной цене страйка до даты экспирации или в момент её наступления.</li>
    <li id="2mZC"><strong>Put-опцион</strong> даёт аналогичное право на продажу актива.</li>
  </ul>
  <p id="Cllp">Покупатель опциона выплачивает премию заранее и не может потерять больше этой суммы. Продавец опциона получает премию, но принимает на себя потенциально неограниченный риск.</p>
  <h3 id="wNgA">Греки: как измеряется риск опционов?</h3>
  <p id="eGV3">В отличие от линейных инструментов вроде фьючерсов, прибыль и убыток по опционам изменяются <strong>нелинейно</strong>. Поэтому для оценки поведения опционов используется специальный набор показателей - греки (<strong>Greeks</strong>).</p>
  <h3 id="QijG">Delta (Δ)</h3>
  <p id="DgaA">Показывает, насколько изменится цена опциона при изменении цены базового актива на один доллар. Если дельта равна 0,5, то опцион ведёт себя примерно как половина единицы базового актива.</p>
  <h3 id="lwiT">Gamma (Γ)</h3>
  <p id="NEJ6">Измеряет скорость изменения самой дельты. Гамма достигает максимума, когда опцион находится около денег (At-The-Money, ATM) - то есть когда цена страйка совпадает или почти совпадает с текущей рыночной ценой актива. Именно поэтому риск-системы бирж особенно внимательно следят за крупными страйками, около которых торгуется рынок.</p>
  <h3 id="htLJ">Vega (V)</h3>
  <p id="BNaX">Показывает, насколько изменится стоимость опциона при изменении подразумеваемой волатильности (Implied Volatility, IV). Чем выше ожидаемая рынком волатильность, тем дороже становятся опционы. Когда участники рынка нервничают и IV резко растёт, позиции с положительной вегой дорожают. Если же IV снижается, стоимость таких опционов уменьшается.</p>
  <h3 id="fhP6">Theta (Θ)</h3>
  <p id="yrIw">Это временной распад опциона. Каждый день часть стоимости опциона исчезает просто из-за приближения даты экспирации. Особенно быстро этот процесс ускоряется в последнюю неделю перед истечением контракта.</p>
  <h3 id="1r1n">Как выглядит прибыль по Call-опциону?</h3>
  <p id="X57g">График прибыли и убытка помогает интуитивно понять механику опциона.</p>
  <p id="obHG">В момент покупки call-опциона кривая P/L плавно растёт вверх - она отражает справедливую стоимость опциона за вычетом уплаченной премии.</p>
  <p id="PjPQ">К моменту экспирации формируется окончательная линия выплат:</p>
  <ul id="orWF">
    <li id="VVlt"><strong>убыток</strong> <strong>ограничен</strong> размером премии;</li>
    <li id="vMgf"><strong>прибыль</strong> <strong>начинает</strong> <strong>расти</strong> (доллар к доллару) выше страйка;</li>
    <li id="xnIF"><strong>точка пересечения линии прибыли</strong> с нулём является точкой безубыточности: Break-Even = Strike + Premium. </li>
  </ul>
  <p id="T4wH">Освоив эти базовые понятия, можно проследить, как первые ончейн-биржи пытались воспроизвести функциональность фьючерсов и опционов - и почему на первых этапах у них возникали серьёзные проблемы.</p>
  <h2 id="FDwC">DeFi догоняет централизованные биржи?</h2>
  <p id="cBQ5">Децентрализованные финансы стремительно сокращают отставание от CEX.</p>
  <p id="W4xA">Новые технологии блокчейнов = прежде всего:</p>
  <ul id="B4C4">
    <li id="e4tc">rollups;</li>
    <li id="Eszn">специализированные блокчейны первого уровня;</li>
    <li id="S3jY">доказательства с нулевым разглашением (ZK-proofs);</li>
  </ul>
  <p id="xQZV">сделали DEX-площадки значительно <strong>быстрее</strong>, <strong>дешевле</strong> и <strong>безопаснее</strong>.</p>
  <blockquote id="aPRJ">За последние 18 месяцев скорость исполнения транзакций выросла радикально: вместо подтверждений длиной в несколько секунд многие платформы теперь работают с задержками в пределах единиц миллисекунд, приближаясь к показателям централизованных бирж.</blockquote>
  <p id="E2VY">В этой статье рассмотрим:</p>
  <ul id="idFD">
    <li id="0fMn">как развивались DeFi-деривативы;</li>
    <li id="7cCK">в каком состоянии рынок находится сегодня;</li>
    <li id="xlbt">какие инновации могут изменить индустрию в ближайшем будущем.</li>
  </ul>
  <h2 id="mnym">1. Прошлое: первые попытки (2019–2021)</h2>
  <p id="5xRD">Первые ончейн-платформы для торговли деривативами - такие как <u><a href="https://v1.opyn.co/#/" target="_blank">Opyn v1</a></u>, <a href="http://www.hegic.co" target="_blank"><u>Hegic</u></a>, <a href="https://siren.xyz" target="_blank"><u>Siren</u></a>, <a href="https://github.com/perpetual-protocol/perpetual-protocol" target="_blank"><u>Perpetual Protocol v1</u></a> и <u><a href="https://dydx.community/dashboard" target="_blank">dYdX v3</a></u> - продемонстрировали потенциал DeFi.</p>
  <p id="IGBK">Они позволяли пользователям торговать опционами и бессрочными фьючерсами непосредственно в сети Ethereum, не передавая контроль над своими средствами третьим лицам.</p>
  <h2 id="6w40">Архитектура ранних проектов</h2>
  <h3 id="qVqo">Opyn v1</h3>
  <p id="j3D4">Использовал смарт-контракты Ethereum и пулы ликвидности на основе AMM для обеспечения ликвидности опционов. Поставщики ликвидности депонировали средства и фактически выступали продавцами опционов.</p>
  <h3 id="hnk8">Hegic и Siren</h3>
  <p id="Mikw">Работали через AMM-пулы опционов, где ликвидность предоставлялась коллективно, а трейдеры получали доступ к ней через общие хранилища ликвидности.</p>
  <h3 id="Gh7h">Perpetual Protocol v1</h3>
  <p id="0nap">Использовал виртуальные автоматизированные маркет-мейкеры (<strong>vAMM</strong>), которые моделировали ликвидность математически, без хранения реальных активов внутри пула.</p>
  <h3 id="CsQX">dYdX v3</h3>
  <p id="M0t8">Применял гибридную архитектуру: книга ордеров находилась вне блокчейна, а расчёты происходили ончейн. Такой подход позволял сохранить некастодиальный характер торговли.</p>
  <h3 id="cFl4">Основные проблемы ранних решений</h3>
  <p id="qlCU">Список:</p>
  <ol id="xQK5">
    <li id="1Qad"><strong>Высокие комиссии и медленные транзакции</strong>.  Из-за перегрузки Ethereum операции часто занимали от 10 до 20 секунд и более. Стоимость одной сделки могла превышать $20.</li>
    <li id="ddEP"><strong>Неэффективность залога</strong>.  Каждая торговая пара требовала отдельного обеспечения. Капитал, заблокированный под одну позицию, нельзя было использовать для компенсации риска в другой позиции, что существенно снижало эффективность использования средств.</li>
    <li id="UVeU"><strong>Гамма-риск для LP</strong>.  AMM-модели плохо справлялись с высокой волатильностью. При резких движениях рынка поставщики ликвидности могли быстро нести серьёзные убытки из-за дисбаланса между стоимостью проданных опционов и реальным движением цены.</li>
  </ol>
  <p id="UJvN">Все эти проблемы наглядно показали ограничения первых поколений DeFi-деривативов и обозначили направления, в которых индустрии необходимо было развиваться дальше.</p>
  <h2 id="8Cb4">2. Потребности профессиональных трейдеров</h2>
  <p id="9DEV">Профессиональный торговый деск редко просто открывает лонг или шорт по монете. Вместо этого он управляет целым набором взаимосвязанных позиций, которые позволяют тонко регулировать риск и максимально эффективно использовать капитал.</p>
  <h3 id="GepG">Дельта-хеджирование</h3>
  <p id="0AVR">Обычно трейдер удерживает спотовую позицию (или застейканный актив) и одновременно открывает противоположную позицию во фьючерсах.</p>
  <p id="N00X">В результате суммарная дельта портфеля оказывается близкой к нулю.</p>
  <p id="lKcl">Так можно получать:</p>
  <ul id="4Cv2">
    <li id="dkF8">доходность от стейкинга;</li>
    <li id="xPLE">funding rate;</li>
  </ul>
  <p id="vixf">при минимальной зависимости от краткосрочных колебаний цены.</p>
  <h3 id="AilK">Торговля волатильностью</h3>
  <p id="isBY">Трейдеры продают опционы, когда подразумеваемая волатильность выглядит завышенной. Если фактические движения рынка оказываются слабее ожидаемых, опционы выкупаются обратно дешевле. Дополнительно используется gamma scalping - активная торговля базовым активом для извлечения прибыли из небольших внутридневных колебаний.</p>
  <h3 id="jHT8">Risk-Reversal и торговля перекосом волатильности</h3>
  <p id="2Law">Для умеренно бычьих ожиданий можно:</p>
  <ul id="v9Vc">
    <li id="i5md">купить call;</li>
    <li id="58Ma">продать put.</li>
  </ul>
  <p id="8mgu">Для умеренно медвежьих - наоборот.</p>
  <p id="1aMh">Такие конструкции позволяют выразить рыночный взгляд с контролируемым уровнем риска.</p>
  <h3 id="l4If">Структурные продукты</h3>
  <p id="BnrP">Профессиональные участники создают более сложные комбинации:</p>
  <ul id="RaS5">
    <li id="0r4I">лестницы (<strong>ladders</strong>);</li>
    <li id="4cEw">календарные <strong>спреды</strong>;</li>
    <li id="GdIU">power-<strong>perpetuals</strong>;</li>
    <li id="Z9W0">другие <strong>многокомпонентные</strong> конструкции.</li>
  </ul>
  <p id="oF8J">Цель - точно настроить профиль доходности под конкретный рыночный сценарий.</p>
  <h3 id="m1tz">Что требуется от инфраструктуры биржи?</h3>
  <p id="Zlfv">Для реализации подобных стратегий профессионалам необходимы три обязательных свойства:</p>
  <ol id="VlcA">
    <li id="vzfs"><strong>Минимальная задержка</strong>. Латентность должна быть менее 10 миллисекунд. Даже небольшое запаздывание хеджирующей сделки способно полностью уничтожить прибыль от стратегии торговли волатильностью. Поэтому профессиональные участники размещают свои системы максимально близко к серверам биржи.</li>
    <li id="Dx9l">Единый пул обеспечения.  Залог не должен быть разрознен по отдельным продуктам. Прибыль по одной позиции должна мгновенно становиться доступной для использования в другой. Один баланс USDC должен одновременно использоваться для:</li>
    <ol id="O5mR">
      <li id="WIZJ">спота;</li>
      <li id="Ps2t">бессрочных контрактов;</li>
      <li id="7a10">опционов.</li>
    </ol>
    <li id="X9BR"><strong>Надёжный риск-движок</strong>. Даже если одна сторона сделки терпит крах, биржа обязана выполнить обязательства перед выигравшей стороной. Централизованные биржи решают эту задачу через:</li>
    <ol id="a8Ef">
      <li id="qHZ9">страховые фонды;</li>
      <li id="moth">автоматическую ликвидацию;</li>
      <li id="KpDI">мониторинг риска в реальном времени.</li>
    </ol>
  </ol>
  <p id="X03e">DEX-платформы пытаются добиться аналогичного уровня надёжности за счёт прозрачных ончейн-доказательств, автоматизированных механизмов риск-менеджмента и полностью проверяемых расчётов.</p>
  <h2 id="pFHE">3. Торговля опционами: риск-движки и архитектура</h2>
  <p id="i2gG">Опционы позволяют создавать гораздо более сложные профили риска, чем линейные фьючерсы, однако именно поэтому они заставляют биржи решать задачи нелинейной математики и поддерживать значительно более сложную инфраструктуру.</p>
  <p id="DJNh">Современная DEX должна уметь:</p>
  <ul id="VP7O">
    <li id="48FO"><strong>оценивать</strong> стоимость тысяч опционных контрактов;</li>
    <li id="fp2C"><strong>рассчитывать</strong> маржу;</li>
    <li id="Yc1a"><strong>проводить</strong> расчёты и экспирацию;</li>
    <li id="7vqn"><strong>поддерживать</strong> десятки сроков истечения и тысячи страйков;</li>
    <li id="IbiS"><strong>обеспечивать</strong> задержку, близкую к уровню централизованных бирж.</li>
  </ul>
  <p id="eDOv">Ниже рассмотрим основные инженерные компромиссы - от логики расчёта маржи до стоимости криптографических доказательств - и покажем, почему один-единственный опцион способен обрушить риск-систему, которая прекрасно справлялась с бессрочными фьючерсами.</p>
  <h3 id="Q9oV">3.1 Почему опционы нагружают единую маржинальную систему?</h3>
  <blockquote id="MWWo">Фьючерс - линейный инструмент. Каждое изменение цены базового актива на один доллар вызывает практически одинаковое изменение прибыли или убытка позиции. </blockquote>
  <p id="IHdw"><strong>С опционами</strong> всё иначе. Здесь кривая прибыли становится <strong>нелинейной</strong>:</p>
  <ul id="6phD">
    <li id="sCdT"><strong>дельта</strong> изменяется вместе с ценой;</li>
    <li id="NXne"><strong>гамма</strong> ускоряет изменение дельты;</li>
    <li id="0y5C"><strong>вега</strong> увеличивает или уменьшает стоимость опциона вслед за изменением волатильности.</li>
  </ul>
  <p id="KcZm">Как только биржа разрешает держать опционы и фьючерсы в одном аккаунте, риск-движок больше не может ограничиваться расчётом по одной текущей цене актива. Он вынужден моделировать множество сценариев.</p>
  <p id="dAH6">Например, короткий call на ETH со страйком $3000 и экспирацией 25 июня может выглядеть практически безрисковым утром понедельника. Но если ETH резко вырастет к обеду, опцион быстро приблизится к состоянию в деньгах (<strong>ITM</strong>), а значения гаммы и требуемой маржи могут вырасти практически вертикально.</p>
  <h3 id="lrp5">Кросс-маржинальность между продуктами</h3>
  <p id="XUTC">Дополнительную сложность создаёт объединение разных продуктов в одной маржинальной корзине. Представим:</p>
  <ul id="Et1l">
    <li id="epSO">трейдер продал call;</li>
    <li id="VRCn">одновременно открыл длинную позицию по perpetual-фьючерсу.</li>
  </ul>
  <p id="m0QN">С точки зрения риска эти позиции частично компенсируют друг друга.</p>
  <p id="K4mb">Поэтому биржа должна учитывать суммарную дельту портфеля и начислять обеспечение только на остаточный риск.</p>
  <p id="AhOL">Такой механизм требует:</p>
  <ul id="Pgrk">
    <li id="qeD3">потоковых оракулов в реальном времени;</li>
    <li id="u8qw">непрерывного пересчёта стоимости портфеля;</li>
    <li id="iyi1">оценки волатильности;</li>
    <li id="0fXV">скорости расчётов, сравнимой со скоростью изменения рынка.</li>
  </ul>
  <h3 id="RE0F">3.2 Где начинает расти объём данных</h3>
  <p id="pbqm">DEX с книгой ордеров сталкиваются с ещё одной проблемой - хранением состояния. Каждая комбинация:<strong> страйк × дата экспирации</strong> - обычно требует отдельной книги ордеров.</p>
  <p id="eSbB">Если взять:</p>
  <ul id="8foC">
    <li id="jRy3">40 дат экспирации;</li>
    <li id="QGI0">100 страйков;</li>
  </ul>
  <p id="8jmY">для BTC и ETH, то получится уже: 40 × 100 = 4000 книг ордеров.</p>
  <p id="tB1n">Добавим:</p>
  <ul id="AgmF">
    <li id="zU0B">Solana;</li>
    <li id="IcoV">мемкоины;</li>
    <li id="B6qE">недельные экспирации;</li>
  </ul>
  <p id="fwyu">и валидаторам придётся записывать мегабайты данных каждые несколько минут.</p>
  <h3 id="vf1o">AMM-подход</h3>
  <p id="fYld">AMM-модели избегают хранения огромного числа книг ордеров. Но цена этого решения проявляется позже. Вместо хранения заявок протокол вынужден постоянно пересчитывать:</p>
  <ul id="hEar">
    <li id="0TPc">кривые ценообразования;</li>
    <li id="fxfr">гамма-риск;</li>
    <li id="8pTu">распределение ликвидности.</li>
  </ul>
  <p id="Dh4L">Каждая сделка вызывает дорогостоящие вычисления, особенно в периоды роста комиссий сети.</p>
  <h3 id="gYps">Проблема котирования через IV</h3>
  <p id="9OQZ">Некоторые централизованные биржи, например Bybit, отображают опционы не через цену, а через подразумеваемую волатильность (IV). Для трейдеров это удобно. Но на блокчейне это превращается в дополнительную вычислительную нагрузку. Смарт-контракт должен:</p>
  <ul id="sy6i">
    <li id="9ac5">перевести IV в премию по модели <a href="https://en.wikipedia.org/wiki/Black%E2%80%93Scholes_model" target="_blank">Black-Scholes</a>;</li>
    <li id="BcSu">сделать это непосредственно во время исполнения сделки;</li>
    <li id="Bjx4">либо довериться внешнему сервису расчёта, что создаёт риск расхождения цен.</li>
  </ul>
  <h3 id="vJJg">3.3 Расчёты и экспирация: срочные и бессрочные опционы</h3>
  <p id="RovR">Европейские опционы. Классические европейские опционы требуют наличия:</p>
  <ul id="PcQy">
    <li id="Kwe7"><strong>таймера</strong> до экспирации;</li>
    <li id="316n"><strong>механизма</strong> исполнения;</li>
    <li id="xf1c"><strong>окна</strong> для расчётов;</li>
    <li id="xGYD">надёжного ценового <strong>оракула</strong>.</li>
  </ul>
  <p id="gmEQ">После наступления даты экспирации необходимо определить финальную цену актива и провести расчёты между сторонами.</p>
  <h3 id="hrKo">Бессрочные опционы</h3>
  <p id="4kWM">Новую концепцию предложила биржа <u><a href="https://www.paradex.trade" target="_blank">Paradex</a></u> - бессрочные опционы (Perpetual Options). Здесь отсутствует фиксированная дата истечения. Вместо временного распада используется постоянный funding-механизм.</p>
  <p id="fTxP">Преимущества:</p>
  <ul id="3jLs">
    <li id="QHQv">меньшее количество состояния в системе;</li>
    <li id="fv7Y">отсутствие сложной логики экспирации;</li>
    <li id="1bLR">более простой жизненный цикл позиции.</li>
  </ul>
  <p id="razL">Недостаток заключается в том, что нагрузка переносится на механизм финансирования. Оракул должен непрерывно вычислять справедливую стоимость опциона и корректно отражать временную стоимость через funding rate.</p>
  <h3 id="D9Hp">Почему профессионалы пока осторожны?</h3>
  <p id="0c1r">Для большинства профессиональных трейдеров бессрочные опционы остаются экзотикой. Причина проста:</p>
  <ul id="oB4p">
    <li id="PP1l"><strong>риск-модели строились под европейские опционы;</strong></li>
    <li id="CJMN">системы оценки портфеля ориентированы на фиксированные экспирации;</li>
    <li id="rwAu">интерфейсы греков рассчитаны именно на классические опционы.</li>
  </ul>
  <p id="NE04">Поэтому переход на perpetual-options требует:</p>
  <ul id="bpqX">
    <li id="RILi">адаптации риск-систем;</li>
    <li id="r8zD">изменения моделей оценки;</li>
    <li id="t7Tq">переобучения трейдеров.</li>
  </ul>
  <h3 id="Irl9">3.4 Нагрузка на доказательства и пределы производительности</h3>
  <p id="Ukqp">Для zk-rollup-систем возникает дополнительная проблема. Каждый новый параметр риска увеличивает размер вычислительной схемы (<strong>zk-circuit</strong>).</p>
  <p id="wUEq">Добавление расчётов:</p>
  <ul id="pp41">
    <li id="9Rx0">дельты;</li>
    <li id="PiRU">гаммы;</li>
    <li id="4SQF">веги;</li>
    <li id="q2kc">маржи;</li>
  </ul>
  <p id="fbLK">увеличивает количество ограничений внутри доказательства.</p>
  <p id="k0bo">По словам разработчиков Lighter, поддержка:</p>
  <ul id="9qYx">
    <li id="8Io8">приоритета исполнения по цене и времени (price-time priority);</li>
    <li id="xp6C">маржинальных расчётов с учётом гаммы;</li>
  </ul>
  <p id="OD4X">почти удваивает размер вычислительной схемы.</p>
  <p id="ItPU">Optimistic-rollup же подход позволяет избежать затрат на генерацию доказательств. Однако возникает другая проблема. Для вывода средств требуется период оспаривания - обычно около семи дней. Для опционной торговли это огромный срок. На рынке, где стоимость контракта может полностью исчезнуть за несколько часов до экспирации, недельная задержка выглядит практически вечностью.</p>
  <h3 id="G2Bz">3.5 Ландшафт факторов риска</h3>
  <p id="URLu">Перед тем как переходить к формулам расчёта маржи, полезно зафиксировать ключевые источники риска для различных типов инструментов. Именно здесь становится очевидно, почему опционы значительно сложнее фьючерсов.</p>
  <p id="ChNb">Для бессрочного фьючерса риск-система в основном отслеживает:</p>
  <ul id="oDWV">
    <li id="SJFl">дельту;</li>
    <li id="DZ4U">ликвидационную цену;</li>
    <li id="nOrB">кредитный риск контрагента.</li>
  </ul>
  <p id="Vy5t">Для опционов дополнительно приходится учитывать:</p>
  <ul id="Twl4">
    <li id="pds0">гамму;</li>
    <li id="Jy8W">вегу;</li>
    <li id="9pOX">тету;</li>
    <li id="jo2L">временную структуру волатильности;</li>
    <li id="qVMe">распределение страйков;</li>
    <li id="ddD1">корреляции между сериями опционов.</li>
  </ul>
  <p id="uJKG">Именно поэтому риск-движок для опционов вынужден анализировать гораздо больше параметров, чем система для обычных perpetual-контрактов:</p>
  <figure id="7g0H" class="m_column">
    <img src="https://img1.teletype.in/files/c0/b7/c0b7340e-c3fe-424c-8b56-e3b96deb0fc5.png" width="1542" />
    <figcaption>Греки</figcaption>
  </figure>
  <h3 id="eD6z">Интуитивное понимание греков</h3>
  <p id="ru55">Списком:</p>
  <ul id="2ezs">
    <li id="4wbd"><strong>Дельта</strong> - рулевое колесо. Она показывает, в каком направлении направлена позиция.</li>
    <li id="M8Ni"><strong>Гамма</strong> - педаль газа. Она показывает, насколько быстро это направление может измениться.</li>
    <li id="Me7K"><strong>Вега</strong> - погода. Она отражает влияние изменения волатильности на стоимость позиции.</li>
    <li id="ugzu"><strong>Тета</strong> - ржавчина. Она символизирует постепенную потерю стоимости с течением времени.</li>
  </ul>
  <blockquote id="6OKd">Надёжный риск-движок должен отслеживать все четыре показателя одновременно, чтобы понимать, в какой момент запас маржи трейдера может внезапно исчезнуть.</blockquote>
  <h3 id="wbve">3.6 Методологии расчёта маржи на практике</h3>
  <p id="gI7G">Большинство DEX сегодня используют один из трёх основных подходов:</p>
  <ol id="cxmB">
    <li id="DG9t"><strong>SPAN-подобные модели</strong>. Методология SPAN (Standard Portfolio Analysis of Risk) моделирует различные сценарии изменения цены и волатильности, рассчитывая потенциальные убытки портфеля. В качестве начальной маржи принимается наихудший результат из набора сценариев. Это классический инструмент традиционных финансов, который хорошо переносится в блокчейн благодаря возможности использовать заранее подготовленные таблицы значений.</li>
    <li id="5yDL"><strong>Аналитические модели Black-Scholes</strong>. Модель Black-Scholes обеспечивает высокую математическую точность и считается академическим стандартом оценки опционов. Однако для блокчейна она слишком затратна (поэтому на практике такие вычисления обычно выполняются вне блокчейна):</li>
    <ol id="lYZk">
      <li id="Tevk">требует большого объёма вычислений;</li>
      <li id="X2kf">существенно увеличивает потребление газа;</li>
      <li id="eirr">усложняет генерацию криптографических доказательств.</li>
    </ol>
    <li id="rwkM"><strong>Гибрид VaR + Stress Testing</strong>. Третий подход объединяет:</li>
    <ol id="FI7e">
      <li id="7O3v">Value-at-Risk (<strong>VaR</strong>) - статистическую оценку возможных убытков;</li>
      <li id="RJZu">стресс-тестирование - моделирование экстремальных рыночных сценариев.</li>
    </ol>
  </ol>
  <p id="5JC9">Такой гибрид позволяет уменьшить вычислительную нагрузку, сохраняя защиту от редких, но разрушительных событий.</p>
  <h3 id="6wgr">Почему Black–Scholes тяжело реализовать ончейн?</h3>
  <p id="kcYx">Язык Solidity не имеет встроенной поддержки многих математических функций:</p>
  <ul id="NAZq">
    <li id="hNp0">логарифмов;</li>
    <li id="JycW">экспонент;</li>
    <li id="msr3">нормального распределения (CDF).</li>
  </ul>
  <p id="Wr8s">Из-за этого полноценный расчёт по Black–Scholes может потреблять: 30–50 тысяч газа на один страйк. </p>
  <p id="xHiT">Для zk-систем ситуация ещё сложнее. Каждая трансцендентная функция превращается в сотни дополнительных ограничений внутри zk-схемы (circuit).</p>
  <p id="z1oG">Поэтому большинство команд сегодня используют следующий подход:</p>
  <ol id="BmIk">
    <li id="tmUR">Рассчитывают коэффициенты маржи вне блокчейна.</li>
    <li id="Jwzq">Формируют таблицы или хэши значений.</li>
    <li id="OHIs">Передают их в смарт-контракты для дальнейшего использования.</li>
  </ol>
  <p id="EhLj">Так достигается баланс между точностью и производительностью.</p>
  <h3 id="yOfK">3.7 Уровни защиты позиций</h3>
  <p id="6FzN">Ликвидация является первой линией обороны любой деривативной платформы. Как только обеспечение пользователя опускается ниже уровня поддерживающей маржи (Maintenance Margin), специальный бот начинает сокращать позицию. В идеальном случае закрывается только необходимая часть позиции, а не весь объём сразу.</p>
  <h3 id="QDeJ">Страховой фонд</h3>
  <p id="j7lh">Следующий уровень защиты - страховой фонд. Обычно он формируется за счёт:</p>
  <ul id="88k8">
    <li id="lIFP">торговых комиссий;</li>
    <li id="s8nh">части доходов протокола;</li>
    <li id="2ec4">дополнительных стратегий хеджирования.</li>
  </ul>
  <p id="AyIF">Некоторые площадки дополнительно покупают опционы глубоко вне денег (OTM), чтобы защититься от экстремальных рыночных событий.</p>
  <h3 id="1rfF">Auto-Deleveraging (ADL)</h3>
  <p id="Ht5A">Если ликвидации и страхового фонда оказывается недостаточно, некоторые протоколы активируют механизм автоматического сокращения плеча (Auto-Deleveraging, ADL). В этом случае система может принудительно закрывать или уменьшать наиболее прибыльные позиции других трейдеров, чтобы покрыть образовавшийся дефицит. По сути, прибыль части участников используется для стабилизации системы.</p>
  <h3 id="wgp2">Socialized PnL</h3>
  <p id="raEA">Последний уровень защиты применяется крайне редко. Это механизм социализации убытков (Socialized PnL). Если после всех предыдущих мер дефицит всё ещё сохраняется, остаточный убыток распределяется между всеми участниками платформы. Фактически пользователи коллективно покрывают хвостовой риск системы.</p>
  <h3 id="l3Hf">Итог</h3>
  <p id="msx6">Если все перечисленные механизмы реализованы корректно, DEX для торговли деривативами способен пережить:</p>
  <ul id="twZt">
    <li id="gnaE">ошибочную оценку подразумеваемой волатильности;</li>
    <li id="hubH">резкий всплеск IV;</li>
    <li id="Mo2G">флэш-крэш;</li>
    <li id="oyU9">цепочку ликвидаций;</li>
  </ul>
  <p id="hpva">не перекладывая издержки на добросовестных пользователей, которые соблюдали правила управления рисками и поддерживали достаточный уровень обеспечения.</p>
  <h2 id="JMlT">4. Настоящее: Rollups и zk-CLOB (2022–2024)</h2>
  <blockquote id="G5MN">После того как платформы первого поколения столкнулись с проблемами медленного подтверждения транзакций, разрозненного обеспечения и неуправляемого гамма-риска, современные решения для DeFi-деривативов начали использовать rollup-технологии второго уровня, специализированные блокчейны первого уровня и доказательства с нулевым разглашением (Zero-Knowledge Proofs), чтобы устранить эти недостатки.</blockquote>
  <h3 id="EpAu">Layer-2 Rollups и специализированные L1</h3>
  <p id="ueMg">Транзакции обрабатываются и агрегируются вне основного блокчейна, после чего в Ethereum или специализированный слой расчётов отправляется лишь компактное обновление состояния.</p>
  <p id="XMsW">Такой подход позволяет:</p>
  <ul id="1vPs">
    <li id="Csfs">значительно <strong>снизить</strong> комиссии;</li>
    <li id="Kfuz"><strong>уменьшить</strong> задержки исполнения;</li>
    <li id="s1DD"><strong>увеличить</strong> пропускную способность системы.</li>
  </ul>
  <h3 id="sxkd">Гибридное сопоставление ордеров</h3>
  <p id="Ukrv">Современные платформы часто используют гибридную архитектуру. Централизованная книга лимитных ордеров (Central Limit Order Book, CLOB) работает вне блокчейна, обеспечивая:</p>
  <ul id="O398">
    <li id="tYy3">глубокую ликвидность;</li>
    <li id="utxZ">быстрое сопоставление заявок;</li>
    <li id="JoTE">привычный трейдерам интерфейс.</li>
  </ul>
  <p id="XsHr">После исполнения сделки расчёты проводятся ончейн, что сохраняет:</p>
  <ul id="Zfsg">
    <li id="zERg">самостоятельное хранение средств (self-custody);</li>
    <li id="K6Xp">прозрачность;</li>
    <li id="DaF0">возможность аудита.</li>
  </ul>
  <h3 id="BEiH">Единая кросс-маржинальная система</h3>
  <p id="bber">Обеспечение пользователей объединяется в единый пул. Это позволяет взаимно компенсировать риски по различным инструментам:</p>
  <ul id="bwAE">
    <li id="uzuj">дельту;</li>
    <li id="eVRv">гамму;</li>
    <li id="3rKd">вегу;</li>
  </ul>
  <p id="gDuV">между:</p>
  <ul id="eAfB">
    <li id="7TH3">бессрочными фьючерсами;</li>
    <li id="D3Or">опционами;</li>
    <li id="bZ55">другими производными инструментами.</li>
  </ul>
  <p id="ht2O">В результате эффективность использования капитала возрастает примерно на 30–50% по сравнению с изолированной маржой.</p>
  <h3 id="NhSt">Доказательства исполнения на базе Zero-Knowledge</h3>
  <p id="CQO8">Для подтверждения корректности торгов используются:</p>
  <ul id="sxbL">
    <li id="cDgt">zk-rollups;</li>
    <li id="o9mG">validity proofs;</li>
    <li id="vIrc">другие виды криптографических доказательств.</li>
  </ul>
  <p id="Quz8">Они позволяют гарантировать:</p>
  <ul id="cj6L">
    <li id="GicZ">правильность исполнения сделок;</li>
    <li id="Unhc">целостность системы;</li>
    <li id="NKoQ">дополнительную конфиденциальность пользователей;</li>
  </ul>
  <p id="yesj">без необходимости хранить большие объёмы данных непосредственно в блокчейне и без существенного ухудшения производительности.</p>
  <h3 id="7jWV">Архитектура DEX на базе Layer 2</h3>
  <p id="VnwU">Современная архитектура DeFi-биржи с деривативами обычно выглядит следующим образом:</p>
  <p id="ECG9"><strong>1. Пользователь</strong></p>
  <ul id="xTlv">
    <li id="bklf">отправляет ордер через интерфейс биржи;</li>
    <li id="F6FP">средства остаются под его контролем.</li>
  </ul>
  <p id="VVif">↓</p>
  <p id="XONz"><strong>2. Off-chain Matching Engine</strong></p>
  <ul id="mu9i">
    <li id="Avbk">принимает заявки;</li>
    <li id="bVi7">ведёт книгу ордеров (CLOB);</li>
    <li id="kkf2">сопоставляет покупателей и продавцов за миллисекунды.</li>
  </ul>
  <p id="bjOG">↓</p>
  <p id="xplt"><strong>3. Risk Engine</strong></p>
  <ul id="FTNi">
    <li id="FkAx">рассчитывает:</li>
    <ul id="0BdL">
      <li id="I4cE">маржу;</li>
      <li id="E8X5">дельту;</li>
      <li id="t1jS">гамму;</li>
      <li id="QPv0">вегу;</li>
      <li id="d8Br">риск ликвидации.</li>
    </ul>
  </ul>
  <p id="UMLq">↓</p>
  <p id="Q6NS"><strong>4. Layer-2 Rollup</strong></p>
  <ul id="kRfn">
    <li id="jnUo">агрегирует множество сделок;</li>
    <li id="JTGf">формирует пакет изменений состояния;</li>
    <li id="zvGw">создаёт криптографическое доказательство.</li>
  </ul>
  <p id="fNNQ">↓</p>
  <p id="IXVR"><strong>5. Settlement Layer</strong></p>
  <ul id="0NGk">
    <li id="sgnt">Ethereum;</li>
    <li id="W2MV">специализированный L1;</li>
    <li id="rIsj">модуль расчётов.</li>
  </ul>
  <p id="U1LE">Здесь происходит финальная фиксация состояния.</p>
  <p id="ABWY">↓</p>
  <p id="p0Nz"><strong>6. Смарт-контракты хранения активов</strong></p>
  <ul id="W6SO">
    <li id="96RM">обеспечивают самостоятельное владение средствами;</li>
    <li id="7giU">выполняют расчёты;</li>
    <li id="ogLS">управляют ликвидациями и страховыми фондами.</li>
  </ul>
  <p id="hJ2m">По сути, современный DeFi-деривативный протокол стремится объединить:</p>
  <ul id="aE68">
    <li id="MTnb">скорость Binance или Bybit;</li>
    <li id="OTpw">прозрачность блокчейна;</li>
    <li id="pvs0">самостоятельное хранение средств как у Ethereum-кошелька.</li>
  </ul>
  <p id="YOCm">Именно это сочетание стало главным направлением развития рынка деривативов в 2022–2024 годах.</p>
  <figure id="vo2s" class="m_column">
    <img src="https://img1.teletype.in/files/c5/62/c562bfc5-6c73-4b10-88a8-9dd7a5522879.png" width="1624" />
    <figcaption>Схема №01</figcaption>
  </figure>
  <p id="YYZA">Типовая архитектура децентрализованной биржи (DEX), построенной на собственном блокчейне первого уровня (Custom Layer-1):</p>
  <figure id="QwM6" class="m_column">
    <img src="https://img2.teletype.in/files/50/2f/502f8d92-cd16-4856-8b56-54742ba7f401.png" width="1693" />
    <figcaption>Схема №02</figcaption>
  </figure>
  <h3 id="eCpZ">4.1 Платформы лидеры</h3>
  <p id="h82j">Списком:</p>
  <ul id="WxIA">
    <li id="JhRi"><strong>Paradex</strong>:</li>
    <ul id="BgQK">
      <li id="qPNh"><strong>Архитектура</strong>: ZK-роллап (Starknet zk‑rollup);</li>
      <li id="Hwev"><strong>Воркфлоу</strong> (структурированная последовательность шагов и задач, необходимых для достижения бизнес-цели): Ethereum Off‑chain CLOB, on‑chain batch settlement, cross-margin;</li>
      <li id="p5WY"><strong>Пропускная способност</strong>ь: ок. 200 ms (sequencer);</li>
      <li id="bajy"><strong>Безопасность</strong>: ZK-доказательства (zk‑STARK proofs), не кастодиальные ключи (non‑custodial keys), аудируемость (audited);</li>
      <li id="ig3P"><strong>Децентрализация</strong>: Секвенсор (Single sequencer), Ethereum L1 securit;</li>
    </ul>
    <li id="husH"><strong>Zeta / Bullet</strong>:</li>
    <ul id="Cfxp">
      <li id="juiV"><strong>Архитектура</strong>: Solana (L1);</li>
      <li id="XtCq"><strong>Воркфлоу</strong>: Оптимистичный ролла (Bullet optimistic roll‑up Off‑chain CLOB), ончейн-портфолио (on‑chain portfolio margin);</li>
      <li id="Na8w"><strong>Пропускная</strong> <strong>способность</strong>: 2-5 ms (round‑trip);</li>
      <li id="ZK8f"><strong>Безопасность</strong>: Solana SPL custody, ончейн-доказательства (on‑chain proofs);</li>
      <li id="ktSu"><strong>Децентрализация</strong>: Централизованный секвенсор (centralized sequencer);</li>
    </ul>
    <li id="0bqB"><strong>Backpack</strong>:</li>
    <ul id="tggv">
      <li id="ZvNt"><strong>Архитектура</strong>: Приватный чейн на Solana (Private mini‑chain + Solana PoR);</li>
      <li id="oexX"><strong>Воркфлоу</strong>: Полностью централизованный ордер-бук (Fully centralized order book);</li>
      <li id="qYfD"><strong>Пропускная способность</strong>: &lt;10 ms (CEX‑level);</li>
      <li id="W0zu"><strong>Безопасность</strong>: Кастодиальность (Custodial, daily zk‑PoR, KYC)ж</li>
      <li id="anCS"><strong>Децентрализация</strong>: Нет (Fully centralized);</li>
    </ul>
    <li id="ZgEB"><strong>Derive</strong>:</li>
    <ul id="lXiM">
      <li id="zUCI"><strong>Архитектура</strong>: Оптимистичный роллап (OP‑Stack roll-up);</li>
      <li id="bRVP"><strong>Воркфлоу</strong>: Ethereum Off‑chain CLOB, on‑chain settlement, cross-margin;</li>
      <li id="MEsX"><strong>Пропускная способность</strong>: 100-200 ms, о. 10 000 TPS;</li>
      <li id="Jxwk"><strong>Безопасность</strong>: L2 (smart-contract custody, fraud proofs);</li>
      <li id="Ttr1"><strong>Децентрализация</strong>: секвенсор (Single sequencer), ДАО (DAO governance);</li>
    </ul>
    <li id="ivSB"><strong>Syndr</strong>:</li>
    <ul id="VwiY">
      <li id="Fl6E"><strong>Архитектура</strong>: L3 (Arbitrum Orbit L3);</li>
      <li id="ep6O"><strong>Воркфлоу</strong>: Off‑chain CLOB, on‑chain SPAN margin;</li>
      <li id="Ib3T"><strong>Пропускная</strong> <strong>способность</strong>: &lt;100 ms, нулевой газ (zero gas fees);</li>
      <li id="vgf1"><strong>Безопасность</strong>: Через Арбитрум (Inherits Arbitrum security, SPAN grid);</li>
      <li id="jilJ"><strong>Децентрализация</strong>: Секвенсор (Single sequencer), ДАО (DAO governance);</li>
    </ul>
    <li id="B3is"><strong>Hyperliquid</strong>:</li>
    <ul id="h4Sf">
      <li id="VWpT"><strong>Архитектура</strong>: Cosmos‑SDK L1 (HyperBFT);</li>
      <li id="Q9jo"><strong>Воркфлоу</strong>: Fully on‑chain CLOB;</li>
      <li id="YnXy"><strong>Пропускная</strong> <strong>способность</strong>: 20 000 orders/s, ок. 200 ms (медиана);</li>
      <li id="h7xr"><strong>Безопасность</strong>: Валидаторы (PoS validators), Не кастодиальность (self‑custody), Страхование (insurance);</li>
      <li id="WC2T"><strong>Децентрализация</strong>: Валидаторы (Permissioned validators);</li>
    </ul>
    <li id="Sok9"><strong>Ostium</strong>:</li>
    <ul id="BYIu">
      <li id="NlAh"><strong>Архитектура</strong>: Arbitrum One L2;</li>
      <li id="tdZM"><strong>Воркфлоу</strong>: Off‑chain CLOB, on‑chain CFD contracts;</li>
      <li id="bLYj"><strong>Пропускная</strong> <strong>способность</strong>: ≤200 ms, &gt;7 000 orders/s;</li>
      <li id="ZBIJ"><strong>Безопасность</strong>: Non‑custodial L2 contracts, fraud proofs;</li>
      <li id="R0Ny"><strong>Децентрализация</strong>: Single sequencer, DAO roadmap;</li>
    </ul>
    <li id="vTa5"><strong>Lighter</strong>:</li>
    <ul id="4a3T">
      <li id="zWcg"><strong>Архитектура</strong>: zkLighter app‑specific zk‑rollup;</li>
      <li id="csOU"><strong>Воркфлоу</strong>: Fully on‑chain CLOB with zk-proofs;</li>
      <li id="8z5Q"><strong>Пропускная</strong> <strong>способность</strong>: &lt;5 ms, ≥10 000 orders/s;</li>
      <li id="ypgy"><strong>Безопасность</strong>: Validity proofs, calldata on Ethereum;</li>
      <li id="QRtT"><strong>Децентрализация</strong>: Central sequencer, zk-integrity.</li>
    </ul>
  </ul>
  <p id="rpEI">В эту эпоху платформы DeFi-деривативов добились значительного прогресса, используя различные архитектурные подходы для поиска баланса между скоростью работы, безопасностью и децентрализацией.</p>
  <p id="92gU"><strong>Paradex</strong> демонстрирует возможности zk-rollup-технологий, сочетая сопоставление ордеров вне блокчейна с ончейн-верификацией и достигая финальности примерно за 200 мс.</p>
  <p id="564N"> <strong>Lighter</strong> доводит скорость ончейн-торговли до менее чем 5 мс благодаря параллельной генерации zk-доказательств, конкурируя с централизованными механизмами матчинга.</p>
  <p id="aY48"><strong>Bullet</strong> и <strong>Backpack</strong> делают ставку на максимальную производительность, жертвуя частью децентрализации ради задержек, близких к централизованным биржам.</p>
  <p id="tj9t"><strong>Hyperliquid</strong> и <strong>Ostium</strong> демонстрируют соответственно полностью ончейн- и гибридный подходы, обменивая часть скорости на полный контроль пользователей над своими средствами.</p>
  <p id="olBH">Чтобы лучше понять достигнутый прогресс, полезно сравнить современные DEX с ведущими централизованными биржами.</p>
  <h3 id="LtiY">4.2 Сравнение производительности CEX и DEX</h3>
  <p id="VF4B">Централизованные биржи по-прежнему остаются эталоном скорости, однако лучшие ончейн-движки уже не отстают на порядок величины. На Binance механизм сопоставления ордеров обрабатывает сделки примерно за 5 мс процессорного времени, а маркет-мейкеры, разместившие свои серверы рядом с биржей (colocation), получают полный цикл запроса и ответа за 1–10 мс. Пропускная способность превышает один миллион ордеров в секунду, если учитывать внутреннее распределение нагрузки.</p>
  <blockquote id="tPdK">Архитектура zk-rollup у Lighter уже приближается к этим показателям.</blockquote>
  <p id="gWyu">Сделка, отправленная в тестовый секвенсор во Франкфурте, обычно получает предварительное подтверждение через 5-15 мс и окончательно фиксируется в блокчейне менее чем за секунду. Само сопоставление ордеров занимает менее 5 мс, поскольку zk-доказательство строится параллельно и не входит в критический путь исполнения. Пропускная способность пока ниже - от 10 000 до 50 000 ордеров в секунду, однако этого достаточно для большинства направленных и базисных стратегий.</p>
  <p id="H9kf"><strong>Hyperliquid</strong> использует полностью ончейн-подход, соглашаясь на задержку подтверждения более 100 мс в обмен на мгновенную финальность внутри собственной сети на базе Cosmos SDK. Средний сетевой цикл составляет 150-250 мс с учётом распределённых валидаторов по всему миру.</p>
  <p id="PbxU">Благодаря высокооптимизированному консенсусу HyperBFT система всё равно способна обрабатывать около 100 000-200 000 ордеров в секунду, однако стратегии микроскопического арбитража, характерные для CEX, здесь уже невозможны. Вывод очевиден.</p>
  <blockquote id="n0hk">Binance остаётся своего рода суперкомпьютером для обработки ордеров.</blockquote>
  <p id="IREr">Однако Lighter показывает, что благодаря грамотному пакетированию транзакций и параллельным доказательствам DEX способен обеспечить ощущения, близкие к централизованной бирже, сохраняя при этом самостоятельное хранение средств.</p>
  <p id="p9Bu">Hyperliquid демонстрирует противоположный конец спектра: более медленную, но полностью ончейн- и устойчивую к цензуре систему, которая остаётся привлекательной для пользователей, ценящих прозрачность выше максимальной скорости.</p>
  <p id="uZOe">В отличие от централизованных бирж, DEX для торговли деривативами никогда не получает доступ к приватным ключам трейдера. Залоговые средства находятся в смарт-контрактном хранилище, распоряжаться которым может только сам пользователь.</p>
  <p id="TM3d">Ни отдел комплаенса, ни географические ограничения, ни внезапное изменение политики платформы не могут заморозить или перенаправить эти средства - возможность вывода гарантируется кодом, а не доброй волей оператора.</p>
  <blockquote id="SFak">[Прим. Menaskop: речь идёт, конечно же, только о смартах: на интерфейсе всё морозится - да ещё как!]...</blockquote>
  <h3 id="OMyi">4.3 Предел пропускной способности L1 для DEX на базе L2 и L3</h3>
  <p id="S3qL">Rollup-системы наследуют свою безопасность от базового блокчейна первого уровня, поэтому каждый сжатый пакет сделок всё равно должен быть опубликован в L1. </p>
  <p id="m2RT">В спокойных рыночных условиях пропускная способность кажется достаточной. Во время всплесков волатильности она превращается в жёсткое ограничение, которое вынуждены делить между собой все DEX.</p>
  <p id="lWEB">В Ethereum обновление <u><a href="https://eips.ethereum.org/EIPS/eip-4844" target="_blank">EIP-4844</a></u> вводит шесть blob-объектов по 128 КБ на каждый 12-секундный блок. Это примерно 0,75 МБ данных на блок или около 64 КБ в секунду. После вычета заголовков и корней Меркла остаётся примерно 58 КБ полезной пропускной способности в секунду.</p>
  <p id="bILn">Если один сжатый ордер вместе с доказательством занимает около 60 байт, сеть способна обработать лишь примерно 1000 ордеров в секунду. При этом все optimistic-rollup и zk-rollup решения, использующие Ethereum как базовый уровень, вынуждены делить эту пропускную способность между собой.</p>
  <p id="hm1a">Во время всплесков волатильности канал передачи данных насыщается, комиссии за blob-хранилище растут, а секвенсоры начинают ограничивать поток транзакций.</p>
  <p id="tuF5">У Solana ситуация выглядит иначе. Часто цитируемые 65 тысяч TPS включают служебный трафик валидаторов. Фактическая телеметрия показывает около 800-2000 пользовательских транзакций в секунду, что соответствует примерно 140-360 КБ полезной нагрузки. Типичный вызов Serum NewOrderV3 занимает около 120 байт, тогда как сверхсжатые пакеты Bullet могут занимать около 80 байт. </p>
  <blockquote id="HYJE">Поэтому совокупный поток ордеров всех DEX в экосистеме Solana ограничивается примерно 2000-4000 операциями в секунду.</blockquote>
  <p id="evtO">Будущие обновления вроде <strong>Firedancer</strong> и увеличение вычислительных лимитов могут повысить этот предел, однако сегодня обе экосистемы всё ещё ограничены пропускной способностью своего базового уровня.</p>
  <p id="nRi2">Проблема усугубляется именно тогда, когда пропускная способность особенно необходима. Во время резкого движения цены арбитражные боты и механизмы ликвидации начинают конкурировать за одни и те же blob-слоты или вычислительные ресурсы. Комиссии растут. Задержки увеличиваются. Неподтверждённые пакеты транзакций накапливаются. Торговым движкам приходится временно буферизовать исполнения вне блокчейна до освобождения ресурсов.</p>
  <p id="Yu0u">Сети доступности данных (<strong>Celestia</strong>, <strong>EigenDA</strong>), дальнейшее масштабирование blob-хранилища и более эффективное сжатие доказательств способны повысить этот потолок.</p>
  <blockquote id="Qjjp">Однако фундаментальное правило остаётся неизменным: DEX никогда не сможет обрабатывать больше сделок в секунду, чем способен окончательно зафиксировать его базовый L1.</blockquote>
  <h3 id="VaxR">4.4 Оставшиеся ограничения и узкие места</h3>
  <p id="KG3x">Даже несмотря на rollup-решения, собственные L1 и zk-доказательства, современные DEX для торговли деривативами продолжают сталкиваться с рядом трудноустранимых ограничений.</p>
  <p id="kwPM"><strong>Во-первых, объём ончейн-состояния постоянно растёт</strong>. Большое количество опционных страйков, экспираций и глубокие книги ордеров увеличивают объём данных быстрее, чем механизмы очистки успевают их сокращать. Следствием становятся более высокие комиссии за обновления и возрастающие требования к оборудованию валидаторов.</p>
  <p id="acqt"><strong>Во-вторых, генерация доказательств требует времени</strong>. Схемы Zero-Knowledge должны обработать каждое исполнение ордера и каждое изменение маржи. Optimistic-rollup дополнительно вынуждены ждать завершения периода оспаривания. В спокойных условиях это выглядит как незначительная техническая деталь. Во время рыночной паники такие задержки способны замораживать вывод средств и временно выводить арбитражных ботов из игры.</p>
  <p id="yxTp"><strong>Третья проблема - дилемма секвенсора</strong>. Единый сверхбыстрый секвенсор обеспечивает задержки, близкие к централизованным биржам. Но одновременно он становится точкой цензуры и отказа. Добавление дополнительных узлов обычно увеличивает время достижения финальности, если только сеть не переходит к действительно распределённой модели секвенсирования. </p>
  <p id="lP5n"><strong>Ликвидность по-прежнему фрагментирована</strong>. Трейдер может видеть десять различных рынков ETH-перпетуалов на разных L2 и специализированных блокчейнах. Каждый рынок имеет собственную глубину, собственные ставки финансирования и собственные особенности. Перемещение капитала между ними требует времени, создаёт риск использования обёрнутых токенов и несёт альтернативные издержки.</p>
  <p id="2oR7"><strong>Проблема волатильности комиссий также не исчезла</strong>. Резкий скачок стоимости газа в L1 или перегрузка L2 могут за считанные минуты превратить прибыльную стратегию арбитража funding rate в убыточную.</p>
  <p id="O8Ck">Наконец, <strong>риск-движки для нелинейных продуктов всё ещё частично остаются вне блокчейна</strong>. Большинство DEX продолжают использовать внешние сервисы, таблицы расчётов или теневые серверы для переоценки греков. Это создаёт операционный риск, который невозможно полностью скрыть даже за полностью не-кастодиальными расчётами.</p>
  <p id="EnCx">Пока эти проблемы не будут решены с помощью аренды состояния (<strong>state rent</strong>), более быстрых доказательств, распределённых секвенсоров, intent-архитектур и полностью верифицируемой риск-математики, DeFi-деривативы продолжат обменивать часть удобства и эффективности на своё главное преимущество - самостоятельное хранение активов пользователями.</p>
  <h2 id="yMlR">5. Безопасность и векторы атак на DEX для торговли деривативами</h2>
  <p id="eNVi">Торговые движки, объединяющие высокое кредитное плечо, ончейн-исполнение и кросс-маржинальность, создают уникальные технические и экономические риски. </p>
  <p id="JRd7">Ниже сначала рассмотрим реальный инцидент, который наглядно демонстрирует эти угрозы, затем обобщим основные сценарии атак и завершим раздел принципами, позволяющими сохранить платёжеспособность DEX в стрессовых условиях.</p>
  <h3 id="jjma">5.1 Практический пример - экономический инцидент Hyperliquid (12 марта 2025 года)</h3>
  <p id="A3zP">12 марта 2025 года на Hyperliquid произошёл резонансный экономический инцидент, выявивший структурные недостатки системы управления рисками.</p>
  <p id="LNN5">Один кошелёк (адрес 0xf3f4) открыл чрезвычайно крупную длинную позицию по бессрочным фьючерсам на Ethereum объёмом около 340 миллионов долларов по номиналу, используя плечо, близкое к максимальному на платформе — примерно 180×.</p>
  <p id="nKgQ">Поначалу сделка оказалась крайне прибыльной.</p>
  <p id="x7TF">По мере роста ETH нереализованная прибыль достигла примерно 8 миллионов долларов.</p>
  <p id="LilN">Однако вместо фиксации прибыли или сокращения риска трейдер вывел большую часть обеспечения, поддерживавшего позицию, оставив аккаунт практически без запаса маржи.</p>
  <p id="j4eO">Этот манёвр воспользовался пробелом в логике вывода обеспечения на Hyperliquid: система не пересчитывала требования к марже немедленно после вывода средств.</p>
  <p id="gk2k">Когда механизм маржин-колла всё же сработал, выявилось ещё одно ограничение платформы — отсутствие частичных ликвидаций.</p>
  <p id="q1Dx">Всю позицию пришлось ликвидировать целиком одним ордером.</p>
  <p id="Pbwb">Внутренний движок ликвидации оценивал позицию по цене 1915 долларов за ETH, тогда как реальная рыночная цена уже упала примерно до 1760 долларов.</p>
  <p id="ZWJR">Разница в 155 долларов на столь огромном объёме привела к убытку значительно более 4 миллионов долларов.</p>
  <p id="8No0">Этот убыток был немедленно переложен на внутренний пул поставщиков ликвидности Hyperliquid (HLP).</p>
  <p id="oWNf">Сам трейдер, напротив, получил приблизительно 1,8 миллиона долларов чистой прибыли.</p>
  <p id="v1fO">Hyperliquid классифицировал произошедшее как торговый инцидент, а не взлом.</p>
  <p id="K3rx">Однако последствия оказались серьёзными.</p>
  <p id="PNwh">В течение нескольких часов биржа:</p>
  <ul id="6j9W">
    <li id="cbht">снизила максимальное плечо до 40× для BTC;</li>
    <li id="k2zF">снизила максимальное плечо до 25× для ETH;</li>
    <li id="nryC">ужесточила требования к обеспечению крупных позиций;</li>
    <li id="xNsx">ускорила внедрение механизма частичных ликвидаций.</li>
  </ul>
  <p id="x8YD">Этот случай подчёркивает важный вывод для всех DEX с деривативами:</p>
  <p id="2iYi">без частичных ликвидаций, ограничений плеча в зависимости от размера позиции и постоянной проверки обеспечения одна удачно спланированная сделка способна переложить хвостовой риск на весь протокол и его страховые механизмы.</p>
  <h3 id="SKQA">5.2 Типовые экономические и технические векторы атак</h3>
  <p id="4xVN">Инцидент Hyperliquid - лишь один из возможных сценариев.</p>
  <p id="81LG">В действительности основными источниками риска остаются:</p>
  <ul id="HV4s">
    <li id="gKQJ">манипуляция оракулами;</li>
    <li id="ue5o">экстремальное кредитное плечо;</li>
    <li id="3SIO">ошибки ликвидации;</li>
    <li id="kjwm">недостатки маржинальных моделей.</li>
  </ul>
  <blockquote id="misR">Манипуляция оракулами остаётся классическим вектором атаки.</blockquote>
  <p id="XajP">Если злоумышленник способен исказить ценовой поток даже на несколько блоков, он может заставить риск-движок неверно оценивать обеспечение и открывать возможности для эксплуатации.</p>
  <p id="Ha84">Подобные сценарии уже наблюдались в ряде известных случаев:</p>
  <ul id="fx1z">
    <li id="q5jL"><strong>Mango Markets</strong> (октябрь 2022): около 116 млн долларов было выведено после искусственного разгона цены токена MNGO.</li>
    <li id="odqh"><strong>dYdX ETH Flash Crash</strong> (февраль 2021): примерно 8 млн долларов ошибочных ликвидаций из-за некорректной котировки маркет-мейкера.</li>
    <li id="IfPA"><strong>Deus Finance </strong>(апрель 2022): около 13,4 млн долларов похищено через манипуляцию TWAP-оракулом.</li>
    <li id="jaEZ"><strong>GMX AVAX Pool </strong>(сентябрь 2022): около 565 тысяч долларов извлечено через влияние на низколиквидные ценовые источники.</li>
  </ul>
  <p id="MRsO">Во всех случаях проблема сводилась к одному: некачественная интеграция оракулов и логика ликвидации, полностью доверяющая их данным.</p>
  <p id="E0LW">Другой распространённый риск - так называемые гамма-ловушки (<strong>Gamma Traps</strong>). Они возникают, когда трейдеры или AMM-протоколы продают большой объём краткосрочных опционов.</p>
  <p id="u9T8">Резкое движение рынка вынуждает продавцов опционов агрессивно хеджироваться, покупая или продавая базовый актив по ухудшающимся ценам. Это ещё сильнее усиливает движение рынка и может привести к банкротству поставщиков ликвидности.</p>
  <p id="3zFc">Подобная ситуация наблюдалась в <strong>bZx</strong> в 2019 году, когда крупная короткая позиция по ETH привела к отклонению DAI от привязки и опустошению маржинальных хранилищ.</p>
  <p id="wZuL">Отдельную категорию составляют <strong>атаки на страховые фонды</strong>. Они возникают, когда реальные выплаты отличаются от ожидаемых потоков funding rate или других расчётных механизмов.</p>
  <p id="R2QP">В 2020 году один из трейдеров dYdX циклически открывал взаимокомпенсирующие позиции по BTC-перпетуалам, эксплуатируя логику начисления funding rate. В результате было извлечено около 8 миллионов долларов, которые пришлось покрывать из резервов платформы.</p>
  <p id="IUpN">Слепые зоны портфельной маржи позволяют опытным трейдерам создавать конструкции, которые выглядят дельта-нейтральными, но содержат огромные скрытые риски по веге и гамме. Когда подразумеваемая волатильность резко растёт, такие позиции могут разрушиться быстрее, чем система успеет потребовать дополнительное обеспечение. Именно эта проблема частично проявилась и в инциденте Hyperliquid.</p>
  <p id="uCHN">Отдельную угрозу представляет <strong>MEV-сэндвичинг</strong>. Боты обнаруживают крупную заявку на покупку опциона или другого дериватива, открывают позицию раньше пользователя, а затем продают ему актив по ухудшенной цене. </p>
  <p id="0qVw">В сентябре 2022 года одна подобная операция на рынке AVAX в GMX привела к потерям поставщиков ликвидности примерно на 500 тысяч долларов всего за один день.</p>
  <p id="8lGN">Наконец, серьёзную угрозу представляют <strong>атаки на межсетевые мосты</strong>. Наиболее известный пример - взлом Wormhole на 326 миллионов долларов. Если обеспечение разблокируется в одной сети, а соответствующие позиции продолжают существовать в другой, возникает критический дисбаланс маржинальной системы.</p>
  <h3 id="G6N5">5.3 Принципы снижения рисков</h3>
  <p id="3w2i">Защита начинается с динамической маржинальной модели, учитывающей греков. Требования к начальному обеспечению должны автоматически увеличиваться по мере роста гамма- и вега-риска. Частота переоценки должна возрастать вместе с ускорением рынка или ростом подразумеваемой волатильности. Кредитное плечо должно уменьшаться по мере роста размера позиции.</p>
  <p id="rBVk">Например:</p>
  <ul id="jX1h">
    <li id="hteQ">первые 1 млн долларов - плечо до 25×;</li>
    <li id="tmUf">свыше 50 млн долларов - не более 5×.</li>
  </ul>
  <p id="g66x">Такой подход лучше соответствует реальной рыночной ликвидности и предотвращает концентрацию риска в руках отдельных участников. Частичные ликвидации являются обязательным элементом современной архитектуры.</p>
  <p id="8Ngx">Разделение позиции на несколько частей позволяет:</p>
  <ul id="o1SU">
    <li id="djfW">уменьшить рыночное воздействие;</li>
    <li id="ERUw">снизить всплески комиссий;</li>
    <li id="ICPy">остановить процесс ликвидации при резком ухудшении ликвидности.</li>
  </ul>
  <p id="lqLC">Например, позицию на 300 миллионов долларов разумнее ликвидировать десятью блоками по 30 миллионов, чем одной операцией.</p>
  <p id="oyOZ">Страховой фонд остаётся последней линией защиты. Однако он должен не просто накапливать средства, а активно хеджироваться. Многие биржи уже направляют часть комиссий на покупку глубоко вне денег (deep OTM) опционов, которые резко растут в цене именно в тех сценариях, когда страховой фонд испытывает наибольшую нагрузку.</p>
  <p id="VGG7">Дополнительную защиту обеспечивают автоматические аварийные механизмы (Circuit Breakers). Они могут реагировать на:</p>
  <ul id="IWDp">
    <li id="uQ1W">сильные отклонения цен оракулов;</li>
    <li id="lFof">резкие скачки funding rate;</li>
    <li id="gSkH">аномальную волатильность.</li>
  </ul>
  <p id="93nm">Такие механизмы дают разработчикам и риск-менеджерам драгоценные минуты для повышения требований к обеспечению или временной остановки принятия нового риска.</p>
  <p id="MFSM">Если все перечисленные меры применяются совместно, то даже при экстремальном росте плеча или волатильности максимальные потери ограничиваются архитектурой системы заранее, а не распределяются между пользователями уже после наступления кризиса.</p>
  <h2 id="7jkh">6. Куда движется рынок (с 2025 года и далее)</h2>
  <p id="qOLR">Следующая волна развития DeFi-деривативов уже начинает формироваться. Она строится вокруг трёх ключевых идей: устранение единых точек отказа, сокращение времени генерации доказательств до уровней, заметных человеку, и объединение разрозненной ликвидности таким образом, чтобы капитал автоматически находил лучшую цену. Ниже рассмотрены основные направления развития.</p>
  <h3 id="iHPu">6.1 Распределённые секвенсоры и общие сети доступности данных</h3>
  <p id="MbNC">Сегодня большинство rollup-решений зависят от одного секвенсора.</p>
  <p id="jasu">Такой секвенсор напоминает болид Формулы-1: он способен обеспечивать сопоставление ордеров менее чем за 5 миллисекунд, но если оператор исчезает или выходит из строя, работа системы останавливается.</p>
  <p id="glXk">Появляющееся решение - распределённая группа секвенсоров, которые совместно используют mempool, по очереди принимают роль лидера в каждом блоке и публикуют свои пакеты данных в высокопроизводительные сети доступности данных, такие как Celestia или EigenDA.</p>
  <p id="y2v4">На практике это означает, что торговые движки сохраняют ощущение сверхбыстрой DEX с задержками в единицы миллисекунд, однако при отказе или цензуре одного узла лидерство автоматически переходит к следующему валидатору.</p>
  <p id="eJFG">Устойчивость к сбоям возрастает, а пропускная способность увеличивается по мере подключения новых сегментов сети доступности данных.</p>
  <h3 id="Sd2H">6.2 Таблицы рисков, дружественные к ZK-доказательствам</h3>
  <p id="MLjY">Все хотят получить точность модели Black-Scholes, но никто не хочет ждать генерации доказательства несколько минут.</p>
  <p id="gVmA">Компромисс оказался довольно элегантным. Вместо выполнения сложных вычислений внутри zk-схем заранее рассчитываются плотные таблицы коэффициентов риска:</p>
  <ul id="MQmw">
    <li id="uVh1">дельта;</li>
    <li id="Ln39">гамма;</li>
    <li id="qHln">вега.</li>
  </ul>
  <p id="g2dH">После этого схема просто выполняет обращение к таблице за постоянное время, не вычисляя логарифмы, экспоненты и функцию нормального распределения. Точность остаётся в пределах нескольких процентов от полноценной модели Black-Scholes, однако время генерации доказательств сокращается с минут до секунд. Для ботов ликвидации этого более чем достаточно.</p>
  <h3 id="3ZXS">6.3 Account Abstraction и MPC-хранение ключей</h3>
  <p id="sL7V">Стандарт <u><a href="https://docs.erc4337.io/index.html" target="_blank">ERC-4337</a></u> превращает криптовалютный кошелёк в полноценный смарт-контракт. Он позволяет:</p>
  <ul id="AAcs">
    <li id="WTeW">оплачивать комиссии любым токеном;</li>
    <li id="eOXT">реализовывать социальное восстановление доступа;</li>
    <li id="c13v">объединять несколько подписей в одну операцию.</li>
  </ul>
  <p id="aJgW">Если объединить эту модель с технологиями многопартийных вычислений (MPC), получается инфраструктура институционального хранения без риска классических горячих кошельков.</p>
  <p id="Eudo">Фактически пользователь может входить в систему через <strong>Face ID</strong>, тогда как реальные ключи распределены между несколькими аппаратными модулями безопасности (<strong>HSM</strong>), находящимися в разных странах и юрисдикциях.</p>
  <h3 id="8qM5">6.4 Универсальные маржинальные кошельки</h3>
  <p id="AYLS">Наибольший прирост эффективности капитала возникает тогда, когда обеспечение перестаёт существовать в изолированных хранилищах. Концепция универсального маржинального кошелька рассматривает как единую балансовую систему:</p>
  <ul id="xbZt">
    <li id="fahX">USDC;</li>
    <li id="xfrp">токенизированные казначейские облигации США;</li>
    <li id="D0pS">NFT;</li>
    <li id="EkKv">позиции по perpetual-контрактам;</li>
    <li id="PdqW">другие активы.</li>
  </ul>
  <p id="Z4nI">Система в реальном времени рассчитывает совокупный риск портфеля. Например, длинная дельта по ETH может компенсироваться короткой гаммой по SOL и вегой по BTC-стрэнглу. Маржа начисляется только на остаточный риск. Ранние прототипы показывают снижение требований к начальному <strong>обеспечению</strong> <strong>на 30-50% </strong>при сохранении того же уровня риска.</p>
  <h3 id="yLcT">6.5 Шардирование ликвидности и Intent-слои</h3>
  <p id="NIsS">Книги ордеров естественным образом дробят ликвидность между различными сетями. Intent-архитектуры предлагают противоположный подход.</p>
  <p id="7wdf">Трейдер больше не указывает, где именно должна быть исполнена сделка. Вместо этого он подписывает намерение. Например: &quot;Купить десять ETH call-опционов с дельтой 0,25&quot;.</p>
  <p id="ub2q">После этого специальные решатели (solvers) конкурируют между собой за наиболее эффективное исполнение намерения через различные сети, мосты и торговые площадки.</p>
  <p id="zDiT">Комиссии мостов и секвенсоров скрываются внутри механизма исполнения. Трейдер видит единую цену исполнения. Маркет-мейкеры получают более крупный совокупный поток заявок. Капитал перестаёт простаивать в отдельных экосистемах.</p>
  <p id="RoGB">В совокупности эти технологии формируют образ будущей DEX для торговли деривативами, которая будет напоминать прайм-брокера:</p>
  <ul id="mGf3">
    <li id="ExcR">скорость централизованной биржи;</li>
    <li id="NF3W">единая маржинальная система;</li>
    <li id="HV8l">единый баланс для различных активов;</li>
    <li id="p8ZZ">отсутствие необходимости доверять какой-либо отдельной организации или машине.</li>
  </ul>
  <h2 id="JTn7">7. Заключение</h2>
  <p id="iCNF">DeFi-деривативы стремительно сокращают отставание от традиционных бирж по скорости исполнения.</p>
  <p id="jdlm">Однако их главное преимущество заключается не в скорости, а в самостоятельном хранении активов. Ваше обеспечение находится в смарт-контракте, которым можете распоряжаться только вы. Ни одна биржа не способна заморозить или конфисковать эти средства. Чтобы выполнить это обещание, DEX должны решить две фундаментальные задачи.</p>
  <p id="mpTJ"><strong>Первая - надёжные ценовые оракулы</strong>. Каждая ликвидация и каждый маржин-колл зависят от корректной цены. Новые архитектуры DEX объединяют несколько источников данных:</p>
  <ul id="LYKK">
    <li id="mwH1">ончейн-средние цены;</li>
    <li id="FVfC">подписанные котировки маркет-мейкеров;</li>
    <li id="DXCF">механизмы коллективной проверки данных.</li>
  </ul>
  <p id="Cdj3">Это позволяет противодействовать манипуляциям ценами.</p>
  <p id="VxoZ"><strong>Вторая задача - использование реального обеспечения</strong>. В экосистему постепенно приходят токенизированные казначейские облигации США и другие реальные активы. Когда маржинальный кошелёк сможет компенсировать риск криптовалютной позиции за счёт токенизированной облигации, трейдеры получат:</p>
  <ul id="E3A0">
    <li id="woV8">более низкие комиссии;</li>
    <li id="ogbQ">более безопасное кредитное плечо;</li>
    <li id="1VYe">более эффективное использование капитала.</li>
  </ul>
  <p id="Fi6l">Проще говоря, DEX, которая обеспечивает:</p>
  <ul id="4M0A">
    <li id="7sCc">невозможность конфискации средств;</li>
    <li id="jmgt">защиту цен от манипуляций;</li>
    <li id="1xMT">гибкую систему обеспечения;</li>
  </ul>
  <p id="or4H">в конечном итоге сможет превзойти даже самую быструю централизованную биржу, поскольку доверие стоит дороже нескольких дополнительных миллисекунд задержки.</p>
  <p id="bduN">Бессрочные фьючерсы достаточно естественно вписываются в архитектуру rollup-решений. Однако полноценные опционы нагружают практически каждый уровень инфраструктуры до предела. Математика становится сложной. Гамма, вега и расчёты по Black-Scholes слишком дороги для выполнения непосредственно в блокчейне.</p>
  <p id="eOK4">Добавление логарифмов, экспонент и функций нормального распределения может увеличить размер zk-доказательств в несколько раз. Состояние системы быстро разрастается. Тысячи комбинаций страйков и экспираций увеличивают объём хранимых данных и поднимают стоимость каждой операции. Маржинальные модели становятся значительно сложнее. Для фьючерсов достаточно одной текущей цены.</p>
  <p id="wP7A">Для опционов необходимо постоянно моделировать изменения:</p>
  <ul id="ckMm">
    <li id="F4rQ">цены актива;</li>
    <li id="7P1c">волатильности;</li>
    <li id="u9mq">времени до экспирации.</li>
  </ul>
  <p id="zt4y">Без таких пересчётов ликвидации будут происходить слишком поздно. Ликвидность также становится более сложной задачей. Маркет-мейкеры должны поддерживать не одну цену, а целую поверхность волатильности, состоящую из множества страйков и сроков. Если платформа не обладает серьёзным институциональным потоком, ликвидность начинает фрагментироваться.</p>
  <p id="DQ9y">Пока одновременно не появятся:</p>
  <ul id="cfIA">
    <li id="gtJJ">более лёгкие модели расчёта рисков;</li>
    <li id="1DQ1">дешёвое хранение данных;</li>
    <li id="wkKI">универсальная кросс-маржинальность;</li>
  </ul>
  <p id="zuE4">опционы будут оставаться наиболее сложным продуктом для полной децентрализации даже на самых быстрых DEX-платформах.</p>
  <p id="UoDm"><em>До!</em></p>

]]></content:encoded></item><item><guid isPermaLink="true">https://teletype.in/@menaskop/tokenomics-2026-00</guid><link>https://teletype.in/@menaskop/tokenomics-2026-00?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop</link><comments>https://teletype.in/@menaskop/tokenomics-2026-00?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop#comments</comments><dc:creator>menaskop</dc:creator><title>Токеномика. Бесплатный курс 2026. Занятие №00. Экономика токена (перевод)</title><pubDate>Mon, 15 Jun 2026 05:05:47 GMT</pubDate><media:content medium="image" url="https://img2.teletype.in/files/11/39/1139529b-4c3b-41b0-bf62-94ac7500bddb.png"></media:content><category>web3</category><description><![CDATA[<img src="https://img2.teletype.in/files/57/58/5758905d-328e-492b-86b3-18a1ee1d84d7.png"></img>Для того чтобы сохранять объективность в рамках каждого курса, стараюсь как можно чаще и больше изучать материалы из различных источников по теме, которую на этом самом курсе будем проходить.]]></description><content:encoded><![CDATA[
  <figure id="lyNU" class="m_column">
    <img src="https://img2.teletype.in/files/57/58/5758905d-328e-492b-86b3-18a1ee1d84d7.png" width="1672" />
    <figcaption>Курс по токеномике 2026</figcaption>
  </figure>
  <h2 id="cKrg">Введение</h2>
  <p id="w231">Для того чтобы сохранять объективность в рамках каждого курса, стараюсь как можно чаще и больше изучать материалы из различных источников по теме, которую на этом самом курсе будем проходить. </p>
  <p id="a60u">И в этот раз решил предоставить вам помимо прочего ряд статей из разных источников, которые помогают скомпоновать общее представление о токеномике. Ниже - один из них, а в <a href="https://t.me/+iavlR8U7ciVkN2Yy" target="_blank"><u>группе</u></a> - можете найти другие. </p>
  <h2 id="kkMb">Перевод</h2>
  <p id="Kzp5">Это вольный перевод: <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5136771" target="_blank">papers.ssrn.com/sol3/papers.cfm?abstract_id=5136771</a>.</p>
  <h2 id="5dw2">Аннотация</h2>
  <p id="grmO">Токеномика - экономическая система, регулирующая цифровые токены и поведение их пользователей в блокчейн-сетях, - играет ключевую роль в стимулировании участия и поддержании устойчивости децентрализованных экосистем.</p>
  <p id="ys84">В данной статье рассматриваются основные аспекты токеномики, включая предложение токенов, их распределение и полезность (утилитарность). Мы анализируем механизмы управления через голосование с использованием токенов, различные токеномические стратегии, такие как сжигание токенов (burning), эмиссия (minting) и стейкинг (staking), а также механизмы управления рисками и обеспечения залогом (collateralization).</p>
  <p id="OnFd">Кроме того, показано, каким образом эти механизмы обеспечивают стабильность сети, способствуют децентрализации и согласованию стимулов между участниками. На основе анализа реальных примеров статья демонстрирует важность токеномики для устойчивого развития и успешного функционирования блокчейн-сетей и протоколов децентрализованных финансов (DeFi).</p>
  <p id="KJyJ">Ключевые слова: токеномика, цифровой токен, криптовалюта, блокчейн, децентрализация, система стимулов.</p>
  <h2 id="CYjn">Введение</h2>
  <p id="Dqew">Экономика токенов (token economics), также известная как токеномика (tokenomics), изучает экономические аспекты цифровых токенов (например, криптовалют вроде BTC или управляющих токенов, таких как MKR в MakerDAO), используемых в блокчейн-сетях (например, Bitcoin или Ethereum).</p>
  <p id="ddJR">Токеномика охватывает ключевые проектные решения, связанные с созданием, распределением и управлением цифровыми токенами с точки зрения рыночной экономики. Эти решения играют важную роль в стимулировании участия в блокчейн-сетях и помогают поддерживать их устойчивое развитие благодаря стратегическому использованию нативных цифровых токенов, что способствует непрерывному совершенствованию и развитию экосистемы (Ellinger et al., 2024).</p>
  <p id="J7Vm">В этом контексте токеномику также рассматривают как систему стимулов (incentive system).</p>
  <p id="ltpl">Основная идея токеномики заключается в создании стимулов для участников блокчейн-сети, побуждающих их к желаемому поведению. Это особенно важно из-за отсутствия в блокчейн-сетях центрального управляющего органа.</p>
  <p id="PMnZ">При отсутствии центральной власти и классической модели управления по принципу командование и контроль блокчейн-сетям, стремящимся к высокой степени децентрализации, необходима сильная система стимулов, обеспечивающая жизнеспособность и устойчивость участия и сотрудничества внутри сети (Lesche et al., 2022).</p>
  <p id="hL97">Такие стимулы могут включать:</p>
  <ul id="Jef9">
    <li id="tUuR">вознаграждения за стейкинг для валидаторов, обеспечивающих безопасность сети;</li>
    <li id="kw10">права управления для держателей токенов;</li>
    <li id="4cLM">другие преимущества, которые согласуют действия участников с долгосрочными интересами сети.</li>
  </ul>
  <p id="6DXL">Поскольку все эти механизмы стимулирования связаны с использованием и обменом цифровых токенов, одним из ключевых аспектов токеномики являются вопросы предложения и распределения токенов.</p>
  <p id="kELE">Токеномика включает принятие решений относительно общего объёма выпуска токенов, способов их эмиссии и стратегии распределения. Эти решения могут определять, будет ли токен обладать инфляционными или дефляционными характеристиками.</p>
  <p id="l63l">Например, токен XRP имеет одновременно обе черты:</p>
  <ul id="fIB9">
    <li id="Fcrs">инфляционные - за счёт регулярного высвобождения токенов из эскроу;</li>
    <li id="Z1Hc">дефляционные - за счёт сжигания комиссий за транзакции и периодического возврата части токенов обратно в эскроу.</li>
  </ul>
  <p id="iDNj">Основой для таких решений является цель создания цифрового токена.</p>
  <p id="ui3f">Назначение токена формируется социально внутри сообщества участников блокчейн-сети. При этом данная цель не всегда бывает чётко определена заранее и может возникать постепенно в процессе развития проекта, что нередко приводит к различиям между восприятием сообщества и первоначальным замыслом разработчиков.</p>
  <p id="514E">Примерами назначения токена могут быть:</p>
  <ul id="wfyl">
    <li id="eZt2">использование в качестве средства обмена;</li>
    <li id="d7eL">участие в коллективном принятии решений посредством голосования;</li>
    <li id="fJvW">предоставление доступа к сервисам блокчейн-сети (utility tokens);</li>
    <li id="a23g">представление прав на активы или доли в проекте (security tokens) (Sockin &amp; Xiong, 2023).</li>
  </ul>
  <p id="nI33">Кроме того, многие блокчейн-проекты используют цифровые токены управления (governance tokens) для организации децентрализованного управления. Такие токены позволяют держателям голосовать по ключевым вопросам, влияющим на будущее проекта.</p>
  <p id="GSfL">Токен управления представляет собой цифровой объект (токен), который закрепляет права заинтересованного участника блокчейн-коллектива на участие в управленческих решениях через голосование. Реализация этих прав осуществляется с помощью смарт-контрактов, обеспечивающих прозрачность и проверяемость процесса участия.</p>
  <p id="Rjly">Независимо от своего назначения, цифровые токены покупаются и продаются на криптовалютных биржах, где ценовой механизм направляет деятельность участников рынка — продавцов, покупателей и маркет-мейкеров.</p>
  <p id="xIL2">Поэтому цифровые токены подвержены рыночным факторам, которые напрямую влияют на решения в области токеномики.</p>
  <p id="SQXB">Ключевыми показателями жизнеспособности токена являются:</p>
  <ul id="lLTW">
    <li id="Yh0u">ликвидность;</li>
    <li id="Pp6q">торговый объём;</li>
    <li id="mLgP">рыночная капитализация.</li>
  </ul>
  <p id="pGBW">[Прим. Menaskop: как видите, даже такие авторы весьма сильно заблуждаются относительно токеномики как таковой].</p>
  <p id="JqMm">Одной из задач токеномики является обеспечение достаточной ликвидности токена для эффективной торговли и формирования рыночной цены без чрезмерной волатильности.</p>
  <p id="XeXw">Таким образом, токеномика - не просто создание цифровых токенов, а разработка устойчивой экономической модели, поддерживающей работу децентрализованного приложения или блокчейн-сети в целом.</p>
  <p id="pKrf">Грамотно спроектированная токеномика позволяет блокчейн-проектам и лидерам сетевых экосистем создавать условия, при которых все участники заинтересованы действовать таким образом, чтобы увеличивать коллективную ценность сети и её долгосрочную устойчивость.</p>
  <p id="aXsI">Для этого необходимо:</p>
  <ul id="JDIz">
    <li id="2ph6">обеспечивать реальную полезность токенов;</li>
    <li id="ECkC">согласовывать стимулы с поведением пользователей и участников;</li>
    <li id="KuF1">управлять предложением токенов таким образом, чтобы инфляция или дефляция не подрывали их стоимость.</li>
  </ul>
  <p id="hmQe">Кроме того, токеномика играет важнейшую роль в более широком понятии экономики токенов (token economy) - совокупности экономических отношений и взаимодействий, которые становятся возможными благодаря цифровым токенам.</p>
  <p id="PMZr">[Прим. Menaskop: собственно, здесь и видим, что авторы всё же понимают разницу между токеномикой и экономикой токенов, но до конца градацию не проводят].</p>
  <p id="dko0">Токены обеспечивают обмен ценностью и услугами внутри блокчейн-сети, потенциально создавая самоподдерживающуюся экономическую экосистему, способную функционировать независимо от традиционной финансовой системы.</p>
  <p id="jtBm">Однако реализация такого потенциала во многом зависит как от качества токеномического дизайна, так и от внешних факторов, включая рыночную конъюнктуру.</p>
  <p id="xF5i">Существует множество токеномических механизмов, применяемых в различных блокчейн-проектах. Далее - рассмотрим наиболее значимые из них.</p>
  <h2 id="xzlN">Первичное распределение токенов (Initial Distribution)</h2>
  <p id="O8w2">Способ первоначального распределения цифровых токенов в блокчейн-сети - через ICO (Initial Coin Offering), частные продажи (private sales) или эйрдропы (airdrops) - может существенно влиять на рыночную динамику токена и его воспринимаемую ценность, формируя тем самым всю токеномическую модель проекта.</p>
  <p id="wK1X">ICO позволяют стартапам обходить традиционных финансовых посредников, таких как банки и венчурные фонды, привлекая средства напрямую от инвесторов. Это делает инвестиционный процесс более демократичным, поскольку участвовать в публичном ICO может практически любой желающий.</p>
  <p id="O3k2">Токены, продаваемые в рамках ICO, могут выполнять различные функции:</p>
  <ul id="jUwA">
    <li id="1trV">предоставлять доступ к продукту или сервису;</li>
    <li id="WNEw">служить средством обмена внутри экосистемы;</li>
    <li id="Lg9A">предоставлять права управления проектом.</li>
  </ul>
  <p id="kCBg">Конкретная полезность токена является одним из центральных элементов его токеномики.</p>
  <h3 id="ba6I">Пример Ethereum</h3>
  <p id="USUd">Одним из наиболее показательных примеров является первоначальное распределение токенов Ethereum через ICO в 2014 году.</p>
  <p id="MRfa">Публичная продажа токенов Ether (ETH) обеспечила широкое участие сообщества и позволила сформировать большое и разнообразное сообщество заинтересованных участников уже на раннем этапе существования сети.</p>
  <p id="KDyh">Широкое распределение токенов стало основой более децентрализованной модели управления, при которой значительное число участников заинтересовано в успехе сети.</p>
  <p id="y4mA">Во время ICO фонд Ethereum Foundation провёл открытую продажу, в рамках которой инвесторы могли приобрести ETH за Bitcoin.</p>
  <p id="ajLa">Такой подход обеспечил широкий доступ к токенам ETH. В результате ICO было привлечено около 31 000 BTC (примерно 18,3 млн долларов по тогдашнему курсу) в обмен на около 60 млн ETH.</p>
  <p id="GWWw">Из этого объёма:</p>
  <ul id="NJcv">
    <li id="pfaW">12 млн ETH были направлены в фонд развития;</li>
    <li id="oRNk">оставшиеся токены распределены между участниками ICO.</li>
  </ul>
  <p id="OgaL">Баланс между финансированием разработки и широким участием сообщества стал одним из факторов формирования современной модели управления Ethereum, которая сочетает:</p>
  <ul id="lvXg">
    <li id="filW">децентрализованное участие сообщества;</li>
    <li id="I3Gx">лидерство ключевых разработчиков.</li>
  </ul>
  <p id="ZWsC">Первоначальное распределение токенов также повлияло на подход Ethereum к принятию решений.</p>
  <p id="GTwB">В отличие от некоторых других блокчейн-проектов Ethereum отказался от полностью ончейн-модели управления через голосование токенами, поскольку такая система может оказаться под чрезмерным влиянием крупных держателей токенов.</p>
  <p id="q8cC">Вместо этого используется более гибкий механизм Ethereum Improvement Proposals (EIP), предусматривающий длительные обсуждения и экспертную оценку предложений до их внедрения.</p>
  <p id="kNZ5">Таким образом, первоначальное распределение ETH заложило основу для формирования децентрализованной экосистемы Ethereum, создав широкую базу держателей токенов, способных участвовать в работе сети, её развитии и управлении.</p>
  <h2 id="xnpq">Сжигание токенов (Token Burning)</h2>
  <p id="Vw1l">Сжигание токенов является одним из важнейших механизмов токеномики.</p>
  <p id="pIuP">Оно представляет собой окончательное удаление определённого количества токенов из обращения.</p>
  <p id="OVFo">Обычно это достигается путём отправки токенов на специальный недоступный адрес - так называемый burn address, с которого невозможно потратить или вернуть средства.</p>
  <p id="HxnP">Сокращение общего предложения токенов создаёт дефицитность (scarcity), что при неизменном или растущем спросе может способствовать росту стоимости оставшихся в обращении токенов.</p>
  <p id="bjRb">Таким образом, сжигание может формировать дефляционный эффект и оказывать поддержку рыночной цене криптовалюты или токена.</p>
  <p id="Fhia">Регулярные программы сжигания также могут служить сигналом инвесторам о том, что проект заинтересован в долгосрочном увеличении ценности токена. Это стимулирует более длительное удержание токенов и может снижать рыночную волатильность.</p>
  <h3 id="6X4Y">Пример Binance Coin (BNB)</h3>
  <p id="fitO">Одним из самых известных примеров является механизм сжигания токена BNB, реализованный компанией Binance.</p>
  <p id="qzm3">Binance внедрила систематическую программу квартального сжигания токенов, в рамках которой часть BNB уничтожается на основе финансовых результатов компании за отчётный период.</p>
  <p id="eZFi">Цель программы - постепенное сокращение общего предложения BNB и потенциальное увеличение его стоимости со временем.</p>
  <p id="2Cyw">Механизм BNB Burn считается одним из наиболее известных и влиятельных примеров в криптовалютной индустрии.</p>
  <p id="KuRk">Binance обязалась уничтожить 100 млн BNB, что соответствует 50% первоначального общего предложения токена.</p>
  <p id="nzF4">Такой подход направлен на создание дефицита предложения, который при сохранении или росте спроса может способствовать повышению цены.</p>
  <p id="FJJ0">Регулярность и прозрачность программ сжигания сыграли важную роль в поддержании высокой рыночной стоимости BNB и доверия со стороны инвесторов.</p>
  <h3 id="XK0i">Пример Tether (USDT)</h3>
  <p id="J4yg">Другой важный пример связан со стейблкоином USDT.</p>
  <p id="8QdA">В данном случае сжигание токенов используется не для повышения стоимости актива, а для поддержания привязки к доллару США.</p>
  <p id="cQDL">Механизм работает следующим образом:</p>
  <ol id="fZru">
    <li id="PLtr">Пользователь вносит доллары США — выпускаются новые USDT.</li>
    <li id="M6Eb">Пользователь возвращает USDT эмитенту и получает доллары США — соответствующее количество токенов уничтожается.</li>
  </ol>
  <p id="dnfh">Когда рыночная цена USDT опускается ниже 1 доллара, арбитражёры могут:</p>
  <ul id="WflE">
    <li id="92DU">покупать USDT со скидкой на рынке;</li>
    <li id="FGMG">обменивать их у эмитента по номиналу;</li>
    <li id="UQmm">получать доллары США.</li>
  </ul>
  <p id="B1dL">После выкупа такие токены погашаются и сжигаются, что уменьшает предложение USDT в обращении и способствует восстановлению привязки к доллару.</p>
  <p id="iJUB">Если же цена USDT поднимается выше 1 доллара, происходит выпуск новых токенов, увеличивающий предложение и возвращающий цену к целевому уровню.</p>
  <p id="Zhtg">Таким образом, контролируемая эмиссия и сжигание токенов являются фундаментальными элементами механизма поддержания стабильности курса USDT (Ciriello, 2021).</p>
  <p id="XV6K">В целом, механизмы первоначального распределения и сжигания токенов относятся к базовым инструментам токеномики. Первый определяет, кто получает экономическую и политическую власть в экосистеме на старте проекта, а второй позволяет управлять предложением токенов, поддерживать ценность актива и реализовывать долгосрочную экономическую стратегию сети.</p>
  <h2 id="Pesc">Эмиссия токенов (Token Minting)</h2>
  <p id="r29r">Эмиссия токенов (minting) - ещё один важный механизм токеномики, связанный с созданием новых токенов и их введением в обращение.</p>
  <p id="cTcL">Этот процесс может использоваться для различных целей:</p>
  <ul id="cpHJ">
    <li id="FbTj">стимулирования участия в сети;</li>
    <li id="9hXn">вознаграждения участников и контрибьюторов;</li>
    <li id="7Jkg">поддержания стабильности стоимости токена;</li>
    <li id="ga1A">финансирования развития экосистемы.</li>
  </ul>
  <p id="ggPV">Эмиссия может происходить:</p>
  <ul id="vqzU">
    <li id="cxqV">через регулярные промежутки времени;</li>
    <li id="9HE5">при наступлении определённых событий;</li>
    <li id="lQKX">по решению системы управления (governance).</li>
  </ul>
  <p id="K3HF">Скорость эмиссии и условия выпуска новых токенов оказывают существенное влияние на динамику предложения, а значит — на ценность и полезность токена внутри экосистемы.</p>
  <h3 id="hgaA">Пример MakerDAO и DAI</h3>
  <p id="lOzG">Характерный пример эмиссии можно наблюдать в системе MakerDAO.</p>
  <p id="ATbw">Пользователи могут выпускать новые токены DAI, размещая криптовалютное обеспечение в специальном хранилище - Maker Vault.</p>
  <p id="1JBN">Процесс эмиссии напрямую связан со стоимостью залога, благодаря чему каждый выпущенный DAI обеспечивается активами большей стоимости.</p>
  <p id="S7zf">Например:</p>
  <ul id="G0kt">
    <li id="NYYe">пользователь вносит Ethereum на сумму 150 долларов;</li>
    <li id="Tdi0">после этого он может выпустить до 100 DAI;</li>
    <li id="ze4B">коэффициент обеспечения составит 150%.</li>
  </ul>
  <p id="4L8O">Такой механизм позволяет предложению DAI динамически адаптироваться к спросу и рыночным условиям, одновременно поддерживая его привязку к доллару США.</p>
  <h2 id="hqgS">Распределение токенов и проблема концентрации</h2>
  <p id="idK9">Распределение токенов играет критически важную роль в формировании согласованности интересов участников, особенно на ранних этапах развития блокчейн-сообщества.</p>
  <p id="RxQl">Грамотно организованное распределение позволяет:</p>
  <ul id="15cJ">
    <li id="9tZW">создавать более децентрализованную структуру управления;</li>
    <li id="p7jU">повышать ликвидность токена;</li>
    <li id="kjHD">стимулировать ранних участников проекта.</li>
  </ul>
  <p id="vkDx">Однако существуют и проблемы.</p>
  <p id="av6m">Наиболее значимая из них - концентрация токенов в руках небольшой группы участников.</p>
  <p id="7HLL">Для борьбы с этим многие протоколы используют:</p>
  <ul id="LRTb">
    <li id="g9W0">вознаграждения сообщества;</li>
    <li id="V03j">программы liquidity mining;</li>
    <li id="40fI">графики вестинга;</li>
    <li id="iNWX">контролируемую разблокировку токенов.</li>
  </ul>
  <h2 id="Yu3o">Разблокировка токенов (Token Unlocks)</h2>
  <p id="IThS">Разблокировки токенов представляют собой заранее запланированные события, в ходе которых ранее заблокированные токены постепенно поступают в обращение в соответствии с графиком вестинга.</p>
  <p id="COiw">Такие разблокировки могут быть связаны:</p>
  <ul id="s2ci">
    <li id="MroZ">с достижением определённых этапов развития проекта;</li>
    <li id="ZHqG">с условиями соглашений с инвесторами;</li>
    <li id="zacC">с программами стимулирования участников.</li>
  </ul>
  <p id="wVEf">Основная цель механизма — контролировать рост предложения токенов и одновременно поддерживать ликвидность.</p>
  <p id="cQyJ">Однако плохо спланированные разблокировки способны вызвать серьёзные проблемы.</p>
  <p id="oLqz">Слишком большие объёмы токенов, одновременно выходящие на рынок, могут привести к:</p>
  <ul id="Thtd">
    <li id="0pV1">росту давления продавцов;</li>
    <li id="RALR">снижению цены;</li>
    <li id="9B2H">повышенной волатильности.</li>
  </ul>
  <h3 id="kyoe">Пример Steem</h3>
  <p id="HCJb">В протоколе Steem существовал механизм блокировки токенов через инструмент Steem Power (SP).</p>
  <p id="2edN">Пользователи могли перевести свои токены STEEM в режим Steem Power, принимая обязательство удерживать их в течение 13 недель.</p>
  <p id="a4Eq">На протяжении этого периода токены нельзя было:</p>
  <ul id="pxQI">
    <li id="NTco">продать;</li>
    <li id="RPwN">перевести;</li>
    <li id="Grlh">вывести из системы.</li>
  </ul>
  <p id="vD8Z">Подобная модель стимулировала долгосрочную заинтересованность участников в развитии платформы и повышала стабильность экосистемы.</p>
  <p id="0LTG">Кроме того, владельцы SP получали права голоса, пропорциональные объёму заблокированных токенов.</p>
  <p id="yAjA">Это создавало дополнительный стимул участвовать в управлении платформой ответственно и с долгосрочным горизонтом планирования.</p>
  <h2 id="nbsZ">Управление через голосование токенами (Governance through Token-Based Voting)</h2>
  <p id="fTWA">Одним из важнейших элементов токеномики является проектирование токенов управления и определение того, каким образом они распределяют власть, согласуют стимулы участников и обеспечивают децентрализованное принятие решений.</p>
  <p id="G5Jc">Governance-токены позволяют держателям участвовать в управлении протоколом.</p>
  <p id="Mfrl">В отличие от традиционных моделей управления, где контроль сосредоточен в руках централизованной организации, governance-токены распределяют полномочия между участниками сети, формируя систему, которая при определённых условиях отражает коллективную волю сообщества (Ellinger et al., 2024).</p>
  <p id="KMl1">Такая модель помогает согласовывать экономические стимулы участников с долгосрочным успехом протокола.</p>
  <h3 id="JTW2">Как работает голосование токенами?</h3>
  <p id="ztkK">В большинстве случаев управление строится на системе голосования, где токен предоставляет право:</p>
  <ul id="5mLp">
    <li id="FRbc">предлагать изменения;</li>
    <li id="leYE">обсуждать инициативы;</li>
    <li id="Hcf4">голосовать за принятие решений.</li>
  </ul>
  <p id="20q5">Вес голоса обычно пропорционален количеству принадлежащих пользователю токенов, хотя существуют и альтернативные модели.</p>
  <p id="H5hZ">Такой подход создаёт эффект skin in the game — участники, принимающие решения, сами заинтересованы в успехе протокола.</p>
  <p id="wZiQ">Предметом голосования могут быть:</p>
  <ul id="VYpq">
    <li id="v8bu">обновления протокола;</li>
    <li id="8uYP">изменение комиссий;</li>
    <li id="uFuk">управление рисками;</li>
    <li id="xr0Y">изменение параметров ликвидности;</li>
    <li id="27Sw">добавление новых активов;</li>
    <li id="7CcP">развитие продукта.</li>
  </ul>
  <h3 id="mSyf">Пример MakerDAO</h3>
  <p id="zwxi">В MakerDAO для управления используются токены MKR.</p>
  <p id="23rt">Держатели MKR голосуют по вопросам:</p>
  <ul id="TRBE">
    <li id="DJWl">выбора типов залога для обеспечения DAI;</li>
    <li id="GnJM">определения процентных ставок;</li>
    <li id="rOBS">настройки риск-параметров системы.</li>
  </ul>
  <p id="UzLo">Эти решения напрямую влияют на стабильность стейблкоина DAI и его привязку к доллару США.</p>
  <p id="T6hz">Одним из инструментов является DAI Savings Rate (DSR) — механизм, позволяющий владельцам DAI получать доходность за хранение токенов в специальном смарт-контракте.</p>
  <p id="7WNL">Если цена DAI на рынке превышает 1 доллар, держатели MKR могут снизить ставку DSR.</p>
  <p id="LxsR">Это:</p>
  <ul id="m9JF">
    <li id="Wh7m">уменьшает спрос на DAI;</li>
    <li id="IaXn">способствует возврату цены к целевому уровню.</li>
  </ul>
  <p id="fD1F">Если цена DAI падает ниже 1 доллара, ставка DSR может быть увеличена.</p>
  <p id="Lx4E">Это:</p>
  <ul id="iAxf">
    <li id="joCh">стимулирует спрос;</li>
    <li id="1Y3c">помогает вернуть цену к отметке 1 доллар.</li>
  </ul>
  <p id="xUSd">Таким образом, MakerDAO передаёт управление тем участникам, которые напрямую заинтересованы в стабильности системы.</p>
  <h3 id="8QHB">Пример Aave</h3>
  <p id="OUSz">Схожую модель использует протокол Aave через токен AAVE.</p>
  <p id="INxI">Владельцы AAVE могут:</p>
  <ul id="AcWW">
    <li id="c2jV">предлагать изменения в протоколе;</li>
    <li id="P4sB">голосовать по предложениям;</li>
    <li id="Dse6">принимать решения о добавлении новых активов;</li>
    <li id="Zzoc">изменять параметры ликвидности;</li>
    <li id="pKRe">корректировать риск-модели.</li>
  </ul>
  <p id="ve1N">Дополнительно в Aave существует Safety Module.</p>
  <p id="LioY">В его рамках держатели AAVE могут размещать свои токены в стейкинг и выступать своеобразным страховым резервом протокола.</p>
  <p id="KhjN">Если возникает серьёзная проблема или дефицит ликвидности, часть застейканных токенов может использоваться для покрытия убытков.</p>
  <p id="7u3f">Поэтому участники управления финансово заинтересованы в принятии осторожных и взвешенных решений.</p>
  <h3 id="qP0d">Преимущества голосования токенами</h3>
  <p id="mZag">Модель token governance обладает рядом преимуществ:</p>
  <ul id="Mnj8">
    <li id="ezkL">решения принимают экономически заинтересованные участники;</li>
    <li id="q2pN">власть распределяется между многими держателями токенов;</li>
    <li id="AjVO">уменьшается зависимость от центрального управляющего органа;</li>
    <li id="7qsn">управление становится более прозрачным.</li>
  </ul>
  <p id="6rvW">В Aave, например, держатели токенов голосуют не только по вопросам безопасности, но и по распределению ликвидности, запуску новых функций и процентной политике протокола.</p>
  <h3 id="DyQb">Проблемы голосования токенами</h3>
  <p id="trlj">Несмотря на преимущества, токенизированное управление сталкивается с серьёзными вызовами.</p>
  <p id="BoaM">Главный из них - концентрация токенов у крупных держателей, так называемых китов (whales).</p>
  <p id="Ofw4">Если значительная часть голосов сосредоточена у небольшого числа участников, управление может фактически стать централизованным, что противоречит идее децентрализации.</p>
  <p id="O9fi">Поэтому многие современные протоколы внедряют дополнительные механизмы, направленные на балансировку влияния крупных держателей и сохранение возможностей участия для более мелких участников сообщества.</p>
  <p id="RYBE">В результате задача токеномики заключается не только в создании токена, но и в построении устойчивой системы распределения власти, стимулов и ответственности внутри децентрализованной экосистемы.</p>
  <h2 id="HRtl">Структуры стимулов: стейкинг и механизмы генерации доходности</h2>
  <p id="YPYu">Стейкинг играет важнейшую роль в экономической модели цифровых токенов. Он стимулирует держателей токенов блокировать свои активы внутри протокола в обмен на вознаграждение.</p>
  <p id="Tdqn">Этот механизм выполняет сразу две функции:</p>
  <ul id="woAQ">
    <li id="BLkK">способствует безопасности сети;</li>
    <li id="q2tq">создаёт доходность для участников.</li>
  </ul>
  <h3 id="Kjda">Пример Lido</h3>
  <p id="42TM">Протокол Lido использует модель ликвидного стейкинга (liquid staking) для Ethereum. Пользователь размещает ETH в стейкинге и получает взамен токены stETH.</p>
  <p id="2Fur">Токены stETH:</p>
  <ul id="8Oig">
    <li id="i8WN">отражают долю пользователя в застейканном ETH;</li>
    <li id="4V9I">накапливают стейкинговые награды;</li>
    <li id="ndQq">могут свободно использоваться в DeFi.</li>
  </ul>
  <p id="fyMH">Главное преимущество ликвидного стейкинга заключается в том, что пользователь не теряет доступ к своему капиталу.</p>
  <p id="hJip">Хотя ETH остаётся заблокированным в механизме консенсуса, stETH остаётся:</p>
  <ul id="m5ng">
    <li id="QQKK">торгуемым активом;</li>
    <li id="NOvx">залогом в кредитных протоколах;</li>
    <li id="95Pc">компонентом LP-позиций;</li>
    <li id="Hlj2">частью других DeFi-стратегий.</li>
  </ul>
  <p id="jx7X">Это повышает ликвидность экосистемы и предоставляет участникам дополнительную гибкость.</p>
  <h3 id="54Rh">Пример Compound и Aave</h3>
  <p id="sgUG">Compound и Aave используют иной подход к созданию доходности.</p>
  <p id="Ehai">Вместо стейкинга они строят её на кредитовании.</p>
  <p id="PKP3">В Compound пользователи:</p>
  <ol id="Pu7W">
    <li id="m0QH">размещают активы в пулах ликвидности;</li>
    <li id="90LY">получают процентный доход;</li>
    <li id="oXLH">доход формируется за счёт процентов, выплачиваемых заёмщиками.</li>
  </ol>
  <p id="uCdu">Процентные ставки определяются алгоритмически в зависимости от спроса и предложения конкретного актива.</p>
  <p id="yVMp">Заёмщики получают кредиты под залог других активов, а выплачиваемые ими проценты становятся доходом поставщиков ликвидности.</p>
  <p id="1vjj">Схожим образом работает и Aave, где процентные ставки автоматически изменяются в зависимости от рыночной ситуации и уровня использования ликвидности.</p>
  <h3 id="53IX">Роль стейкинга и доходности в DeFi</h3>
  <p id="aU1w">Стейкинг и механизмы генерации доходности являются важнейшими драйверами развития экосистемы децентрализованных финансов (DeFi).</p>
  <p id="dw1Z">Они обеспечивают двойной эффект:</p>
  <ul id="lN6o">
    <li id="hAxy">мотивируют пользователей участвовать в работе протокола;</li>
    <li id="gHG7">создают ликвидность для кредитования, торговли и других финансовых операций.</li>
  </ul>
  <p id="tsXT">Однако такие механизмы не лишены рисков.</p>
  <p id="sO9p">Основные угрозы связаны с:</p>
  <ul id="sD8s">
    <li id="zf5E">высокой волатильностью ликвидности;</li>
    <li id="K65C">падением стоимости активов;</li>
    <li id="6Ylm">кризисами ликвидности;</li>
    <li id="UAgD">системными рисками протоколов.</li>
  </ul>
  <p id="3TLr">Для управления этими рисками используются:</p>
  <ul id="LOX0">
    <li id="zRNu">пороги ликвидации (liquidation thresholds);</li>
    <li id="jchu">избыточное обеспечение (over-collateralization);</li>
    <li id="YUiD">динамические процентные ставки;</li>
    <li id="a1Yu">автоматические механизмы ликвидации.</li>
  </ul>
  <h2 id="XKks">Механизмы управления рисками и обеспечения залогом</h2>
  <p id="nbEU">Одним из важнейших аспектов токеномики является внедрение механизмов управления рисками и обеспечения обязательств залогом.</p>
  <p id="A2Ca">Эти механизмы помогают:</p>
  <ul id="JBt0">
    <li id="ThCi">поддерживать стабильность системы;</li>
    <li id="t5ZI">защищать протокол от внешних шоков;</li>
    <li id="0uMH">снижать вероятность потерь участников;</li>
    <li id="yZZg">предотвращать неплатёжеспособность.</li>
  </ul>
  <p id="f5OU">Многие блокчейн-протоколы в значительной степени опираются на обеспечение залогом для защиты от дефолтов, особенно в системах кредитования.</p>
  <h3 id="KWtq">Избыточное обеспечение (Over-Collateralization)</h3>
  <p id="bdCi">Одной из ключевых стратегий управления рисками является избыточное обеспечение.</p>
  <p id="p9SA">В протоколах вроде MakerDAO пользователи обязаны внести залог, стоимость которого превышает объём выпускаемых DAI.</p>
  <p id="GCwJ">Такой подход гарантирует наличие достаточного объёма обеспечения для выпущенных токенов.</p>
  <p id="4OFv">Если стоимость залога снижается ниже установленного порога, система автоматически ликвидирует обеспечение для погашения долга.</p>
  <p id="Ql2w">Это позволяет защитить протокол от системного риска и неплатёжеспособности.</p>
  <h3 id="ckip">Сравнение с Tether</h3>
  <p id="4uAz">Авторы приводят противоположный пример в виде USDT.</p>
  <p id="oMJH">Компания Tether неоднократно подвергалась критике из-за вопросов относительно достаточности резервов, обеспечивающих выпущенные токены USDT (Eichengreen, 2019).</p>
  <p id="oesP">Этот пример показывает, насколько важно наличие прозрачных и надёжных механизмов обеспечения для поддержания доверия и стабильности финансовой системы.</p>
  <h3 id="4xOo">Модели Compound и Aave</h3>
  <p id="zvEn">В Compound и Aave заёмщики также обязаны предоставлять залог перед получением кредита.</p>
  <p id="D9PM">Размер необходимого обеспечения определяется так называемым collateral factor — коэффициентом залога. Он отражает риск конкретного актива.</p>
  <p id="mPun">Более волатильные активы получают более низкий коэффициент обеспечения.</p>
  <p id="enIf">Это означает, что пользователь должен предоставить больший объём залога для получения займа.</p>
  <p id="FsfG">Подобная модель позволяет протоколу сохранять платёжеспособность даже при существенных колебаниях рыночных цен.</p>
  <h3 id="0D10">Flash Loans в Aave</h3>
  <p id="KWlM">Aave внедрил один из самых необычных инструментов управления ликвидностью — флеш-займы (flash loans).</p>
  <p id="Q4Rk">Флеш-займ позволяет получить кредит без предоставления залога при условии, что заём будет полностью возвращён в рамках одной блокчейн-транзакции.</p>
  <p id="OyFm">Этот инструмент используется для:</p>
  <ul id="qVir">
    <li id="VdYT">арбитража;</li>
    <li id="05GA">рефинансирования позиций;</li>
    <li id="IwOU">ликвидаций;</li>
    <li id="giYz">балансировки ликвидности.</li>
  </ul>
  <p id="hTME">Поскольку возврат займа происходит в той же транзакции, протокол практически не принимает на себя кредитный риск.</p>
  <p id="ivHv">Flash loans открыли новые возможности для управления ликвидностью и проведения сложных финансовых операций без угрозы для устойчивости системы.</p>
  <h3 id="FMvj">Stability Fee в MakerDAO</h3>
  <p id="Fo3R">Ещё одним важным инструментом управления рисками является Stability Fee в MakerDAO.</p>
  <p id="XkQ4">Это переменная процентная ставка, начисляемая на займы в DAI.</p>
  <p id="yLYT">Она используется для регулирования предложения стейблкоина.</p>
  <p id="CY3o">Если спрос на DAI слишком высок, увеличение комиссии стимулирует пользователей погашать долги, что приводит к сокращению количества DAI в обращении.</p>
  <p id="9El6">В результате давление на привязку к доллару уменьшается.</p>
  <p id="908w">Таким образом Stability Fee выступает инструментом денежно-кредитной политики внутри протокола MakerDAO.</p>
  <h2 id="0oXz">Значение риск-менеджмента для DAO</h2>
  <p id="jpvV">Благодаря механизмам управления рисками и обеспечения залогом DAO способны поддерживать безопасность и стабильность своих экосистем.</p>
  <p id="o2mb">Эти механизмы позволяют:</p>
  <ul id="EqD1">
    <li id="B96I">защищать активы пользователей;</li>
    <li id="eodQ">минимизировать риск дефолтов;</li>
    <li id="ahLs">предотвращать неплатёжеспособность протокола;</li>
    <li id="p1RB">снижать вероятность системных кризисов.</li>
  </ul>
  <p id="OeuD">Особенно важны такие инструменты в кредитных протоколах, где дефолт отдельных участников может привести к цепной реакции и распространиться на всю экосистему.</p>
  <h2 id="3gIU">Заключение</h2>
  <p id="nRyC">В заключение можно отметить, что токеномика играет фундаментальную роль в формировании экономической архитектуры блокчейн-сетей и децентрализованных приложений.</p>
  <p id="6deg">Посредством тщательного проектирования:</p>
  <ul id="kOfq">
    <li id="apy7">распределения токенов;</li>
    <li id="Slen">механизмов управления;</li>
    <li id="6nro">систем стимулов;</li>
    <li id="Hma6">моделей управления рисками;</li>
  </ul>
  <p id="YMCO">блокчейн-проекты, сообщества и децентрализованные организации стремятся создавать устойчивые экосистемы, в которых интересы участников согласованы с долгосрочным развитием и устойчивостью сети.</p>
  <p id="JCjE">Токеномика определяет не только то, как создаются и используются цифровые токены, но и то, каким образом формируется доверие, распределяется власть, создаётся экономическая ценность и обеспечивается жизнеспособность децентрализованных систем в долгосрочной перспективе.</p>
  <p id="sxcD">[<a href="https://t.me/+iavlR8U7ciVkN2Yy" target="_blank">Продолжение - в группе</a> бесплатных событий...]</p>

]]></content:encoded></item><item><guid isPermaLink="true">https://teletype.in/@menaskop/defi-aave-TALF</guid><link>https://teletype.in/@menaskop/defi-aave-TALF?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop</link><comments>https://teletype.in/@menaskop/defi-aave-TALF?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop#comments</comments><dc:creator>menaskop</dc:creator><title>DeFi. AAVE формализует листинг токенов</title><pubDate>Sat, 30 May 2026 04:21:12 GMT</pubDate><media:content medium="image" url="https://img1.teletype.in/files/c9/58/c9586cd9-354b-44d4-bd36-05e18b5f742a.png"></media:content><category>DeFi</category><description><![CDATA[<img src="https://img3.teletype.in/files/2f/95/2f958e66-05b8-4cce-817c-754dff1dc686.png"></img>Это вольный перевод важнейшего решения: https://governance.aave.com/t/arfc-technical-asset-listing-framework/24988.]]></description><content:encoded><![CDATA[
  <figure id="7IVp" class="m_column">
    <img src="https://img3.teletype.in/files/2f/95/2f958e66-05b8-4cce-817c-754dff1dc686.png" width="1983" />
    <figcaption>AAVE. <strong>TALF</strong></figcaption>
  </figure>
  <h2 id="IDWV">Перевод</h2>
  <p id="bPCS">Это вольный перевод важнейшего решения: <a href="https://governance.aave.com/t/arfc-technical-asset-listing-framework/24988" target="_blank">https://governance.aave.com/t/arfc-technical-asset-listing-framework/24988</a>. </p>
  <h2 id="ts3N">Краткое содержание</h2>
  <p id="4ga4">Aave Labs предлагает внедрить стандартизированный <strong>Technical Asset Listing Framework</strong> (<strong>TALF</strong>) для активов, претендующих на листинг, сохранение листинга или существенное расширение параметров в Aave V3, Aave V4 и Horizon.</p>
  <p id="jiCK">Цель инициативы - сделать процесс листинга и мониторинга активов более единообразным, прозрачным и воспроизводимым, а также создать постоянную базу для контроля того, что уже размещённые активы продолжают соответствовать требованиям <strong>качества</strong> и <strong>безопасности</strong> протокола. </p>
  <p id="1IQR">Фреймворк должен дополнять существующие методологии риск-провайдеров и <strong>Aave Asset Classification Framework </strong>(<strong>AACF</strong>), определяя публичный базовый стандарт технической безопасности.</p>
  <p id="dyWQ">Документ описывает техническую информацию и требования, которые ожидаются от эмитентов активов и участников проверки. Формальные технические отчёты могут содержать качественные оценки или сводки выявленных проблем для использования риск-провайдерами и участниками управления. </p>
  <p id="qxHZ">Однако данный <strong>ARFC</strong> не устанавливает конкретные пороговые значения рейтингов и не определяет исчерпывающий список блокирующих факторов.</p>
  <h2 id="DWLN">Мотивация</h2>
  <p id="ZeD9">Процесс листинга активов в Aave значительно развился со временем благодаря более активному участию риск-провайдеров, технических экспертов и участников DAO. </p>
  <p id="Wlru">По мере расширения протокола на новые рынки, типы активов и блокчейн-сети технические требования должны оставаться достаточно понятными для оценки предложений сообществом, но при этом достаточно строгими для охвата полного спектра рисков актива.</p>
  <p id="qzdw">Среди ключевых требований:</p>
  <ul id="1PQN">
    <li id="F63M">совместимость с ERC-20;</li>
    <li id="Dp98">предсказуемое поведение переводов токена;</li>
    <li id="5hNE">ограниченная эмиссия (bounded minting);</li>
    <li id="pbxX">надёжный контроль привилегированных ролей;</li>
    <li id="51JW">устойчивые и надёжные оракулы;</li>
    <li id="OmGI">безопасная архитектура мостов (bridges);</li>
    <li id="VqJ7">наличие аудита кода;</li>
    <li id="0CpM">раскрытие информации о внецепочечных компонентах и договорённостях, если критически важные данные отсутствуют ончейн.</li>
  </ul>
  <p id="vIPP">Хотя многие из этих вопросов являются техническими, они напрямую влияют на:</p>
  <ul id="2J94">
    <li id="bosz">платёжеспособность Aave;</li>
    <li id="2ql0">процессы ликвидации;</li>
    <li id="GXDv">настройку параметров обеспечения;</li>
    <li id="BxuR">архитектуру оракулов;</li>
    <li id="y0sd">механизмы экстренного реагирования.</li>
  </ul>
  <blockquote id="fHfe">Токен с неограниченной эмиссией, слабыми механизмами управления обновлениями, неподходящим или устаревшим оракулом, рисками рассинхронизации предложения через мосты, непрозрачной процедурой погашения либо недостаточной прозрачностью из-за оффчейн-компонентов может создавать риски, которые невозможно выявить только по рыночным метрикам.</blockquote>
  <p id="DZlr">Поэтому данный <strong>ARFC</strong> предлагает формализовать и стандартизировать технические требования к активам, чтобы все будущие предложения оценивались по единому базовому стандарту, а DAO могло чётко понимать:</p>
  <ul id="hXAE">
    <li id="az9k">какие активы соответствуют требованиям;</li>
    <li id="6dDh">какие требуют дополнительных мер по снижению рисков;</li>
    <li id="7RFm">какие нуждаются в дополнительном аудите или доработке.</li>
  </ul>
  <h2 id="fZon">Область применения</h2>
  <p id="v532">Фреймворк распространяется на:</p>
  <ul id="STaP">
    <li id="cMly">новые листинги активов в любых экземплярах Aave V3, Aave V4 и Horizon;</li>
    <li id="r9Gh">уже размещённые активы, проходящие существенные изменения;</li>
    <li id="g4PE">уже размещённые активы, подлежащие периодической или внеплановой технической переоценке.</li>
  </ul>
  <p id="gvZ9">Фреймворк учитывает особенности разных сетей. Если актив существует в нескольких блокчейнах, он должен соответствовать требованиям в каждой из них отдельно, включая:</p>
  <ul id="3VgH">
    <li id="rQtx">реализацию смарт-контрактов в каждой сети;</li>
    <li id="DO5A">используемые оракулы;</li>
    <li id="1kN6">архитектуру мостов;</li>
    <li id="Gf5A">систему контроля доступа;</li>
    <li id="jGJz">конфигурацию внешних зависимостей.</li>
  </ul>
  <p id="mipY">При этом <strong>фреймворк не заменяет</strong>:</p>
  <ul id="Ke0q">
    <li id="Icgp">анализ рыночных рисков;</li>
    <li id="6lep">анализ ликвидности;</li>
    <li id="9kui">юридическую экспертизу;</li>
    <li id="ozk5">дискреционные решения DAO.</li>
  </ul>
  <p id="meOO">Он  определяет базовый уровень технической пригодности актива. Решения о листинге и параметрах актива по-прежнему остаются за DAO и принимаются на основе полного набора доступной информации, проведённого анализа и рекомендаций сервис-провайдеров.</p>
  <p id="dhKB">Анализ ликвидности и глубины рынка предполагается получать от риск-провайдеров DAO в рамках их стандартной оценки рыночных рисков. Их выводы должны рассматриваться совместно с техническими выводами данного фреймворка при определении таких параметров, как:</p>
  <ul id="BjhI">
    <li id="LrVJ">Supply Cap;</li>
    <li id="7Qk8">Borrow Cap;</li>
    <li id="wqoA">коэффициенты обеспечения (Collateral Parameters).</li>
  </ul>
  <h2 id="QxZO">Связь с AAcA</h2>
  <p id="Kbju">Каждый актив сначала должен быть отнесён к соответствующей категории в рамках <a href="https://governance.aave.com/t/arfc-endorse-the-asset-classification-framework-aaca/23114" target="_blank">Aave Asset Classification Framework (AAcA)</a>.</p>
  <p id="lRdc">На этапе предварительного отбора категория AAcA должна быть подтверждена. Активы, относящиеся к неразрешённым (non-approved) или санкционированным категориям, не должны проходить дальше по процессу оценки.</p>
  <p id="4US8">Классификация AAcA определяет, на каких требованиях необходимо сосредоточить основное внимание при проверке. Например:</p>
  <ul id="6Mnr">
    <li id="kp9o">доходные активы (yield-bearing assets) должны соответствовать специальным требованиям к обменному курсу (exchange rate), процедурам вывода средств (withdrawal path) и механизму CAPO;</li>
    <li id="hMpb">мостовые активы (bridged assets) должны соответствовать требованиям к безопасности мостов и целостности предложения токенов (supply integrity).</li>
  </ul>
  <h2 id="DosR">Методология оценки</h2>
  <p id="nQ0x">Данный фреймворк определяет технические требования к активам, претендующим на листинг, сохранение листинга или существенное расширение параметров в Aave.</p>
  <p id="JCsx">Он <strong>не предназначен</strong> для публикации фиксированных рейтинговых шкал или полного списка автоматических причин для отказа.</p>
  <p id="GeoA">Когда Aave Labs или другой участник готовит официальный технический отчёт по активу, такой отчёт может включать:</p>
  <ul id="WkTH">
    <li id="Kvvc">качественные оценки по отдельным разделам;</li>
    <li id="Jco6">метки рисков (risk labels);</li>
    <li id="HZMB">другие результаты оценки.</li>
  </ul>
  <p id="J951">Эти оценки следует рассматривать как выводы конкретного отчёта, основанные на:</p>
  <ul id="qBsm">
    <li id="MBhA">анализируемом активе;</li>
    <li id="6q2s">конкретной сети развёртывания;</li>
    <li id="NlPo">предоставленной эмитентом информации;</li>
    <li id="kFFf">текущем состоянии рынка и самого протокола.</li>
  </ul>
  <h2 id="MoZX">Что должен содержать технический обзор?</h2>
  <p id="ajDh">Проверка должна чётко разделять фактические выводы и рекомендации.</p>
  <p id="CYiX">Для каждого раздела аудитор или рецензент должен указать:</p>
  <ul id="CqK4">
    <li id="JG01">какие контракты и системы были проверены;</li>
    <li id="rXSy">ключевой вывод;</li>
    <li id="n2ta">необходимые исправления (<strong>remediation</strong>);</li>
    <li id="LoOB">остаточный риск после исправлений;</li>
    <li id="ZNAd">должен ли выявленный риск ограничивать параметры листинга или лимиты экспозиции;</li>
    <li id="lnsf">итоговую качественную оценку и заключение.</li>
  </ul>
  <p id="Gqp5">Отсутствие в данном ARFC конкретных пороговых рейтингов не означает автоматическое одобрение любой реализации, которая формально предоставила запрошенную информацию.</p>
  <p id="XQIw">Существенные недостатки могут привести к:</p>
  <ul id="JC5d">
    <li id="gFX5">снижению лимитов экспозиции;</li>
    <li id="Af94">усиленному мониторингу;</li>
    <li id="MO3F">переносу листинга;</li>
    <li id="Op7h">рекомендации не проводить листинг до устранения проблем.</li>
  </ul>
  <h2 id="OGkt">Требования предварительного отбора (Pre-Screening)</h2>
  <p id="8QK2">До начала полноценной технической проверки актив должен соответствовать следующим требованиям:</p>
  <ol id="ooT0">
    <li id="UMEO">Контракт актива должен быть развёрнут и верифицирован в целевой сети.</li>
    <li id="lqL9">Категория актива в рамках AAcA должна быть подтверждена.</li>
    <li id="3EzH">Актив не должен относиться к неразрешённой или санкционированной категории AAcA.</li>
    <li id="2ISi">Если актив уже присутствует в Aave, существующие листинги должны быть выявлены и использованы как ориентир для параметров там, где это применимо.</li>
    <li id="2yB1">Должен быть определён наиболее близкий по характеристикам актив, уже размещённый в Aave.</li>
    <li id="3BuY">Байткод прокси-контракта и реализации должен совпадать либо быть сопоставлен с последней аудированной версией кода (если используется прокси-архитектура).</li>
    <li id="qAdS">Если существует сопоставимый актив, он должен использоваться как отправная точка для настройки:</li>
    <ul id="sj9r">
      <li id="iCo9">оракулов;</li>
      <li id="kxtM">LTV;</li>
      <li id="m0SC">Liquidation Threshold;</li>
      <li id="d3SV">лимитов (Caps);</li>
      <li id="7kGU">прочих параметров обеспечения.</li>
    </ul>
  </ol>
  <p id="qFBw">При этом окончательные параметры всё равно должны учитывать уникальный технический профиль нового актива.</p>
  <h2 id="OIV7">Стандартный отчёт по результатам проверки (Standard Findings Report)</h2>
  <p id="sicH">Если для актива готовится официальный технический отчёт, он должен использовать стандартизированную структуру, чтобы результаты можно было сопоставлять между различными активами и сетями развёртывания.</p>
  <p id="vbkb">Отчёт может содержать:</p>
  <ul id="Refw">
    <li id="npbk">рейтинг;</li>
    <li id="Ii0Y">уровень серьёзности выявленных проблем;</li>
    <li id="RiLO">рекомендации;</li>
    <li id="bO2c">другие выводы, предусмотренные конкретной методологией проверки.</li>
  </ul>
  <p id="qIUB">При этом данный ARFC не определяет эталонные значения или шкалы для таких оценок.</p>
  <p id="md8h">Если какой-либо раздел неприменим к рассматриваемому активу, проверяющий должен явно объяснить причину.</p>
  <h2 id="frbS">Разделы фреймворка</h2>
  <p id="KQb9">Ниже перечислены основные технические области, которые обычно должны проверяться при рассмотрении:</p>
  <ul id="X9nJ">
    <li id="B0LJ">нового листинга;</li>
    <li id="qLgf">сохранения листинга;</li>
    <li id="bxfu">существенного расширения параметров актива в Aave.</li>
  </ul>
  <p id="Taaj">Этот перечень не является окончательным или исчерпывающим.</p>
  <p id="QAdr">Дополнительные требования могут появляться в зависимости от:</p>
  <ul id="cSLy">
    <li id="Q4XQ">типа актива;</li>
    <li id="Cs5y">особенностей реализации;</li>
    <li id="41pI">среды развёртывания;</li>
    <li id="3ENS">операционной модели эмитента;</li>
    <li id="i0bb">внешних зависимостей;</li>
    <li id="QzRL">новых рисков, выявленных DAO или сервис-провайдерами.</li>
  </ul>
  <h2 id="MGK9">Активы с существенными оффчейн-компонентами</h2>
  <p id="TkV4">Для активов, имеющих значимые внецепочечные элементы, включая:</p>
  <ul id="H7r6">
    <li id="LcK2">токенизированные реальные активы (RWA);</li>
    <li id="93kU">кастодиальные инструменты;</li>
    <li id="8n08">активы, погашение или обеспечение которых зависит от юридических соглашений, а не от смарт-контрактов,</li>
  </ul>
  <p id="4ZdM">требования данного фреймворка применяются прежде всего к ончейн-слою.</p>
  <p id="pa0h">При этом оффчейн-механизмы, влияющие на:</p>
  <ul id="xMla">
    <li id="BLEN">целостность предложения токена (supply integrity);</li>
    <li id="tp2U">надёжность погашения (redemption reliability);</li>
    <li id="YxZJ">контрагентские риски,</li>
  </ul>
  <p id="e0Xe">должны быть раскрыты и оценены в рамках:</p>
  <ul id="ZDmu">
    <li id="sLVM">Раздела 8 (Dependencies and Composability);</li>
    <li id="oAle">раздела Issuer Expectations.</li>
  </ul>
  <p id="GQ70">Если оффчейн-компонент является критически важной зависимостью, он должен проверяться столь же тщательно, как и критическая ончейн-зависимость.</p>
  <h2 id="NrKl">1. Соответствие стандарту ERC-20 (ERC20 Compliance)</h2>
  <p id="1JUq">Активы, размещаемые в Aave, должны вести себя предсказуемо с точки зрения стандартных предположений ERC-20 и общей совместимости с DeFi-протоколами.</p>
  <p id="E5p4"><strong>Технические требования</strong></p>
  <p id="fuWE">Контракт должен корректно реализовывать следующие функции:</p>
  <ul id="bVKj">
    <li id="TKFg"><code>name()</code></li>
    <li id="dlio"><code>symbol()</code></li>
    <li id="9OIN"><code>decimals()</code></li>
    <li id="wOaB"><code>totalSupply()</code></li>
  </ul>
  <p id="Qwjh">и возвращать разумные значения.</p>
  <p id="bFTn">Функции:</p>
  <ul id="XCd1">
    <li id="ZX6Q"><code>transfer()</code></li>
    <li id="1zkW"><code>transferFrom()</code></li>
  </ul>
  <p id="eDLo">должны возвращать булево значение (<code>bool</code>).</p>
  <p id="q23q">Токен не должен иметь механизмов:</p>
  <ul id="wvW1">
    <li id="PTLQ">Fee-on-Transfer (комиссия при переводе);</li>
    <li id="Rwsv">автоматического ребейза (rebase),</li>
  </ul>
  <p id="nMF2">если только не используется специальная обёртка (wrapper), которая устраняет эти особенности.</p>
  <p id="VzEw">Токен не должен использовать:</p>
  <ul id="A39F">
    <li id="pYI5">ERC-777 Hooks;</li>
    <li id="1Ro8">callback-механизмы передачи ERC-1363.</li>
  </ul>
  <p id="m4cV">Если поддерживается Flash Mint, необходимо:</p>
  <ul id="IYps">
    <li id="TYVE">полностью документировать механизм;</li>
    <li id="bTlm">доказать, что он не нарушает учёт активов и логику работы Aave.</li>
  </ul>
  <p id="urCr">Смарт-контракты должны иметь возможность:</p>
  <ul id="w5da">
    <li id="xyeY">хранить токены;</li>
    <li id="gTt2">получать токены;</li>
    <li id="HJy1">отправлять токены</li>
  </ul>
  <p id="faF1">без необходимости попадания в белый список или получения специальных разрешений.</p>
  <p id="wX6Z">Количество десятичных знаков (<code>decimals</code>) должно быть совместимо с:</p>
  <ul id="XnVj">
    <li id="Y6ci">интеграциями Aave;</li>
    <li id="wmvr">пользовательскими интерфейсами Aave.</li>
  </ul>
  <p id="2yUf"><strong>Что считается проблемой?</strong></p>
  <p id="topm">Следующие особенности обычно требуют исправления либо специального подхода к листингу:</p>
  <ul id="1NZ0">
    <li id="DIoS">Fee-on-Transfer токены;</li>
    <li id="kCf1">ребейзинг-токены без безопасной обёртки;</li>
    <li id="iOoM">использование ERC-777 Hooks;</li>
    <li id="WFjD">нестандартные decimals, которые невозможно безопасно интегрировать.</li>
  </ul>
  <p id="lXA8">До устранения таких проблем актив обычно не рассматривается как полностью соответствующий требованиям фреймворка.</p>
  <hr />
  <p id="gS9Z">Для RWA-проектов и стейблкоинов это означает, что Aave фактически начинает с самого базового вопроса:</p>
  <blockquote id="uU1j">Можно ли обращаться с этим токеном как с обычным ERC-20 без скрытых побочных эффектов для учёта, ликвидаций и залоговой системы?</blockquote>
  <p id="dfNM">Если ответ отрицательный, дальнейший анализ часто теряет смысл до устранения этой проблемы.</p>
  <h2 id="LAok">2. Оракулы (Oracle)</h2>
  <p id="OMuo">Для каждого актива, размещаемого в Aave, необходим надёжный источник ценовых данных. Оракул является одной из ключевых составляющих безопасности протокола, поэтому любая схема ценообразования, которая не использует Chainlink в качестве основного источника, должна быть отдельно обоснована.</p>
  <p id="gdiI"><strong>Технические требования</strong></p>
  <ul id="grw4">
    <li id="jSC0">В целевой сети должен существовать ценовой фид Chainlink, который используется напрямую либо через адаптер CAPO, если это необходимо.</li>
    <li id="8111">Количество десятичных знаков (decimals) в ценовом фиде должно соответствовать стандартам Aave.</li>
    <li id="kDkh">Ценовой фид должен работать в рамках ожидаемых параметров heartbeat и deviation threshold. Любые отклонения должны быть отдельно объяснены.</li>
    <li id="J0Xs">По возможности должны быть определены аналогичные оракульные адаптеры из уже существующих развёртываний Aave.</li>
    <li id="Reuj">Необходимо проверить и задокументировать уровень риска соответствующего фида Chainlink (Chainlink Market Risk Tier).</li>
    <li id="j9lF">Для доходных активов (yield-bearing assets) должен использоваться CAPO там, где это требуется для ограничения предположений о росте цены или обменного курса.</li>
  </ul>
  <p id="Z9aQ">Отсутствие оракульной инфраструктуры, устаревшие данные, повышенный риск фида или отсутствие надёжного механизма определения цены должны быть вынесены на рассмотрение риск-провайдеров и отражены в рекомендациях по листингу, параметрам актива и его мониторингу.</p>
  <h2 id="1oMN">3. Контроль доступа и управление активом (Asset Operations Access Control)</h2>
  <p id="jfTx">Актив должен иметь понятную систему контроля доступа и гарантии безопасности предложения токенов как на уровне ERC-20 контракта, так и на уровне вспомогательных (periphery) контрактов, способных влиять на:</p>
  <ul id="WCrJ">
    <li id="f9U0">предложение токенов;</li>
    <li id="rzYy">балансы пользователей;</li>
    <li id="Jmpt">возможность перевода токенов;</li>
    <li id="HsAj">процедуры погашения (redemption).</li>
  </ul>
  <p id="Z5jK">Помимо перечисления привилегированных ролей необходимо оценивать:</p>
  <ul id="2cvN">
    <li id="D3QQ">кому принадлежат эти роли;</li>
    <li id="IlWi">насколько они сконцентрированы;</li>
    <li id="drDP">создаёт ли их структура общие точки отказа (correlated failure modes).</li>
  </ul>
  <p id="AY8N"><strong>Уровни безопасности ролей</strong>:</p>
  <ul id="Rh9y">
    <li id="9C5G">Один приватный ключ (EOA), без задержек и мультисиг-защиты: 0</li>
    <li id="1rcd">Мультисиг без честного большинства подписантов: 1</li>
    <li id="XMk0">Мультисиг с честным большинством, без timelock: 2</li>
    <li id="1Saw">Мультисиг с timelock менее 48 часов: 3</li>
    <li id="s2Jn">Мультисиг с timelock не менее 48 часов: 4</li>
    <li id="U6K0">DAO-управление ончейн + timelock: 5</li>
  </ul>
  <p id="Z2f5">Под <strong>слабой конфигурацией безопасности (weak security configuration)</strong> далее понимается любой держатель роли уровня 0 или 1.</p>
  <p id="qmGa">Эта классификация должна использоваться при определении:</p>
  <ul id="beLh">
    <li id="LPeC">лимитов экспозиции;</li>
    <li id="S1bO">требований к мониторингу;</li>
    <li id="CCkN">необходимых мер по устранению рисков.</li>
  </ul>
  <h3 id="GluG">3a. Карта ролей ERC-20 (ERC20 Role Mapping)</h3>
  <p id="a3fC">Эмитент обязан раскрыть и задокументировать все привилегированные роли контракта.</p>
  <p id="jb2i">К ним относятся:</p>
  <ul id="OSk3">
    <li id="npyI">owner/admin;</li>
    <li id="H46u">default admin;</li>
    <li id="tmx8">minter;</li>
    <li id="TBsJ">burner;</li>
    <li id="JJrO">pauser;</li>
    <li id="EBDB">blacklister;</li>
    <li id="snre">bridge/adaptor roles;</li>
    <li id="WMdr">любые иные специальные роли протокола.</li>
  </ul>
  <p id="my53">Для каждой роли необходимо предоставить:</p>
  <ul id="2gyU">
    <li id="mMDl">адрес держателя;</li>
    <li id="xSUy">тип держателя;</li>
    <li id="2vSj">модель безопасности;</li>
    <li id="KPs8">административную иерархию назначения и отзыва ролей.</li>
  </ul>
  <p id="7gdV">Концентрация ролей должна быть отдельно оценена.</p>
  <h3 id="9f1r">3b. Карта вспомогательных контрактов (Periphery Role Mapping)</h3>
  <p id="17be">К вспомогательным относятся любые контракты, которые:</p>
  <ul id="GqZe">
    <li id="dI0J">владеют ролями токена;</li>
    <li id="UplU">способны влиять на эмиссию;</li>
    <li id="PYpp">способны влиять на балансы пользователей;</li>
    <li id="hfD3">способны изменять ключевую функциональность токена.</li>
  </ul>
  <p id="fNsr">Примеры:</p>
  <ul id="Pw01">
    <li id="xGV9">bridge adapters;</li>
    <li id="QDqT">minters;</li>
    <li id="q7a9">treasury controllers;</li>
    <li id="xkSs">fee receivers;</li>
    <li id="3QcP">redemption contracts;</li>
    <li id="VNJA">staking wrappers;</li>
    <li id="SUd8">другие привилегированные модули.</li>
  </ul>
  <p id="bY3x">Эмитент должен:</p>
  <ul id="NwVN">
    <li id="9t34">раскрыть все такие контракты;</li>
    <li id="oIzm">предоставить исходный код;</li>
    <li id="GLk7">раскрыть их административную структуру;</li>
    <li id="5AMy">подтвердить, что они не могут обновляться под более слабым контролем, чем сам токен.</li>
  </ul>
  <h3 id="vhgn">3c. Логика эмиссии и сжигания (Minting and Burning Logic)</h3>
  <p id="jikN">Актив должен обеспечивать высокую целостность предложения токенов.</p>
  <p id="zSpp">Эмитент обязан раскрыть:</p>
  <ul id="OAvJ">
    <li id="lSWh">кто может выпускать токены;</li>
    <li id="lyRc">кто может их сжигать;</li>
    <li id="q6TO">при каких условиях это происходит;</li>
    <li id="H7YI">существуют ли лимиты и ограничения.</li>
  </ul>
  <p id="cfZy"><strong>Технические требования</strong>:</p>
  <ul id="NRtB">
    <li id="BKi2">Должны быть определены точные функции <strong>mint</strong> и <strong>burn</strong>.</li>
    <li id="JQoZ">Необходимо раскрыть все авторизованные адреса.</li>
    <li id="A1D3">Эмиссия должна иметь жёсткие лимиты или периодические ограничения.</li>
    <li id="QRY0">Адрес, увеличивающий лимит эмиссии, должен отличаться от адреса, который этот лимит использует.</li>
    <li id="fgnR">Необходимо оценить максимальный объём возможной эмиссии в USD и сравнить его с потенциальной залоговой экспозицией Aave.</li>
    <li id="dvHl">Привилегированный адрес не должен иметь возможность сжигать токены с произвольных пользовательских кошельков.</li>
    <li id="kCYc">События mint и burn должны логироваться через события (events).</li>
  </ul>
  <p id="UQ1r">Особенно проблемными считаются случаи, когда:</p>
  <ul id="9Ouf">
    <li id="8DFR">эмиссия контролируется адресом со слабой конфигурацией безопасности;</li>
    <li id="GmJS">эмиссия не ограничена;</li>
    <li id="aS2W">один адрес может и повышать лимиты, и использовать их;</li>
    <li id="HrY5">существует возможность произвольного сжигания пользовательских токенов.</li>
  </ul>
  <p id="frZy">Такие ситуации обычно требуют устранения либо серьёзно ограничивают рекомендации по листингу.</p>
  <h3 id="bKu1">3d. Возможности паузы и чёрного списка (Pause and Blacklist Capability)</h3>
  <p id="daat">Механизмы паузы и блокировки адресов должны быть раскрыты, поскольку они напрямую влияют на ликвидации и вывод средств в Aave.</p>
  <p id="MYO2"><strong>Требования</strong>:</p>
  <ul id="1k9O">
    <li id="fHjc">Должен быть определён владелец права паузы (pause/freeze).</li>
    <li id="r6aL">Должен быть определён владелец права чёрного списка (blacklist).</li>
    <li id="EqbI">Необходимо раскрыть адреса держателей этих полномочий и их модель безопасности.</li>
    <li id="XZwG">Blacklist-механизм не должен иметь возможности незаметно блокировать ликвидации Aave без ведома DAO.</li>
  </ul>
  <p id="bVOR">Хотя подобные механизмы могут быть необходимы для некоторых активов, их влияние на работу Aave должно быть полностью понятно до листинга или расширения параметров.</p>
  <h3 id="JxmG">3e. Обновляемость контрактов (Upgradeability)</h3>
  <p id="mtuY">Актив и его критически важные вспомогательные контракты должны иметь понятную и безопасную модель обновления.</p>
  <p id="aYVe">Если контракты обновляемые, необходимо определить, кто контролирует процесс обновления и какие ограничения действуют на этот контроль.</p>
  <p id="KRSz"><strong>Технические требования</strong>:</p>
  <ul id="DmGc">
    <li id="Ptpb">Необходимо определить тип прокси:</li>
    <ul id="9i2f">
      <li id="204l">Transparent Proxy;</li>
      <li id="pbjx">UUPS;</li>
      <li id="H2Li">Beacon;</li>
      <li id="mLjV">либо неизменяемый контракт (Immutable).</li>
    </ul>
    <li id="nwL9">Должен быть определён Proxy Admin или иной орган обновления.</li>
    <li id="T9kx">Контроль обновления не должен находиться у адреса со слабой конфигурацией безопасности.</li>
    <li id="fWw8">Proxy Admin должен представлять собой мультисиг, timelock или DAO-механизм с проверенным исходным кодом и достаточными экономическими гарантиями.</li>
    <li id="0BEe">Задержка timelock должна быть раскрыта.</li>
    <li id="8nQY">История обновлений не должна содержать подозрительных или необъяснённых изменений.</li>
  </ul>
  <p id="yTed">С точки зрения Aave путь обновления через слабую конфигурацию безопасности не соответствует ожидаемому стандарту. Даже мультисиг без значимого timelock может считаться допустимым лишь временно и обычно приводит к ограничениям по экспозиции до тех пор, пока DAO не убедится в надёжности операционной модели эмитента.</p>
  <h2 id="gL4p">4. Механизм обменного курса и доходности (Exchange Rate and Yield Mechanism)</h2>
  <p id="koce">Этот раздел применяется к:</p>
  <ul id="WrHk">
    <li id="iht4">доходным активам (yield-bearing assets);</li>
    <li id="sHqK">обёрткам (wrappers);</li>
    <li id="oHeA">LST (Liquid Staking Tokens);</li>
    <li id="F3Vd">LRT (Liquid Restaking Tokens);</li>
    <li id="sFDw">токенам хранилищ (vault tokens);</li>
    <li id="HvuE">аналогичным инструментам.</li>
  </ul>
  <h3 id="Vshg">Технические требования</h3>
  <ul id="wvGb">
    <li id="dUT9">Функция расчёта обменного курса (exchange rate) должна быть определена и задокументирована.</li>
    <li id="bfx0">В нормальных условиях обменный курс должен быть монотонно неубывающим, если только снижение стоимости не предусмотрено самой моделью актива (например, через слэшинг или отрицательную доходность).</li>
    <li id="DPLA">Курс не должен поддаваться манипуляции в рамках одной транзакции через:</li>
    <ul id="G3bg">
      <li id="fUCS">пожертвования (donations);</li>
      <li id="uC92">flash loans;</li>
      <li id="RiQB">особенности бухгалтерского учёта.</li>
    </ul>
    <li id="dVvh">Размещаемый токен не должен использовать ребейзинг.</li>
    <li id="A3oi">Последствия слэшинга или отрицательного ребейза должны быть полностью понятны и отражены в параметрах риска.</li>
    <li id="g9Cp">Процедура вывода базового актива должна быть прозрачной и пригодной для ликвидаций.</li>
    <li id="l1mj">Если требуется CAPO, для него должен быть установлен обоснованный лимит роста относительно ожидаемой доходности.</li>
    <li id="fQLj">Необходимо задокументировать точность расчётов и правила округления.</li>
  </ul>
  <h3 id="NjeQ">Что считается проблемой</h3>
  <p id="80Ik">Обычно требуют исправления либо серьёзно ограничивают листинг:</p>
  <ul id="mifa">
    <li id="LrM3">обменный курс, который можно манипулировать одной транзакцией;</li>
    <li id="OEyP">доходный актив без CAPO там, где CAPO необходим;</li>
    <li id="LmRP">актив без механизма погашения и без достаточной ликвидности на вторичном рынке.</li>
  </ul>
  <p id="gE9c">Для таких активов, как stETH, weETH, rsETH, ezETH и других LST/LRT, этот раздел фактически проверяет:</p>
  <blockquote id="yoUg">Насколько безопасно и предсказуемо растёт exchange rate и сможет ли Aave корректно ликвидировать позиции в стрессовой ситуации?</blockquote>
  <h2 id="ATUA">5. Архитектура токена (Token Architecture)</h2>
  <p id="MZRS">Актив должен иметь архитектуру, совместимую с интеграциями Aave и не содержать скрытых предположений относительно:</p>
  <ul id="2vso">
    <li id="zm8V">предложения токенов;</li>
    <li id="YZ0c">переводов;</li>
    <li id="F9UC">контроля доступа.</li>
  </ul>
  <h3 id="CXU1">Технические требования</h3>
  <ul id="nuVN">
    <li id="Hgv2">Должна быть полностью понятна модель предложения:</li>
    <ul id="gxUW">
      <li id="PQ95">фиксированная эмиссия;</li>
      <li id="LshE">инфляционная модель;</li>
      <li id="l7cl">эмиссия под контролем эмитента.</li>
    </ul>
    <li id="T8N3">Ограничения на переводы должны быть раскрыты и совместимы с принципами DeFi-композируемости.</li>
    <li id="tTgJ">Контроль доступа не должен основываться на <code>tx.origin</code>.</li>
    <li id="N1mn">Контракт не должен позволять выполнять <code>delegatecall</code> в произвольные внешние контракты.</li>
    <li id="w7JM">Все привилегированные функции должны быть явно задокументированы и защищены системой прав доступа.</li>
    <li id="8O6x">Не должно существовать нескольких независимых точек выпуска одного и того же предложения токенов, включая:если между ними отсутствует прозрачный механизм учёта общего предложения.</li>
    <ul id="yLle">
      <li id="lU6W">дублирующиеся деплойменты;</li>
      <li id="Yl5e">старые версии токенов;</li>
      <li id="M1qN">миграционные контракты,</li>
    </ul>
  </ul>
  <h2 id="Uh4M">6. Риски мостов и кроссчейн-инфраструктуры (Bridge and Cross-Chain Risk)</h2>
  <p id="tfwy">Для активов, чья целостность предложения зависит от мостов, вводятся дополнительные требования.</p>
  <h3 id="VGGw">Технические требования</h3>
  <p id="0W18">Необходимо определить и задокументировать:</p>
  <ul id="bG8O">
    <li id="6hAZ">исходную сеть (origin chain);</li>
    <li id="jQN6">каноническое предложение токена;</li>
    <li id="xuwo">представление токена в целевой сети;</li>
    <li id="jN6x">используемый мост или систему сообщений;</li>
    <li id="Rdmt">конфигурацию валидаторов, аттестаторов, оракулов или DVN;</li>
    <li id="E1Rs">лимиты скорости переводов (rate limits);</li>
    <li id="eq9y">механизмы эскроу;</li>
    <li id="BKsg">административный контроль и обновление моста.</li>
  </ul>
  <h3 id="lMiY">Важный принцип</h3>
  <blockquote id="oYM0">Проверка не должна ограничиваться только целевой сетью.</blockquote>
  <p id="4BRy">Если канонический токен в исходной сети:</p>
  <ul id="sbZ8">
    <li id="ltTE">обновляемый (<strong>upgradeable</strong>);</li>
    <li id="96w6">имеет функцию эмиссии (<strong>mintable</strong>);</li>
    <li id="xG7a">управляется слабыми механизмами доступа,</li>
  </ul>
  <p id="GK4f">то эта слабость распространяется на всю кроссчейн-модель предложения независимо от качества самого моста.</p>
  <h3 id="TXny">Что считается серьёзным риском?</h3>
  <p id="MzeR">Особое внимание должно уделяться случаям, когда присутствуют:</p>
  <ul id="5NxP">
    <li id="0dtO">мосты со слабой моделью безопасности;</li>
    <li id="LKCB">отсутствие надёжной верификации;</li>
    <li id="8PxQ">неограниченная эмиссия через мосты;</li>
    <li id="ewWj">слабый контроль Bridge Admin.</li>
  </ul>
  <p id="OV2J">Такие риски должны напрямую отражаться в рекомендациях по:</p>
  <ul id="3hJV">
    <li id="6lDw">листингу;</li>
    <li id="xOFF">лимитам экспозиции;</li>
    <li id="q5zQ">мониторингу.</li>
  </ul>
  <h2 id="HLyc">7. Аудиты и история безопасности (Audit and Security History)</h2>
  <p id="DIPx">Актив должен иметь актуальную и релевантную историю проверок безопасности, охватывающую как сам токен, так и критические зависимости.</p>
  <h3 id="UdIQ">Технические требования</h3>
  <ul id="s5M3">
    <li id="Vxc9">Текущая развёрнутая версия должна быть проверена авторитетным аудитором.</li>
    <li id="JmOp">Не должно оставаться неустранённых замечаний уровня Critical или High.</li>
    <li id="F6ub">Дата аудита должна быть достаточно свежей относительно последних существенных изменений кода.</li>
    <li id="OSs7">Должна существовать bug bounty программа, соответствующая предполагаемому TVL актива.</li>
    <li id="zxKO">Все прошлые инциденты должны быть задокументированы вместе с:</li>
    <ul id="CL5b">
      <li id="94ji">post-mortem отчётом;</li>
      <li id="Ez0G">описанием исправлений.</li>
    </ul>
    <li id="Cz9z">Развёрнутый код должен совпадать с последней аудированной версией по соответствующему commit hash.</li>
    <li id="Hmxu">Эмитент должен иметь официальный канал коммуникации и обязаться заранее уведомлять команду Aave о существенных изменениях.</li>
  </ul>
  <h3 id="wCCQ">Что считается проблемой?</h3>
  <p id="4h9o">Обычно требуют исправления либо существенно ограничивают листинг:</p>
  <ul id="tqeY">
    <li id="iI6l">отсутствие аудита;</li>
    <li id="WaQE">наличие открытых Critical или High замечаний;</li>
    <li id="15U1">прошлый эксплойт без документированного исправления.</li>
  </ul>
  <p id="Cc7S">Интересно, что если собрать разделы 1–7 вместе, то получится почти полный чек-лист для оценки любого RWA, стейблкоина, LST/LRT или мостового актива перед листингом в Aave: ERC20 → Oracle → Access Control → Mint/Burn → Yield Logic → Architecture → Bridges → Security History. Именно на этих пунктах сегодня чаще всего проваливаются новые активы.</p>
  <h1 id="1VlC">8. Зависимости и композируемость (Dependencies and Composability)</h1>
  <p id="Xu42">Внешние зависимости должны быть задокументированы, поскольку они могут негативно повлиять на актив, даже если сам токен реализован корректно.</p>
  <p id="IDVz">К таким зависимостям относятся:</p>
  <ul id="QUGx">
    <li id="Ft8Y">стейкинг-протоколы;</li>
    <li id="csE7">хранилища (vaults);</li>
    <li id="EOZn">мосты;</li>
    <li id="5fTA">кастодианы;</li>
    <li id="3JfA">оракульные системы;</li>
    <li id="DvjK">валидаторы;</li>
    <li id="9GYf">операторы инфраструктуры;</li>
    <li id="C8O7">слои рестейкинга;</li>
    <li id="SZtx">механизмы погашения (redemption infrastructure).</li>
  </ul>
  <h3 id="pb4m">Технические требования</h3>
  <ul id="ieNM">
    <li id="jk15">Все внешние зависимости должны быть идентифицированы.</li>
    <li id="Mtpt">Каждая зависимость должна иметь собственную историю аудитов и эксплуатации в продакшене.</li>
    <li id="bYnJ">Управление зависимостью не должно иметь возможности незаметно для ончейна нарушить работу актива.</li>
    <li id="meug">Очереди вывода средств и сроки вывода должны быть совместимы с предположениями Aave относительно ликвидаций.</li>
    <li id="BJmd">Необходимо раскрыть концентрацию среди:</li>
    <ul id="LOzu">
      <li id="xbgM">валидаторов;</li>
      <li id="PhII">операторов;</li>
      <li id="q9wl">кастодианов.</li>
    </ul>
    <li id="RjAF">Там, где это применимо, должны быть количественно оценены сценарии:</li>
    <ul id="uXyW">
      <li id="TCCa">слэшинга;</li>
      <li id="w8aA">неплатёжеспособности (<strong>insolvency</strong>).</li>
    </ul>
  </ul>
  <p id="4Dlh">Критически важная зависимость со слабой моделью управления или без аудита обычно требует исправления либо приводит к существенным ограничениям на листинг и лимиты экспозиции.</p>
  <h2 id="6ngv">Ожидания от эмитента (Issuer Expectations)</h2>
  <p id="nkYA">Данный фреймворк охватывает только техническую сторону пригодности актива к листингу.</p>
  <p id="XmhM">Предполагается, что в будущем он будет дополнен отдельным нетехническим фреймворком, который будет оценивать:</p>
  <ul id="j04N">
    <li id="D5mB">юридическую структуру эмитента;</li>
    <li id="s9ro">раскрытие информации о компании;</li>
    <li id="RzVv">регуляторный статус;</li>
    <li id="ssb7">операционные процессы;</li>
    <li id="Vmof">юридическую природу прав на базовый актив;</li>
    <li id="Naj3">иные факторы, важные для DAO при принятии решения о листинге.</li>
  </ul>
  <p id="RSKJ">Эмитенты должны понимать, что для листинга потребуется соответствовать как техническим, так и операционным требованиям, поскольку оффчейн-структура напрямую влияет на ончейн-риски.</p>
  <p id="fiA7">Если часть информации является конфиденциальной, она может быть раскрыта приватно соответствующему риск-провайдеру или сервис-провайдеру.</p>
  <p id="s3hd">Однако публичное предложение по управлению всё равно должно содержать:</p>
  <ul id="dVxN">
    <li id="zWbF">краткое описание результатов проверки;</li>
    <li id="p32Y">итоговую оценку;</li>
    <li id="4ve5">описание остаточных рисков,</li>
  </ul>
  <p id="daK2">чтобы DAO могла принимать осознанные решения.</p>
  <h2 id="8xXU">Интеграция в процесс управления (Governance Process Integration)</h2>
  <p id="uHSI">Фреймворк предлагается встроить в процесс листинга и расширения активов следующим образом.</p>
  <h3 id="5PHX">1. Предварительная проверка (Pre-screening)</h3>
  <p id="T8wk">Подтверждаются:</p>
  <ul id="juUi">
    <li id="Ab90">классификация AACF/AAcA;</li>
    <li id="UD39">верификация контракта;</li>
    <li id="a4xy">наличие аналогичных листингов в Aave;</li>
    <li id="ef78">базовая пригодность актива.</li>
  </ul>
  <h3 id="iY3l">2. Технический обзор (Technical Review)</h3>
  <p id="Tq21">Проводится оценка актива по всем разделам фреймворка и выявляются существенные технические риски.</p>
  <h3 id="B1Zc">3. Координация с риск-провайдерами</h3>
  <p id="PXqT">Технические выводы сопоставляются с:</p>
  <ul id="vzeN">
    <li id="hHge">параметрами рыночного риска;</li>
    <li id="TkW9">лимитами;</li>
    <li id="CNlI">конфигурацией оракулов;</li>
    <li id="eZwd">условиями листинга.</li>
  </ul>
  <h3 id="q5Wd">4. Публикация предложения</h3>
  <p id="bfRn">В governance-предложение включается стандартизированная таблица результатов проверки.</p>
  <h3 id="0wre">5. Контроль исправлений (Remediation Tracking)</h3>
  <p id="IBpb">Документируются:</p>
  <ul id="D6Jl">
    <li id="LhEM">необходимые исправления;</li>
    <li id="FK7B">являются ли они обязательным условием листинга;</li>
    <li id="qDDC">либо могут быть выполнены уже после листинга.</li>
  </ul>
  <h3 id="5lZo">6. Регулярное обновление оценки (Ongoing Refresh)</h3>
  <p id="5EAO">Проверка должна проводиться:</p>
  <ul id="IdvF">
    <li id="0FSc">ежегодно для всех активных активов;</li>
    <li id="Jhqt">немедленно при существенных изменениях.</li>
  </ul>
  <p id="Ttp2">Под существенными изменениями понимаются:</p>
  <ul id="4nn1">
    <li id="6Wsu">обновление контрактов;</li>
    <li id="3MI1">запуск в новых сетях;</li>
    <li id="Z6XW">новые или изменённые мостовые маршруты;</li>
    <li id="xkFr">изменение держателей привилегированных ролей;</li>
    <li id="0zfT">изменение модели безопасности;</li>
    <li id="wNzq">изменение лимитов эмиссии;</li>
    <li id="F9BD">изменение критических зависимостей;</li>
    <li id="eAfX">инциденты безопасности актива или его ключевых компонентов.</li>
  </ul>
  <p id="o4mq">Сервис-провайдеры и Aave Labs должны сообщать о таких изменениях DAO по мере их обнаружения.</p>
  <p id="NW1h">Эмитенты обязаны уведомлять о них заранее в рамках своих постоянных обязательств.</p>
  <h2 id="Bwa8">Главная идея</h2>
  <p id="DJIO">Фреймворк не должен создавать лишние препятствия для простых и хорошо контролируемых активов.</p>
  <p id="wQSf">Его задача - сделать требования более предсказуемыми и выявлять технические проблемы до того, как они превратятся в риск для протокола.</p>
  <h2 id="a9Vv">Обращение с выявленными проблемами (Treatment of Findings)</h2>
  <p id="k7sR">Результаты проверки должны напрямую превращаться в управленческие и риск-менеджмент решения.</p>
  <p id="m5Zi">В зависимости от серьёзности проблемы последствия могут включать:</p>
  <ul id="ndLR">
    <li id="pmEi">снижение Supply Cap;</li>
    <li id="3AmM">снижение Borrow Cap;</li>
    <li id="XuR8">уменьшение LTV;</li>
    <li id="QAwZ">запрет использования актива в качестве залога;</li>
    <li id="hBY2">дополнительный мониторинг;</li>
    <li id="YSoI">обязательные исправления со стороны эмитента;</li>
    <li id="vmtR">периодические повторные проверки;</li>
    <li id="qcXk">рекомендацию отложить листинг или расширение параметров.</li>
  </ul>
  <p id="L8Y3">Формальные технические отчёты могут использовать:</p>
  <ul id="6Fua">
    <li id="QH4e">качественные рейтинги;</li>
    <li id="l1JN">уровни серьёзности (severity labels);</li>
    <li id="VUzu">другие формы оценки,</li>
  </ul>
  <p id="0rt2">чтобы передавать выводы риск-провайдерам и участникам управления.</p>
  <p id="Zj5y">Однако такие оценки являются частью конкретного отчёта и не считаются универсальными шкалами, установленными данным ARFC.</p>
  <h2 id="EtC8">Если DAO всё же принимает риск?</h2>
  <p id="b5WO">Если DAO решает листить актив несмотря на наличие существенных нерешённых проблем, в предложении должно быть прямо указано:</p>
  <ul id="Uy3V">
    <li id="OGlX">какой остаточный риск остаётся;</li>
    <li id="eCqd">почему DAO считает этот риск приемлемым.</li>
  </ul>
  <p id="mteV">Если посмотреть на весь документ целиком, то это фактически попытка Aave превратить листинг активов в стандартизированный <strong>due diligence-фреймворк</strong>, очень похожий на то, как банки или институциональные кастодианы оценивают новые финансовые инструменты. Особенно это заметно по разделам про:</p>
  <ul id="JOBq">
    <li id="rk1f">контроль эмиссии;</li>
    <li id="s6Rr">апгрейды;</li>
    <li id="UzuY">мосты;</li>
    <li id="oTmw">оракулы;</li>
    <li id="IYyH">оффчейн-зависимости;</li>
    <li id="8qTH">раскрытие информации об эмитенте.</li>
  </ul>
  <p id="xbiA">Для RWA, стейблкоинов, LST/LRT и кроссчейн-активов такой подход может стать новым де-факто стандартом листинга далеко за пределами самого Aave.</p>
  <p id="Hwoo"><em>До!</em></p>

]]></content:encoded></item><item><guid isPermaLink="true">https://teletype.in/@menaskop/W0R4VxiU79k</guid><link>https://teletype.in/@menaskop/W0R4VxiU79k?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop</link><comments>https://teletype.in/@menaskop/W0R4VxiU79k?utm_source=teletype&amp;utm_medium=feed_rss&amp;utm_campaign=menaskop#comments</comments><dc:creator>menaskop</dc:creator><title>Токеномика. RWA. Товарно-обеспеченные стейблкоины</title><pubDate>Wed, 27 May 2026 06:28:08 GMT</pubDate><media:content medium="image" url="https://img3.teletype.in/files/a1/93/a1930fb7-8383-41a3-9733-12d440fd33ac.png"></media:content><description><![CDATA[<img src="https://img3.teletype.in/files/e8/b1/e8b1084e-2955-4d67-bd47-fdff9190340a.png"></img>Это вольный перевод: chain.link/article/commodity-backed-stablecoins.]]></description><content:encoded><![CDATA[
  <figure id="tFeD" class="m_column">
    <img src="https://img3.teletype.in/files/e8/b1/e8b1084e-2955-4d67-bd47-fdff9190340a.png" width="1693" />
    <figcaption>RWA</figcaption>
  </figure>
  <h2 id="5aON">Перевод</h2>
  <p id="rYrs">Это вольный перевод: <a href="https://chain.link/article/commodity-backed-stablecoins" target="_blank">chain.link/article/commodity-backed-stablecoins</a>.</p>
  <h2 id="Cmng">Определение</h2>
  <p id="paNm">Товарно-обеспеченный стейблкоин - криптовалюта, привязанная к стоимости физического актива, такого как золото, нефть или недвижимость. Эти токены сочетают стабильность материальных ресурсов с эффективностью, прозрачностью и программируемостью блокчейн-технологий.</p>
  <p id="DPoE">Стабильность - необходимое условие для массового внедрения цифровых активов.</p>
  <p id="XW7F">Хотя Bitcoin и Ethereum обеспечивают программируемую передачу ценности, их волатильность часто делает их неудобными для повседневных платежей и краткосрочных расчётов. Именно это привело к появлению стейблкоинов - цифровых активов, предназначенных для поддержания стабильной стоимости.</p>
  <p id="HgJC">Хотя рынок по-прежнему доминируется фиатно-обеспеченными стейблкоинами, привязанными к доллару США, сектор товарно-обеспеченных стейблкоинов быстро растёт, соединяя традиционные финансы (TradFi) и децентрализованные финансы (DeFi).</p>
  <p id="oFkK">Токенизируя физические хранилища ценности - драгоценные металлы, энергетические ресурсы и недвижимость - такие активы дают пользователям прямой доступ к реальным активам (RWA) без логистических сложностей хранения и транспортировки.</p>
  <p id="Yn0f">Для институциональных инвесторов и участников DeFi они становятся инструментом хеджирования инфляции и диверсифицированным средством обмена.</p>
  <p id="T2la">Однако соединение физического хранилища с цифровым блокчейном требует специальной инфраструктуры для обеспечения прозрачности и доверия.</p>
  <h2 id="AsyP">Что такое товарно-обеспеченные стейблкоины?</h2>
  <p id="geob">Товарно-обеспеченные стейблкоины - цифровые токены, выпускаемые в блокчейне и напрямую зависящие по стоимости от физического актива. В отличие от алгоритмических стейблкоинов, поддерживающих привязку с помощью кода, или фиатных стейблкоинов, привязанных к государственным валютам, товарные токены обеспечены материальными ценностями.</p>
  <p id="F0QT">Наиболее распространённым обеспечением являются драгоценные металлы, прежде всего золото, но также используются серебро, нефть, углеродные кредиты и недвижимость.</p>
  <p id="I8af">Ключевая идея заключается в токенизации актива. Каждый токен представляет собой цифровой сертификат собственности на определённую единицу физического товара (например, одну тройскую унцию золота), находящуюся в защищённом и проверяемом хранилище у кастодиана.</p>
  <p id="j7s0">Благодаря этому цифровой токен наследует ценовую стабильность базового актива, одновременно получая преимущества блокчейна: скорость транзакций, делимость и глобальную доступность.</p>
  <p id="D4mB">Для инвесторов такой подход значительно упрощает доступ к классам активов, которые традиционно требуют крупного капитала, страховки и сложной логистики. Вместо покупки физического золота и организации его хранения пользователь может приобрести долю токена, представляющего это золото, на децентрализованной бирже.</p>
  <p id="n66E">Кроме того, поскольку такие активы существуют ончейн, они могут интегрироваться в DeFi-протоколы для кредитования, заимствования и генерации доходности.</p>
  <h2 id="sLxK">Как работают товарно-обеспеченные стейблкоины?</h2>
  <p id="vU6c">Механика работы товарно-обеспеченного стейблкоина строится вокруг взаимодействия эмитента, кастодиана и смарт-контракта.</p>
  <p id="85KL">Жизненный цикл обычно начинается с этапа создания (minting). Инвестор вносит фиатную валюту или физический товар доверенному эмитенту. Эмитент приобретает эквивалентное количество товара и размещает его у стороннего кастодиана. После подтверждения наличия актива в хранилище эмитент выпускает эквивалентное количество токенов ончейн и переводит их в цифровой кошелёк пользователя.</p>
  <p id="wpo8">Для поддержания привязки к рыночной цене товара система использует арбитраж и право выкупа.</p>
  <p id="ar9B">Если цена токена на вторичном рынке падает ниже спотовой цены базового актива, держатели могут обменять токены на физический товар (или его денежный эквивалент). Во время такого выкупа токены сжигаются, уменьшая предложение и подталкивая цену обратно вверх. Если же токен торгуется с премией, пользователи могут купить физический товар, передать его эмитенту для выпуска новых токенов и продать их на рынке с прибылью.</p>
  <p id="oFIy">Пользователи должны доверять тому, что физические резервы действительно существуют, не обременены обязательствами и соответствуют объёму токенов в обращении.</p>
  <p id="fBkc">Именно поэтому критически важна система проверки данных. Без постоянной связи между оффчейн-хранилищем и ончейн-смарт-контрактом система уязвима к практике частичного резервирования - риск, который современная оракульная инфраструктура стремится минимизировать.</p>
  <h2 id="ZvIA">Техническая архитектура</h2>
  <p id="eAJT">Технической основой любого товарно-обеспеченного стейблкоина является архитектура смарт-контрактов, управляющая выпуском, переводами и погашением токенов.</p>
  <p id="o71C">Эти само-исполняемые контракты прозрачно обеспечивают соблюдение правил системы. В сетях вроде Ethereum они обычно соответствуют стандарту ERC-20, определяющему свойства токена: имя, тикер и делимость. Однако для институциональных активов архитектура значительно сложнее и требует координационного слоя, связывающего различные системы.</p>
  <p id="A8qY">Среда выполнения Chainlink Runtime Environment (CRE) выполняет роль такого координационного слоя. CRE соединяет ончейн-смарт-контракты с оффчейн-миром — кастодианами, аудиторами резервов и поставщиками рыночных данных. Используя CRE, разработчики могут создавать процессы, при которых выпуск токена происходит только после получения криптографического подтверждения того, что соответствующий физический актив действительно размещён в хранилище.</p>
  <p id="BTqP">Помимо базового выпуска, смарт-контракты часто включают механизмы контроля доступа и комплаенса.</p>
  <p id="8QIg">Например, контракт может запрещать перевод токена, если адрес получателя не прошёл процедуру KYC. Для корректной работы такие контракты требуют постоянного потока точных данных. Они используют стандарт данных Chainlink для получения рыночных цен в реальном времени (через Chainlink Data Feeds) и информации о резервах (через Chainlink Proof of Reserve). Это обеспечивает соответствие внутренней логики смарт-контракта реальному состоянию рынка.</p>
  <h2 id="1kmo">Типы стейблкоинов</h2>
  <p id="F9Kg">Чтобы понять уникальность товарно-обеспеченных активов, полезно рассмотреть их в контексте всей экосистемы стейблкоинов. Обычно стейблкоины классифицируются по типу обеспечения.</p>
  <h3 id="JeS4">Фиатно-обеспеченные (Fiat-Collateralized)</h3>
  <p id="kMyR">Обеспечены фиатной валютой в соотношении 1:1 (например, USD или EUR), размещённой на банковских счетах. На сегодняшний день это самые ликвидные стейблкоины, однако они зависят от централизованной банковской системы.</p>
  <h3 id="MPFa">Крипто-обеспеченные (Crypto-Collateralized)</h3>
  <p id="18Xs">Обеспечены другими криптовалютами (например, ETH или BTC). Из-за волатильности обеспечения такие позиции обычно имеют избыточное обеспечение. Смарт-контракты автоматически ликвидируют позиции при чрезмерном падении стоимости залога.</p>
  <h3 id="mcKB">Алгоритмические (Algorithmic)</h3>
  <p id="dohO">Используют программные алгоритмы для расширения или сокращения предложения токенов в зависимости от рыночного спроса, зачастую без значительного обеспечения. Такие модели несут повышенный риск потери привязки (depeg).</p>
  <h3 id="Y1tK">Товарно-обеспеченные (Commodity-Backed)</h3>
  <p id="Ij8C">Привязаны к физическим активам. Они объединяют защиту от инфляции, присущую материальному обеспечению, с прозрачностью блокчейн-технологии.</p>
  <h2 id="VCX6">Примеры товарно-обеспеченных стейблкоинов</h2>
  <p id="sMEj">Рынок товарно-обеспеченных стейблкоинов достаточно разнообразен, хотя сегодня в нём доминируют драгоценные металлы благодаря их многовековой роли средства сохранения стоимости.</p>
  <h3 id="04l5">Токенизированное золото</h3>
  <p id="8MCw">Такие проекты, как Paxos Gold и Tether Gold, являются наиболее известными примерами. В этих моделях каждый токен представляет определённый объём физического золота (например, одну тройскую унцию), хранящегося в профессиональных застрахованных хранилищах.</p>
  <p id="E7eN">Важной особенностью качественных золотых токенов является возможность аллокации: держатели часто могут проверить серийные номера конкретных золотых слитков, закреплённых за их токенами.</p>
  <h3 id="WATI">Токенизированное серебро</h3>
  <p id="QoDh">Серебро также токенизируется, чтобы предоставить инвесторам более доступный способ хеджирования против колебаний промышленного спроса или обесценивания валюты.</p>
  <h3 id="zvEI">Энергетика и недвижимость</h3>
  <p id="Igo0">Протоколы всё активнее токенизируют баррели нефти, углеродные кредиты и доли недвижимости. Такие токены позволяют осуществлять дробные инвестиции в рынки, которые традиционно считаются низколиквидными.</p>
  <p id="2dec">Ведущие проекты этого сектора, например Cache Gold, используют сервисы Chainlink для повышения прозрачности резервов. Интеграция оракульных решений позволяет эмитентам доказывать, что цифровое представление актива в блокчейне соответствует физическим резервам в хранилище.</p>
  <h2 id="clgC">Преимущества и варианты использования</h2>
  <p id="fGuB">Товарно-обеспеченные стейблкоины открывают несколько важных преимуществ для цифровой экономики.</p>
  <h3 id="v4I5">Хеджирование инфляции</h3>
  <p id="M2rW">В отличие от фиатно-обеспеченных стейблкоинов, зависящих от денежно-кредитной политики центральных банков, товарные токены обычно сохраняют стоимость в долгосрочной перспективе, отражая динамику базового материального актива.</p>
  <h3 id="ceof">Композируемость в DeFi</h3>
  <p id="eqEM">Такие токены могут использоваться как залог в децентрализованных денежных рынках. Например, пользователь может внести токенизированное золото в Aave и занять под него стейблкоины. Это позволяет получать ликвидность из “твёрдых” активов без необходимости продавать базовую позицию.</p>
  <h3 id="Oq1o">Глобальная доступность</h3>
  <p id="8OGK">Физические товары тяжёлые, дорогие в хранении и неудобные для дробления. Токенизация позволяет пользователю владеть, например, золотом или нефтью на сумму всего $10 через обычный криптокошелёк, обходя минимальные пороги входа и расходы на хранение. Это создаёт модель дробного владения ценными активами.</p>
  <h3 id="oyx2">Межсетевое перемещение активов</h3>
  <p id="QeKC">Благодаря стандарту взаимодействия Chainlink Interoperability Standard, основанному на CCIP, такие активы больше не ограничены одной блокчейн-сетью. Инвесторы могут безопасно перемещать токенизированные товары между различными сетями для доступа к ликвидности или конкретным DeFi-приложениям.</p>
  <h2 id="hzdm">Роль Chainlink</h2>
  <p id="5AOd">Chainlink является отраслевым стандартом среди оракульных платформ, обеспечивающих работу экосистемы товарно-обеспеченных стейблкоинов. Компания решает так называемую “проблему оракулов” - неспособность блокчейнов самостоятельно получать оффчейн-данные - с помощью набора сервисов, организованных для обеспечения прозрачности.</p>
  <p id="SkQK">Наиболее важным сервисом для этого сектора является Chainlink Proof of Reserve. Этот механизм обеспечивает автономную и надёжную проверку оффчейн-резервов.</p>
  <p id="Ed5w">Для золотого токена система подключается к хранилищу кастодиана (через API или поток данных от стороннего аудитора) и проверяет точный объём золота в резерве. Эти данные публикуются ончейн. Если объём золота в хранилище уменьшается, оракул обновляет данные смарт-контракта, который может активировать функцию Secure Mint и остановить выпуск новых токенов.</p>
  <p id="piYJ">Это предотвращает практику частичного резервирования и гарантирует обеспечение каждого токена в соотношении 1:1.</p>
  <p id="uaHv">Дополнительно стандарт данных Chainlink предоставляет критически важные ценовые данные. Chainlink Data Feeds передают точные глобальные рыночные цены (например, XAU/USD) ончейн. Это особенно важно для DeFi-протоколов, принимающих такие токены в качестве залога, поскольку им необходимы корректные цены для расчёта коэффициентов loan-to-value.</p>
  <p id="T43X">Использование децентрализованных оракульных сетей Chainlink (DONs) позволяет устранить единые точки отказа.</p>
  <h2 id="8sJV">Критерии выбора и оценки</h2>
  <p id="2VWQ">При выборе товарно-обеспеченного стейблкоина участникам следует учитывать несколько факторов.</p>
  <h3 id="zTB4">Прозрачность резервов</h3>
  <p id="j2ek">Инвесторам стоит отдавать предпочтение проектам, предоставляющим ончейн-проверку резервов в реальном времени, а не полагающимся только на редкие бумажные аудиты. Chainlink Proof of Reserve считается отраслевым стандартом такой проверки.</p>
  <h3 id="29zy">Ликвидность</h3>
  <p id="qhrb">Глубокая ликвидность необходима для эффективного входа и выхода из позиций. Инвесторам следует проверять, торгуется ли токен на крупных биржах и поддерживается ли достаточная глубина рынка.</p>
  <h3 id="iTrP">Кастодиальная и юридическая структура</h3>
  <p id="YPwh">Физическая безопасность актива имеет первостепенное значение. Необходимо проверять, где именно хранится актив, застраховано ли хранилище и регулируется ли кастодиан. Также должно быть чётко определено юридическое право выкупа токена на физический актив.</p>
  <h3 id="I4hr">Комиссии</h3>
  <p id="HUh6">Инвесторам следует внимательно анализировать комиссии за выпуск, погашение и хранение токенов. Высокие издержки могут существенно снижать доходность в долгосрочной перспективе.</p>
  <h2 id="N4El">Меры безопасности и прозрачности</h2>
  <p id="SWIG">Безопасность в секторе товарно-обеспеченных активов включает как физическую безопасность резервов, так и цифровую безопасность токенов. Физические активы должны храниться в проверяемых и застрахованных хранилищах под управлением регулируемых кастодианов. С цифровой стороны смарт-контракты обязаны проходить аудит у авторитетных компаний по кибербезопасности для предотвращения эксплойтов.</p>
  <p id="sImB">Прозрачность связывает эти два мира. Традиционные бумажные аттестации отражают состояние резервов лишь постфактум и подвержены ошибкам. Индустрия постепенно переходит к криптографически подтверждаемой истине, где ончейн-данные обеспечивают проверяемое доказательство обеспечения. Используя Chainlink Proof of Reserve, эмитенты могут автоматически публиковать данные о резервах ончейн. Это позволяет любому пользователю или dApp в реальном времени проверять коэффициент обеспечения токенов.</p>
  <h2 id="y6qm">Регуляторная среда и комплаенс</h2>
  <p id="IjeP">По мере роста рынка стейблкоинов он всё сильнее привлекает внимание регуляторов. Такие нормативные рамки, как Markets in Crypto-Assets Regulation (MiCA) в Европейском союзе, устанавливают строгие требования к обеспеченным активами токенам, обязывая эмитентов поддерживать ликвидные резервы и гарантировать право выкупа токенов.</p>
  <p id="UGkL">Комплаенс в этой сфере сложен, поскольку затрагивает как законодательство о финансовых ценных бумагах, так и регулирование товарных рынков.</p>
  <p id="WqUq">Эмитенты должны соблюдать требования KYC (Know Your Customer) и AML (Anti-Money Laundering). Стандарт комплаенса от Chainlink помогает интегрировать данные идентификации и политики непосредственно в смарт-контракты. Это позволяет автоматизировать проверки соответствия требованиям без потери эффективности блокчейн-расчётов. Для реализации таких механизмов используется Automated Compliance Engine (ACE).</p>
  <h2 id="Edjt">Риски и вызовы</h2>
  <p id="vJlZ">Несмотря на преимущества, товарно-обеспеченные стейблкоины несут ряд рисков.</p>
  <h3 id="SRX0">Риск централизации</h3>
  <p id="kJLK">В отличие от децентрализованных крипто-обеспеченных стейблкоинов, товарные токены зависят от центральной организации, которая хранит физический актив. Если кастодиан будет скомпрометирован или обанкротится, стоимость токена может резко упасть. Это разновидность контрагентского риска.</p>
  <h3 id="ilQP">Потеря привязки (De-pegging)</h3>
  <p id="ZdVn">Если механизм выкупа перестанет работать или ликвидность исчезнет во время рыночного стресса, цена токена может отклониться от спотовой цены базового товара. Подобные процессы хорошо иллюстрируют ограничения так называемой “трилеммы стейблкоинов.</p>
  <h3 id="Tw86">Регуляторная неопределённость</h3>
  <p id="h1Qn">Изменения государственной политики в отношении цифровых активов или торговли сырьевыми товарами могут повлиять на законность или доступность таких токенов в отдельных юрисдикциях.</p>
  <h3 id="JXhe">Задержка аудита</h3>
  <p id="2kH5">Для проектов, не использующих автоматизированные решения вроде Chainlink Proof of Reserve, существует временной лаг между фактическим состоянием резервов и опубликованной информацией. Это создаёт окно, в течение которого возможная неплатёжеспособность может оставаться незамеченной.</p>
  <h2 id="O2Uu">Будущее и эволюция рынка</h2>
  <p id="t3Ol">Будущее товарно-обеспеченных стейблкоинов тесно связано с токенизацией реальных активов (RWA). По мере того как крупные финансовые организации, такие как BlackRock, SWIFT и международные банки исследуют возможности блокчейн-технологий, ожидается расширение токенизации за пределы золота - в сторону сельскохозяйственной продукции, редкоземельных металлов и углеродных кредитов.</p>
  <p id="jqyO">Индустрия движется к концепции “проверяемого интернета” (Verifiable Web), где финансовые продукты будут определяться криптографическими гарантиями.</p>
  <p id="Rcxi">Chainlink Runtime Environment позволяет координировать сложные мультиактивные продукты между различными сетями. Дополнительно стандарт взаимодействия Chainlink обеспечивает свободное перемещение таких токенов между блокчейнами, формируя единый глобальный слой ликвидности. По мере развития этой инфраструктуры товарно-обеспеченные стейблкоины, вероятно, станут стандартной частью инвестиционных портфелей для пользователей, ищущих ончейн-диверсификацию.</p>
  <h2 id="EXLB">Заключение</h2>
  <p id="eEgO">Товарно-обеспеченные стейблкоины объединяют стабильность материальных ресурсов с функциональностью блокчейна. Привязывая цифровую стоимость к реальным активам, они предлагают надёжный инструмент для пользователей, избегающих высокой волатильности. Однако их долгосрочный успех напрямую зависит от прозрачности и качества инфраструктуры.</p>
  <p id="dfNm">Благодаря внедрению Chainlink Proof of Reserve и стандартов данных Chainlink эмитенты формируют необходимый уровень доверия для переноса рынков капитала ончейн.</p>
  <p id="mV2Y">Чтобы подробнее узнать о том, как инфраструктура Chainlink поддерживает будущее стейблкоинов и токенизированных активов, авторы рекомендуют обратиться к профильным экспертам.</p>
  <p id="zLQ9"><em>До!</em></p>

]]></content:encoded></item></channel></rss>