Перевод

Это вольный перевод: tokenterminal.beehiiv.com/p/uniswap-after-unification.

TL;DR

UNIfication от Uniswap представила новую модель для крупнейшей децентрализованной биржи спотовой торговли.

Она передаёт Uniswap Labs часть ответственности за развитие и рост экосистемы, формализует отношения между Labs и управлением UNI, а также напрямую связывает активность протокола с UNI через протокольные комиссии и программное сжигание токенов.

В нашем последнем отчёте разбираем эти изменения и с помощью данных Token Terminal оцениваем, как новая модель работает на практике.

Введение

Uniswap - крупнейшая децентрализованная биржа спотовой торговли. По данным Token Terminal, по состоянию на 8 августа 2026 года совокупный объём торгов на Uniswap достиг примерно $3,7 трлн, а совокупные торговые комиссии - ок. $5,1 млрд.

Эта экономическая активность обеспечивается экосистемой, которая выходит далеко за рамки самого протокола и включает Uniswap Labs, Uniswap Foundation, DUNI, поставщиков ликвидности, трейдеров, разработчиков и интеграторов.

На протяжении большей части истории Uniswap обязанности внутри его экосистемы оставались разделёнными.

Часть операционных функций была распределена преимущественно между Uniswap Labs и Uniswap Foundation, тогда как управление UNI контролировало решения на уровне протокола и находящиеся под управлением сообщества ресурсы.

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

Поэтому держатели UNI могли оценивать распространение Uniswap и создаваемую протоколом экономическую ценность, но связь этих показателей непосредственно с UNI оставалась менее очевидной.

UNIfication изменила эту модель. Она передаёт Uniswap Labs часть функций по развитию и росту экосистемы и формализует отношения между Labs и управлением.

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

В этом отчёте Uniswap после UNIfication рассматривается в трёх аспектах:

• Во-первых, разберём, как отдельные обязанности распределяются между Uniswap Labs, Uniswap Foundation и DUNI.
• Во-вторых, объясним, как протокольные комиссии и сжигание UNI меняют экономическую модель Uniswap.
• В-третьих, используя данные Token Terminal, оценим работу этой модели на практике, уделяя особое внимание извлечению ценности на уровне протокола, накоплению ценности UNI и тому, как наблюдаемый доход протокола может использоваться для фундаментального анализа.

1. UNIfication упрощает распределение обязанностей в Uniswap

1.1 До UNIfication

До UNIfication часть обязанностей была разделена между Uniswap Labs и Uniswap Foundation. Labs руководила разработкой протокола Uniswap и создавала продукты, через которые пользователи и разработчики могли взаимодействовать с ним.

Foundation, созданная по итогам голосования держателей UNI в 2022 году, поддерживала более широкую экосистему посредством грантов, поддержки управления, взаимодействия с разработчиками и развития сообщества.

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

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

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

1.2 DUNI связывает ончейн-управление с офчейн-миром

Управление UNI начало решать эту проблему ещё до UNIfication. В сентябре 2025 года в качестве своей юридической структуры оно утвердило DUNI - Wyoming Decentralized Unincorporated Nonprofit Association, децентрализованную неинкорпорированную некоммерческую ассоциацию, зарегистрированную в штате Вайоминг.

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

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

DUNI расширяет возможности управления UNI. Решения по-прежнему принимаются посредством установленного ончейн-процесса, а DUNI предоставляет юридические возможности для тех случаев, когда эти решения необходимо реализовать в офчейн-мире.

Uniswap Foundation выступает в качестве Ministerial Agent - административного представителя DUNI, полномочия которого ограничены определёнными административными и исполнительными функциями. Для выполнения других задач, например налогового учёта и отчётности, DUNI также использует отдельного администратора.

Это разделение становится особенно важным в рамках UNIfication, поскольку именно DUNI выступает юридическим контрагентом, через которого управление может установить формальные договорные отношения с Uniswap Labs как с поставщиком услуг.

1.3 UNIfication передаёт операционное исполнение Uniswap Labs

UNIfication передаёт Labs большую часть функций по развитию и росту экосистемы, которые ранее традиционно выполняла Foundation.

Функции, исторически находившиеся в ведении Foundation, включая поддержку и финансирование экосистемы, поддержку управления и взаимодействие с разработчиками, переходят к Labs вместе с большей частью сотрудников Foundation.

Таким образом, Labs объединяет свои прежние обязанности по разработке протокола и продуктов с более широкими полномочиями по развитию и росту экосистемы Uniswap.

Foundation сохраняет меньшую команду, отвечающую за гранты и стимулы, и продолжает выполнять определённые функции, включая роль административного представителя DUNI.

Новая операционная модель предусматривает ежегодный бюджет на развитие в размере 20 млн UNI, который Labs получает в обмен на оказываемые услуги. Средства выделяются ежеквартально из уже существующего запаса токенов казначейства. В рамках UNIfication финансирование было одобрено на два года.

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

Окончательное соглашение было согласовано независимым комитетом Foundation, действовавшим в качестве административного представителя DUNI. UNIfication была реализована в конце декабря 2025 года, а первый квартальный транш в размере 5 млн UNI был переведён Labs в январе 2026 года.

Таким образом, структуру после UNIfication можно свести к трём основным функциям:

1. Управление UNI принимает решения → DUNI обеспечивает юридическую возможность их реализации → Uniswap Labs исполняет их.
2. При этом Foundation сохраняет ряд отдельных обязанностей. UNIfication передаёт Labs операционное исполнение, но не передаёт Labs базовые полномочия управления UNI.
3. После формирования этой операционной структуры возникает следующий вопрос - экономический: как активность внутри протокола превращается в ценность, которую получает сам протокол, и в конечном итоге - в накопление ценности UNI?

2. UNIfication формирует более понятную экономическую модель UNI

Изменения, описанные в разделе 1, определяют распределение функций управления, заключения договоров и исполнения между Labs, Foundation и управлением UNI.

Однако UNIfication также меняет механизм связи между экономической ценностью, создаваемой протоколом, и токеном UNI.

Исторически протокол Uniswap обеспечивал огромные торговые объёмы и генерировал значительные торговые комиссии, однако не существовало постоянного механизма, посредством которого часть этих комиссий превращалась бы в доход протокола, связанный с UNI.

Активация протокольных комиссий (protocol fees), механизм которых изначально был заложен в смарт-контракты Uniswap, устраняет этот разрыв.

2.1 От использования протокола к накоплению ценности UNI

Экономическая модель начинается с трейдеров и создаваемой ими активности.

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

Доход протокола (protocol revenue) - это часть торговых комиссий, которую получает непосредственно протокол.

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

Различие между торговыми комиссиями (trading fees) и доходом протокола (protocol revenue) особенно важно. Торговые комиссии показывают общий объём комиссий, полученных в результате торговой активности, тогда как доход протокола отражает только ту их часть, которую получает непосредственно протокол.

Таким образом, доход протокола - это часть экономической ценности, создаваемой Uniswap, а не отдельная комиссия, взимаемая со всей торговой активности.

2.2 Протокольные комиссии позволяют протоколу получать часть создаваемой ценности

Новый механизм получения дохода применяется к уже существующей экономической базе. По данным Token Terminal, по состоянию на 8 августа 2026 года совокупный объём торгов Uniswap составлял около $3,7 трлн, а совокупные торговые комиссии - около $5,1 млрд.

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

• Первоначально протокольные комиссии были активированы для Uniswap v2 и отдельных пулов v3 в основной сети Ethereum.
• В v2 общая комиссия за обмен остаётся на уровне 0,30%, но теперь распределяется следующим образом: 0,25% → поставщикам ликвидности0,05% → протоколу
• В v3 механизм становится более гибким. Управление UNI может устанавливать протокольную комиссию отдельно для каждого пула.

В первоначальной конфигурации протокол получает:

• 1/4 комиссии LP в пулах с уровнями комиссии 0,01% и 0,05%;
• 1/6 комиссии LP в пулах с уровнями комиссии 0,30% и 1,00%.

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

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

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

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

Именно эти переменные определяют, какая доля экономической ценности, создаваемой торговлей, в конечном итоге превращается в доход самого протокола.

2.3 Доход протокола связывается с UNI через автономный механизм сжигания

Доход протокола связан с UNI посредством двух смарт-контрактов, введённых в рамках новой архитектуры комиссий.

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

Firepit обеспечивает механизм их извлечения: участник рынка вносит определённое количество UNI, а взамен получает активы, накопленные в TokenJar.

UNI, использованные в этой операции, навсегда сжигаются.

Таким образом, самому протоколу не требуется продавать накопленные комиссионные активы и самостоятельно покупать за них UNI.

Этот механизм отличается от распределения дохода протокола между держателями токенов. Владельцы UNI не получают накопленные комиссионные активы в виде дивидендов или денежных выплат. Вместо этого доход протокола создаёт экономическую основу для регулярного сокращения предложения UNI.

При этом получение дохода и сжигание UNI могут происходить в разное время.

Комиссионные активы накапливаются в TokenJar до тех пор, пока их стоимость не станет достаточно высокой, чтобы у участника рынка появился экономический стимул запустить механизм их извлечения.

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

Поэтому единовременное сжигание токенов казначейства следует отличать от постоянного механизма: 100 млн UNI из казначейства → однократное сокращение предложения;протокольный доход → регулярное сжигание UNI в будущем.

После появления этого механизма ключевые вопросы становятся количественными:

• Какой объём активности обеспечивает Uniswap?
• Какую экономическую ценность создаёт эта активность?
• Какая её часть становится доходом протокола?
• И что эта экономика означает для UNI?

В разделе 3 эти вопросы рассматриваются на основе данных Token Terminal.

3. Новую экономическую модель теперь можно измерить

В разделах 1 и 2 были рассмотрены изменения, внесённые UNIfication. Теперь сформировавшуюся структуру можно оценивать на основе фактических данных об использовании протокола и его финансовых показателях.

Данные Token Terminal позволяют последовательно отслеживать: активность в Uniswap → долю этой активности, превращающуюся в доход протокола → связь дохода протокола с UNI.

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

3.1 Uniswap продолжает привлекать трейдеров и обеспечивать значительный объём торгов

Экономическая модель Uniswap в конечном счёте зависит от сохранения спроса на торговлю через протокол.

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

Эти показатели полезно анализировать вместе, поскольку изменение числа участников не обязательно приводит к пропорциональному изменению торгового объёма.

Например, большее количество трейдеров может создать меньший совокупный объём торгов, если средняя торговая активность каждого из них снизилась. И наоборот, меньшее количество трейдеров может обеспечить больший торговый объём, если средняя активность одного трейдера выросла.

С января по июль 2026 года объём торгов на Uniswap составил примерно $357,6 млрд, то есть в среднем около $51,1 млрд в месяц.

Ежемесячный объём торгов снизился примерно с $69,5 млрд в январе до $37,0 млрд в мае, после чего начал восстанавливаться: до $40,8 млрд в июне и $42,3 млрд в июле.

Таким образом, данные показывают снижение торговой активности в первой половине рассматриваемого периода с последующим частичным восстановлением в июне и июле.

За те же семь месяцев торговая активность принесла около $297,9 млн торговых комиссий. В январе ежемесячные комиссии составили примерно $47,6 млн, в феврале - $48,8 млн. В марте и апреле они снижались вместе с торговой активностью, после чего выросли примерно с $35,0 млн в мае до $54,7 млн в июле.

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

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

С января по июль Uniswap в среднем генерировал около 8,3 базисного пункта торговых комиссий на каждый доллар торгового объёма, однако фактическая ставка менялась в зависимости от структуры торговой активности.

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

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

3.2 Протокольные комиссии создают измеримый уровень дохода и накопления ценности

Протокольный доход начал формироваться после активации комиссий в конце декабря 2025 года.

С января по июль 2026 года Uniswap получил около $28,2 млн протокольного дохода по сравнению с примерно $297,9 млн торговых комиссий за тот же период.

Таким образом, за первые семь полных календарных месяцев 2026 года протокольный доход составлял примерно: 9,5% от всех торговых комиссий и 0,79 базисного пункта от торгового объёма.

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

Отношение протокольного дохода к торговому объёму даёт ещё один взгляд на эффективность монетизации, сопоставляя доход протокола с торговой активностью, которая его создаёт.

Вместе эти два показателя позволяют отделить изменения эффективности монетизации протокола от простого роста или снижения общей активности пользователей.

Протокольный доход рос неравномерно.

Ежемесячный доход увеличился примерно с $2,8 млн в январе до $4,8 млн в марте, затем снизился примерно до $3,7 млн в мае, вырос до $5,3 млн в июне и составил около $4,1 млн в июле.

По данным Token Terminal, к 8 августа 2026 года совокупный протокольный доход с момента активации механизма достиг примерно $29,8 млн.

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

Внедрение началось в декабре 2025 года со всех пулов Uniswap v2 в Ethereum и отдельных пулов v3 в Ethereum. Затем механизм был распространён на дополнительные сети, все пулы v3 в этих сетях и отдельные группы пулов v4.

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

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

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

Первые семь полных месяцев дают первоначальное представление об экономике новой модели. С января по июль на каждые $100 торговых комиссий примерно $9,50 становились доходом протокола.

Если рассматривать показатель относительно торговой активности, то на каждый $1 млрд торгового объёмаприходилось примерно $79 000 протокольного дохода.

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

Протокольный доход - лишь одна сторона нового механизма накопления ценности. Активы, полученные протоколом, накапливаются в TokenJar, после чего могут быть извлечены через Firepit в обмен на UNI, которые навсегда сжигаются.

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

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

Поэтому сравнение этих двух показателей на коротких временных промежутках может приводить к ошибочным выводам, если на момент измерения значительный объём дохода всё ещё находится в TokenJar. На более длительном горизонте совокупный протокольный доход и стоимость совокупно сожжённых UNI должны иметь близкие значения.

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

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

Масштаб обоих эффектов по-прежнему зависит от торговой активности, объёма генерируемых комиссий, охвата протокольными комиссиями, параметров, устанавливаемых управлением, и времени извлечения активов из TokenJar. Однако теперь эти переменные можно не предполагать, а непосредственно измерять.

3.3 Наблюдаемый протокольный доход создаёт новую основу для фундаментального анализа UNI

Появление протокольного дохода также меняет подход к анализу UNI.

До активации протокольных комиссий держатели UNI могли оценивать Uniswap по таким показателям, как число активных трейдеров за месяц, торговый объём, торговые комиссии, ликвидность (TVL) и доля рынка.

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

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

Протокольный доход и регулярное сжигание UNI добавляют в эту систему анализа два новых измеримых показателя.

Теперь инвесторы могут оценивать, какую экономическую ценность создаёт Uniswap, какая её часть остаётся на уровне протокола и как эта полученная ценность способствует сокращению предложения UNI.

Это не делает UNI аналогом акций и не предоставляет держателям UNI традиционных прав собственности, дивидендов или прав акционеров.

Однако новая модель позволяет анализировать операционные показатели протокола и экономику UNI в рамках значительно более прямой взаимосвязи.

Влияние этих изменений на оценку UNI лучше рассматривать как расширение набора инструментов для анализа, а не как появление единственного универсального метода оценки.

По данным Token Terminal, на 8 августа 2026 года полностью разводнённая оценка (FDV) UNI составляла примерно $3,5 млрд.

Исходя из приведённого к годовому значению протокольного дохода на эту дату, UNI торговался с мультипликатором FDV / годовой протокольный доход около 67×.

Обратное значение этого мультипликатора соответствует годовой доходности протокола около 1,5% относительно полностью разводнённой оценки UNI.

Мультипликатор около 67× не следует рассматривать как прямой аналог коэффициента P/S традиционной компании. UNI не представляет собой долю в капитале Uniswap Labs, а протокольный доход не распределяется между держателями UNI как корпоративная выручка или прибыль.

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

При этом знаменатель этого мультипликатора пока нельзя считать устоявшимся.

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

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

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

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

Таким образом, UNIfication делает экономическую связь между Uniswap и UNI значительно более измеримой. Ключевые экономические вопросы всё больше напоминают вопросы, применяемые при анализе бизнеса, создающего экономическую ценность: как быстро растёт активность, насколько эффективно она монетизируется и какую оценку рынок присваивает создаваемой ценности. При этом ответы остаются специфичными для структуры протокола и управления Uniswap.

Итоги

UNIfication перераспределила обязанности между Uniswap Foundation и Uniswap Labs и изменила механизм связи экономической ценности, создаваемой протоколом, с UNI.

С организационной точки зрения большая часть функций по разработке и развитию экосистемы, которые исторически выполняла Uniswap Foundation, теперь сосредоточена преимущественно в Uniswap Labs. При этом управление, юридическая инфраструктура и операционное исполнение остаются разделёнными.

DUNI сохраняет контроль над определёнными решениями на уровне протокола и ресурсами, находящимися под контролем управления, а также предоставляет юридическую инфраструктуру, необходимую для реализации некоторых решений в офчейн-мире. Labs выступает поставщиком услуг для DUNI и отвечает за развитие и рост протокола Uniswap. Uniswap Foundation сохраняет более узкий набор функций, включая роль административного представителя DUNI (Ministerial Agent).

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

По данным Token Terminal, с января по июль 2026 года Uniswap: обработал около $357,6 млрд торгового объёма;сгенерировал около $297,9 млн торговых комиссий;получил около $28,2 млн протокольного дохода.

Таким образом, протокольный доход составил примерно 9,5% от торговых комиссий за рассматриваемый период.

Через механизмы TokenJar и Firepit полученная протоколом ценность впоследствии может использоваться для регулярного сокращения предложения UNI посредством сжигания.

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

Uniswap и раньше можно было анализировать через количество активных трейдеров, торговый объём, торговые комиссии, ликвидность (TVL) и долю рынка. Теперь протокольный доход и регулярное сжигание UNI добавляют к этой системе показатели получения и накопления ценности, а мультипликаторы на основе дохода дают дополнительный инструмент для сопоставления рыночной оценки UNI с экономикой самого протокола.

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

Полномочия управления → операционное исполнение → получение ценности протоколом → сокращение предложения UNI → рыночная оценка теперь связаны между собой более явно и при этом могут измеряться независимо друг от друга.

До!

Введение

Кошелёк menaskop.eth - тестовый, поэтому на нём совершаю самые разные транзакции. В итоге это приводит к тому, что порой он окрашивается в “красный” цвет для сервисов и его блокируют.

Но подобное может случиться с каждым и один из способов обхода - это прямое взаимодействие с контрактами. Расскажу сегодня на свежем примере методологию…

sETH - ETHFI

Итак, зададимся простым вопросом: “Как вручную вывести sETHFI - ETHFI через контракты ether.fi?”. Кошелёк мой: 0x23802e21c6cd72c091792bfb9f7afc2265cc68d6.

Определяем токены и контракт вывода

Для начала ищем токен sETHFI: 0x86B5780b606940Eb59A062aA85a07959518c0161: etherscan.io/address/0x86B5780b606940Eb59A062aA85a07959518c0161. Далее идём дальше и ищем ETHFI: 0xFe0c30065B384F05761f15d0CC899D4F9F9Cc0eB: etherscan.io/address/0xFe0c30065B384F05761f15d0CC899D4F9F9Cc0eB.

И, наконец, контракт ончейн-вывода: etherscan.io/address/0xF03352da1536F31172A7F7cB092D4717DeDDd3CB.

Что получаем?

Сначала смотрим, сколько ETHFI получим.

Для этого проделываем следующие не хитрые манипуляции:

• В Read Contract ищем previewAssetsOut
• вводим:
• assetOut = 0xFe0c30065B384F05761f15d0CC899D4F9F9Cc0eB
• amountOfShares = 431931916160290135402
• discount = 0

Тут немного поясню. amountOfShares - это количество sETHFI, которое хотим вывести, записанное в минимальных единицах токена. Но как его вычислить-то?

Для этого на контракте sETHFI (0x86B5780b606940Eb59A062aA85a07959518c0161) делаем тот же финт ушами: sETHFI - Read Contract и открываем параметр: balanceOf(address) - после чего вводим адрес кошелька: 0x23802e…f7afc2265cc68d6.

На момент моей проверки balanceOf показывал: 431931916160290135402.

Важно всегда учесть разрядность: у sETHFI 18 decimals, поэтому: 431931916160290135402 / 10^18 = 431.931916160290135402 sETHFI. То есть если хотим вывести весь баланс, то: amountOfShares = 431931916160290135402. И уже именно это число без точки и без округления вставляем в previewAssetsOut - amountOfShares.

Важно! Дисклеймер! Не нужно вручную переписывать 431.9319 как число токенов - контракт принимает значение в минимальных единицах. Для другого кошелька или другого объёма amountOfShares будет другим.

Итак, amountOfShares здесь = 431.931916 sETHFI, а discount = 0 означает отсутствие добровольной скидки.

В нашем примере контракт вернул: 520343039203819529027, то есть примерно 520.343039 ETHFI. Это логично: помимо застейканных токенов начислили ещё ведь проценты.

Разрешаем Withdrawal-контракту забрать sETHFI

После всего, что описано выше, на контракте sETHFI вызываем approve():

• spender = 0xF03352da1536F31172A7F7cB092D4717DeDDd3CB
• value = 431931916160290135402

Тут spender - это тот, кому разрешаем забрать токены; а value - ровно сколько sETHFI разрешаем использовать. Фактический approve из примера: транзакция approve 431.931916 sETHFI.

Создаём заявку на вывод

На Withdrawal-контракте вызываем requestOnChainWithdraw():

• assetOut = 0xFe0c30065B384F05761f15d0CC899D4F9F9Cc0eB
• amountOfShares = 431931916160290135402
• discount = 0
• secondsToDeadline = 1209600

Здесь assetOut = ETHFI; amountOfShares = 431.931916 sETHFI; discount = 0 = без скидки; 1209600 секунд = 14 дней срока действия заявки, а не 14 дней ожидания (как раньше).

Фактическая транзакция: requestOnChainWithdraw - чтобы был пример перед глазами.

Проверяем событие OnChainWithdrawRequested

В нашем случае контракт записал:

• nonce = 892
• amountOfShares = 431.931916160290135402 sETHFI
• amountOfAssets = 520.343039203819529027 ETHFI
• secondsToMaturity = 3600
• secondsToDeadline = 1209600

Самое важное: secondsToMaturity = 3600 в статус “cooldown “ и этовсего 1 час! А вот secondsToDeadline = 1209600 - это срок, когда заявка остаётся действительной: 14 дней.

См. requestId этой конкретной заявки.

После часа проверяем состояние заявки: без интерфейса ether.fi. Не создаём новую заявку только потому, что ETHFI ещё не появились: сначала проверяем существующий requestId.

Итог примера: 431.931916 sETHFI “превратились” в 520.343039 ETHFI, скидка составила 0, cooldown - 1 час, а окно исполнения 14 дней.

Вроде, не так и плохо?

До!

P.S. Вывод через час

Итог: https://etherscan.io/address/0xba538b15bbcA0cb5e3ad844241C7a0d2DFc4F13b#writeContract:

См. https://etherscan.io/tx/0xdaa37c8cd3fd7d6b74f921e3623b33bda4c1a82e6be2ab47bb13718490608c81

Всё.

У этого блокчейна есть какая-то своя, особая, аудитория, с которой впервые встретился в 2018 году в Швейцарии - в Базеле... И с тех пор меня не отпускает ощущение, что вся экосистема Cardano пытается жить по какой-то своей, особой, логике, но логика эта не похожа на обычную.

В общем, несколько месяцев назад рассказывал про airdrop NIGHT и теперь решил заклемить на 5 самых активных кошельков то, что "прилетело". И вот что из этого вышло...

Кошельки под airdrop

Во-первых, нужно было для начисления указать кошелёк, который "нигде до этого не использовался": я взял и создал такой в Yoroi, который, как вы знаете, был взломан (из-за плохой энтропии при создании приватных ключей) и переименован.

Соответственно, seed-фразу пришлось переносить: и хотя на странице клейма (https://redeem.midnight.gd) было не мало вариантов, оказалось, что у всех у них одна и та же проблема: они показывают НЕ тот адрес, а чтобы найти тот - пришлось помучаться...

Казалось бы: чего проще? Есть seed, есть деривация - возьми свои токены и радуйся. Но нет: 2 из 5 кошельков сами аккаунты были не под индексом 0, а поэтому попросту не попадали в процесс клейма.

При этом на странице клейма есть кнопка Redeem и видео, но ни то, ни другое никак не решает столь простой задачи.

Пришлось через консоль попробовать поставить утилиту, чтобы проверить адреса, но в итоге, даже сверив подпись, расхотелось это делать, т.к. под MAC не оказалось нормально реализованного сервиса. Это ведь тоже странно?

Но в наше время унывать не приходится - решил навайбкодить, как модно говорить, свою утилиту:

Собственно, в первой версии были поля поиска именно кошелька, но потом решил, что легче выводить первые 100 (или более) аккаунтво и уже искать среди них:

И в итоге кошелёк (аккаунт) быстро нашёлся. Но! Внутри именно приложений кошельков - выдавались по-прежнему другие значения:

И даже там, где можно было добавить аккаунт (для сдачи и др. операций) - всё равно выдавались рандомные значения:

И получался замкнутый круг:

1. Seed-фраза верная;
2. При вводе её в кошельке - выдаётся аккаунт с индексом 0;
3. А остальные или не выдаются вовсе;
4. Или выдаются рандомно.

И это при том, что утилита, написанная за 5 минут, всё делала быстро и правильно:

И получался парадокс: из 10 рекомендованных кошельков - лишь один был способен справится с поставленной задачей! Да и то - не напрямую, а за счёт того, что в него был встроен клейм токенов NIGHT (и на том спасибо разработчикам):

На скриншот выше видно, что тестировал сразу 3 кошелька, но до этого - Lace также прошёл по всем фронтам, а Yoroi попросту закрылся (и почему он до сих пор висит на сайте при этом - не ясно).

И фактически лишь в VESPR шалость эирдроп удался, т.к. функционал был предустановлен.

При этом ни Eternl с этой задачей ни справился - потому что у него своя, совершенно не последовательная деривация адресов:

Ни другие кошельки и даже их агрегаторы:

Выводы

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

И это при том что Хоскинсон, вышедший из Ethereum, постоянно критикует последний, но за 10+ лет так и не смог решить простых проблем...

В общем, надеюсь, что рассказ-инструкция будут кому-то полезны, а сам Кардано всё же сможет эволюционировать до внятной NON-EVM системы и займёт пусть одну, но достойную нишу в Web 3.0 & Web3.

До!

Вопрос не праздный и один из самых частых, поэтому зафиксирую его здесь в виде статьи.

Способ №01. Merkl

Тут всё просто:

1. Переходим на сайт: https://app.merkl.xyz;
2. Проверяем его (см. об этом в курсе);
3. Подключаем кошелёк;
4. Получаем программы инсетивов в моменте;
5. При этом можем ещё посмотреть уже накопленные.

На всё про всё у вас уйдёт едва ли минута. Сети - основные EVM, поэтому бОльшую часть вы тем самым закроете.

Отбирать лучше всего по критериям ежедневных выплат и по стандартному CPD-подходу:

1. Оцениваем сеть (здесь - чем новее, тем интересней);
2. Оцениваем протокол (4К-методика + безопасность);
3. Оцениваем сам Dapp.

Какие-то значимые истории бывают не всегда, но для набора опыта - вполне подходит. К тому же часто инсентивы - это хороший бонус к той доходности, что вы и так получаете на депозитах, пулах, etc.

DeFiLlama Yields

Ещё одно очевидное решение: https://defillama.com/yields - здесь довольно много полей, но рекомендую для начала см. на:

1. Количество холдеров;
2. APY выплат.

А потом уже оценивать всё по стандартным методикам.

В отличие от предыдущего способа инсентивы здесь не обязательный элемент, поэтому выставляйте какие-то объективные критерии для фильтрации: скажем, APY от 5% до 50% для уже известных сетей.

Косвенные выводы

Если взять Beefy, Yearn, Aura/Convex... Shake DAO, Harvest, YFI и подобные проекты, то можно нарыть не мало интересного: скажем, приводил в пример ETH/ETH+ пул, кот. не раз исследовали: если его взять БЕЗ Stake DAO, то проценты будут ниже, чем с блоком именно через этот проект. И таких примеров - пруд-пруди: надо лишь сосредоточиться на поиске.

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

Пулы/LP

Если вы когда-нибудь открывали Revert, Krystal, Vfat, то знаете, что они помогают создавать пуловые стратегии и вполне успешно:

1. Revert можно использовать для помощи разбора позиций;
2. Krystal для нахождения стратегий (для) копирования;
3. Vfat как альтернативу.

И при этом всегда можно найти именно те пулы, где здесь и сейчас раздают инсенитвы: собственно, Uniswap, PancakeSwap и др. проекты тоже в своих интерфейсах это делают, но не так широко и детально.

значально на том же Krystal даже в API делали параметр withIncentives=true,поэтому в эпоху ИИ-агенов проблем с подобным ещё меньше.

Квесты

Собственно, даже если вы уже выросли из квест-комнат, они всё ещё хорошее подспорье для поиска инсентивов. Скажем, app.layer3.xyz/discover:

Здесь можно найти новые кампании и по ним понять, где в моменте платят буст-награды и за что именно. Особенно хорошо видно, когда идёт кампания по сетям: Ink, Monad, Linea, etc.

Это же касается и galxe.com.

DAOs

Собственно, самый надёжный способ - всегда читать форумы ДАО и искать начало выплат именно там. Пример подобного: teletype.in/@menaskop/zksync-ignite-2025-manual-ru.

Но это же касается и отдельных приложений, и целых экосистем.

Alerts

Если ввести ключевики навроде insentives, инсентивы, награды, бонусы, бусты, etc. в гугл, то google.com/alerts ежедневно, а то и ежечасно вы будете получать сводку. Более того: можно настроить ИИ-агента и он будет делать это за вас.

Это же касается стандартного IFTTT-подхода.

Дополнительно

На этом способы не заканчиваются:

1. Можно следить на YT- & Telegram-каналах;
2. В блогах (не) известных проектов;
3. Через новостные агрегаторы навроде cryptonews.net;
4. На сайтах больших приложений (Uniswap, AAVE, etc.);
5. И много где ещё.

Главное - не отходить от позиции CPD-методики:

1. Ищем новые сети;
2. В них - новые протоколы;
3. И уже потом - новые дапсы.

И так - получаем максимум от жизни, DeFi и инноваций в целом :).

А пока всё и

До!

Коротко

Выход позиции (возьмём для примера USDT/ETH, но в целом - любая подобная может быть) из диапазона - не техническая неисправность, которую всегда надо немедленно исправлять. Это вполне себе исполнение встроенной стратегии обмена:

• Выход через нижнюю границу цены ETH превращает позицию преимущественно или полностью в ETH;
• Выход через верхнюю границу превращает её преимущественно или полностью в USDT;
• После выхода комиссия перестаёт начисляться, но накопленный IL/DL уже отражает то, что AMM систематически продавал дорожающий актив и покупал падающий.

Если не знаете, что такое DL, а особенно - IL, то сначала - изучите предыдущие уроки.

Поэтому решение должно приниматься не по правилу "позиция вне диапазона - срочно переставить", а по 4 вопросам:

1. Какой актив хотите держать после выхода?
2. Есть ли связанный долг или залог?
3. Какова вероятность возврата цены в диапазон?
4. Превышает ли ожидаемый будущий доход стоимость ребаланса, LVR, газа, свопов и риска ликвидации?

Важно! Не только практика, но и академическая литература подтверждает, что прибыль LP нельзя оценивать только как комиссии минус IL. Более корректная модель выглядит так:

​​​​​Net LP PnL = Fees + Incentives + Yield on Idle Assets - LVR - Rebalancing Costs - Borrow Cost - Liquidation Losses - Protocol Risk Losses

Если это переписать теперь на русском языке, то получим буквально следующее:

Чистая прибыль LP = Комиссии + Стимулы + Доход на свободные активы − LVR − Расходы на ребалансировку − Стоимость займа − Убытки от ликвидаций − Убытки от рисков протокола

LVR - это что? Это экономическая стоимость того, что арбитражёры торгуют против AMM по запаздывающей цене. Эмпирические исследования показывают, что в значительной части крупных пулов арбитражные потери могли превышать комиссии, причём пассивные позиции Uniswap v3 иногда оказывались хуже v2 именно из-за концентрации и постоянных ребалансов.

Не верите мне? Правильно делаете: доверять можно только цифрам и фактам. Они - по ссылке: arxiv.org/abs/2208.06046.

Но это всё лирика. Давайте теперь конвертику. По шагам.

Шаг №01. Определить роль LP-позиции

До открытия пула позицию следует отнести к одному из 4 типов.

Подход здесь такой:

• Тип
• Экономический смысл
• Что означает нижний выход
• Что означает верхний выход

И тогда получаем следующие решения:

Это принципиально: одна и та же позиция, вышедшая в ETH, для аккамулирующей стратегии является успехом, а для дельта-нейтральной - нарушением... мандата! Да, вот такое заковыристое слово :), но это факт.

2. Выход через нижнюю границу: позиция осталась в ETH

2.1. Первый вопрос: есть ли уже долг под ETH-залог?

Предположим:

• ETH лежит залогом на Aave или Morpho;
• Против него заимствованы стейблы;
• LP-позиция после падения также превратилась в ETH.

Здесь возникает неприятная положительная корреляция:

• Стоимость основного залога падает;
• LP на падении докупает ETH;
• Долг в стейблах остаётся почти постоянным;
• Весь портфель становится ещё более чувствительным к ETH.

Это не диверсификация. Это усиление лонга ETH при ухудшении кредитного плеча. Да-да, именно так: а вы как думали?)

Aave допускает ликвидацию при HF (что такое Health Factor - тоже есть в курсе) ниже 1. На Morpho позиция становится ликвидируемой при достижении LTV ≥ LLTV. Подробней см., например: aave.com/help/borrowing/liquidations.

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

Но многие ли так делают? Ответ краткий и простой: нет. А вот ситуация - сложная.

Приоритизация в общем виде выглядит так:

1. Погасить часть долга.
2. Либо добавить ETH к залогу.
3. Либо одновременно погасить долг и уменьшить ETH-экспозицию.
4. Только избыточный ETH направлять в стейкинг, xETH/yETH-пулы и/или вольты.

Допустим.

Но всё же - что лучше: добавить ETH в залог или погасить долг?

Погашение долга обычно лучше, если:

• Borrow APR высокий или быстро растёт;
• ETH уже занимает большую долю портфеля;
• Падение было резким и волатильность остаётся высокой;
• Health Factor находится ниже внутренней целевой зоны;
• Стейбл можно вернуть без большого проскальзывания.

Добавление ETH в залог может быть оправдано, если:

• Сознательно сохраняете лонг по ETH;
• Borrow APR низкий;
• Долг нужен для другой прибыльной стратегии;
• Есть достаточный внешний стейбл-резерв;
• Залог и долг используют надёжные активы и оракулы.

Но добавление ETH в залог не уменьшает направленный риск. Оно лишь отодвигает ликвидацию: это надо усвоить как 2х2. И ещё: "запасные" стейблы сильно снижают эффективность вашего капитала.

Допустим. Что дальше?

Дальше надо определить...

Практические зоны HF

Это не параметры протокола, а консервативная политика управления:

• Пусть HF > 2.0: допустимо рассматривать продуктивное использование нового ETH;
• HF = 1.6-2.0: не наращивать долг; часть ETH оставить ликвидной;
• HF = 1.35-1.6: погашать долг или добавлять залог;
• HF = 1.15-1.35: активное срочное уменьшение плеча (не даром в англ. есть слово deleverage);
• HF < 1.15: никаких дополнительных стратегий; закрытие риска;
• HF < 1.0: позиция ликвидируема.

Для волатильного ETH-залога разумнее ориентироваться не на текущий HF, а на стрессовый:

Здесь:

• C - стоимость залога;
• d - стрессовое падение ETH;
• LT - liquidation threshold;
• D - долг;
• rT - ожидаемый рост долга за горизонт.
• rT — ожидаемый рост долга за горизонт.

Важно! Целевой параметр: HFstress > 1.1-1.2: при стрессовом падении ETH ещё на 30–40%.

Пример сразу приведу. Пусть:

• залог: $150 000 в ETH;
• долг: $70 000 USDT;
• liquidation threshold: 80%.

И получаем следующее:

• Текущий HF: (150 000 * 0,8) / 70 000 =1,71
• После падения ETH ещё на 30% - HF: (105 000 x 0,8) / 70 000 =1,20
• После падения на 40% - HF: (90 000 * 0,8) / 70 000 =1,03

То есть формально комфортный HF 1.71 на практике почти не оставляет запаса.

Если LP после первого снижения выдал ещё $30 000 в ETH, логичнее использовать часть этих ETH для погашения долга, а не помещать весь объём в стейкинг.

2.2. Можно ли положить вышедший ETH в стейкинг?

Да, когда одновременно выполнены условия:

• ETH является желаемым долгосрочным активом;
• Нет опасного долга;
• Не потребуется быстрый возврат всей суммы в LP;
• Вы понимаете риски: LST, смарт-контрактов, ликвидности и возможного отклонения цены от ETH.

Ликвидный стейкинг позволяет получить stETH или аналогичный LST, продолжая использовать его в DeFi, но добавляет отдельный слой риска поверх ETH.

Возможные варианты:

1. Нативный стейкинг. Минимум дополнительных DeFi-рисков, но хуже ликвидность и операционная гибкость.
2. Ликвидный стейкинг: stETH, rETH и аналоги. Удобно для временно неиспользуемого ETH.
3. ETH/LST или LST/LST-пулы. Например, ETH/wstETH, wstETH/rETH.
4. Лендинг ETH/LST. Поставка ETH или LST в консервативный лендинг (депозит/вольт).
5. ETH-вольт. Стратегия должна оцениваться именно в ETH, а не только в долларах.

Но! Есть важное ограничение: ETH/LST-пул не является безрисковым ETH/ETH. В нём остаются:

• риск отклонения LST;
• слэшинг;
• риск смарта;
• риск ликвидности;
• риск протокола и оракула;
• IL относительно чистого ETH, если LST теряет привязку.

Академические исследования, к слову, показывают, что зацикливание stETH - collateral - borrow ETH - stETH действительно может повышать APR, но одновременно усиливает каскадные ликвидации при дисконте stETH.

Ссылка для подробного изучения: arxiv.org/abs/2401.08610.

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

• long ETH;
• LST basis risk;
• borrow-rate risk;
• liquidation risk;
• smart-contract risk.

2.3. Когда размещать ETH в ETH/ETH+ и подобный пул?

Подходящая ситуация может быть следующей:

• Ожидается боковик или постепенное восстановление;
• Вы не хотите продавать ETH;
• Диапазон ETH/стейбл пока открывать рано;
• LST-пара имеет достаточный объём и нормальную глубину;
• Диапазон широкий либо пул псевдо-стейбл.

Неподходящая ситуация - это, соответственно, складывается, когда:

• Падение вызвано проблемой конкретного LST;
• Выход из основного LP совпал с ростом системного риска;
• ETH потребуется для срочного погашения долга;
• Доходность существует в основном за счёт временных инсентивов и программа не долгосрочная.

Правило капитала я бы описал так (консервативно):

• Ок. 20-40% вышедшего ETH оставить ликвидным, если существует долг;
• Ок. 20-50% можно разместить в стейкинг/LST;
• Не более 20-30% - в дополнительные сложные вольты/LP-стратегии;
• Остальное - использовать для делевериджа и/или будущего возврата в ETH/стейбл-пул.

2.4. Когда возвращать ETH обратно в USDT/ETH-пул?

Короткий ответ: не сразу после касания границы. Перестановка оправдана, когда выполняется хотя бы одно условие:

1. Цена вернулась внутрь старого диапазона и удержалась там.
2. Сформирован новый торговый диапазон.
3. Реализованная волатильность снизилась.
4. Прогноз комиссий за следующий период превосходит цену ребаланса.
5. Вы сознательно готовы снова продавать ETH по мере роста.

Есть такой подход гистерезис (это буквальный перевод слова hysteresis): фактически это защита от дёрганья позиции. Если коротко сформулировать суть, то звучать она будет так:

Не реагировать на первое же пересечение границы пула, а дать цене дополнительный запас/подтверждение.

Что для этого нужно? Ввести 2 разные границы:

• Граница выхода;
• Более удалённая граница возврата.

Например:

• Позиция вышла ниже (L);
• Не переставлять её, пока цена не вернулась выше (L \times 1.02) или (L \times 1.04);
• Либо пока цена не проведёт внутри диапазона 12–24 часа;
• Либо пока не закроются 2-3 заданных временных бара (если вам близок тех. анализ).

Это предотвращает повторные ребалансы вокруг одной границы.

3. Если ETH-залога и долга нет

Здесь схема проще. Вариант A. Вы хотите накопить ETH. Тогда после нижнего выхода:

1. Не считать выход аварией.
2. Сохранить ETH.
3. Разделить его на ликвидный резерв и доходную часть.
4. Возвращать в ETH/стейбл LP только при восстановлении подходящего режима.

Возможная структура:

• 30% - liquid ETH;
• 30% - staking/LST;
• 20% - ETH/LST или LST/LST;
• 20% - резерв для нового диапазона.

Вариант B. Вы не хотите держать ETH. Тогда нижний выход означает нарушение риск-мандата (да, я по-прежнему настаиваю на этом термине :)).

Действия здесь такие:

1. Не открывать новый узкий диапазон ниже рынка.
2. Конвертировать часть ETH в стейблы.
3. Можно продавать несколькими траншами.
4. Вернуть LP только после определения нового диапазона.

Пример:

• Ок. 25% продать сразу;
• Ещё 25% - при закрытии ниже контрольного уровня;
• Оставшиеся (примерно) 50% - оставить для восстановления или хеджа.

Вариант C. Вы хотите временно сохранить ETH, но убрать дельту

Можно открыть шорт ETH (на perp DEX) приблизительно на величину ETH-дельты. Тут придётся напрячь мозг, ибо:

После же полного нижнего выхода LP:

Для полной нейтрализации:

Формулы пишу в упрощённом виде, но зато должно стать понятнее. Другой вопрос, что сам шорт добавляет риски. Какие? Например, такие:

• Фандинг риск;
• Риск ликвидации (уже на perp DEX);
• Риск базового актива;
• Риск биржи;
• Риск оракула;
• А ещё - необходимость динамического изменения хеджа при возврате в диапазон.

Поэтому для частного управления часто разумнее хеджировать 50–75% дельты, а не 100%. Да, вот такие пироги :).

4. Выход через верхнюю границу: позиция осталась в стейбле

Верхний выход означает, что AMM постепенно продал ETH при росте. Это может быть:

• Желательной фиксацией;
• Потерей дальнейшего апсайда;
• Исполнением covered-call-подобной стратегии (курс про опционы также бесплатен, напомню :)).

Да, ещё раз! Концентрированная LP-позиция экономически имеет опционную природу: LP продаёт выпуклость и получает комиссии за принятие этого риска. Да чего там - моё мнение, когда есть целые исследования, которые показывают, что IL концентрированной позиции можно реплицировать набором опционов внутри диапазона. См. пример: arxiv.org/pdf/2205.12043.

В общем, есть несколько ситуаций. Рассмотрю их кратко.

4.1. Не покупать ETH обратно сразу после выхода

Самая распространённая ошибка:

1. LP продал ETH по мере роста.
2. Цена вышла выше диапазона.
3. LP покупает ETH обратно выше.
4. Открывает новый диапазон.
5. Цена откатывает.
6. LP снова покупает ETH через AMM.

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

Пере-вход оправдан, когда: E[FeesT​]>SwapCost+Gas+E[LVRT​]+RiskPremium.

То есть возвращаться в LP имеет смысл, только если ожидаемые комиссии до следующего пересмотра позиции больше ожидаемых потерь и расходов от этого решения.

Разберём на примере ETH/USDT.

• E[FeesT] - сколько комиссий мы ожидаем заработать за период T. Например, за следующие 30 дней ожидаем $120.
• Swap Cost - потери на обмене активов при формировании новой позиции: комиссия DEX + проскальзывание. Например, $12.
• Gas - стоимость закрытия/перестановки/открытия позиции. Например, $3.
• E[LVRT] - ожидаемые потери LP из-за того, что при движении рынка арбитражёры торгуют против нашей ликвидности выгоднее для себя. Условно оценим давайте в $45.
• Risk Premium - дополнительная компенсация, которую хотим получить за принимаемые риски: смарт-контракт, волатильность, необходимость управления, вероятность снова быстро выйти из диапазона и т. п. Допустим, $20.

Получаем: 120 > 12 + 3 + 45 + 20 (если кратко: 120 >80). То есть ожидаемый экономический запас: 120 − 80 = $40. Пере-вход имеет смысл. Но если ожидаемые комиссии всего $60: 60 < 80, то лучше не возвращаться в LP: например, оставить USDT в лендинге и дождаться более подходящего режима.

И я бы для практики добавил сюда ещё альтернативную доходность капитала: E[FeesT​]>Swap+Gas+E[LVRT​]+RiskPremium+OpportunityCost.

Если USDT без всей этой возни приносит, например, $25 за тот же период на лендинге, то: 120 > 12 + 3 + 45 + 20 + 25: 120 > 105, но реальное преимущество LP уже всего $15.

Именно поэтому Fee APR 20% сам по себе ещё не означает, что пул выгоднее лендинга под 8%. Нужно сравнивать чистую ожидаемую доходность после всех специфических издержек LP.

Об этом я снял десяток видео и написал столько же статей, но пока донести простую мысль удалось(, но) не до всех.

Не следует использовать только отображаемый Fee APR. Он экстраполирует прошлый поток комиссий и не учитывает:

• Время вне диапазона;
• Изменение объёма;
• Изменение TVL;
• Влияние на цену (или price impact);
• LVR;
• Стоимость следующего ребаланса;
• Стоимость займа.

4.2. Куда помещать стейбл до перевхода?

Уровень 1 - низкая сложность:

• Депозит-лендинг на Aave, Spark, Morpho, etc.;
• Консервативные стейбл-вольты;
• Короткие стратегии с высокой ликвидностью.

Цель - получать базовый доход, пока не выполнено условие пере-входа.

Уровень 2 - стейбл/стейбл LP:

• USDC/USDT;
• USDC/DAI;
• Другие высоколиквидные stable-пары.

Риски:

• Депег;
• Несбалансированное накопление слабого стейбла;
• Смарт-контракт-риск;
• Инсентивы, маскирующие слабую органическую доходность.

Уровень 3 - GM/GLV или LP perp-DEX. GM-пул GMX - не стейбл-депозит! (Почему-то многие это не хотят признать даже): LP является контрагентом трейдеров, получает часть комиссий (если почитаете доки, то это trading, borrowing, swap & liquidation fees), но несёт PnL-риск и риск дисбаланса по открытом интересу. GM-пулы изолированы по рынкам; а мульти-токен экономически близок к ребалансирующемуся портфелю ETH/стейбл плюс результат торговли против трейдеров. Подробней об этом прямо написано в документации опять же: docs.gmx.io/docs/providing-liquidity.

Поэтому вложение стейблов в ETH/USD GM-пул означает, что вы снова приобретаете ETH-экспозицию и совокупный риск по контрагенту для трейдера (он на англ. так и называется: trader-counterparty exposure). Это не парковка стейбла поэтому и это надо понять и принять.

Подходящее применение:

• Небольшая доля портфеля;
• Достаточная компенсация за trader-PnL;
• Понятный дисбаланс открытого интереса (на англ. open-interest imbalance);
• Предпочтительно полностью обеспеченный (буквально - fully backed), а не синтетический рынок;
• Приемлемые депозит и вывод и потенциал.

Неподходящее применение:

• Стейбл нужен для погашения долга;
• Вероятен быстрый перевход в LP;
• Пул имеет высокий trader-PnL;
• Вывод ограничен риск-факторами;
• Доходность формируется коротким аномальным периодом.

GMX прямо указывает на подобные риски, если что: скажем, на возможную неликвидность GM-токенов, PnL-factor ограничения и риски синтетик-рынков. Многие ли готовы это реально принять и разобрать? Не уверен.

Уровень 4 - дельта-нейтральный вольт. Структура тут может быть разной, но, скажем, такую возьмём:

• Long spot/staked ETH;
• Short ETH perpetual;
• Доход от стейкинга и фандинга.

Она может быть близка к дельта-нейтральной, но не является безрисковой. Исследования модели, скажем, Ethena показывают, что доходность зависит от фандинга, базисного актива и др. факторов. Опять же - не верьте мне на слово - изучайте в документах: arxiv.org/abs/2605.11263.

Использовать такую стратегию стоит как отдельную доходную аллокацию, а не как автоматическую замену вышедшей LP-позиции.

5. Когда перекладывать стейбл обратно в ETH/stable LP?

Подход 1. Возврат цены

После верхнего выхода (U):

• Ждать возврата ниже (U);
• Либо ниже (U \times 0.98);
• Либо подтверждения новой консолидации.

Плюс: меньше риск покупать вершину. Минус: можно пропустить продолжение тренда.

Подход 2. Временной фильтр

Перевход только после:

• Ок. 12-24 часов вне диапазона на L2;
• Ок. 1-3 дней на майннете;
• Формирования нового режима волатильности (опять же: на англ. буквально так и звучит это в доках - volatility regime).

Подход 3. Диапазон с поправкой на волатильность

Ширина диапазона определяется не фиксированными 5-10%, а волатильностью (опять же - тут вам потребуется в помощь курс по опционам и optionizator.com):

где:

• σ - годовая реализованная или подразумеваемая волатильность;
• T - плановый срок до следующего управления;
• k - множитель, например 1-2.

Приведу пример, чтобы стало ещё понятней: при ETH волатильности в 65% и горизонте 30 дней получаем буквально по формуле следующее: 0.65 * кв.к. (30/365), или ок. 18,60%. И что дальше?

Отсюда получаем, что диапазон ±5% при таком режиме - это не пассивная позиция, а крайне активная ставка, требующая частых перестановок.

Подход 4. Рейтингование (Ladder)

Вместо одного диапазона:

• 40% капитала - широкий диапазон;
• 30% - средний;
• 20% - узкий;
• 10% - резерв.

Это снижает бинарность формата: весь капитал работает / весь капитал вне диапазона.

Подход 5. Односторонний пере-вход

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

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

6. Revert, Maverick и другие сервисы как помощь

Revert имеет Auto-Compounder и он, как следует из названия, автоматически реинвестирует накопленные комиссии за долю от компаундируемых средств. Это полезно, когда: Дополнительная доходность от реинвестирования > Комиссия за выполнение + Дополнительный риск смарт-контракта.

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

Revert позволяет продолжать управлять позицией, добавлять и удалять ликвидность и собирать комиссии. Собственно - подробности по ссылке снова оставлю: docs.revert.finance/revert/auto-compounder. При этом auto-range после выхода позиции автоматически переставляет диапазон согласно настройкам.

Но! Auto-Range не решает главный экономический вопрос: нужно ли вообще возвращаться в рынок? Он механически поддерживает активность позиции и поэтому может:

• Увеличивать число свопов;
• Фиксировать IL;
• Покупать актив после роста;
• Накапливать LVR;
• Ухудшать результат в трендовом рынке.

Использовать Auto-Range следует только с:

• Минимальным отклонением от границы;
• Понятным временем ожидания перед повторным входом;
• Ограничением частоты;
• Широким диапазоном;
• Минимальной ожидаемой выгодой от перестановки;
• Максимальной стоимостью свопа/газа/etc.

Maverick... Сейчас он не так популярен, но он всё ещё позволяет размещать ликвидность через бины (про bins - на курсе тоже есть) и использовать разные режимы движения/распределения ликвидности. При этом так называемые забущенные позиции дают возможность задавать и стимулировать конкретное распределение. Если интересно, можете почитать: docs.mav.xyz/further-information/frequently-asked-questions.

Практический же смысл такой:

• Уменьшить необходимость ручного перемещения;
• Сдвигать ликвидность вслед за ценой в заданном направлении;
• Строить направленные-позиции;
• Концентрировать капитал не обязательно симметрично.

Но движущаяся ликвидность не устраняет IL/LVR. Она меняет способ, которым стратегия ребалансируется. И это надо помнить.

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

Скажу лишь, что тут проверять необходимо следующее:

• Бенчмарк относительно HODL;
• Бенчмарк относительно простого широкого диапазона;
• Оборачиваемость (буквально - turnover);
• Реализованные IL;
• Комиссии без доп. наград/стимулов;
• Комиссии вольта (если есть);
• Долю времени в рейнже (диапазоне);
• Максимальную просадку;
• А ещё: кт может менять стратегию?

Steer - ещё одно решение, не шибко популярное, но всё же ссылку дам: docs.steer.finance. Он предоставляет автоматизированное управление CL-позициями через вольт-архитектуру и библиотеку стратегий на разных DEX и сетях.

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

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

• Arrakis;
• Beefy и другие yield-агрегаторы;
• Algebra-based ALM;
• Нативные вольты;
• Euler (частично);
• Вольты на perp DEXs;
• Опционы для статического или динамического хеджа IL.

А в завершении своего обзора - несколько важных слов о вещах, кот. "принято" обходить стороной

7. IL, DL и LVR: как считать правильно?

7.1. IL/DL относительно чего?

Без бенчмарка термин бессмысленен: это вы должны уяснить себе раз и навсегда. На мой взгляд - нужно всегда одновременно вести минимум 4 PnL:

• Benchmark A - HODL исходных активов: PnLvs HODL​= VLP​ + F - VHODL​. Это классический IL/DL.
• Benchmark B - просто ETH: PnLvs ETH​ = Vstrategy​ - NETH,0​Pt​. Показывает, не уступила ли стратегия простому владению ETH.
• Benchmark C - управляемый 50/50-портфель: PnLvs rebalance​ = VLP +F- Vrebalanced​. Это ближе к LVR и качеству исполнения AMM.
• Benchmark D - безрисковая альтернатива: PnLeconomic​ = Vstrategy​ - Vstable yield benchmark​. Иначе LP с доходностью 6% может выглядеть прибыльным, хотя лендинг давал 8% при меньшем риске.

7.2. Когда IL становится перманентным?

IL реализуется экономически не только при закрытии позиции (по сути - сжигания/удаления/etc. NFT). Он фактически закрепляется, когда вы:

• Выводите активы;
• Меняете диапазон через своп;
• Переводите вышедший ETH в стейбл;
• Покупаете ETH после верхнего выхода;
• Меняете бенчмарк и/или инвестиционный мандат (да-да, опять это слово :)).

Название impermanent не означает, что потеря "обязательно вернётся": для концентрированной ликвидности при полном выходе и продолжении тренда расхождение с HODL может увеличиваться.

7.3. Условие перекрытия IL комиссиями

Сейчас попробую вас удивить...

Feesnet​+Rewardsnet​>∣IL∣+Gas+Swap cost+Borrow interest+Manager fees

Как вам такое? Но для полной картины добавлю ещё вот так:

Strategy Edge=F+Y+I- IL - LVR - Crebalance​ - Cborrow​ - ELprotocol​

Но что это всё значит? Что если взять EL - ожидаемый убыток от протокольного риска, то можно получить куда более точную формулу:

Знаю, что уже поднадоел с формулами, но чтобы их собрать в 1 месте - потребовалось время, а чтобы объяснить - ещё больше.

По сути же речь идёт вот о чём: fee coverage ratio (чаще в финансовом анализе и кредитовании называемый Fixed-Charge Coverage Ratio, или FCCR) - это коэффициент, который показывает способность покрывать свои фиксированные регулярные обязательства (проценты) за счёт операционной прибыли.

И именно его я решил использовать в DeFi. Попробуйте - вам тоже понравится.

Чтобы было проще - вот таблица с моим подходом:

7.4. Когда комиссии чаще перекрывают потери?

Если оформить ответ списком, то получим примерно такие тезисы:

• Высокая органическая торговая активность;
• Умеренная реализованная волатильность;
• Цена колеблется внутри диапазона;
• Небольшое направленное движение;
• Низкая конкуренция ликвидности;
• Мало ребалансов;
• Низкие по стоимости газ и своп-косты;
• Широкий диапазон;
• Комиссия пула соответствует токсичности потока: вот так-то :).

Когда чаще не перекрывают?

• Сильный однонаправленный тренд;
• Скачки цены;
• Узкий диапазон;
• Частые перестановки;
• Много арбитражного, а не пользовательского объёма;
• Fee APR рассчитан по краткому аномальному периоду;
• Инсентивы доминируют над органическими комиссиями;
• LP использует дорогой займ;
• Позиция управляется с плечом.

8. Полная схема без плеча

Не знаю, дойдёте ли вы до этого места, но в любом случае вот ,что надо сделать ДО открытия:

1. Определить желаемый конечный актив при обоих выходах.
2. Установить бенчмарк.
3. Задать максимальную долю ETH.
4. Задать допустимое число ребалансов.
5. Рассчитать минимально необходимую доходность от комиссий.
6. Выделить резерв 10-30% вне LP.
7. Установить правила выхода заранее.

Что делать, пока позиция в диапазоне? Контролировать:

• Входящие комиссии;
• IL vs HODL;
• PnL vs ETH;
• PnL vs лендинг;
• Время в рейнже (диапазоне);
• Объём (и потом уже TVL: но не наоборот);
• Fee APR без инсентивов;
• Доходность LP от комиссий после вычета расходов на транзакции;
• Реализованную волатильность (о ней - на курсе по опционам всё есть: и бесплатно!);
• Расстояние до границы.

Нижний выход в ETH:

1. Не переставлять автоматически.
2. Определить, нужен ли лонг ETH.
3. Если да - использовать стейкинг/LST, широкий ETH/LST, резерв.
4. Если нет - частичная продажа и/или шорт-хедж.
5. Возврат в LP только с hysteresis (это загадочное слово - см. выше: читать по диагонали ЭТУ статью НЕ выйдет, к сожалению).

Верхний выход - в стейбл:

1. Перевести стейбл в лендинг/короткий вольт.
2. Не покупать ETH сразу.
3. Ждать возврата, консолидации или нового диапазона.
4. Рассмотреть односторонний диапазон ниже цены.
5. GM (или perp vault) использовать как отдельную риск-корзину.

9. Полная схема с плечом через лендинг

9.1. Допустимые подходы

Архитектура A: ETH collateral - borrow stable - ETH/stable LP. Это направленная леверидж-LP-стратегия (или как бы вы её назвали?).

На падении:

• Залог падает;
• LP превращается в ETH;
• HF ухудшается;
• Портфель получает больше ETH.

Это наиболее опасная конструкция для нижнего выхода.

Архитектура B: стейбл-collateral - займ ETH - ETH/стейбл LP.

На росте ETH:

• Долг дорожает;
• LP превращается в стейбл;
• Стоимость долга растёт;
• ETH для погашения в LP становится меньше.

Опасна при верхнем выходе.

Архитектура C: ETH collateral - займ стейбла - доход от стейбла.

Это обычный "carry trade", если перевести в язык ТА: Net carry= Ystable​ - Rborrow​. Но сохраняется риск ликвидации (ETH).

Архитектура D: collateral + займ + хедж LP. LP-дельта компенсируется шорт/лонг (perp DEX). Более нейтрально, но требует регулярного хеджа и несёт риск ликвидации и риск фандинга на двух площадках.

9.2. Максимальное плечо должно определяться стрессом

Да, это важно! Не просто протокол позволяет LTV 75%, значит можно использовать 70%. Нет, это, простите за мой французский, байда. Надо подходить серьёзней :).

Скажем, так (А-позиция):

Приведу пример, чтобы легче воспринималась ещё одна формула:

• Залог пусть у нас - $100 000;
• LT = 80%;
• Стресс-падение ETH = 40%;
• Целевой стрессовый HF = 1.2.

Отсюда получаем что? Dmax = (100 000 * 0,6 * 0,8) / 1,2 = 40 000: то есть безопасный исходный LTV по этой модели - ок. 40%, хотя протокол технически допускает заметно больше.

9.3. Правила плеча

Да, и такое я для себя вывел:

1. Не занимать максимальный доступный объём.
2. Держать отдельный стейбл-резерв (в LP) на 15-30% долга.
3. Не использовать LP-NFT как единственный источник погашения.
4. Borrow APR должен быть ниже консервативного ожидаемого дохода, а не текущего "рекламного" (буквально - headline) APR.
5. Проверять доходность без инсентивов (да, много раз написал об этом, но это и важно: критически!).
6. Не использовать рекурсивный луп, если коллетерал и стратегия чувствительны к одному активу.
7. Устанавливать триггер (буквальное название: deleverage trigger) намного выше ликвидационного.
8. Учитывать рост долга во времени.
9. Не смешивать несколько плечевых стратегий в одном аккаунте без агрегированного HF расчёта.
10. Для Morpho и подобных историй отдельно проверять LLTV, оракул и ликвидность конкретного изолированного маркета. Потому что эти рынки изолированы не просто так, а параметры LLTV неизменны для созданного рынка, однако рыночный и оракульный риск остаются специфичными для каждой пары.

Опять же - не верьте мне на слово - изучайте документацию: docs.morpho.org/build/borrow/get-started.

10. Рекомендуемая рабочая архитектура

Только не надо на меня сваливать свою практику :). Рекомендованная эта архитектура лишь в том смысле, что сводная по статье. Итак, для капитала (K), выделенного на ETH/стейбл-стратегию (ну или любую подобную) - получаем:

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

11. Итоговое дерево решений

Куда без него? Поехали!

Пул вышел вниз и остался ETH

Есть стейбл-долг под ETH?

• Да:
• HF ниже целевого - погасить долг.
• HF приемлем, но стрессовый HF плохой - частично погасить долг.
• HF и стрессовый HF безопасны - часть ETH можно застейкать.
• Не открывать новый (leveraged) LP, пока риск не нормализован.
• Нет:
• Хотите ETH держать: стейкинг, ETH/LST, широкий LP.
• Не хотите ETH - продать траншами или захеджировать.
• Хотите повторный LP- ждать возврата/консолидации.

Пул вышел вверх и остался stable

Хотите зафиксировать прибыль?

• Да:
• лендинг/стейбл-вольт;
• часть оставить резервом;
• односторонний диапазон ниже рынка.
• Нет (хотите снова ETH):
• не покупать весь ETH сразу;
• поэтапный вход в позицию (тот самый ladder entry: если внимательно читали всё выше);
• новый широкий диапазон;
• использовать hysteresis (да, опять это "мутное" слово :)).

Хотите дополнительную доходность?

• лендинг - базовый уровень;
• стейбл/стейбл пул (но депег риск) - далее;
• GM/GLV - но тут риск убытков от прибыли трейдеров и ETH экспозиция, т.е. зависимость стоимости позиции от цены ETH или, короче, ценовой риск ETH.
• дельта-нейтральные вольты - тут риск фандинга и ликвидации прежде всего.

12. Краткий регламент управления

Не знаю, надо ли это ещё сокращать до списка/чек-листа, но все их любят, поэтому:

1. Не переставлять позицию по одному касанию границы.
2. Использовать буфер 2-5% или временное подтверждение.
3. Не возвращать весь капитал одним новым диапазоном.
4. После нижнего выхода при наличии ETH-залога сначала снижать долг.
5. После верхнего выхода временно парковать stable в ликвидной стратегии.
6. Считать IL одновременно против HODL, ETH, 50/50 ребаланса и лендинга.
7. Комиссии считать все (это могут быть: net of gas, manager fee, borrow и incentives и др. по документации вещи);
8. GM/perp-vault НЕ считать заменой стейбл-лендинга.
9. Авто-рейндж использовать только с кулдауном (см. выше) и экономическим порогом.
10. Плечо рассчитывать по стрессовому HF, а не по максимальному LTV протокола.

Наиболее устойчивая модель для простого LP - широкий базовый диапазон, небольшой активный диапазон, отдельные резервы ETH и стейблов и умеренное либо отсутствующее плечо. Узкие полностью автоматизированные позиции с большим LTV могут демонстрировать высокий Fee APR, но часто скрывают коэффициент оттока (поищите на англ. про churn), LVR и ликвидационный хвостовой риск.

Так что будьте внимательны, не жадны и удачи вам в начинаниях:

До!

Как пользоваться курсом?

Ниже объединены ссылки разных лет по DeFi-курсам: первые статьи от 2019 года, последние - от 2026-го. Чтобы материал не был устаревшим, обновляю те части, кот. меняются со временем, но большинство фундаментальных данных изменить попросту невозможно. Незачем.

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

Компромисс возможен, но вам он не нужен. Поверьте.

Формат подходит как для совсем новичков (узнаете основные термины, правила и сервисы), так и для тех, кто хочет идти дальше (для вас есть: тонкости AMM, работа с DeFi через смарт-контракты, опционные стратегии и многое другое).

А теперь - к сути.

Схема курса. Простая

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

Схема курса. Настоящая

Как видите, всё немного сложнее?

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

Введение

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

• Прото-примитив: стейкинг, когда нужно заморозить уже имеющиеся средства;
• Мета-примитив: индекс, когда средства замороженные посредством некой операции объединения можно разморозить.

Всё.

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

Исключение составляют те истории из DeFi, которые касаются не B2C-сегмента: скажем, MEV-боты (см. пример №01 и пример №02) и оракулы, но поэтому о них рассказываю лишь в ознакомительном аспекте.

Что ещё нужно знать до начала? Хорошо бы освоить - главное правило DeFi, а звучит оно так:

Максимизация получаемого дохода (и итоговой прибыли) в DeFi, достигаемая за счёт возможностей блокчейна, его экосистемы, конкретных протоколов и дапсов (децентрализованных приложений: dAPPs).

Не сложно? Да, но на деле всё не так просто, поэтому перейдём к практике.

Подготовка

Безопасность. Краткое введение

Прежде всего вы должны знать, что пресловутая аббревиатура DYOR, которая буквально означает Do Your Own Research, т.е. призывающая делать вас свои собственные исследования, производна от общего принципа Web 3.0 & Web3 (далее - WW3) - децентрализации, которая призывает всех нас быть самостоятельными, ответственными и честными.

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

Базовые риски

В первую очередь стоит усвоить базовые риски. Перечислю их:

1. Идеологические основы DeFi и безопасности - дадут вам остов, на который можете нанизывать своё понимание общей защищённости: без этого прожить можно, но не долго :).
2. Риски, описанные мной в виде тезисов, - аналитическое представление тех угроз, кот. можете встретить внутри WW3.
3. Если мало п. 2, попробуйте вникнуть и сюда: если пока для вас сложно - пропустите п. 3: вернётесь, но позже (такие случаи - возможных пропусков - буду обозначать отдельно).
4. Инструменты, кот. можно использовать для улучшения безопасности: только не думайте, что они заменят вам методологию - нет, но помогут её развить точно: большая ошибка - думать иначе.
5. Если вам уже не терпится узнать о методологии именно, то рекомендую изучить 4К-подход, который включает оценку команды, концепта (проекта), коин (или токен) и код (даже если вы - не кодер): поверьте, вы сможете с его помощью отсеивать не нужное весьма быстро. Методология была придумана внутри DAO Synergis в 2016 году и с тех пор не теряет актуальности.

Самозащита

В целом за те (почти) 15 лет, что тружусь в индустрии, сложилась такая воронка самозащиты от скама и одновременно - отбора важных проектов:

1. Для начала выделил те проекты, с которыми совсем не работаю: токенизация разных запрещённых веществ (как Paragon), оружия и XXX, а также казино и схожий хайп (мем-токены, допустим);
2. Далее, если проект прошёл первое “сито”, изучаю его по 4К: благо сейчас коллеги автоматизировали процесс и можете это делать с помощью AI в том числе (см. ссылку: tcccai.xyz, но, возможно, вам хватит и просто ИИ-анализа: зависит от вашего же аппетита);
3. Наконец, после этого провожу фундаментальный, стоимостный и визуальный анализ.

За всё время на “голимый” скам (навроде, пираМММид Cashberry или OneCoin) ещё ни разу не наткнулся: и именно благодаря воронке. Это не спасёт от технических методов нападения (на них приходилось нарываться, но тоже ограниченное число раз), но о них - позже.

Самое важное, что стоит учесть в технической, экономической и прочей безопасности, это факт того, что часто кажется, что она (безопасность) - нечто сложное и даже недоступное, а поэтому? Можно её просто игнорировать! Нет, это не так.

Но такого “слона надо есть по кусочкам” - тогда (и только тогда) всё получится.

Скажем, каждую пятницу-воскресенье (у меня) есть несколько ритуалов, которые полезными считаю для любого типа DeFi-щиков, и кот. избавят вас от ненужных цифровых следов:

1. Проверьте транзакции по кошельку в разных сетях: вы в них уверены? Через debank.com или любой сканер (о них - ещё упомяну), агрегатор, etc. Понимаете ли источники происхождения этих транзакций? Отделяете скам / спам-транзакции от легитимных? Знаете, зачем вообще создают так много спама (пыли)?
2. Проверьте браузер по умолчанию: он НЕ должен совпадать с тем, что связан с крипто-операциям. Никогда. Почему? Потому что даже если вы откроете ссылку - у вас она не должна появиться в том же месте, где находится крипто-кошелёк.
3. Обязательно очищайте историю браузера, с кот. работаете в DeFi: для многих это звучит как безумие: утомительно же! Но:
1. Во-первых, это, напомню, должен быть браузер (и профиль в нём) именно для криптоактивов (у меня ещё есть распределение для ETH & NOV-EVM проектов), т.е. абсолютно отдельный (автономный).
2. Во-вторых, подключаетесь всё равно через кошелёк, поэтому лишнего не надо: отсюда - всё стоит и всегда проверять (например, зачем дали разрешение на рекламное отслеживание или избыточные куки).
3. В-третьих, спросите себя, а вы точно в актуальном состоянии содержите закладки / папки / etc. и всё помните / знаете про эти сайты / dAPPs (децентрализованные приложения)? Если нет, то примите и поймите, что и через них совершаются атаки (фактически - это один из видов атак на цепочку поставок (Supply Chain Attack) - кибератака, кот. нацелена не на само приложение/проект напрямую, а на менее защищённых партнеров, подрядчиков или программные компоненты).
4. Обязательно нужно удалять связи приложений (через Metamask или Rabby, например) по выше названным же причинам: проверить, чем пользуетесь, а чем - нет. В идеале у вас сформируется белый список приложений, который запомните и удалять не будете, кроме самых крайних случаев. В Metamask, например, это делается так: все разрешения - отключить; в Rabby - схожим образом. Многие, опять же, считают этот пункт избыточным, но безопасность и строится именно на ней - на избыточности.
5. К слову: запоминать адреса сайтов, которые чаще всего применяете в деле, - бонтон, а вот не знать их, вводя по 10 раз и переходя лишь по закладкам, - моветон.
6. “Уж сколько раз твердили миру…”, а про аппрувы не все до сих пор в курсе. И зря! Начните с revoke.cash: они автоматизируют многое. Далее - в том же Rabby есть такая функция. Наконец, и в эксплорерах... Перечислю ресурсы для простоты:
1. revoke.cash;
2. approved.zone;
3. de.fi;
4. etherscan.io/tokenapprovalchecker;
5. bscscan.com/tokenapprovalchecker;
6. polygonscan.com/tokenapprovalchecker;
7. arbiscan.io/tokenapprovalchecker;
8. optimistic.etherscan.io/tokenapprovalchecker;
9. v3app.everrise.com/everrevoke - альтернативно;
10. tools.sunscrypt.ru/checker;
11. gist.github.com/0xngmi/789e297f3107d3c28c56da7acf11828d - антифишинг база.
7. Когда базовую чистку произвели, проверьте обновление ПО (важно - именно в такой последовательности):
1. ОС (операционная система: от Win отказаться лучше сразу);
2. Браузер (подходят для работы Brave, Chrome, Firefox и даже порой Opera; для поиска лучше использовать TOR-браузер);
3. Базовые кошельки вне браузера: как на ПК/Mac, так и на смартфоне;
4. Иное ПО (да-да, его тоже ломают на атаках).
8. Отдельным шагом стоит удаление:
1. Всех неиспользуемых программ;
2. Разных пакетов, которые уже не нужны;
3. Прочего: корзина должна быть пуста, если по-простому.
9. Настройки брандмауэра тоже лучше всего иметь всегда под рукой и проверять, т.к. сетевые подключения лучше понимать и разбираться в них - хотя бы на базовом уровня (в совсем уж запущенном случае - хотя бы с помощью ИИ).
10. Конечно, важно сверять и гугл-аккаунт, и соц. сети:
1. Во-первых, они никогда не подключаются в том же браузере, в каком работаете с криптопроектами: исключения бывают, но только если этого требуют тестнеты/airdrops, и в любом случае это ограниченный список. И время подключения - тоже ограниченное.
2. Во-вторых, google-аккаунт лучше иметь один публичный (у меня это menaskop) и не публичный - это крайне значимо. Не публичных может быть даже 2-3. Проверить настройки вашего именно гугл-аккаунта можно по ссылкам: myaccount.google.com/security и myaccount.google.com/security-checkup.
3. В-третьих, безопасность других соц. сетей - обязательно тоже бдить. Приведу в пример X (Twitter): x.com/settings/security_and_account_access.
4. В-четвёртых, обязательно проверяйте двухфакторную авторизацию: а) стоит/нет? б) подключенные устройства (если уместно); в) способы авторизации и т.д. И всегда сверяйте авторизованные устройства.
11. Посмотрите отчёты по времени, на что его тратите онлайн: удалите всё ненужное. Ещё раз: обязательно введите временной контроль! То есть:
1. Установите режим на неделю. Скажем, у вас стоит с 6 утра до 21 вечера - время для операций. Из них для активных операций - с 9 до 19. Остальное - резервное время. Это не значит, что с 6:00 до 21:00 вы у компьютера, но это значит, что раньше, чем в 06:05 и позже чем в 20:55 по любому местному времени не будете проводить транзакции, связанные с WW3 или даже банком (хотя там почти и не делаю ничего и вам не советую). Фишинг и др. массовые векторы нацелены на вашу усталость - помните об этом.
2. Устанавливайте временные лимиты на ПК/MAC, смартфон: вы должны знать, что сжирает время не только ваше, но и их: скрытые майнеры и прочее - это не сказки, а быль.
12. Обязательно вспомните ключевые проекты, за которыми следите. У меня для этого стоит приложение от cryptonews.net, а также уведомления google.com/alerts. Но сейчас это через ИИ-агентов прекрасно настраивается. Тоже.
13. Не забывайте про анализ хаков и взломов: rekt.news и DeFiLlama hacks - лучшие помощники в этом, а знание и понимание паттернов взломов - 51% успешного ухода от таковых.
14. Наконец, не забывайте:
1. Сканировать сеть на подключенные устройства (подойдут Nmap, Fing и аналоги);
2. Менять пароль на Wi-Fi хотя бы 1 раз в год;
3. Смотреть входы/выходы подключений (если уместно);
4. Никогда не используйте публичные Wi-Fi-сети: даже через VPN. Никогда!

Главный вопрос

Теперь задам вопрос, который должны задать себе сами: “Почему безопасностью надо заниматься сразу, а не потом?”. И отвечу:

1. HODL. 1 биткоин 10 лет назад и ровно тот же биткоин сегодня - разные по стоимости вещи (хотя и одинаковые по ценности, возможно). HODL не означает, что надо отказаться от аналитики безопасности: Квантовые компьютеры (КК) - не сегодня родятся (в нужном для взломов виде), но скоро; методы взлома совершенствуются; соц. инженерия никуда не делась (вспомните о краже на 3000++ BTC). Поэтому когда очухаетесь - будет уже поздно. Делать надо сразу, а не потом.
2. Безопасность - набор ежедневных ритуалов, а не ad hoc занятия, кот. то есть, то нет; кот., к тому же, не зависят от чего-то внешнего и т.д. Нет.
1. Безопасность - дневник сделок.
2. Безопасность - алгоритм включения и выключения компьютера.
3. Безопасность - схема резервирования. Нельзя заменить безопасность сиюминутными решениями: поставил надёжную ОСь, файрволл и выучил базовые атаки и всё - ты в дамках. Нет. Именно игнорирование этого пункта губит всех неофитов.
3. Очень многие считают, что инструменты == безопасность, но на самом деле инструменты - лишь часть технической безопасности. Туда же относится контроль над железом, "бумажным" резервированием и т.д. А ещё есть безопасность бывает:
1. социальная (организационная и физическая);
2. экономическая (стратегия, портфель, т.д.);
3. правовая;
4. прочая (упускать любую из них - подобно смерти чаще всего. Об этом поговорим отдельно).
4. Если хотите понять, как вас взломают, зайдите к себе в комнату / офис / иное помещение, где стоит ПК / Мак и/или находится ваш смартфон и попробуйте сделать 4 простых действия:
1. Украдите их: это сложно? Сможете восстановить быстрее похитителей всё нужное и важное? А отследить железо своё?
2. Попробуйте подобрать пароль и/или попросите это сделать близких (и замените потом).
3. Можно ли что-то скачать без спец. авторизации с устройств(а)?
4. Можно ли быстро подключиться к вашей сети?
5. И да, помните про нулевое правило безопасности: взломать можно всё, что угодно, и кого угодно. Вопрос всегда во:
1. Времени;
2. Внимании;
3. Валюте;

Если будет достаточно внимания, времени и валюты (ресурсов в целом) - вас взломают. И поэтому задача всего одна: убрать себя из зоны внимания (хакеров) и при этом удлинить время максимально, кот. они тратят на взлом, чтобы сделать взлом баснословно дорогим (храните $1M, а на взлом надо потратить >$1.1M - идеальная пропорция).

Seed-фраза

А далее вам следует понять, что ваши деньги - это приватный ключ. Или, чуть в более общем виде, сид фраза.

Что это и как см. в видео:

Здесь же дам несколько первичных рекомендаций:

1. Изучить обзорную статью;
2. Посмотреть компоновку про 2 связанные категории;
3. Углубиться в материал;
4. Использовать шаблон для учёта кошельков;
5. Потренироваться на практике с таблицей;
6. И не забыть про сервис: iancoleman.io/bip39;
7. Изучить также и материал о SSS.
8. Отдельно вникнуть в связку Trezor + Metamask (и любую подобную).
9. Научиться использовать утилиты:
1. ssss-split
2. VeraCrypt
3. Crypt3
4. Их аналоги
10. Узнать о защите от дурака и не пренебрегать ей;
11. Научиться в стеганографию (разные её типы / виды);
12. Понять, почему плохие пароли - не защищают;
13. Также как и плохие сид-фразы, созданные без нужной энтропии (вероятности) - тоже не помогают и не защищают.

Базовые тезисы обозначил бы так:

1. Оффлайн (физическое) хранение: железо, бумага и голова - должны быть всегда и для крупных сумм - "крупность" определяете вы: кому-то $1000 - много, а иным - $1 000 0000 мало;
2. Онлайн-хранение тоже должно опираться на несколько уровней самозащиты: пароль от 21+ символа и сложный, а по возможности - хорошая беспарольная авторизация/аутентификация, проверенные (и) open source утилиты (лучше - с эффектом матрёшки (зашифровали одной - поместили в скрытый контейнер/диск другой)) и т.д.

Но помимо этого важно вести таблицу учёта кошельков, но не сид-фраз. Заморачиваться только с основными (сид-фразами) на оффлайн уровне.

Кошельки

Градация кошельков первичная для этого примерно такая:

1. Тестовый кошелёк (MetaMask, Trust, Trustee, Rabby, etc.) - для первичного подключения к новым dAPPs;
2. Операционный кошелёк - горячий - для повседневной работы;
3. Хедж (Trezor/Ledger/etc.) - базовый холод;
4. Инвестиции - мультисиг или в этом роде.

Для всего этого крайне важно - изучать ПО, которое ставите: от и до. Без анализа хотя бы через ИИ - здесь не обойтись. Точно.

При этом также важно, создаёте ли уникальную систему хранения сид-фразы. Если пока не хватает опыта, то начните с книг К. Митника и шифропанков: они вам точно помогут. Потом переходите на Сноудена. А дальше - больше.

Собственно, по этим же причинам важно иметь резервные копии там, где есть гражданство, но отдельно следует заморочьтесь именно там - полной с защитой: скажем через Траст (DAO) и Депозитарий, - т.е. сделать так, чтобы доступ к средствам на холоде был не у вас, а распределённым именно.

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

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

Но только не делайте так с рабочим сидом! :): это тест места, а не самого доступа.

Практикуйте уникальные способы хранения:

• через сложные аккорды;
• через шахматные партии;
• через нарезки видео;
• через детские рисунки;
• через страницы книг;
• через…

В общем и ещё раз: используйте фантазию, но не забывайте принципы (де) шифровки.

После этого - переходите уже к действиям с DeFi. В частности, в любом случае при тестах и тем более - при “боевой” работе с DeFi-инструментами всегда вначале исследуйте:

1. Был ли ранее взломан протокол (приложение) ДО вашего его использования?
2. Есть ли негативный опыт работы с ним в моменте (сейчас) у вас и/или других: отзывы, комментарии, обсуждения прочего толка?
3. Как реагирует на URL virustotal.com?
4. Каков трафик проекта (если ниже 10 000/мес., то новичкам это не подходит)? Тут поможет similarweb и аналоги.
5. Давно ли создан домен (если менее года - тоже не подходит новичкам).

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

Для начала - общая оценка сайта (dAPP):

1. whois.com - проверка возраста домена;
2. virustotal.com - проверка URL на малварь;
3. similarweb.com - проверка трафика;
4. web3antivirus.io - web3-аналог антивируса;
5. defisafety.com/app - проверка дапса в целом;
6. pocketuniverse.app - защита ассетов;
7. tenderly.co/transaction-simulator - симулятор транзакций (помните только про токсичные пулы!).

Агрегаторы и доп. ПО:

1. Open source тулзы: trailofbits.com/opensource
2. Агрегатор ПО: tools.crypton.xyz/main
3. Спец. ПО: certora.com/gambit
4. Сравнение сетей: evmdiff.com/diff
5. L2-сравнение: l2beat.com/scaling/summary

Новостной фон: если его не изучаете, то это ещё хуже, чем если только на нём и сконцентрированы. Тем более что новые протоколы, а равно - взломы, иначе найти сложно. Итак:

• google.com/alerts - простой и надёжный как швейцарские часы инструмент, который каждый день может приносить вам уведомления по ключевикам.
• cryptonews.net - лучший агрегатор новостей на разных языках.
• rekt.news - взломы и всё о них вокруг Web3 и не только.
• xakep.ru - новости не всегда акутальны, а вот разборы атак - да.
• defillama.com/hacks - база взломов.
• haveibeenpwned.com/PwnedWebsites - уязвимости разного рода.
• certik.com/resources - блог про безопасностей сетей и протоколов.
• hacken.io/research - альтернатива.
• slowmist.com/service-incident-response.html - оповещения.
• scamadviser.com/report-a-scam - оповещения.

Аудиторы - важные участники экосистемы безопасности, поэтому не пренебрегайте их отчётами:

• рейтинг 2024.
• или ещё один рейтинг.
• важные данные.
• и альтернативный список.

Из тех, чьи услуги использовались мной на практике и к чьим советам можно прислушаться:

• Immunefi - известны своими баг-баунти кампаниям.
• Certik - дорого, но бывает качественно.
• Hacken - в большинстве случае плохие аудиты за дёшево и дорого за хорошие.
• Auditdb.io - альтернатива.
• Mixbytes - не плохи как раз в DeFi-структурах.
• Cyberscope - альтернатива.
• Decurity - и ещё одна.
• Composable-security - лично не встречался, но отзывы получал.
• Hexens - альтернативно.
• Strongholdsec - альтернативно.
• iBer - мой основной партнёр.

Если помните, то выше обсудили 4К-систему. Так вот обычно последняя К (код) вызывает оторопь у новичков. Но на деле это тоже - вполне автоматизированный и визуализированный даже процесс.

Вот несколько сервисов, которые помогут вам с анализом гитов:

• gitlive.net - здесь можно посмотреть общую активность по гитам, чтобы оценить объёмы.
• cryptomiso.com - это один из самых простых способов выявить крипто-лидеров гита в моменте.
• tokensniffer.com - много пишет, часто ошибается, но для общей аналитики подходит.
• contractreader.io - визуализирует и систематизирует данные по коду токена.
• w3bs3c.com/tools - поиск по инструментам безопасности.

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

• tokensniffer.com - общий аудит токена.
• honeypot.is - альтернатива.
• pessimistic.io - база по само-образованию по безопасности смартов.
• github.com/crytic/building-secure-contracts - альтернатива.

Если же вам нравится визуализировать всё и вся, то вот список инструментов для этого:

• metasleuth.io - cамый простой из всех.
• intel.arkm.com - самый популярный.
• shard.ru - альтернативно.
• debank - самый известный смарт-агрегатор данных.

Когда разобрались с сид-фразой, поняли про безопасность всё из отчётов и новостей - самое время обратится к усилению. И здесь на помощь приходит Safe:

Коротко о нём:

1. Освойте основные функции: создание, транзакции ввода, вывода;
2. Фундамент безопасности мультисига состоит в том, что подписи должно быть 2 из 3, 3 или 4 из 5 и т.д., но не 1 из 1;
3. Лайфхаки безопасного использования: вы можете найти у меня на канале и в группе бесплатных событий;
4. Фичи именно safe - то, что придётся учить постоянно.

Другие сети тоже имеют свои мультисиги. Приведу лишь 2 примера, но их гораздо больше:

• Bitcoin-мультисиг;
• Polkadot-мультисиг.

В целом же (на примере Safe) алгоритм следующий:

1. Создать на app.safe.global мультисиг в любой EVM-сети;
2. Провести транзакцию пополнения;
3. Провести транзакцию вывода;
4. Применить для себя 3 кошелька;
5. Входить по подписям 1 из 3-х;
6. Потом 2 из 3-х;
7. Первый кошелёк (первый подписант) - операционный;
8. Второй - c пасс-фразой;
9. Третий - бумажный.

После этого можно освоить доп. утилиты:

• safeutils.openzeppelin.com
• etherscan.io/inputdatadecode

И также никогда не грех применить альтернативные интерфейсы и/или посмотреть их архивы:

• app.palmeradao.xyz
• eternalsafe.eth.limo
• app.onchainden.com

Наконец, можно изучить доп. источники (для) проверки:

• chainlist.org - список сетей;
• chainid.network - альтернатива.

Компонуем сказанное

И дополнительно:

Ханипоты

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

Коротко: honeypot (с англ. - "горшочек с мёдом") - ресурс, представляющий собой приманку для злоумышленников.

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

• Виртуалка: чтобы определить потенциально опасные dAPPs.
• Сид-фраза: у меня всегда есть 5-7-10 seed-ов, чтобы их мог найти любой, но ценности в них нет никакой, кроме того, что в ряде случаев я узнаю о попытках взлома;
• Кошелёк: как правило, всё тестирую на menaskop.eth, а уже потом на др.
• Email: публичный - обязателен (см. выше);
• Соц. сети: унификация через данные, фото, etc., чтобы всё личное сразу было понятно, что "слито";
• Фото: в том числе и ХХХ формата (поддельные ;), конечно же): по той же причине, что и выше;
• Прочее.

Суть в том, чтобы создавать цифровые следы, которые известны и понятны вам, но не другим: скажем, у вас похитили сид-фразу, которую хранили в файлах (на) iPhone, забрали средства оттуда и всё шито-крыто.

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

Такой метод (подход) используется и довольно часто: например, для Profanity-адресов, чтобы понимать, когда ключ подобран. Но никто не мешает делать это более повседневно.

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

Тоже касается и email: чем больше будете собирать на него спама/скама/фишинга, тем быстрее сможете им противостоять.

Но ханипоты, конечно же,требуют дисциплины, выдержки даже и опыта: простые приманки действуют не на всех, а слишком крупные - приведут рыбу, которая откусит не то.

И всё же завершать свою стратегии безопасности надо именно на ханипотах: так вы выставляете маяки, за которыми следите… Удачи!

Простой чек-лист

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

1. Вы начали с tier-1 чейнов (Ethereum, Bitcoin), протоколов (Uniswap) и приложений? Если да, то ок: обычно подавляющее большинство бежит туда, где APR выше. И ошибается…
2. Вы начали работу без займов? Если да, то ок: как правило, никто так не хочет делать, а хочет увеличить "маржу", или, иначе, левериджа (на деле - убытки и риск), а по сути - плечо.
3. Вы начали с простых способов и шли к сложным? Если да, то ок: обычно люди берутся за фарминг, деривативы и т.д. сразу же. И это заканчивается плачевно.
4. Вы начали с инвестиций в 1% в сделку, а не с 3-5%? Если да, то ок: обычно легко берут 10%-30%, а то и 50%-100%. И это совсем не безопасно.
5. Вы начали с получения 5-10% APR, а не 20%-30% и больше? Если да, то ок.: обычно все хотят больше денег. Сразу и много. Но это иллюзия.
6. Вы начали с безопасности?.. Если да, то ок: обычно на это вообще не обращают внимания. А обратить 100% нужно: см. и читай статьи выше.

[Продолжение следует...]

До!

Введение

Когда говорят о безопасности Bitcoin, разговор почти всегда сводится к приватному ключу // seed-фразе, аппаратным кошелькам, мультисигам, резервным копиям и физической защите (ключей).

Но у Bitcoin есть ещё один уровень защиты, который принципиально отличается от защиты самого ключа:

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

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

1. Абсолютную временную блокировку через nLockTime;
2. Относительную блокировку UTXO через BIP68 + OP_CHECKSEQUENCEVERIFY (CSV).

Главная цель эксперимента - не просто прочитать документацию Bitcoin Core, а увидеть поведение сети непосредственно в связке: валидная подпись + правильный ключ + правильный UTXO ≠ обязательная возможность потратить BTC прямо сейчас (в момент транзакции).

Все эксперименты проводились локально через Bitcoin Core v31.1.0 в публичной сети Signet, т.к. использовать реальные BTC для этого - перебор (как по мне).

Вопрос №01. Что именно хотел проверить?

Исходная идея была связана с безопасностью хранения Bitcoin. Предположим, злоумышленник каким-либо образом получил приватный ключ. В обычной схеме: если приватный ключ скомпроментирован - создаётся транзакция - через подпись и монеты транслируются через них в сеть, т.е. BTC меняют "статус" на : "украдены".

Но можно ли построить UTXO так, чтобы самого приватного ключа было недостаточно?

Например: приватный ключ + условие времени = возможность расходования? Короткий ответ: да, можно. Но зачем? Всё просто: компрометация ключа в момент Tо не обязательно означает возможность немедленной кражи.

Это особенно интересно для архитектур:

• холодного хранения;
• наследства;
• восстановления;
• резервных путей восстановления;
• отложенного вывода;
• vault-подобных конструкций;
• схем, в кот. время используется как доп. граница безопасности.

Чтобы понять фундамент, отдельно верифицировал абсолютное и относительное время.

Вопрос №02. Что нужно для опытов?

Короткий ответ: лаборатория. Для эксперимента мной был создан отдельный Bitcoin Core datadir (пишу для Mac, т.к. для Linux повторить не сложно, а с Win не советую работать никому):

mkdir -p "$HOME/BitcoinSignet"
nano "$HOME/BitcoinSignet/bitcoin.conf"

Bitcoin Core запускался nfr:

bitcoind -datadir="$HOME/BitcoinSignet" -daemon

Проверка сети в свою очередь - следующей командой:

bitcoin-cli -datadir="$HOME/BitcoinSignet" getblockchaininfo

После синхронизации получил буквально следующее:

• "chain": "signet"
• "initialblockdownload": false

Использовал отдельный кошелёк под всё это дело: locktime-lab (назвать можете иначе). Важно другое: эксперимент полностью был изолирован от майннет сети. Во-первых, чтобы для вас это не было дорого (см. выше); во-вторых, чтобы можно было быстрее "пощупать" результаты труда.

Вопрос №03. А в Биткоин точно есть целых два разных понятия времени?

Короткий ответ: да. Поэтому перед экспериментами необходимо разделить две конструкции.

nLockTime

Это абсолютное ограничение. Логика приблизительно такая: не раньше блока X или при соответствующем значении (переводчик с языка "блоков" на язык стандартного времени - задача тривиальная): не раньше времени T.

Т.е. транзакция существует целиком, но до наступления соответствующего условия считается в статусе "non-final", т.е. по-русски говоря: не финализированной (хотя в сети Биткоин такого понятия нет, в моих экспериментах финализация появляется - в виду доп. слоя защиты).

BIP68 + CSV

Это уже относительное время. Логика тут другая: этот конкретный UTXO, ко. можно потратить только после того, как он достаточно "состарится". Сразу давайте пример приведу - берём упрощённое представление UTXO (входов/выходов) и получаем такую примитивную схему:

• 1 подтверждение
• 2
• 3
• после необходимого возраста - разрешаем трату.

Ещё раз! Важно! Это фундаментально другое свойство: nLockTime смотрит на абсолютную координату в блокчейне, CSV может привязать расходование к возрасту конкретного UTXO.

Вопрос №04. Как смастерить абсолютный таймлок через nLockTime?

Короткий ответ: просто. Но давайте на пальцах и подробно.

4.1. Постановка задачи

Вот я получили Signet UTXO: TXID:

d40dee16911e2eac06355f69b3eaddb2cd6f2905f00398c4d23e896a444f69e2

А далее см. на vout (сокращение от vector output) - выход транзакции или порядковый номер (индекс) конкретного выхода внутри транзакции): он будет равен нулю (0).

Затем получаем значение передаваемое (value): 1000 sats, скажем. И после этого создаём новый адрес назначения:

DEST=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
-rpcwallet="locktime-lab" \
getnewaddress "locktime-destination" bech32)
echo "$DEST"

В моём случае получилось вот такое значение:

tb1q9gau0rtpet6dpncgk749zxnu4yn03vkx58nruy

После этого надо определить текущую высоту:

H=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" getblockcount)
LOCK=$((H + 1))
echo "Current height: $H"
echo "nLockTime: $LOCK"

На момент создания было так:

• Current height: 317395
• nLockTime: 317396

Именно 317396 становится абсолютным ограничением транзакции.

Вопрос №05. А как создать транзакцию с nLockTime?

Для этого как раз создаём сырую транзакцию (raw transaction):

RAW=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
createrawtransaction \
'[{"txid":"d40dee16911e2eac06355f69b3eaddb2cd6f2905f00398c4d23e896a444f69e2","vout":0,"sequence":4294967294}]' \
"{\"$DEST\":0.00000700}" \
"$LOCK")

Здесь принципиально важны два поля:

• locktime = 317396
• sequence = 4294967294

Sequence специально был не установлен в финальное 0xffffffff, чтобы nLockTime имел нужный эффект ("переключатель" перевода).

Вопрос №06. Что с подписанием

Тут тоже всё не сложно: чтобы подписать транзакцию в кошельке, надо выполнить следующую команду:

SIGNED=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
-rpcwallet="locktime-lab" \
signrawtransactionwithwallet "$RAW" |
python3 -c 'import sys,json; print(json.load(sys.stdin)["hex"])')

Проверить можно так:

bitcoin-cli -datadir="$HOME/BitcoinSignet" \
decoderawtransaction "$SIGNED"

Bitcoin Core показал мне следующее:

• txid: ce4bd00889e65d42372c4fdda5b63373d2b2f30ff54285043a862fdbcf2baee0
• version: 2
• locktime: 317396
• sequence: 4294967294

То есть транзакция уже была:

• создана;
• подписана;
• имеет фиксированный TXID;
• содержит правильный вход;
• содержит правильный выход.

Но blockchain ещё находился на высоте 317395.

Вопрос №07. Как проверить мемпул? И получить отказ :)

Используем для этого простой и очень удобный RPC:

bitcoin-cli -datadir="$HOME/BitcoinSignet" \
testmempoolaccept "[\"$SIGNED\"]"

Результат будет примерно следующий:

• "allowed": false
• "reject-reason": "non-final"
• "reject-details": "non-final"

Это первая ключевая точка эксперимента:

• Подпись правильная.
• UTXO существует.
• Транзакция корректно сформирована.
• Но Bitcoin Core отказывается принимать её в mempool: non-final

Почему? Причина и есть заданное временное ограничение, т.е. всё работает верно, поэтому в данном случае отказ - это плюс, а не минус.

Вопрос №08. Что случается, когда проходит время?

Итак, в моём эксперименте высота блокчейна увеличилась (доросла / возвысилась - как хотите) с блока 317395 до 317411.

Саму транзакцию не изменял. Но повторил:

bitcoin-cli -datadir="$HOME/BitcoinSignet" \
testmempoolaccept "[\"$SIGNED\"]"

Теперь уже получилось так: "allowed": true.

Bitcoin Core также показал:

• vsize: 110
• fees: n/a
• base: 0.00000300

Таким образом, одна и та же транзакция прошла два состояния (запишу символично): саму подпись менять не потребовалось! Ещё раз: последняя фраза - ключ к разгадке всех этих виляний хвостом с Bitcoin.Core.

Вопрос №09. Что с трансляцией?

Для начала надо было отправить уже существующий HEX:

bitcoin-cli -datadir="$HOME/BitcoinSignet" \
sendrawtransaction "$SIGNED"

Bitcoin Core вернул следующее:

ce4bd00889e65d42372c4fdda5b63373d2b2f30ff54285043a862fdbcf2baee0

Транзакция попала в мемпул. Проверку сделал так:

bitcoin-cli -datadir="$HOME/BitcoinSignet" \
getmempoolentry \
ce4bd00889e65d42372c4fdda5b63373d2b2f30ff54285043a862fdbcf2baee0

И она (проверка) - подтвердила её (транзакции) присутствие (в мемпуле).

Вопрос №10. Что доказал первый эксперимент?

Получил следующую схему: TX создана - (потом) TX подписана - (затем) подпись валидна - (но) TX всё равно не принимается - (потому что) nLockTime условие не достигнуто (буквально - not yet satisfied).

После же изменения состояния блокчейна: Та же самая (!) TX - та же самая подпись - те же самые входные данные - те же самые выходные данные - и в итоге тот же самый TXID, но дают другой статус (опять же буквально: "allowed=true").

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

Вопрос №11. В чём суть тогда второго эксперимента?

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

Для этого использовал:

• BIP68;
• nSequence;
• OP_CHECKSEQUENCEVERIFY;
• Miniscript/descriptor older().

Вопрос №12. Как создать ключ для CSV?

Для этого использовал адрес: tb1qz0ug9q9rnpvfauly3l2g2er6s56jk4f9jynr85.

Его дескриптор (если коротко, то дескриптор вывода в Биткоине (output descriptor) - определённая строка-шаблон: она описывает, как кошелёк создает адреса, вычисляет скрипты для транзакций (scripts) и восстанавливает ключи; важно, что дескриптор объединяет правила генерации адресов и сами публичные/приватные ключи в едином стандарте):

wpkh([4fd9c5b6/84h/1h/0h/0/4]0297308e84ffc38a99db28bdb8f4e38bacc05620119b1f03b16a8e397881b1e7ff)#z3gcvhx2

Публичный ключ вышел такой:

0297308e84ffc38a99db28bdb8f4e38bacc05620119b1f03b16a8e397881b1e7ff

Вопрос №13. Каков первый CSV дескриптор?

Для изучения механизма использовал небольшую задержку:

PUBKEY="0297308e84ffc38a99db28bdb8f4e38bacc05620119b1f03b16a8e397881b1e7ff"
DESC="wsh(and_v(v:pk($PUBKEY),older(3)))"
bitcoin-cli -datadir="$HOME/BitcoinSignet" \
getdescriptorinfo "$DESC"

Bitcoin Core вернул такой ответ:

wsh(and_v(v:pk(0297308e84ffc38a99db28bdb8f4e38bacc05620119b1f03b16a8e397881b1e7ff),older(3)))#sfk0un53

А главное:

• issolvable: true
• hasprivatekeys: false

Дескриптор (в моём случае) означает по существу: валидную подпись и относительную задержку одновременно.

На уровне скриптов Bitcoin Core позже декодировал это следующим образом <PUBKEY> OP_CHECKSIGVERIFY 3 OP_CHECKSEQUENCEVERIFY.

Вопрос №14. Как получить адрес?

Для начала - снова команды:

DESC_FULL="wsh(and_v(v:pk(0297308e84ffc38a99db28bdb8f4e38bacc05620119b1f03b16a8e397881b1e7ff),older(3)))#sfk0un53"
bitcoin-cli -datadir="$HOME/BitcoinSignet" \
deriveaddresses "$DESC_FULL"

Получил следующее:

tb1qnpzwyqf8syagtw4u53h4d0t4kslt73sm7d5pq0uvl7w090wv540qup2f0l

Это уже не обычный P2WPKH (Pay-to-Witness-Public-Key-Hash) - стандартный формат адреса и тип транзакции в сети Биткоин, появившийся после внедрения обновления SegWit (Segregated Witness)). Bitcoin Core определяет его как: witness_v0_scripthash, то есть деньги теперь отправлялись на состояние сценария (буквально: script condition).

Вопрос №15. Что дальше с CSV UTXO?

Создал я спонсирующую транзакцию (funding transaction):

CSV_FUND_RAW=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
createrawtransaction \
'[{"txid":"b2e4c95b57d400196dc31b057b9d59b5eabffe8597fb2afe0aa8d0b9d4a2f3b4","vout":2}]' \
'{"tb1qnpzwyqf8syagtw4u53h4d0t4kslt73sm7d5pq0uvl7w090wv540qup2f0l":0.00008000}')

Подписал так:

CSV_FUND_SIGNED=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
-rpcwallet="locktime-lab" \
signrawtransactionwithwallet "$CSV_FUND_RAW" |
python3 -c 'import sys,json; d=json.load(sys.stdin); print(d["hex"]) if d["complete"] else print("INCOMPLETE")')

А проверил так:

bitcoin-cli -datadir="$HOME/BitcoinSignet" \
testmempoolaccept "[\"$CSV_FUND_SIGNED\"]"

И получил буквально следующее: allowed: true.

Что до трансляции то здесь работает следующее:

bitcoin-cli -datadir="$HOME/BitcoinSignet" \
sendrawtransaction "$CSV_FUND_SIGNED"

TXID у меня такой получился:

f5ccccba414a8ffb6e88f331f2ccd68135dcdb83a82cd9df1aaf9a5bf639a575

Позже транзакцию нашёл непосредственно в блокчейне (тут уже немного помучал регулярные выражения через AI:

TXID="f5ccccba414a8ffb6e88f331f2ccd68135dcdb83a82cd9df1aaf9a5bf639a575"
for H in 317478 317479 317480; do
BH=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" getblockhash $H)
echo "Checking block $H..."
bitcoin-cli -datadir="$HOME/BitcoinSignet" getblock "$BH" 1 |
grep -q "$TXID" && echo ">>> FOUND IN BLOCK $H"
done

Результат простой оказался: >>> FOUND IN BLOCK 317478

16. Почему понадобился мне PSBT?

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

• какой UTXO расходуется;
• какой witness_script его контролирует;
• какой pubkey используется;
• какое relative-lock условие должно выполняться.

Поэтому и перешёл к PSBT. Схема стала после этого примерно такая: RAW (сырые данные) - PSBT - UTXO + информация дескриптора (буквально именно: descriptor information) - подпись в кошельке (wallet signature) - и так самая финализация (да, буквально именно: finalize) и в итоге - подписание сырой транзакции (raw signed transaction: оставляю англ. термины, т.к. при пошаговом повторении вам с ними всё равно придётся столкнуться).

Вопрос №17. Что там со spend с sequence=3?

Созданная транзакция (и даже потраченная: spending transaction) имела такие выходные параметры:

• version: 2
• locktime: 0
• sequence: 3

После utxoupdatepsbt (по сути это RPC-команда (или, если хотите, метод программного интерфейса) в клиентах ноды Биткоина - в том числе и Bitcoin Core, с кот. работал, кот. обновляет частично подписанную транзакцию (PSBT), добавляя в неё недостающие данные об используемых UTXO (неизрасходованных выходах) из локального набора UTXO или мемпула) Bitcoin Core уже видел, что:

• witness_utxo: 0.00008000 BTC (и при этом)
• witness_script: <PUBKEY> OP_CHECKSIGVERIFY 3 OP_CHECKSEQUENCEVERIFY

Подписание же происходило так:

PSBT3=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
-rpcwallet="locktime-lab" \
walletprocesspsbt "$PSBT2" true ALL true |
python3 -c 'import sys,json; d=json.load(sys.stdin); print(d["psbt"])')

Финализация в свою очередь - так:

FINAL=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
finalizepsbt "$PSBT3")

Получил буквально следующее: complete: true. А ещё testmempoolaccept (если оч. коротко, то это тоже RPC-команда в Bitcoin Core, которая проверяет, будет ли сырая транзакция принята в мемпул: команда не отправляет транзакцию в сеть и не сохраняет её, а лишь тестирует на соответствие правилам консенсуса и текущей политике узла): allowed: true.

Это доказало работоспособность всей цепочки: descriptor - WSH - CSP - SBT - подпись (signature) - финализация (finalized TX) - политика мемпула (mempool policy/consensus checks).

Но older(3) оказался слишком коротким для красивой демонстрации перехода во времени: пока вручную выполнял команды, UTXO уже успевал достаточно состариться. Поэтому эксперимент последовательно увеличил сначала до older(6), а затем до older(20).

Вопрос №18. Как провести контрольный отрицательный эксперимент?

Отдельно попробовал создать spend для older(3) с параметром sequence = 2. Т.е. вместо необходимых: sequence = 3 (и) после:

finalizepsbt "$PSBT_BAD3"

Bitcoin Core вернул мне: "complete": false. То есть вместо готового HEX остался PSBT. Это тоже важный (как по мне) результат. Условие скрипта было оч. простым: older(3), а транзакция (spending transaction) пыталась "предъявить": sequence=2, поэтому условие и не выполнялось. Следовательно, корректная приватная подпись сама по себе не позволила финализировать трату.

Вопрос №19. Как осуществить переход к older(6)?

Короткий ответ: никак :). Но это, конечно же - шутка: вы могли просто-напросто устать, дочитав до этого места, поэтому развеял ваш сон и теперь - давайте дальше.

Создал так:

DESC6="wsh(and_v(v:pk(0297308e84ffc38a99db28bdb8f4e38bacc05620119b1f03b16a8e397881b1e7ff),older(6)))"

Bitcoin Core отвечает в этом случае в своём стиле - что-то вроде:

wsh(and_v(v:pk(...),older(6)))#hl82wqkj

Адрес в моём случае такой:

tb1qf4d7pc3fhgxv6h45zpkxcjmzw9qgsdh3kgqc7ufrtnwv6w7hxagqwwkvnd

Транзакция (Funding transaction):

• TXID: 3f75090c74baebba1fc5a5ac8323c5d54300cb22c3dc7f0d1b8202006ed58968
• Она была мной найдена блоке 317488.

Трата имела такие параметры:

• version: 2
• locktime: 0
• sequence: 6

И всё это на высоте: 317493.

Bitcoin Core ответил просто: allowed: true. Поэтому для окончательного эксперимента отложенный период был увеличен мной ещё раз.

Вопрос №20. Что там с финальным боссом экспериментом? Older(20)

А ничего. Создал условие:

DESC20="wsh(and_v(v:pk(0297308e84ffc38a99db28bdb8f4e38bacc05620119b1f03b16a8e397881b1e7ff),older(20)))"

Проверил:

bitcoin-cli -datadir="$HOME/BitcoinSignet" \
getdescriptorinfo "$DESC20"

Bitcoin Core вернул:

wsh(and_v(v:pk(0297308e84ffc38a99db28bdb8f4e38bacc05620119b1f03b16a8e397881b1e7ff),older(20)))#8hsakux6

Получил адрес:

DESC20_FULL='wsh(and_v(v:pk(0297308e84ffc38a99db28bdb8f4e38bacc05620119b1f03b16a8e397881b1e7ff),older(20)))#8hsakux6'
CSV20_ADDR=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
deriveaddresses "$DESC20_FULL" |
python3 -c 'import sys,json; print(json.load(sys.stdin)[0])')

Результат был такой:

tb1qnmkl7psvvst782y4wwmldvgkas7wzw7ax2fjua525wqvukstz6hqpxl6k6

21. И что тогда с funding older(20)?

А тоже - ничего плохого! Средства перенёс из предыдущего older(6) UTXO:

CSV20_FUND_RAW=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
createrawtransaction \
'[{"txid":"3f75090c74baebba1fc5a5ac8323c5d54300cb22c3dc7f0d1b8202006ed58968","vout":0,"sequence":6}]' \
"{\"$CSV20_ADDR\":0.00006000}")

RAW - PSBT:

CSV20_FUND_PSBT=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
converttopsbt "$CSV20_FUND_RAW")

Добавил дескриптор предыдущего older(6):

CSV20_FUND_PSBT2=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
utxoupdatepsbt \
"$CSV20_FUND_PSBT" \
'["wsh(and_v(v:pk(0297308e84ffc38a99db28bdb8f4e38bacc05620119b1f03b16a8e397881b1e7ff),older(6)))#hl82wqkj"]')

Подписал:

CSV20_FUND_PSBT3=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
-rpcwallet="locktime-lab" \
walletprocesspsbt "$CSV20_FUND_PSBT2" true ALL true |
python3 -c 'import sys,json; print(json.load(sys.stdin)["psbt"])')

Финализировал так:

CSV20_FUND_FINAL=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
finalizepsbt "$CSV20_FUND_PSBT3")

Получил: complete: true. И TXID funding transaction:

ea0eaea966b2cb8e80328d5333acb6fb282a51b8d0977a1288ff11f1a78eacbe

Тогда как testmempoolaccept: allowed: true.

Вопрос №22. Как можно зафииксировать рождение UTXO?

Вопрос на самом деле не тревиальный. Но перед трансляцией сделала было так:

Height before broadcast: 317494

Funding TX была отправлена и затем найдена в:

>>> CSV20 FUNDING FOUND IN BLOCK 317495

Это и была ключевая точка эксперимента:

CSV20 UTXO
born at block 317495

И релевантный блок (relative lock)приобрёл, если хотите, наблюдаемый смысл! Или верифицирован стал - как хотите.

Вопрос №23. Как создать трату и больше никогда не изменять её?

Сначала просто поймём, что транзакцию создал такую (spending transaction, опять же, если точнее): TXID:

7841b47fb5e86b24d8a2bb57213d117e2f6a4177c92819439f3354cd7dbf2458

Проверка структуры при этом вышла такой:

• version: 2
• locktime: 0
• input: ea0eaea966b2cb8e80328d5333acb6fb282a51b8d0977a1288ff11f1a78eacbe:0
• sequence: 20

Полученный HEX сохранил следующим образом:

printf '%s\n' "$CSV20_SPEND_HEX" > \
"$HOME/BitcoinSignet/csv20-spend.hex"

Это принципиально важная часть методологии. Поэтому - подчеркну: ВАЖНАЯ ЧАСТЬ!

После этого транзакцию:

• не пересоздавал;
• не переподписывал;
• не меняли выходы;
• не меняли входы;
• не меняли последовательность (данных);
• не меняли комиссию.

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

Вопрос №24. Что там с первой проверкой дальше? Older(20)

Блокчейн когда был на высоте: 317495, а траты параметр показывал: sequence = 20, проверил:

bitcoin-cli -datadir="$HOME/BitcoinSignet" \
testmempoolaccept "[\"$CSV20_SPEND_HEX\"]"

Получил именно тот результат, который хотели поймать:

• "allowed": false
• "reject-reason": "non-BIP68-final"
• "reject-details": "non-BIP68-final"

Это центральный результат второго эксперимента. Почему? Потому что транзакция уже существовала. Она была подписана. Скрипт был известен. Ключ был правильным. Но Bitcoin Core всё равно говорил: НЕТ (NO). Почему? Потому что относительное временное условие ещё не выполнялось.

Вопрос №25. Где оно - автоматически наблюдаем старение UTXO?

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

LAST=""
while true; do
H=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" getblockcount)
if [ "$H" != "$LAST" ]; then
HEX=$(cat "$HOME/BitcoinSignet/csv20-spend.hex")
RESULT=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
testmempoolaccept "[\"$HEX\"]")
ALLOWED=$(echo "$RESULT" |
python3 -c 'import sys,json; print(json.load(sys.stdin)[0]["allowed"])')
REASON=$(echo "$RESULT" |
python3 -c 'import sys,json; d=json.load(sys.stdin)[0]; print(d.get("reject-reason","ACCEPT"))')
echo "tip=$H | allowed=$ALLOWED | $REASON"
if [ "$ALLOWED" = "True" ]; then
echo ">>> CSV20 MATURED AT TIP $H"
break
fi
LAST="$H"
fi
sleep 5
done

Теперь эксперимент шёл без моего прямого участия.

Вопрос №26. Каков реальный результат?

Начало наблюдения было таким

• tip=317495 | allowed=False | non-BIP68-final
• tip=317496 | allowed=False | non-BIP68-final
• tip=317497 | allowed=False | non-BIP68-final
• tip=317498 | allowed=False | non-BIP68-final
• tip=317499 | allowed=False | non-BIP68-final
• tip=317500 | allowed=False | non-BIP68-final

Транзакция всё это время оставалась одной (той же самой):

7841b47fb5e86b24d8a2bb57213d117e2f6a4177c92819439f3354cd7dbf2458

Затем наступил момент ключевой:

• tip=317516 | allowed=True | ACCEPT
• >>> CSV20 MATURED AT TIP 317516

Вот это и был главный результат внутри моей лаборатории.

27. Что фактически произошло?

На уровне ключа не произошло ничего. Не получил новый приватный ключ. Не создал новую подпись. Не изменил даже скрипт. Но и не создал новую транзакцию (да, снова речь и именно про spending transaction). Зато изменилось состояние блокчейна (и только оно). Схематично это выглядит так:

• Некая транзакция (SAME SIGNED TRANSACTION)
• Выоста: 317495
• Статус: non-BIP68-final
• Высота: 317496
• Статус: non-BIP68-final
• Высота: 317497
• Статус: non-BIP68-final
• Высота: 317516
• Статус: ACCEPT.

Следовательно: валидность подписи и возможность расходования UTXO - не одно и то же, а это я и доказывал в рамках эксперимента. Bitcoin Script способен наложить дополнительное условие времени и тем самым можем придумать свой защищённый вольт.

28. Почему именно 317516 и его не стоит просто считать как 317495 + 20?

Это место важно описывать аккуратно, потому что здесь, уверен, многие могут допустить ошибки. Почему? Потому что наивная модель могла бы выглядеть так: 317495 + 20 = 317515. Да? Да. Но есть "но": отсюда можно было бы ожидать принятия ровно там, на этой высоте этого блока.

Но мой-то эксперимент зафиксировал первое наблюдение (буквально: first observed ACCEPT) на 317516 именно!

И на мой взгляд это хороший пример того, почему в Биткоине нельзя заменять реальные правила проверки бытовым подсчётом "прошло N блоков".

Собственно, если вы разберёте BIP68, то узнаете, что он использует "relative lock-time semantics", а Bitcoin Core при добавлении в мемпул проверяет допустимость транзакции относительно "chain state" и следующего потенциального блока. Поэтому для практической реализации нужно опираться на точные политики (если будете искать, то контекст такой: consensus/policy semantics), а не на самостоятельно придуманное арифметическое правило.

Для статьи и эксперимента при этом важнее даже другое: граница была обнаружена мной экспериментально - одной и той же транзакцией! До неё: non-BIP68-final, а вот после: ACCEPT.

Вопрос №29. В nLockTime против CSV: что я увидел?

Если коротко и не повторяясь: что они очень разные. И это тоже была гипотеза, кот. надо было проверить.

Вопрос №30. Самый важный вывод для безопасности: он какой?

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

Экспериментальный ответ у меня получился короткий: "Да". Непосредственно получил ситуацию, кот. описывается краткой схемой: "Даже если у злоумышленника есть приватный ключ и он может создать корректную подпись, но условие расходования при этом ещё не выполнено, то средства нельзя переместить по такому пути" (нечто подобное получите и вы, если будете соблюдать подобные условия).

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

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

Вопрос №31. Где и когда это становится действительно интересным?

Опять же, отвечу коротко: когда вы совмещаете мультисиг с описанной выше схемой. Поскольку и первый, и второй аспект уже описал, то вам остаётся лишь соединить их вместе :).

Вопрос №32. Что время даёт защитнику?

Главная ценность отложенных транзакций - окно реакции. Или спасения. Опять же - как хотите. В традиционной схеме что имеем? Ключ украден - транзакция - конец игры. В правильно спроектированной (delayed/vault) архитектуре потенциально появляется иной подход: компрометация (ключа/сида) - запасной путь - окно возможностей для исправления - детект взлома - восстановление.

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

Это уже гораздо более сильная модель менеджмента (опять же - для меня).

Вопрос №33. Неужели CSV - не есть отмена транзакции?

Очень важно не сделать из эксперимента неправильный вывод. CSV сам по себе не создаёт кнопку Cancel. НЕ создаёт! Зато он говорит: этот путь (spending path) невалиден до выполнения временного условия.

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

Поэтому полноценная архитектура требует дополнительных элементов:

• альтернативных ключей;
• доп. путей;
• мультисига;
• заранее продуманной структуры UTXO;
• мониторинга;
• менеджмента комиссий (приоритета их);
• иногда - заранее подготовленных транзакций;
• строгой модели того, какой ключ способен использовать какую ветку и т.д.

Вопрос №34. Что ещё показал эксперимент с точки зрения безопасности?

Интересным оказался не только сам CSV. Я столкнулися с рядом реальных особенностей Bitcoin Core.

Например, "watch-only descriptor" нельзя было просто импортировать в кошелёк с включёнными приватными ключами. Ошибка формата: "Cannot import descriptor without private keys to a wallet with private keys enabled", - буквально об этом.

Поэтому мной был создан отдельный watch-only wallet:

bitcoin-cli -datadir="$HOME/BitcoinSignet" \
createwallet "csv-watch" true true

Затем возникло ещё одно ограничение: нода работала в моде, кот. буквально называется "prune mode", т.е. режим обрезки. Попытка полного рескана дала ещё одну ошибку: "Rescan failed... This error could be caused by pruning...".

Это полезное практическое наблюдение, считаю: для серьёзной инфраструктуры необходимо заранее решить, нужна ли вам именно урезанная или полная нода, потому что возможности восстановления истории (кошелька/дескриптора) различаются. Местами - существенно.

Вопрос №35. Что-то ещё?

Да, ещё одна ошибка, которую полезно сохранить. В процессе работы переменная shell с подписанной транзакцией оказалась пустой:

echo ${#SIGNED}

Результат: 0

Попытался дальше так:

sendrawtransaction "$SIGNED"

Но такая попытка дала лишь: TX decode failed.

Восстановил HEX непосредственно из кошелька поэтому:

SIGNED=$(bitcoin-cli -datadir="$HOME/BitcoinSignet" \
-rpcwallet="locktime-lab" \
gettransaction ce4bd00889e65d42372c4fdda5b63373d2b2f30ff54285043a862fdbcf2baee0 |
python3 -c 'import sys,json; print(json.load(sys.stdin)["hex"])')

И уже после этого команда:

echo ${#SIGNED}

Показала: 382, а трансляция прошла нормально. Отсюда простой вывод: shell-переменная - так себе хранилище критически важной Bitcoin-транзакции. Точнее - НЕ хранилище вообще.

Для реального воркфлоу подписанный HEX/PSBT должен сохраняться как самостоятельный артефакт и проверяться перед использованием.

Да, вот так просто! Именно поэтому в финальном CSV-тесте уже сделал:

printf '%s\n' "$CSV20_SPEND_HEX" > \
"$HOME/BitcoinSignet/csv20-spend.hex"

Вопрос №36. Что в итоге доказал-то? :)

Без теоретических предположений получил 4 результата. Давайте коротко по ним ещё раз пройдусь.

Первый. Абсолютный timelock работает

То есть: valid signed TX + future nLockTime = non-final. После наступления соответствующего состояния: same signed TX = allowed

Второй. Relative timelock работает

То есть: valid signed TX + immature CSV condition = non-BIP68-final. После старения UTXO: same signed TX = allowed

Третий. Наличие приватного ключа не эквивалентно безусловной возможности расходования

То есть: PRIVATE KEY ≠ UNCONDITIONAL CONTROL, если сам UTXO создан с дополнительными условиями (их и называю: spending conditions).

Четвёртый. Время действительно может выступать самостоятельным секьюрити-примитивом

Да, именно так.

Вопрос №37. А каков главный практический вывод?

Обычная модель не кастодиального хранения выглядит так: BTС-ключ - компрометация. Но Bitcoin Script позволяет построить гораздо более интересную модель: BTC UTXO - политика трат - время - валидный путь (для трат) и добавить более сложные конструкции (мультисиги, ключи восстановления, таймлоки и проч. - это всё выше уже описывал, повторяться не буду).

И для меня важно, чтпостепенно ухожу от примитива: "Ко знает seed - тот владеет BTC", - к куда более свежей идее: "BTC контролирует тот, кто способен удовлетворить условия расходования конкретного UTXO".

И ключ - лишь одно из возможных условий!

Вопрос №38. Может хватит и подведём черту? :)

Давайте. Тем более что эксперимент начался с довольно простого вопроса: "Можно ли за счёт времени сделать хранение BTC безопаснее?". На тестах с Signet последовательно увидел: 2 кейса и простой ответ: "Да, можно".

При этом в обоих случаях изменение произошло не в приватном ключе и не в подписи!

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

Именно поэтому таймлоки интересны не как экзотическая функция Bitcoin Script, а как один из строительных блоков более серьёзной архитектуры. Я бы её по итогу обозначил так:

1. Сид защищает секрет.
2. Мультисиг распределяет доверие.
3. Таймлок добавляет время как отдельный слой защиты.
4. Сочетание же этих механизмов позволяет проектировать систему, в кот. компрометация одного элемента ещё не обязательно означает мгновенную и необратимую потерю BTC.

Вот такие дела и

До!

Введение

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

Похожие названия

Большинство людей валится на том, что думают, что или знают всё, или знают, как надо. При этом хакеры (а точнее - взломщики) мыслят не линейно и всегда ищут сценарии иного формата: "Как НЕ надо".

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

Но если автор уже столкнулся с подобным - зачем это отрицать? Лучше разобраться в механике. А она такова, что, может, сама соц. сеть/мессенджр и унифицируют аккаунты при написании (переводить всё в нижний регистр, условно), но ссылка-то на аккаунт хоть в тексте, хоть на сайте, хоть где в др. месте может быть сформирована почти любым образом.

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

Постоянные миграции

Обновите ваше ПО, купите новое железо, вышли апдейты под установленный кошелёк... Призывов может быть много и разных, но суть всегда одна:

1. Вы получаете сообщение от (НЕ) проверенного источника: да, именно так - ведь проверенный источник могут и взломать;
2. Где указано, что нужно что-то там сделать с вашим Леджером или Метамаском, или чем-то ещё;
3. Переходите по ссылке на (НЕ) проверенный сайт: опять же - сайт могут и взломать;
4. И просто дарите деньги (обычно - в виде сид-фразы или приватного ключа) злоумышленникам.

Вот пример первый на этот счёт:

Как видите, даже сами фильтры Gmail относят письмо к подозрительным. Но таких рассылок мошенники делают не 100-200, а 100-200 тыс., а то и миллионов, поэтому вероятность даже в 0.1% - уже хорошее попадание.

Вот ещё пример:

Здесь вообще всё смешено:

1. Апдейт аппаратного кошелька, на кот. делал обзор и не раз за последние 10 с лишним лет;
2. Стиль Reddit, к кот. мог (по мнению мошенников) привыкнуть;
3. И совершенно левый домен jerry AI.

И отключение картинок по умолчанию - уже сортирует это письмо в СПАМ-фильтр в голове, хотя сам Gmail в этот раз не справился и поставил его просто во входящие.

Ещё один подобный пример:

И ещё один, весьма похожий пример:

Но есть и другие механики. Скажем:

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

Излюбленный же способ - это всегда крикнуть о том, что ваш аккаунт будет:

1. Удалён;
2. Заблокирован;
3. Как-то иначе "уничтожен"...

И хотя мой публичный email даже не привязан ни к какому iCloud мошенники будут пробовать и пробовать ломать именно его (для этого он, публичный адрес, мне и нужен: как и ряд других выданных в сеть данных).

И, конечно же, ставка на то, что вы "приняли" супер-оффер на супер-сделку; выиграли в лотерею; получили наследство и т.п. - всегда "рабочая" схема (если вы - не внимательны).

Не только Email

На самом деле фишинг может быть где угодно:

1. Email
2. Сайт
3. Мессенджер
4. QR-код
5. etc.

Вот яркий пример от якобы контакта (почему у меня в TG и написано: "No DM"):

Банальная проверка через https://www.virustotal.com часто помогает, но порой - нет(особенно - если это векторная атака), поэтому здесь важно включать собственную голову, а не всё скармливать AI или общим анализаторам.

Ещё один яркий пример (по этой причине комментарии под моими видео проходят первичную модерацию постоянно и давно) - это те самые sed-фразы из якобы "полного" кошелька на блокчейне Tron, кот. обязательно обчистит вас:

Постфактум

Наконец, не стоит забывать, что фишинг даже когда он закончился, всё равно может не завершится:

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

1. Всегда чистите куки;
2. Проверяйте ПК/MAC/смарт/etc. на вредоносов;
3. См. в логи ОСи и файрвола;
4. Считайте, что вас взломали и проверяйте...

Но большинство этого не делает. И причина банальна: лень.

Техника сама по себе бессильна

Да, к сожалению, но это так. Давайте пройдём путь недавнего взлома у одного начинающего DeFi-щика:

Казалось бы: уже тут всё написано:

1. Предупреждение от кошелька (Metamask);
2. Адрес сайта записан чёрт пойми как.

Но что происходит дальше?

Человек не проверяет адрес из окна кошелька, а доверяет тому, что введён в URL: aerodromê. finance (НЕ переходите по этому адресу!) - как видим, здесь вместо e подставлена ê и никого этого не смущает?

Нет. Не смущает.

Что в итоге?

Фейково-фишинговый контракт получает разрешения и выводит (моментально) средства с кошелька.

В итоге отзывать пришлось разрешения более чем в 5 сетях... А всего-то - секунд 10-15 делов.

Выводы

Поэтому система безопасности - это именно СИСТЕМА: не набор сервисов, а методология прежде всего. И игнорировать её никак нельзя: даже если вам кажется ПО-другому.

Плейлист: https://www.youtube.com/watch?v=OcN0kwEJCRk&list=PLXVr1qt7yWkU.

Курс бесплатный: https://t.me/+iavlR8U7ciVkN2Yy

До!

ICO - это НЕ скам

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

1. ICO мифология в ссылках: https://forklog.com/hub-archive/chetyre-mifa-o-kriptovalyute-i-blokchejne-chast-ii-vspomnit-vsyo
2. Полный разбор, почему скама в ICOs на деле было так мало: https://docs.google.com/document/d/1Ae4CQsg113M2SsnrQih6U9LhlyzTwQ3BE2eBuDDgi6M/edit?usp=sharing

А теперь - ряд фактов, кот. подсвечивал не так часто.

ICO - это сети

Очень многие сети появились или благодаря майнингу, или airdrop-у, или ICO. И при этом всё это - децентрализованные способы. И два последних - во много родились через ETH, но равно именно как ICOs:

1. Tron
2. EOS
3. Polkadot
4. Tezos
5. etc.

Т.е. от Эфира родилось не только с десяток форков (ETC, ETHPoW, etc.), но и десятки ICOs именно, часть из которых - это сети. А не было бы сетей, не было бы и проектов внутри них: тот же Hydration, что так был популярен в 2024-2025 гг. в DeFi или dYdX, кот. перешёл с EVM, но там зородился, или всеми любимый HYPE, кот. за счёт EVM-депозитов рос изначально.

Да и в целом в итоге ICO породили всю экосистему сетей во многом: ведь делают или на Ethereum (EVM), или на Cosmos (IBC), Polkadot (тот же TAO) и куда реже на Solana или Near, etc.

И что получаем в итоге?

1. Без Ethereum не было ETC и др.;
2. Без Cosmos - DYDX... и такого развития perp DEXs;
3. Без Polkadot - TAO (один из ТОП проектов Web 3.0 + AI экосистемы) и Hydration;
4. Без 0x - Matcha - одно из самых важных крипто-агрегаторов;
5. Без Tezos - замкнутой экосистемы, где есть всё, от NFT до DePin;
6. Без Binance - BNB (да, это тоже ICO);
7. Без TRON - BTT и огромной доли оборота стейблкоинов в 2020-х;
8. Без GRAM - Ton, а без Ton - Gram (думаю, вы оцените шутку);
9. Без ETH Lend - AAVE;
10. Без FIL, STORJ, GOLEM - современного DePin;
11. Без VeChain - всей отрасли, связывающей логистику и чейны;
12. Без STEEM/GOLOS/VOICE & и в какой-то степени BITCHARES/EOS - DeSoc;
13. Без BORG - связки страхования и блокчейна...

И можно продолжать довольно долго.

Закат проектов?

Да, не все проекты выдерживают конкуренцию. Но сегодня, когда более 60 проектов закрылось за год, а среди них: Odos, Zapper, Kernel, G, etc., становится ясным, что подобная участь уготована кому угодно: не только ICOs.

Выводы

Статья маленькая... Если только вы не прочитаете 2 первых документа, где даны сотни пруфов о том, о чём говорю. Но даже если вы просто по верхам, что называется, пройдётесь, убедитесь, что ICOs были важной вехой (и остаются, как предполагалось).

Вот и всё -

До!

Сразу - о главном

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

• верифицируемые вредоносные инструменты;
• повторяемые TTPs;
• инфраструктурные пересечения;
• ончейн-практики (финансовые следы в блокчейне);
• человеческие и OPSEC‑ошибки.

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

При этом и MITRE, и Mandiant, и CrowdStrike отдельно предупреждают, что Lazarus в открытых источниках часто используется как зонтичное название для нескольких северокорейских кластеров, которые делят людей, инфраструктуру, м малварь и tradecraft (совокупность профессиональных навыков, методов, приемов и технологий, используемых в определенной сфере деятельности).

Поэтому точность бывает высокой на уровне DPRK/RGB nexus (термин из киберразведки, означающий связь (nexus) между Северной Кореей (DPRK) и Reconnaissance General Bureau (RGB) - главным разведывательным управлением КНДР), но ниже - на уровне конкретного подподразделения.

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

Для Sony и WannaCry ключевыми были кодовые пересечения, общие артефакты малвари, повторяющиеся инфраструктурные и операционные признаки, а затем... официальное обвинение США и союзников.

Для ЦБ Бангладеша и более поздних банковских и крипто-хищений связующими элементами стали сочетания малвари, пересечения по TTP, инфраструктуре, а также следам в SWIFT (банковской среде) и, позднее, on‑chain трассировки, в частности - списков адресов, миксеров и санкционных действий (OFAC/ФБР).

Для 3CX/X_TRADER связка строилась в основном на генеалогии малвари, совпадении инфраструктуры и цепочек поставок.

Для Ronin, Harmony, Atomic/Bybit на первый план вышли блокчейн‑аналитика, поведенческие паттерны отмывания, кластеризация кошельков и перечисление конкретных адресов, дополненные официальными заявлениями.

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

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

Какие доказательства используют для атрибуции к Lazarus?

В открытой практике для Lazarus применяют шесть устойчивых семейств доказательств: ф

1. Финансовые следы;
2. Инфраструктура;
3. Малварь и её кодовые признаки;
4. TTP;
5. Операционные (человеческие) признаки;
6. Разведывательно‑правовые подтверждения.

Эта классификация хорошо укладывается и в так называемую алмазную модель анализа вторжений (Diamond Model), которая представляет собой не что иное, как аналитическую платформу по кибер-безопасности, которая используется для обнаружения, расследования и отслеживания кибератак, а также для того, чтобы через расследование связать жертву, инфраструктуру и нападающих. Это если коротко :).

Рассмотрим теперь...

Семейства доказательств

Финансовые следы

Сюда входит сразу несколько разноплановых историй:

1. Адреса кошельков;
2. Кластеры адресов;
3. Маршруты вывода;
4. Бриджевая активность (bridge activity, сhain‑hopping);
5. Использование миксеров;
6. Время обналички (timing cash‑out).

Подобный метод даёт наблюдаемую связь контроля денег. Но опять же: особенно сильный сигнал, когда адрес прямо назван гос. органами или когда поток денег консолидируется в уже известных DPRK‑кластерах (DPRK threat cluster - сеть связанных между собой хакерских группировок (например, Lazarus, Kimsuky), спонсируемых властями Северной Кореи (КНДР) для кибершпионажа, кражи криптовалюты и обхода международных санкций), т.е. основным доказательством всего остаётся отнесение со стороны кого-то, а значит - это всегда операция не беспристрастная.

OFAC, скажем, идентифицировал адрес Ronin-взлома как принадлежащий именно Lazarus и дополнительные адреса для отмывания (Axie/Ronin), а ФБР перечислил адреса для Bybit, допустим; в свою очередь Elliptic и Chainalysis показали типовые схемы Tornado/Blender/Sinbad, которые считаются как "консолидация с предыдущими DPRK‑взломами" из-за характерного поведения.

Но что важно для меня?

Что один поведенческий паттерн отмывания не является доказательством сам по себе: благо тот же Elliptic прямо пишет, что, например, в Harmony ни один фактор по отдельности не доказывает участия Lazarus.

Инфраструктура

В этот перечень входят:

1. Домены;
2. IP-адреса;
3. Параметры экранов;
4. DNS-история;
5. TLS и сертификаты;
6. Хостинг;
7. Жёсткое кодирование (hardcoded C2);
8. Dead‑drop resolvers (техника кибератак, при которой вредоносное ПО скрывает адрес своего командного сервера (C2/C&C) на легитимных, популярных интернет-ресурсах вместо того, чтобы жестко прописывать его в своем коде);
9. Переменные окружения и проч.

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

Компания Mandiant, расследовавшая атаку на разработчика программного обеспечения 3CX, пришла к выводу, что за ней, вероятнее всего, стояла группировка UNC4736, связанная с северокорейскими кибероперациями.

Основанием для такого вывода стали несколько независимых технических совпадений с ранее известной операцией AppleJeus. Приведу несколько самых важных:

• Во-первых, в обоих случаях использовался один и тот же тип вредоносной программы - POOLRAT. Это троян удалённого доступа (Remote Access Trojan, RAT), который позволяет злоумышленникам незаметно управлять заражённым компьютером: запускать команды, загружать и выгружать файлы, устанавливать дополнительное вредоносное ПО и выполнять другие действия.
• Во-вторых, исследователи обнаружили использование одного и того же доменного имени journalide[.]org. Под доменным именем здесь понимаю стандартный интернет-адрес, который используется для связи заражённого компьютера с сервером злоумышленников. Совпадение подобных доменов между различными кампаниями считается важным признаком того, что ими управляет один и тот же оператор или одна и та же инфраструктура.
• В-третьих, в обеих операциях применялся одинаковый программный компонент под названием X_TRADER. Это внутреннее название одного из элементов вредоносного комплекса, который использовался атакующими. Повторное использование редко встречающихся компонентов является ещё одним аргументом в пользу связи между атаками.

Кроме того, специалисты обнаружили совпадения DNS- и IP-инфраструктуры (DNS/IP overlaps). Это означает, что различные вредоносные домены в разные периоды времени "разрешались" в одни и те же IP-адреса либо использовали одинаковые серверы, сетевые настройки или инфраструктуру управления. Подобные совпадения редко бывают случайными и часто свидетельствуют о повторном использовании злоумышленниками собственной инфраструктуры.

Исследовательская компания ESET независимо пришла к схожим выводам. Она обнаружила связь между операциями DreamJob и 3CX благодаря анализу Linux-компонентов вредоносного программного обеспечения. Под Linux-компонентами здесь понимаю версии вредоносных программ, предназначенные для операционной системы Linux. Исследователи установили, что эти версии содержали одинаковые участки программного кода, схожую архитектуру и идентичные методы работы, что говорит о высокой вероятности их разработки одной и той же группой.

Компания Kaspersky в свою очередь провела криминалистический анализ (forensic-анализ) одного из серверов управления злоумышленников (C2-сервера, Command-and-Control server). Такой сервер используется для передачи команд заражённым компьютерам и получения от них информации.

В ходе расследования было установлено, что оператор практически всегда подключался к этому серверу через прокси-серверы и VPN-сервисы, то есть использовал промежуточные узлы для сокрытия своего реального местоположения и IP-адреса.

Однако один раз была допущена операционная ошибка (OPSEC failure): подключение произошло напрямую из диапазона IP-адресов, принадлежащих Северной Корее.

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

Малварь, код и артефакт сборки

Здесь в свою очередь используются такие параметры, как:

1. Общие фрагменты кода;
2. YARA‑совпадения (т.е. результаты работы инструмента YARA - открытой программы для поиска угроз, который обнаруживает вредоносные программ, сравнивая их код с заранее заданными шаблонами);
3. Генотипы малвари;
4. Rich Header (скрытый и неофициальный блок метаданных в Windows-файлах формата PE (например, .exe и .dll));
5. Компилятор и/или линкер;
6. Константы;
7. Формат строк;
8. Уникальные пароли;
9. Конфигурации.

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

Приведу примеры.

Kaspersky связал ряд хаков Lazarus через кодовые фичи, перечислю несколько:

• Юзер-агенту (User‑agent Mozillar);
• Самоуничтожающиеся BAT‑скрипты;
• Общий ZIP‑пароль;
• Корейские PE‑resources (данные, встроенные внутрь исполняемых файлов Windows (например, .exe, .dll, .ocx));
• Метаданные по тайм-зоне.

WannaCry с другой стороны связали с ранним Lazarus‑образцом по shared code (обозначает использование одних и тех же исходников, библиотек или логики в разных программах).

ESET связал 3CX с Lazarus через сходство SimplexTea & sysnetd& BADCALL (это связанные между собой вредоносные программы (бэкдоры) для Linux, которые используются северокорейской хакерской группировкой) и общие ключи.

Mandiant по 3CX указал в свою очередь на общий RC4‑ключ, куки _tutma (один из основных служебных файлов системы веб-аналитики Google Analytics)и AES‑256‑GCM‑поведение (сочетает потоковое шифрование и аутентификацию, а главная особенность поведения - строгий запрет на повторное использование пары "ключ-nonce" (вектор инициализации), что ведёт к утечке ключа и компрометации данных).

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

См. доп.:

• https://securelist.com/big-threats-using-code-similarity-part-1/97239
• https://securelist.com/operation-blockbuster-revealed/73914

Важно! Семантика кода даёт направление, но не заменяет аналитика: те же Kaspersky отдельно предупреждают о ложных флагах и о том, что подобные подходы (технологии) можно сознательно отравлять. И да, здесь нет противоречия с тем, что я написал выше: Лаборатория высказалась лишь об одном векторе и осторожна, а я о совокупности ракурсов и куда более жёстко.

Тактика, методы и процедуры

На английском это звучит как TTP (Tactics, Techniques, and Procedures). О них и поговорим.

Сюда входят параметры:

1. Техники атакующих;
2. Связь первичного доступа с последующим проникновением в системы и вплоть до отмывания средств.

В частности, группировка Lazarus на протяжении многих лет использует схожий набор тактик, техник и процедур (TTP), которые неоднократно фиксировались в различных кампаниях. Именно повторяемость этих методов является одним из факторов, позволяющих исследователям связывать между собой разные атаки.

• DreamJob / атаки через LinkedIn. Злоумышленники создают поддельные аккаунты рекрутеров крупных компаний, инвестиционных фондов или криптовалютных проектов. Под видом привлекательной вакансии они устанавливают контакт с жертвой и убеждают открыть вредоносный документ или установить программу, которая заражает компьютер.
• Троянизированные криптовалютные приложения. Нападающие распространяют модифицированные версии программ для торговли криптовалютами, управления кошельками или анализа рынка. Внешне такие приложения выглядят легитимными, однако содержат скрытый вредоносный код, который после установки получает доступ к системе.
• DLL Sideloading (подмена DLL-библиотек). Атакующие размещают вредоносную динамическую библиотеку (DLL) рядом с доверенным исполняемым файлом. При запуске легитимная программа автоматически загружает эту библиотеку, позволяя вредоносному коду выполняться под видом обычного приложения и обходить часть механизмов защиты.
• Многоэтапное заражение (Staged Implants). Вместо установки полноценного вредоносного ПО сразу злоумышленники сначала запускают небольшой загрузчик, который проверяет окружение и затем постепенно загружает дополнительные компоненты. Такой подход снижает вероятность обнаружения антивирусами и позволяет адаптировать атаку под конкретную цель.
• Безопасное удаление следов (Secure Deletion). После выполнения атаки вредоносное ПО может удалять временные файлы, журналы и собственные компоненты таким образом, чтобы максимально затруднить их восстановление и проведение последующей криминалистической экспертизы.
• Целевой фишинг (Spear Phishing) под видом предложений о работе. В отличие от массовых фишинговых рассылок, сообщения тщательно готовятся под конкретного человека. Жертве отправляют персонализированное письмо или сообщение с предложением работы, приглашением на интервью либо документами, содержащими вредоносные вложения.
• Компрометация цепочки поставок (Supply Chain Attacks). Вместо прямой атаки на конечную организацию злоумышленники сначала взламывают разработчика программного обеспечения, поставщика услуг или подрядчика. Через обновления доверенного ПО вредоносный код затем распространяется сразу на большое количество клиентов. Одним из наиболее известных примеров такой тактики стала атака на компанию 3CX.

База знаний MITRE ATT&CK отмечает, что именно сочетание этих техник регулярно встречается в различных операциях, которые аналитики связывают с группировкой Lazarus. Повторяемость инструментов, способов первоначального проникновения, методов закрепления в системе и сокрытия следов является важным элементом атрибуции подобных кибератак.

TTP‑перекрытие без уникальных артефактов часто даёт лишь умеренноедоверие, потому что методы могут копироваться и мигрировать между близкими DPRK‑кластерами.

Доп.:

• https://cloud.google.com/blog/topics/threat-intelligence/mapping-dprk-groups-to-government
• https://www.welivesecurity.com/2020/06/17/operation-interception-aerospace-military-companies-cyberspies

Человеческие и OPSEC‑признаки

Что сюда входит? Список следующий:

• Фальшивые аккаунты;
• Дропы;
• Язык взломщиков;
• Часовые зоны;
• Рабочие часы (и операционные дни);
• Опечатки;
• Ошибки операторов;
• Сессии и куки.

Часто это сшивающий (синтезирующий) слой между техникой и субъектом, особенно когда артефакты повторяются через годы.

DOJ описал повторное использование алиасов (aliases), акаунтов (collector accounts), емэйл и акаунтов в соц. сетях (email/social media accounts) и доступы с северокорейских и китайских IP как единое целое.

Kaspersky показал рабочий график GMT+8/+9, локализацию корейскую (Korean locale в PE‑resource) и единичный коннект (к C2) из северокорейского диапазона. Kaspersky (по Andariel) описал команды с ошибками и операторские промахи.

ESET и ФБР неоднократно документировали фальшивых LinkedIn‑рекрутеров.

Эти признаки легко инсценировать, поэтому сами по себе они почти никогда не тянут на высокую атрибуцию

Доп.: https://securelist.com/big-threats-using-code-similarity-part-1/97239.

Разведывательно‑правовые подтверждения

Этот список внушительный, но сокращу его до главного:

• Санкции;
• Обвинительные акты;
• Системы или сообщения для информирования пользователей (PSA/alerts: PSA (Public Service Announcement) и Alerts (оповещения));
• Многосторонние атрибуции;
• Привязка к RGB/110th Research Center (акже известен как Лаборатория 110 или Отдел 110) - элитное северокорейское подразделение кибервойны.

Не раз публично указалась подчинённость Lazarus (Bluenoroff/Andariel) структурам RGB. Скажем, DOJ связал Sony, ЦБ Бангладеша и WannaCry с Park Jin Hyok и Lazurus‑conspiracy. ФБРС многократно публиковал адреса по TraderTraitor (Stake/DMM/Bybit).

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

Доп.: https://home.treasury.gov/news/press-releases/sm774

Как оценивают надёжность атрибуции?

Надёжная атрибуция к Lazarus обычно строится не как «да/нет», а как оценка доверия по нескольким осям.

Базовые опоры здесь та самая Diamond Model, аттак-мэпинг (ATT&CK‑mapping) и разведывательные стандарты по вероятности/уверенности.

Суть:

• Diamond Model рекомендует двигаться между "capability, infrastructure, victim и adversary" через аналитические пивоты.
• ATT&CK помогает сравнивать технику и последовательность действий.
• ICD 203 (Intelligence Community Directive 203 - основополагающая директива Разведывательного сообщества США, устанавливающая строгие стандарты для подготовки и оценки всех аналитических продуктов) и практики CIS требуют отдельно выражать вероятность.

В практических SOC/CTI‑процессах полезно разделять минимум семь метрик или наборов метрик, поэтому обозначу и их:

• IOC corroboration (подтверждение индикаторов компрометации) - показывает, сколько IOC (хэшей, доменов, IP-адресов, криптокошельков и т.д.) подтверждаются независимыми источниками и собственной телеметрией. Чем больше независимых подтверждений, тем выше доверие к индикатору. Методологии вроде Palo Alto Unit 42 дополнительно отдельно оценивают надёжность источника и достоверность самого артефакта.
• TTP overlap (совпадение тактик, техник и процедур) - оценивает, насколько вся цепочка поведения злоумышленника совпадает с уже известными операциями. Совпадение полного набора техник (первичное проникновение, закрепление, управление, выполнение целей и т.д.) значительно сильнее, чем совпадение одной отдельной техники, например DLL sideloading.
• Code similarity score (степень сходства вредоносного кода) - измеряет количество уникальных общих фрагментов кода, конфигураций и артефактов сборки. Наиболее ценны уникальные участки, отсутствующие в стандартных библиотеках и легитимном ПО. Для оценки применяются YARA-правила (плюс fuzzy hashing и n-gram-анализ (метод обработки текстов, разбивающий их на последовательности из n элементов (слов, слогов или символов)), сравнение графов, Rich Header (см. выше) и другие методы.
• Blockchain clustering confidence (уверенность в кластеризации блокчейн-адресов) - показывает вероятность того, что группа адресов принадлежит одному оператору или связана с уже известным кластером. Наиболее сильным доказательством считается совпадение с адресами, официально опубликованными FBI или OFAC. Ниже по силе - связи с известными кластерами и характерные схемы отмывания средств.
• WHOIS/IP reuse frequency (повторное использование инфраструктуры) - оценивает, насколько часто домены, IP-адреса и серверная инфраструктура повторяются между различными атаками. Регулярное повторное использование C2-инфраструктуры, одинаковых доменов или IP-адресов существенно усиливает атрибуцию, тогда как единичное совпадение имеет небольшой вес.
• Temporal correlation (временная корреляция) - анализирует совпадения по рабочему графику операторов, последовательности событий и временным паттернам вывода средств. Например, совпадение часов активности, пауз в отмывании средств или последовательности "взлом => развёртывание инфраструктуры => вывод средств" усиливает атрибуцию, хотя само по себе не является доказательством.
• Kill-chain mapping (сопоставление полной цепочки атаки) - показывает, насколько вся операция соответствует историческому сценарию действий конкретной группировки: от первоначального вектора атаки (например, фишинга, троянизированного приложения или компрометации цепочки поставок) до закрепления, кражи данных и последующего отмывания похищенных активов. Чем больше совпадений по всей цепочке, тем выше уверенность в атрибуции.

Отмечу, что для обозначения доверия разумно использовать разведывательную шкалу, а не категоричное точно/не точно.

В ICD 203 и в практике CIS диапазоны вероятности выражаются словесно - от almost no chance до almost certain - а уверенность делится на high / moderate / low confidence в зависимости от качества, количества и согласованности источников.

Поэтому на русском использую те же подходы.

CIS, например, определяет высокую степень уверенности (high confidence) как оценку на основе качественной информации из нескольких надёжных источников с минимальным конфликтом; умеренную степень уверенности (moderate confidence) - как правдоподобную, но недостаточно подтверждённую; с низкой степенью уверенности (low confidence) - как фрагментарную и плохо подтверждённую (corroborated).

Для прикладной оценки атрибуции именно к Lazarus полезна следующая операционная шкала как аналитический синтез на основе Diamond Model, Admiralty, ICD 203 и практики публичных кейсов Lazarus. Она не является отраслевым стандартом, но хорошо отражает то, как реально звучат качественные публичные выводы.

Получаем следующую историю:

• Очень высокая. Есть официальное указание адресов/кошельков/операторов от ФБР/OFAC/DOJинезависимая техническая корреляция по малвари/инфраструктуре/поведению.
• Высокая. Есть минимум три различных семейства доказательств, включая хотя бы одно из следующих: "co‑residency malware, hardcoded C2/keys" и плюс адреса из санкционных/правоохранительных публикаций, повторяемое инфраструктурное перекрытие через время.
• Средняя. Есть два семейства доказательств, но без прямого правоохранительного артефакта; например, "code overlap + TTP overlap" или "blockchain behavior + target profile".
• Низкая.Атрибуция основана в основном на TTP, географии жертвы, языке, IP или похожем паттерн отмыва (laundering pattern) без жёсткой "сшивки".

Отдельно важно учитывать вес отдельного артефакта. Unit 42 напрямую показывает, что IP‑адрес по умолчанию должен считаться слабым артефактом и может начинать с достоверности уровня 4 / Doubtfully True, пока не появятся hardcoded config и active C2 telemetry, тогда как телеметрия может стартовать с высокой надёжности источника.

В той же логике артефакт типа "адрес из PSA FBI" или "ко‑резидентность Gopuram и AppleJeus на одной машине" существенно тяжелее, чем "похоже на прошлые приёмы Lazarus".

Ключевые инциденты и конкретные доказательства

Ниже приведены репрезентативные инциденты, по которым в открытых источниках наиболее хорошо виден механизм атрибуции.

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

Sony Pictures (2014)

Использованные доказательства: Министерство юстиции США (DOJ) связало атаку с Lazarus через участников группы, псевдонимы, связанные эл. почты и адреса в соц. сетях, кошельки, прокси-сервисы, общие библиотеки вредоносного ПО и инфраструктуру. Дополнительно Kaspersky (Operation Blockbuster) выявила повторное использование кода, одинаковые компоненты (Mozillar, BAT self-delete), общий пароль ZIP-архивов, корейскую локаль и совпадающие рабочие часы (GMT+8/+9). Оценка надёжности: Высокая.

ЦБ Бангладеш (2016)

Использованные доказательства: Kaspersky показала связь банковских атак (Bluenoroff) с более широким кластером Lazarus на основе вредоносного ПО и инфраструктуры. Позже Министерство финансов США официально указало, что Bluenoroff/Lazarus похитили около $80 млн, используя компрометацию SWIFT и вредоносное ПО, сходное с ранее известными образцами. Оценка надёжности: Высокая.

WannaCry (2017)

Использованные доказательства: Основным аргументом стало обнаружение уникальных общих фрагментов кода между ранними версиями WannaCry и образцами Lazarus 2015 года. Позже Kaspersky использовала этот кейс как пример эффективности анализа сходства кода, а правительства Великобритании и США (NCSC и Treasury) публично атрибутировали атаку Северной Корее/Lazarus. Оценка надёжности: Средне-высокая.

Operation DreamJob / In(ter)ception (2019-2020)

Использованные доказательства: ESET выявила использование поддельных аккаунтов рекрутеров в LinkedIn, приманок в виде вакансий, техники Living-off-the-Land (тратегия кибератак, при которой злоумышленники используют легитимные, встроенные инструменты операционной системы и доверенное ПО для выполнения вредоносных действий), сходной среды разработки и антианалитических механизмов. При этом исследователи прямо указали, что не располагают сильными доказательствами, а лишь признаками возможной связи с Lazarus, включая пересечение с NukeSped. Оценка надёжности: Средняя.

3CX и предшествующая атака X_TRADER (2022-2023)

Использованные доказательства: Mandiant связала 3CX с AppleJeus/X_TRADER через совпадения в доставке полезной нагрузки, общий RC4-ключ, одинаковые криптографические реализации, POOLRAT, домен journalide[.]org и пересечения DNS/IP-инфраструктуры. Kaspersky обнаружила совместное использование Gopuram и AppleJeus, а ESET дополнила картину Linux-компонентами (SimplexTea, sysnetd, BADCALL, SIMPLESEA) и оценила связь с Lazarus как высоко достоверную. Оценка надёжности: Средне-высокая / высокая.

Ronin Bridge (2022)

Использованные доказательства: OFAC официально санкционировало адрес эксплойтера как принадлежащий Lazarus. Elliptic показала типичную схему действий группировки: социальную инженерию против операторов валидаторов, обмен украденных USDC на ETH, использование централизованных бирж и Tornado Cash, а также сходство с предыдущими криптовалютными операциями Lazarus. Оценка надёжности: Высокая.

Harmony Horizon (2022)

Использованные доказательства: FBI официально атрибутировало атаку Lazarus/APT38. Ещё до этого Elliptic отмечала, что отдельные признаки сами по себе ничего не доказывают, однако их совокупность - компрометация мультисиг-ключей, вероятная социальная инженерия против команды проекта, программное дробление средств через Tornado Cash, сходство с Ronin и характерные временные паттерны - указывает на Lazarus. Позже Chainalysis и OFAC также связали использование Sinbad, Tornado Cash и Blender с северокорейскими операциями. Оценка надёжности: Высокая.

Atomic Wallet, Alphapo, CoinsPaid и Stake (2023)

Использованные доказательства: FBI объединило эти инциденты в серию TraderTraitor/Lazarus и опубликовало конкретные Bitcoin- и EVM-адреса злоумышленников. Chainalysis по Atomic Wallet показала "chain-hopping", использование мостов, Sinbad и последующую консолидацию средств. По Stake FBI также опубликовало адреса и напрямую связало атаку с Lazarus/APT38. При этом первоначальный способ компрометации Atomic Wallet в открытых отчётах окончательно не установлен. Оценка надёжности: Высокая, однако первоначальный вектор атаки Atomic Wallet остаётся неуточнённым.

DMM Bitcoin (2024)

Использованные доказательства: ФБР, DC3 и Национальное полицейское агентство Японии (NPA) восстановили полную цепочку атаки: поддельный рекрутер в LinkedIn => вредоносное тестовое задание на Python => компрометация сотрудника Ginco => кража сессионных кукисов => выдача себя за сотрудника => проведение легитимной транзакции DMM => вывод средств на известные кошельки TraderTraitor. Это один из наиболее полных примеров атрибуции по всей цепочке атаки. Оценка надёжности: Высокая.

Bybit (2025)

Использованные доказательства: ФБР официально связало кражу около $1,5 млрд с группировкой TraderTraitor и опубликовало адреса злоумышленников. Ещё до заявления FBI компания Elliptic атрибутировала атаку Северной Корее на основе анализа схем отмывания средств. Chainalysis показала, что похищенные активы консолидировались вместе со средствами из предыдущих атак КНДР, а сама операция соответствовала характерному сценарию Lazarus: социальная инженерия, манипуляция пользовательским интерфейсом и JavaScript, а затем многоступенчатое отмывание средств через различные сервисы. Оценка надёжности: Высокая.

Выводы

Если посмотреть на эти кейсы поперёк времени, видно, что для деструктивных/шпионских операций сильные сигналы чаще исходят из малварь‑генеалогии, инфраструктуры, подготовительных операций и OPSEC, а для финансовых - из ончейн-расследования и последующего государственного "наименования".

С 2018 года особенно заметно смещение части северокорейской экосистемы в сторону криптовалют (trojanized trading apps) и мостов/кошельков; CrowdStrike в 2026 году даже пересобрал старую схему и выделил отдельные линии GOLDEN CHOLLIMA и PRESSURE CHOLLIMA под финансовые цели при сохранении общего DPRK‑ядра.

Связи между инцидентами, инфраструктурой и финансовыми следами

Ниже - аналитическая схема, составленная по публичным связям из отчётов Kaspersky, ESET, Mandiant, FBI, Treasury, Chainalysis и Elliptic. Она не претендует на полноту всех подкластеров и показывает именно опорные публично документированные мосты атрибуции.

Публикую на английском языке, чтобы не было разночтений по наименованиям:

• Lazarus[Lazarus umbrella]
• RGB[RGB / государственная привязка]
• Lazarus => RGB

1. Sony[Sony 2014]
2. Bangladesh[Bangladesh 2016]
3. WannaCry[WannaCry 2017]
4. DreamJob[DreamJob / In(ter)ception]
5. XTRADER[X_TRADER supply chain]
6. ThreeCX[3CX supply chain]
7. Ronin[Ronin 2022]
8. Harmony[Harmony 2022]
9. Atomic[Atomic / Alphapo / CoinsPaid / Stake 2023]
10. DMM[DMM Bitcoin 2024]
11. Bybit[Bybit 2025]

• Destover[Destover / Hangman / Blockbuster traits]
• Gopuram[Gopuram]
• AppleJeus[AppleJeus / POOLRAT / CoinGoTrade]
• BADCALL[BADCALL / SimplexTea / SIMPLESEA]
• TraderTraitor[TraderTraitor]
• Swift[SWIFT access & bank tooling]
• TCash[Tornado Cash]
• Blender[Blender]
• Sinbad[Sinbad]
• Railgun[Railgun]
• CoinJoin[CoinJoin / chain-hopping]
• Wallets[FBI / OFAC wallet lists]

1. Sony => Destover
2. Bangladesh => Swift
3. Bangladesh => Destover
4. WannaCry => Destover

• DreamJob => AppleJeus
• DreamJob => BADCALL
• XTRADER => AppleJeus
• ThreeCX => Gopuram
• ThreeCX => AppleJeus
• ThreeCX => BADCALL
• XTRADER => ThreeCX

1. Ronin => TraderTraitor
2. Ronin => Blender
3. Ronin => TCash
4. Ronin => Wallets

• Harmony => TraderTraitor
• Harmony => TCash
• Harmony => Railgun
• Harmony => Sinbad

1. Atomic => TraderTraitor
2. Atomic => Sinbad
3. Atomic => Wallets

• DMM => TraderTraitor
• DMM => CoinJoin
• DMM => Wallets

Bybit => TraderTraitor

Bybit => Wallets

Эволюция поэтому выглядит так: сначала публичное ядро Lazarus ассоциировалось с разрушительными и саботажными кампаниями - Sony, DarkSeoul, Operation Troy и затем WannaCry; затем параллельно усилился финансовый контур через Bluenoroff / APT38 / AppleJeus и банковые SWIFT‑хищения; после 2021–2022 годов основной публично наблюдаемый денежный след сместился в криптобиржи, кошельки, бриджи и атаки на цепочки поставок. Именно поэтому для более новых кейсов роль ончейн и адресной публикации кошельков стала существенно выше, чем в ранних операциях.

ИИ всё свёл вот в такую диаграмму:

Эта шкала также показывает, почему старые и новые кейсы нельзя оценивать одной линейкой. В ранних кейсах преобладали forensic‑и malware‑свидетельства; в более поздних — адресная блокчейн‑аналитика и санкционные действия. Одновременно taxonomy усложнилась: чем больше публичных материалов, тем яснее, что «Lazarus» — это не одна стабильная команда, а система близкородственных операторов внутри DPRK‑экосистемы.

Ограничения, ложные совпадения и контр‑атрибуция

Главное ограничение - терминологическое. В публичных отчётах под словом Lazarus могут скрываться разные связки: Lazarus как "зонтик" для многих групп, Bluenoroff как финансовое крыло, Andariel как отдельный кластер, APT38, TraderTraitor, AppleJeus и иные.

Это означает, что публичное утверждение "это Lazarus" иногда корректно только в смысле связи с DPRK‑nexus, но не обязательно в смысле точного подразделения.

Mandiant и CrowdStrike прямо подчеркивают, что общие люди, фреймворки и инфраструктура затрудняют детальную развязку.

Второе ограничение - ложные совпадения по коду. Kaspersky показывает две важные вещи одновременно: с одной стороны, общий код (shared code) реально даёт сильнейшие указания; с другой - схожие технологии могут ошибаться, если атакующий сознательно подмешивает заимствованный код (borrowed code), библиотечные фрагменты или устанавливает фальшивые флаги (false flags).

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

Третье ограничение - слабость отдельных инфраструктурных данных. IP‑адреса, whois‑сведения и даже домены часто переиспользуются через общий хостинг (shared hosting), диапазоны (от) провайдеров, прокси, VPN и заранее скомпрометированные серверы.

Unit 42 специально отмечает, что IP по умолчанию заслуживает низкой оценки и должен повышаться только при наличии других данных (hardcoded config, active C2 telemetry) или другого контекста. Поэтому "этот IP тоже мелькал рядом с Lazarus" - слабый аргумент; "этот IP сидит в конфиге малвари, виден в телеметрии и перекрывается с инфраструктурой AppleJeus" - уже более сильный.

Четвёртое ограничение - блокчейн‑паттерны сами по себе не абсолютны. Elliptic в кейсе Harmony прямо формулирует правильную оговорку: ни один фактор в отдельности не доказывает участие Lazarus; убеждает сочетание факторов - техника атаки, профиль жертвы, использование определённых инструментов (programmatic Tornado deposits, APAC‑timing), повторение схемы (Ronin) и последующее подтверждение ФБР. Это особенно важно потому, что миксеры, бридж‑маршруты, кроссчейн-транзакции могут копироваться другими преступниками.

Пятое ограничение - контр‑атрибуция и скрытие следов. В публичных кейсах Lazarus регулярно использовал прокси/VPN, поддельные рекрутерские аккаунты, фальшивые компании и приложения, куки/сессии, троянизированные легитимные пакеты и др. (DLL sideloading, secure deletion), а при финансовых операциях - схожие инструменты (Tornado Cash, Blender, Sinbad, Railgun, мосты) и консолидирующие адреса. Всё это снижает точность одиночного наблюдения и требует многослойной проверки.

Как проверить и воспроизвести выводы?

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

Первый - форензика и малварь: образцы, хэши, конфиги, память, логи (EDR/SIEM, PE/ELF/Mach‑O metadata, build artifacts, YARA‑совпадения).

Второй - инфраструктура: в самом широком смысле (passive DNS, исторические A‑/AAAA‑/NS‑резолвы, TLS‑сертификаты, WHOIS, netflow/PCAP, URL history, sandbox telemetry).

Третий - финансовые сегмент: адреса из ФБР/OFAC/правоохранительных релизов, ончейн-графы, данные (об обменах и т.п.). Именно такое сочетание лежит под лучшими публичными кейсами Lazarus.

Для малварь‑части основной рабочий набор - это YARA‑поиск, реверс-инжиниринг и сравнение кода. Kaspersky описывает полезные подход (sub‑checksums, CFG/graph comparison, n‑grams, fuzzy hashes, metadata analysis и поиск уникальных genotypes, не встречающихся в чистом ПО) - их тоже можно и нужно использовать.

На практике это означает, что для проверки связей между инцидентами Lazarus нужно искать не просто похожие строки, а редкие фрагменты, конфигурационные ключи, пароли (hardcoded passwords), куки, константы, Rich Header и совместимость с уже известными наборами правил.

Для инфраструктурой части воспроизведение должно идти через историческую корреляцию, а не "снимок на сегодня". Нужно проверять, какие домены резолвились в те же IP в то же окно времени, какие сертификаты и хосты повторялись (доп.: были ли hardcoded C2 и active beacons, встречались ли одни и те же резолвер‑узлы между разными кампаниями).

Хороший пример - 3CX/X_TRADER, где атрибуция усиливалась не одним доменом, а цепочкой: компрометированный сайт, предыдущая версия ПО, POOLRAT, journalide[.]org, CoinGoTrade/JMT Trading и др.

Для blockchain‑части ключевой принцип - строить граф контроля средств, а не только список переводов.

Надо отделять: адреса, прямо названные правоохранителями; адреса первого уровня от эксплоита и т.д. ("consolidation nodes; bridge‑переходы; mixer exposure; cash‑out endpoints").

Chainalysis и Elliptic показывают, что именно графовые признаки (wallet clustering, exposure through transaction graph, repeated laundering signatures, consolidation with previously known DPRK funds) превращают сырой блокчейн в атрибуционное доказательство. Для целого ряда свежих кейсов репликация без ончейн фактически невозможна.

Практически воспроизводимый воркфлоу выглядит так

Сначала нужно собрать и нормализовать артефакты по Diamond Model: жертва (victim) - от неё уже связки (capability, infrastructure, possible adversary hypotheses).

Затем - сделать ATT&CK‑mapping и проверить полноту даных. После этого - оценить каждый артефакт (по reliability/credibility), используя логику Admiralty, где IP не равен вводным (malware sample), а телеметрия не равна блог‑сводке.

Далее - построить корреляционную сетку (code overlap, infra overlap, temporal overlap, wallet overlap, victimology overlap). Только после этого разумно повышать вывод до высокого.

Наконец, при проверке выводов по Lazarus важно фиксировать, какие детали всё ещё неуточнённы в открытых источниках.

Например, по Atomic Wallet сам начальный вектор в публичном отчёте Chainalysis остаётся нераскрытым; по Harmony и Ronin ключевой вектор описывается как вероятная компрометация через соц. инженерию, а не как полностью раскрытая техническая ошибка; по некоторым кейсам часть внутренней телеметрии остаётся за пределами публичных материалов.

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

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

Именно этот многослойный подход и отличает сильные кейсы Lazarus от слабых... Проблема в том, что их - крайне мало...

До!