Restaking в криптовалюте: дополнительная доходность и дополнительный слой риска

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

Главная ошибка новичка — складывать базовый staking APR и обещанный restaking reward так, будто второй слой не меняет профиль риска. Дополнительная выплата существует потому, что капитал или оператор берёт на себя дополнительную работу, дополнительные условия поведения либо дополнительный smart-contract и governance контур. Если новый сервис может наказать оператора, если vault распределяет обеспечение между несколькими сетями или если пользователь получает liquid restaking token вместо прямого требования, вместе с новой доходностью появляются новые пути потери, задержки и расхождения между расчётной и рыночной стоимостью.

Эта статья не повторяет базовое руководство по стейкингу и не заменяет отдельный материал про Liquid staking. Здесь задача другая: построить карту именно второго слоя обязательств — restaker, оператор, сервис или сеть, vault/куратор, reward-потоки, slashable stake, LRT и выход. Отдельный материал о реальной доходности стейкинга остаётся владельцем расчёта gross APR, комиссии валидатора, инфляции предложения и изменения цены базового токена.

Числовые примеры ниже учебные. Они не являются текущими ставками, параметрами EigenLayer, Symbiotic, Karak или любого другого протокола. В restaking особенно опасно переносить одну формулу между системами: разные протоколы используют разные модели delegation, vault, operator set, slashing, reward distribution и withdrawal. Поэтому хороший анализ начинается не с процента, а с ответа на вопрос: какой именно актив остаётся под риском, кто может наложить дополнительное обязательство и по каким правилам.

Рабочий принцип: restaking не создаёт второй независимый капитал. Один и тот же экономический ресурс используется в нескольких контурах. Дополнительный reward следует сравнивать не только с нулём, но и с новым слоем риска, временем выхода и альтернативой оставить исходный stake без restaking.

1. Что такое restaking и чем он отличается от обычного staking

Обычный staking связывает капитал с безопасностью базовой сети

В Proof-of-Stake актив используется как экономический залог за корректное участие в работе сети. Валидатор или делегатор получает вознаграждение по правилам этой сети, а нарушение определённых правил может повлечь санкции. Базовая позиция уже имеет свой набор рисков: цена токена, работа валидатора, slashing базовой сети, очереди активации и выхода, а также операционные или кастодиальные риски выбранного способа участия. Реальную доходность стейкинга поэтому считают отдельно от роста цены и отдельно от дополнительных стратегий.

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

Restaking добавляет вторую или несколько задач к одному экономическому обеспечению

В простейшей логике restaking означает, что капитал, уже участвующий в одном контуре безопасности, используется для дополнительных проверяемых задач. В EigenLayer такие сервисы традиционно описываются как AVS и operator sets; в других системах терминология и архитектура иные — например, сети, vaults, middleware или DSS. Общая идея одна: внешняя система получает экономическую гарантию, а оператор и обеспечивающий его stake принимают новые обязанности.

Важный вывод для инвестора: две задачи не превращают 10 ETH в 20 ETH капитала. Если один и тот же stake обеспечивает несколько сервисов, нужно понимать, разделён ли slashable amount, выделены ли уникальные доли, используются ли общие guarantees или конкретный vault изолирует риск. Слова «shared security» и «capital efficiency» описывают архитектуру, но не доказывают, что риски разных сервисов независимы.

Дополнительный reward — плата за дополнительную функцию, а не подарок протокола

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

Для сравнения доходных стратегий полезно пользоваться той же дисциплиной, что и в разборе источников пассивного дохода: базовый staking reward, restaking reward, бонусный токен, points, airdrop expectation и рост рыночной цены — разные строки. Они не должны сливаться в один APY без модели получения, продажи и доступности.

Liquid staking и restaking — разные слои

Liquid staking превращает staking-позицию в ликвидное требование или токен, который можно использовать дальше. Restaking добавляет к экономическому обеспечению новые задачи и условия. Пользователь может restake нативно, может restake LST, а может войти через liquid restaking token. Эти маршруты похожи в интерфейсе, но содержат разное количество договорных и smart-contract слоёв.

Например, LST уже несёт риск underlying staking, протокола выпуска и вторичной ликвидности. Если этот LST затем помещается в restaking vault, возникает ещё один контур правил. Если поверх позиции выпускается LRT, появляется ещё одно представление требования. Поэтому глубина composability должна отражаться в карте рисков. Liquid staking разбирает первый производный слой; здесь нас интересует именно то, что добавляется после него.

Liquid restaking token — не ещё одна копия underlying

LRT обычно представляет долю или требование на restaking-позицию по правилам конкретного протокола. Его нельзя автоматически считать 1:1 идентичным ETH, LST или активам vault. Рыночная цена может отклоняться от расчётного underlying-equivalent, а погашение может иметь очередь, лимит, зависимость от состояния контракта или период, когда запрос всё ещё подвержен определённым рискам.

Для учёта нельзя складывать underlying stake и полученный LRT как два независимых актива, если LRT только представляет то же вложение. Это та же проблема двойного счёта, которая встречается с LP-токенами и токенизированными требованиями. При построении портфеля полезно открыть методику ончейн-анализа и проверить, какие записи являются первичным активом, а какие — его представлением.

Restaker, operator и сервис выполняют разные роли

Restaker предоставляет экономический ресурс. Operator запускает программное обеспечение и принимает операционные обязательства. Дополнительный сервис формулирует работу, правила участия, rewards и, если предусмотрено, условия slashing. В некоторых архитектурах между ними находится vault или curator, который выбирает распределение капитала. В LRT-модели пользователь может вообще не выбирать отдельный сервис вручную — это делает управляющий слой продукта.

Ошибка — оценивать только известность протокола и игнорировать оператора или управляющего. Если пользователь делегирует stake оператору, его результат зависит не только от смарт-контракта, но и от того, какие сервисы оператор обслуживает, как распределяется slashable capital и насколько устойчиво работает инфраструктура. Вопрос «кто контролирует решение добавить новый сервис?» часто важнее разницы в несколько десятых процента доходности.

Restaking — это не отдельная гарантия прибыли

Даже если базовый staking начисляет токены и restaking добавляет дополнительные rewards, денежный итог зависит от цены underlying, цены reward-токенов, комиссий, доступности выхода и возможных потерь. Величина в интерфейсе может быть годированной оценкой краткого периода или суммой нескольких программ, часть которых ещё нельзя реализовать.

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

2. Архитектура restaking: native stake, LST, vault, operator и дополнительные сети

Native restaking начинается с исходного validator stake

В нативной модели базовый валидатор Ethereum или другой PoS-системы сохраняет исходную staking-позицию, но связывает её с дополнительным restaking-протоколом по предусмотренным правилам. Это ближе всего к идее повторного использования исходной economic security: отдельный LST не нужен как промежуточный актив. Однако пользователю всё равно нужно понять, кто управляет validator keys, кто выбирает дополнительные сервисы и какие части stake действительно могут быть наказаны.

Нативный маршрут не означает отсутствие smart-contract риска. Протокол restaking может использовать собственные контракты для delegation, учёта, withdrawal и slashing. Кроме того, operator software расширяется: базовый валидатор получает дополнительные процессы. Чем больше программных компонентов и signing-обязанностей, тем важнее изоляция ключей, мониторинг и понятный порядок обновлений.

Restaking LST добавляет риск производного токена до нового слоя

Если вместо нативного валидатора пользователь вносит liquid staking token, restaking начинается уже не с ETH как такового, а с требования на staking-позицию. Это удобно для розничного капитала, но в цепочке появляется эмитент LST, его accounting, smart contracts, market liquidity и redemption. Новая restaking-позиция наследует эти свойства.

При stress-тесте нужно рассматривать минимум два независимых ценовых процесса: underlying asset и рыночное соотношение LST к underlying. Падение ETH и скидка stETH/ETH могут происходить одновременно. Если LST одновременно служит collateral в lending или liquidity position, риск ещё больше усложняется. Для таких сценариев полезно сверяться с логикой depeg как общей методикой расхождения расчётной и рыночной стоимости, не приравнивая LST к стейблкоину.

Vault отделяет хранение collateral от правил распределения

Во многих современных restaking-архитектурах vault является контейнером, который принимает collateral, выпускает долю или ведёт внутренний учёт и определяет, куда stake может быть выделен. Vault может поддерживать один или несколько сервисов, операторов и лимитов. В зависимости от протокола правила могут быть фиксированными, управляемыми curator, governance или набором модулей.

Пользователю важно выяснить, является ли vault просто бухгалтерской оболочкой или дополнительно использует капитал во внешних стратегиях. Если collateral одновременно restake и направляется в yield-generating adapter, risk stack растёт. В таком случае нельзя считать restaking reward единственным дополнительным источником результата: нужно восстановить все потоки и все места, где актив может быть потерян или задержан.

Operator set показывает, кто фактически несёт обязанности

Дополнительный сервис редко работает с абстрактным «протоколом в целом». Он использует конкретный набор операторов, которые выполняют задачи. У одного оператора может быть stake нескольких пользователей и несколько обязанностей. В некоторых системах slashable amount выделяется на конкретный operator set; в других часть collateral может использоваться совместно между сетями или vaults.

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

Delegation не передаёт владение, но передаёт часть операционного выбора

Во многих non-custodial restaking-моделях оператор не получает право вывести пользовательский stake на свой адрес, но его действия способны определять, какие обязательства выполняются и подвергается ли выделенный капитал slashing. Поэтому фраза «оператор не хранит средства» верна лишь для custody-риска и не исключает operational risk.

До delegation следует записать, какие полномочия пользователь сохраняет: можно ли redelegate, какой период ожидания, что происходит с pending withdrawal, какие события могут быть наказаны после запроса выхода. Похожие проверки полезны и в других DeFi-системах: проверка контракта помогает отделить права пользователя от прав управляющих адресов.

Shared collateral повышает capital efficiency и усложняет причинность потерь

Когда один пул обеспечения используется несколькими сервисами, капитал работает эффективнее: каждому новому сервису не требуется отдельная полная база stake. Но при проблеме становится сложнее определить, какая часть remaining security остаётся у остальных участников и как один slash влияет на другие guarantees. Некоторые архитектуры специально вводят изоляцию или unique allocations, чтобы ограничить spillover.

Инвестору не нужно запоминать конкретные названия модулей. Достаточно задать три вопроса: сколько моего collateral реально может быть наказано конкретным сервисом, может ли один и тот же кусок участвовать в нескольких slashable обязательствах и что останется другим сервисам после наказания. Если интерфейс не позволяет ответить, сумма дополнительного APR не компенсирует информационную неопределённость.

Протоколы restaking используют разную терминологию

EigenLayer говорит об AVS и operator sets; Symbiotic — о Networks, vaults, delegators и slashers; Karak использует DSS. Эти термины полезны для чтения документации, но не следует переносить свойства одного протокола на другой. Например, withdrawal timing, способ перераспределения slashed collateral, curator powers и reward distribution могут заметно отличаться.

Практическая карточка позиции должна переводить маркетинговые термины в общие поля: collateral, owner, operator, service/network, allocation, slashable amount, reward source, exit delay и upgrade authority. Тогда два протокола можно сравнить по функции, а не по названию. Это особенно полезно перед тем, как добавлять restaking в общую систему доходных инвестиций.

3. Откуда берётся дополнительная доходность в restaking

Базовый staking reward и restaking reward нужно хранить раздельно

Если исходный актив уже приносит staking reward, этот поток существовал бы и без restaking. Поэтому для оценки добавочной ценности создайте контрольную позицию: тот же underlying, тот же срок, но без второго слоя. Разница между двумя ветками после расходов и потерь показывает вклад restaking. Без такой контрольной базы легко приписать всей стратегии доход, который на самом деле создаёт базовая сеть.

Например, если staking-only добавил 0,20 ETH, а restaking-вариант получил те же 0,20 ETH плюс токены сервиса стоимостью 100 U, нельзя говорить, что restaking «заработал» весь staking reward. Его добавочный gross result равен стоимости дополнительных токенов до учёта новых расходов и рисков. Та же логика применяется в расчёте реальной staking-доходности.

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

У дополнительного сервиса могут быть пользователи, которые платят за данные, вычисления, доступность, сообщения или другие услуги. Тогда часть revenue может финансировать operators и restakers. Другой вариант — временная токеновая эмиссия, treasury budget или programmatic incentive. Оба механизма создают выплату, но устойчивость у них разная.

Для анализа запишите не только reward token и APR, но и источник распределяемого количества. Если выплату можно поддерживать только постоянным расширением предложения токена, сравните эмиссию с реальным спросом. Если reward идёт из fees, проверьте, насколько эти fees зависят от субсидий самой сети. Циклическая схема «мы платим пользователям, чтобы они создавали fees, из которых платим стейкерам» требует отдельного stress-test.

Operator и curator fees уменьшают валовую награду

Дополнительная сеть может объявлять gross reward, но пользователь получает сумму после доли оператора, LRT-протокола, curator или других посредников. Комиссия может удерживаться из каждого reward, начисляться в виде management/performance fee или быть встроенной в обменный курс доли. Если интерфейс показывает net APY, нельзя снова вычитать ту же комиссию вручную.

Сохраняйте четыре величины: reward до распределения, operator share, protocol/curator share и фактически поступивший пользователю актив. Для токенизированной доли дополнительно проверьте, отражается ли reward ростом количества токенов или ростом их exchange rate. Одновременное прибавление обоих эффектов даст двойной счёт.

Points и ожидаемый airdrop не равны денежному reward

Restaking-экосистемы часто используют points, seasons, loyalty score или будущие распределения. Такие единицы могут иметь маркетинговую ценность, но пока не существует подтверждённого права на конкретный ликвидный актив, их нельзя включать в доступный доход как деньги. Даже после объявления токена остаются vesting, eligibility, claim cost и рыночная цена.

В инвестиционной модели разумно хранить points отдельной строкой с нулевой либо сценарной оценкой, но не смешивать её с realized yield. Если без оценки будущего airdrop стратегия перестаёт быть привлекательной, это важный вывод о качестве дохода. Подобный подход применяется и в yield farming, где incentive token отделяется от базовых fees.

Программная награда может быть регулярной, но не фиксированной навсегда

Некоторые протоколы распределяют rewards по снимкам stake, operator sets или активному участию. Правила могут зависеть от времени, выбранных сервисов, токена награды и доли оператора. Годирование нескольких недель не означает обязательство сохранять тот же темп 365 дней.

Для рабочего журнала храните amount per period, active stake, долю пользователя и фактическую дату claim. Если ставка меняется, рассчитывайте последовательность периодов, а не среднее арифметическое процентов. Принцип тот же, что в сравнении APY: результат должен воспроизводиться из денежных потоков, а не из баннера.

Reward в собственном токене сервиса добавляет price risk

Дополнительная выплата может быть номинирована не в ETH, а в токене AVS, network, протокола или программы. Количество токенов и денежный доход — разные метрики. Большая эмиссия способна увеличить баланс пользователя и одновременно снизить цену. Низкая ликвидность добавляет price impact при продаже.

Если reward нельзя реализовать по отображаемой цене, используйте исполнимый сценарий: доступный объём, spread, slippage и комиссии. Для крупных сумм полезны методы из анализа ликвидности и price impact. Привычка оценивать reward по последней сделке особенно опасна в новом токене с тонким рынком.

Дополнительный APR следует сравнивать с новым capital-at-risk

Процент сам по себе не показывает, какой объём капитала действительно подвергнут дополнительному наказанию. Дополнительные 2% годовых на 10 ETH могут быть неинтересны, если вся позиция или значительная доля collateral становится slashable по новым правилам, которые пользователь плохо понимает. С другой стороны, изолированная малая allocation может иметь другой профиль.

Вместо попытки выразить риск одной «премией за опасность» используйте сценарии: reward прекращается; reward token падает; slash на 1%, 5% или заданный protocol maximum; withdrawal задерживается; LRT торгуется со скидкой. Затем сравните конечный капитал. Вероятности нельзя выдумывать, но последствия конкретных событий можно рассчитать.

4. Slashing и коррелированные риски: почему второй слой меняет профиль staking

Slashing базовой сети и restaking-slashing — не одна и та же причина

Базовая PoS-сеть определяет собственные нарушения и штрафы. Restaking-сервис может вводить дополнительное проверяемое обязательство: например, корректно выполнять определённую вычислительную, подписывающую или data-availability задачу. Ошибка на этом уровне может существовать даже тогда, когда Ethereum validator полностью соблюдает правила Ethereum.

Поэтому в risk register должны быть разные строки: base-layer slashing, operator downtime, сервис-specific fault и smart-contract enforcement. Формулировка «валидатор никогда не был slashed в Ethereum» полезна, но не доказывает безошибочность нового AVS software. Новая бинарная программа, ключ или signing domain создают новый класс событий.

Одинаковый оператор связывает риски нескольких сервисов

Если один operator обслуживает несколько дополнительных сетей, у них появляется общая операционная зависимость. Компрометация машины, ошибка автоматизации, неверное обновление или общий signing bug способен затронуть несколько задач. Даже когда stake allocation экономически изолирована, downtime и человеческая ошибка могут быть коррелированы.

Пользователь должен смотреть на operator portfolio: число сервисов, требования к ресурсам, географию, инфраструктурные зависимости, частоту обновлений и прошлые инциденты. Большое количество AVS не обязательно означает диверсификацию; оно может означать большую поверхность атаки и нагрузку на команду.

Shared stake создаёт риск spillover между сетями

В multi-network restaking один collateral pool может поддерживать несколько сетей. Если protocol architecture допускает shared guarantees, slash в одной сети уменьшает доступное обеспечение, на которое рассчитывают другие. Это не обязательно приводит к прямому второму slash, но меняет security capacity и может вызвать дальнейшие реакции curator, network или users.

Некоторые системы используют unique stake, per-network limits или отдельные vaults, чтобы ограничивать spillover. Не предполагайте наличие такой защиты по слову «restaking». Нужно прочитать конкретную конфигурацию: какая часть collateral выделена, можно ли её использовать несколькими networks одновременно и как учитываются предыдущие slashings.

Veto и dispute window уменьшают один риск и добавляют governance layer

Некоторые slashing-системы исполняют доказуемое наказание сразу, другие предусматривают окно review или veto. Окно полезно против ошибочных запросов и незрелых fault proofs, но создаёт дополнительный субъект управления. Нужно знать, кто имеет право veto, как меняется этот набор и может ли пользователь выйти до изменения правил.

Нельзя считать наличие multisig или resolver абсолютной защитой. Оно снижает одни ошибки, но создаёт governance и key-management risk. В паспорте позиции записывают exact role такого органа: может ли он только отменить slash, может ли обновлять contracts, менять networks или параметры withdrawal.

Slashing может не означать полное уничтожение collateral

В разных протоколах penalized amount может сжигаться, перераспределяться пострадавшим пользователям, отправляться treasury или обрабатываться специальным контрактом. С точки зрения restaker важно, насколько уменьшается его экономическое требование; направление дальнейшего движения slashed asset влияет на системную модель, но не отменяет факт потери пользователя.

Поэтому не стройте формулу «slash = burn» без документации. В учебных стрессах достаточно задать уменьшение underlying claim на конкретную величину и отдельно отметить, куда уходит penalty. Такой подход сохраняет корректность между разными архитектурами.

Pending withdrawal может оставаться под риском

Запрос выхода не всегда мгновенно выводит капитал из slashable set. Протоколу нужен период, чтобы сервис мог обнаружить нарушение, подтвердить его и применить наказание к stake, который действительно обеспечивал работу в соответствующий момент. Поэтому withdrawal queue — не только неудобство ликвидности, но и часть security design.

Перед выходом проверьте три времени: когда перестают начисляться rewards, когда прекращаются новые обязательства и когда средства перестают быть slashable. Эти моменты могут не совпадать. Если пользователь считает позицию «закрытой» сразу после нажатия Withdraw, он может неправильно оценить остаточный риск и доступный капитал.

Коррелированный slashing нельзя свести к сумме независимых вероятностей

Если несколько сервисов используют одного оператора, одинаковый клиент, oracle, cloud provider или общий кусок software, их события не независимы. Складывать отдельные «вероятности slash» и считать итог по школьной формуле без данных нельзя. В молодом протоколе статистики может просто не хватать.

Вместо выдуманной вероятности используйте deterministic stress: один software incident затрагивает все operator sets, где работает одинаковая версия; одна governance ошибка меняет параметры нескольких vaults; один depeg collateral ухудшает все стратегии, где он используется. Такой сценарный подход хорошо дополняет общую дисциплину риск-менеджмента.

5. Liquid restaking token, depeg и выход из позиции

LRT добавляет ликвидность ценой ещё одного слоя условий

Liquid restaking token позволяет передать или использовать restaking-позицию без ожидания полного withdrawal underlying. Это удобно для DeFi, но ликвидность не равна гарантированному погашению по расчётной стоимости. Пользователь получает отдельный токен со своим контрактом, governance, рыночным стаканом или AMM-пулом и правилами redeem.

Если LRT используется дальше как collateral или LP-asset, один исходный stake начинает участвовать в нескольких финансовых отношениях. Для контроля создайте dependency graph: ETH → staking/LST → restaking vault → LRT → lending или liquidity. Каждый новый arrow должен иметь своё условие выхода и собственный failure mode.

Depeg LRT — это расхождение market exit и расчётного требования

Термин depeg здесь используют бытово: LRT может торговаться со скидкой к underlying-equivalent. Причинами бывают низкая ликвидность, страх slashing, длинная очередь redemption, изменение доверия к оператору или общая паника. Скидка не обязательно означает немедленную потерю underlying при eventual redemption, но для пользователя, которому нужны деньги сейчас, она становится реальным экономическим убытком.

Всегда считайте минимум две стоимости: сколько underlying обещает accounting модели и сколько можно получить при фактической продаже нужного размера. Разница между ними — не «ошибка цены», а стоимость ликвидности и риска во времени. Методы из разбора slippage помогают оценивать именно исполнимый market exit.

Redemption может быть лучше рынка и хуже по времени

Если протокол позволяет погасить LRT в underlying, расчётный маршрут может давать больше единиц, чем немедленная продажа на DEX. Но пользователь принимает queue risk и timing risk: ставка может перестать начисляться, средства могут остаться slashable, а обязательный платёж наступит раньше claim. Поэтому «получить больше ETH» не равно «получить лучший экономический результат».

Сравнение делают на одну дату. Если market exit сегодня даёт 9,7 ETH, а redemption обещает 10 ETH через две недели, нужно учитывать стоимость ожидания, вероятность изменения параметров, необходимость денег и возможность хеджирования. Не дисконтируйте будущее произвольным процентом — покажите два сценария отдельно.

Вложенный LRT в lending меняет смысл collateral risk

Если LRT внесён как collateral, падение его oracle price может снизить health factor независимо от того, сохраняется ли underlying claim. Тогда пользователь сталкивается одновременно с restaking risk и liquidation risk. Отложенное redemption не спасает позицию, если lending protocol использует текущую oracle valuation и запускает ликвидацию раньше.

Такой сценарий напрямую связан с механикой криптокредитов под залог. Перед использованием LRT в кредитовании нужно построить стресс не только по ETH/USD, но и по LRT/ETH. Два движения могут происходить одновременно и усиливать друг друга.

LRT в пуле ликвидности добавляет composition risk

Пара LRT/ETH выглядит как пул близких активов, но при скидке состав позиции меняется: арбитражеры могут оставить LP больше дешёвого LRT и меньше ETH. Комиссии компенсируют часть отклонения, но не гарантируют возврат исходного состава. Если пользователь одновременно получает restaking reward и LP fees, нужно следить, не скрывает ли одна строка потерю в другой.

Для контроля сравните LP-позицию с простым хранением того же исходного количества LRT и ETH. Impermanent loss здесь является отдельным измерением от restaking reward; складывать их только в APY без конечного portfolio value бессмысленно.

Bridge создаёт новый домен риска поверх restaking

Некоторые LRT или их обёртки доступны в нескольких сетях. Переход через bridge добавляет смарт-контракт, relayer/validator assumptions, задержки и возможный disconnect между wrapped representation и исходным claim. Restaking-risk никуда не исчезает — к нему добавляется cross-chain risk.

Если стратегия требует bridge только ради дополнительного incentive, сравните добавочный reward с новым failure mode. Чем больше необратимых шагов, тем важнее тестовая сумма и проверка каждого TxID. Для on-chain контроля используйте проверку транзакции по TxID вместо скриншотов интерфейса.

Успешный выход подтверждается активом, а не только статусом UI

Закрытие restaking-позиции может состоять из нескольких событий: request, undelegation, withdrawal finalization, claim, unwrap LRT и фактическое получение underlying. Статус «Completed» одного промежуточного шага не гарантирует, что на конечном адресе уже находится свободный ETH или другой актив.

Перед удалением приложения или отзывом всех разрешений сохраните transaction hashes, адреса контрактов, amount и timestamp. После завершения проверьте баланс на независимом explorer. Если использовались approve или permit, отдельно оцените, остались ли активные разрешения. Разбор подписей кошелька помогает отличать disconnect интерфейса от реального изменения разрешений.

6. Как считать реальный результат restaking и строить stress-сценарии

Сначала создайте control: staking без restaking

Контрольная ветка отвечает на вопрос, что произошло бы с тем же активом без дополнительного слоя. Она включает базовый staking reward, комиссию базового оператора и рыночную цену underlying. Restaking-ветка начинается с того же основания и добавляет только специфические rewards, fees и losses.

Такое сравнение защищает от маркетингового двойного счёта. Если ETH вырос на 20%, это не заслуга restaking; если Ethereum staking начислил 3%, это тоже не отдельная restaking alpha. Добавочный результат — разница между двумя сопоставимыми ветками на одну дату.

Reward layers складывают в деньгах только после определения доступности

Дополнительные выплаты могут приходить в ETH, EIGEN-подобном токене, собственном токене сервиса или другом активе. Для каждой строки фиксируются amount, claimability, price source, liquidity и fees. Заблокированный reward показывают отдельно. Только после этого доступные суммы переводят в одну валюту сравнения.

Если reward отражён ростом exchange rate LRT, не добавляйте его второй раз как отдельный token reward. Сначала восстановите accounting: сколько underlying-equivalent представляет доля до и после периода, какие отдельные токены действительно поступили на адрес и какие fees удержаны.

Slashing моделируйте как уменьшение требования, а не как процент APR

Slash — это событие капитала, а не отрицательная доходность, равномерно распределённая по году. Если позиция 10 ETH теряет 0,15 ETH, нужно уменьшить underlying claim на 0,15 ETH в момент события и затем пересчитать денежную стоимость. Нельзя просто вычесть «1,5% APR» из рекламного годового процента, особенно на коротком горизонте.

Для нескольких stress levels задайте конкретные slash amounts или доли, разрешённые учебной моделью. Вероятность события оставьте неопределённой, если нет статистически обоснованной оценки. Цель stress-test — понять последствия, а не выдать точную ожидаемую доходность.

Цена underlying может перекрыть любую дополнительную награду

Если ETH подешевел на 10–20%, дополнительные несколько процентов rewards не гарантируют положительный долларовый итог. Поэтому результат в токенах и результат в валюте расходов нужно показывать отдельно. То же относится к reward token: он может упасть сильнее underlying.

Для сравнения можно построить матрицу: ETH −20/0/+20%, reward token −70/−30/0%, slash 0/1/5% и LRT discount 0/2/5%. Не нужно перебирать тысячи комбинаций и выбирать красивую; достаточно заранее определить несколько осмысленных stress-сценариев.

Комиссии и gas особенно важны для маленькой позиции

Restaking часто требует несколько действий: deposit, delegate, claim, withdrawal request, final claim, unwrap, swap reward. На маленьком капитале фиксированные network fees способны поглотить заметную часть добавочного reward. Если strategy предполагает частый claim ради compounding, gas нужно считать на каждом цикле.

Минимальный экономический вопрос: сколько дополнительного reward должно накопиться, чтобы покрыть дополнительные расходы restaking по сравнению с staking-only. Эта break-even величина не делает стратегию безопасной, но показывает, имеет ли смысл усложнение на вашем размере позиции.

Операторская комиссия и LRT fee не должны исчезать в агрегированном APY

Если интерфейс показывает итоговый net APY после всех fee, используйте его только как ориентир и проверьте фактический balance change. Если доступны gross rewards, рассчитайте operator/curator/protocol shares вручную. Главное — не вычесть одно и то же дважды.

В журнале полезно иметь поля gross service reward, operator fee, protocol fee, net service reward и realized value. Тогда изменение fee можно увидеть отдельно от падения reward rate. Это помогает решить, изменился ли рынок restaking или просто выросла доля посредника.

В stress-тесте liquidity risk считается отдельно от solvency

Позиция может сохранять accounting claim на 10 ETH, но сегодня продаваться только за 9,6 ETH-equivalent. Это liquidity/depeg stress, а не обязательно потеря underlying. И наоборот, slash уменьшает само требование — это capital loss. Смешивание двух эффектов мешает понять, что именно произошло.

Поэтому итоговый отчёт показывает минимум три строки: underlying-equivalent claim, market-exit value и available cash на нужную дату. Такая структура полезна и в сравнении доходных инвестиций, где ликвидность не подменяется расчётной стоимостью.

7. Как проверить restaking-протокол, operator, vault и LRT до внесения средств

Начните с точного объекта и сети

Одинаковое название токена или протокола может существовать в нескольких сетях, обёртках и версиях. Запишите chain ID, точный token contract, vault contract и официальный интерфейс. Не переходите к restaking по ссылке из сообщения или поисковой рекламы без сверки домена и контракта.

Если предлагается новый LRT, сначала проверьте, что именно он представляет и какой контракт выпускает. Проверка смарт-контракта токена полезна как базовый слой, но для restaking дополнительно нужен маршрут underlying и правила withdrawal.

Прочитайте slashing conditions до reward page

До оценки APR найдите описание обязанностей операторов и событий, которые могут привести к penalty. Хорошая документация должна позволять понять, какой сервис инициирует slash, против какого snapshot или allocation он применяется, существуют ли лимиты и review/veto, и как обрабатывается penalized collateral.

Если slashing описан только фразой «для безопасности» без проверяемых условий, risk model неполна. Для раннего сервиса отсутствие live slashing тоже не равно нулевому будущему риску: нужно понимать roadmap и возможность включения новых enforcement правил.

Проверьте полномочия curator, governance и upgrade keys

Vault или LRT может быть управляемым: кто-то выбирает operators, networks, caps и adapters. Это не обязательно плохо — активное управление может ограничивать риск. Но полномочия должны быть видимы. Особое внимание уделяйте возможности добавлять новые сервисы, менять fee, обновлять implementation и переводить средства во внешние стратегии.

Если upgrade контролируется multisig, оцените threshold, timelock и историю изменений. Не нужно пытаться идентифицировать личность каждого signer; важнее понять, что технически может сделать этот контур и есть ли задержка, позволяющая пользователю выйти до существенного изменения.

Operator нужно оценивать как технологического поставщика

Для оператора важны uptime, безопасность ключей, опыт с конкретными сервисами, diversity клиентов, мониторинг и incident response. Большой delegated stake говорит о доверии рынка, но не доказывает будущую безошибочность. Слишком быстрое расширение на десятки AVS может увеличить операционную сложность.

Смотрите на slashing history, публичные incidents, software stack и concentration. Если LRT сам выбирает operators, выясните методику и лимиты на одного оператора. Это одна из причин, почему restaking нельзя анализировать только как токен: реальная услуга выполняется инфраструктурой.

Reward source должен быть документирован отдельно от points

Проверьте, какие rewards уже выплачиваются on-chain, какие зависят от конкретных networks, какие являются protocol incentives, а какие — только points. Для каждого токена сохраните contract, distribution period, claim method, lock-up и fee. Если интерфейс агрегирует всё в одну annualized цифру, восстановите компоненты вручную.

Для сравнения используйте методику APY: одна дата, одна валюта, одинаковая доступность. Не считайте future airdrop как уже заработанный капитал.

Withdrawal process нужно протестировать небольшой суммой

Теоретически понятный withdrawal может иметь несколько on-chain фаз и зависеть от epoch, queue, slashable window или liquidity. Прежде чем масштабировать позицию, пройдите полный цикл на небольшой сумме: deposit → delegation → reward/claim → withdrawal request → final claim.

Тест не гарантирует будущую доступность, но подтверждает, что пользователь понимает адреса, роли и комиссии. Сохраняйте TxID и проверяйте итог независимо от dApp. Если small withdrawal не воспроизводится без поддержки, крупный капитал преждевременен.

Проверьте, какие разрешения остаются у приложений

Restaking и LRT часто требуют ERC-20 approve, permit или взаимодействия с router/vault. Одноразовая операция может оставить большой allowance. Отключение кошелька от сайта не всегда отзывает on-chain разрешение. После завершения маршрута проверьте approvals и удалите ненужные полномочия, если это соответствует архитектуре токена.

Никогда не вводите seed-фразу для «активации restaking», «восстановления rewards» или «подтверждения slashing insurance». Публичный протокол не требует передачи private key оператору или службе поддержки. Подпись должна иметь понятный domain, spender и действие.

Концентрация капитала важнее количества логотипов в списке

Restaking-интерфейс может показывать десятки сервисов и операторов, создавая ощущение широкой диверсификации. Но экономическая концентрация определяется не числом карточек, а тем, какая доля вашего slashable capital зависит от одинаковых операторов, vaults, governance keys, oracle providers и инфраструктуры. Если несколько сервисов используют один и тот же operator set или один curator распределяет большую часть капитала, формально разные названия могут представлять один кластер риска.

Для практической оценки построьте таблицу зависимостей: строки — ваши positions, столбцы — operator, vault, service, cloud/provider, governance и reward token. Повторяющиеся значения показывают скрытую концентрацию. Такой анализ полезнее заявления «я распределил деньги между пятью AVS». Настоящая диверсификация требует различий в экономических и технических причинах потерь, а не только разных интерфейсов.

Restaking не следует путать с кредитным плечом, но capital reuse создаёт похожую иллюзию эффективности

Классическое leverage увеличивает рыночную экспозицию за счёт заёмного капитала или маржинального номинала. Restaking обычно не создаёт отдельный денежный долг пользователя. Однако повторное использование одного collateral для нескольких security commitments может психологически выглядеть так же привлекательно: один капитал «работает несколько раз». В обоих случаях ошибка начинается, когда пользователь видит только дополнительный return и перестаёт отслеживать общий capital-at-risk.

Поэтому не нужно называть restaking скрытым плечом — это технически неточно. Правильнее считать количество и характер обязательств. Если одна и та же доля stake может быть наказана по нескольким правилам, капитал используется интенсивнее. Если protocol изолирует unique stake для каждого сервиса, профиль другой. Сравнивать эти модели следует через конкретную slashable allocation, а не через метафору leverage.

Lifecycle дополнительного сервиса важен не меньше его текущего reward

Новый сервис проходит стадии запуска, bootstrap incentives, набора операторов, изменения технических требований и, возможно, перехода к более зрелой модели fees. На ранней стадии высокая награда может компенсировать отсутствие устойчивого спроса. Позже subsidy снижается, зато появляется реальная выручка. Обратная ситуация тоже возможна: rewards уменьшаются быстрее, чем формируется платящий спрос.

Для restaker полезно хранить версию тезиса: зачем сервису нужна economic security, кто его пользователи, какой объём работы реально выполняют операторы и что должно произойти, чтобы rewards сохранялись без постоянной эмиссии. Если ответ меняется, позицию нужно пересмотреть. Restaking — не пассивная подписка на вечный процент; underlying service имеет собственный product lifecycle.

Новая сеть или AVS не обязаны увеличивать net yield

Operator или curator может добавить ещё один сервис, но дополнительная работа может повысить инфраструктурные расходы, усложнить мониторинг и увеличить slashable obligations. Если новый service reward мал, net result restaker почти не меняется, а operational complexity растёт. Поэтому «больше AVS» не равно «лучше» даже без негативного события.

Проверяйте marginal effect: какая дополнительная награда появилась после подключения сервиса, какая доля stake подверглась его правилам, изменилась ли operator fee и появился ли новый software dependency. Такая маржинальная оценка помогает не оценивать portfolio только по aggregate APY, который скрывает вклад отдельных компонентов.

Мониторинг после входа должен быть событийным, а не только ценовым

Пользователь restaking-позиции должен следить не только за ETH/USD и ценой LRT. Важные события включают изменение operator allocation, подключение новых services, upgrade contracts, изменение withdrawal parameters, новый slashing module, изменение curator, программу rewards, инциденты инфраструктуры и появление большой скидки LRT к underlying. Эти события могут изменить риск без заметного движения базового актива.

Удобный журнал делится на три группы: economic — reward rate, fees, prices; technical — operator status, slash/incident, contract upgrade; liquidity — market depth, redemption queue, claim status. Такой формат помогает понять, почему изменилась позиция, и не объяснять любой минус словом «рынок». Для крупного капитала полезно заранее определить, какие события требуют немедленного пересмотра, а какие только записи в журнал.

Решение об выходе лучше привязать к наблюдаемому событию

Фраза «выйду, если станет опасно» бесполезна без критерия. Выход можно связать с ростом allocation на одного оператора выше собственного лимита, включением непонятного slashing rule, снижением доступного reward ниже уровня, который покрывает дополнительные расходы, ухудшением market depth LRT или изменением governance powers. Другой критерий — календарный: капитал нужен к определённой дате, а withdrawal queue становится несовместимой с ней.

Событийные правила не гарантируют, что выход произойдёт без убытка. Их задача — не дать позиции оставаться бесконечной по инерции. После триггера пользователь всё равно сравнивает market sale, redemption и другие маршруты. Если один путь заблокирован, это не повод автоматически использовать второй без проверки price impact и permissions.

Страхование и safety module не отменяют чтение первичного риска

Некоторые экосистемы предлагают insurance-like coverage, safety modules, redistribution или компенсационные механизмы. Они могут уменьшить последствия определённых событий, но имеют собственные exclusions, caps, governance, источники капитала и порядок выплаты. Нельзя вычитать предполагаемую страховку из slash amount заранее, если право на компенсацию не подтверждено условиями.

В risk report такие механизмы показываются отдельной строкой после gross loss: событие → прямое уменьшение claim → возможное возмещение по конкретному правилу → фактически полученная компенсация. Только последний шаг уменьшает realized loss. Маркетинговое обещание protection не превращается в cash до выполнения условий.

Когда restaking не подходит даже при положительном ожидаемом reward

Restaking может быть рационально исключён, если пользователь не способен проверить operator/service set, если капитал нужен в короткий срок, если позиция уже слишком зависит от одного LST/LRT, если дополнительные rewards малы относительно gas и сложности или если страховой резерв портфеля недостаточен для задержки withdrawal. Неподходящий продукт не становится подходящим из-за временно высокой эмиссии.

Особенно осторожно относитесь к цепочке «LST → restaking → LRT → lending collateral → borrow → farming». Каждый шаг может быть корректен отдельно, но combined system имеет взаимозависимые ликвидационные и liquidity paths. Если невозможно нарисовать схему активов и обязательств на одном листе и объяснить порядок выхода без помощи рекламного интерфейса, сложность уже превышает управляемость позиции.

Минимальный набор данных для повторной проверки через месяц

Чтобы через месяц понять, улучшилась ли стратегия, сохраните snapshot в момент входа: underlying quantity, LST/LRT exchange rate, operator и allocations, список services, slashable limits, reward balances, market price и depth, active approvals, withdrawal timing, fees и фактические TxID. Без исходного snapshot позднее невозможно отличить изменение протокола от ошибки памяти.

Повторная проверка должна использовать те же единицы. Если сначала exposure измерялся в ETH-equivalent, а потом сравнивается только долларовая стоимость LRT, рыночное движение смешивается с accounting. Храните и token units, и chosen valuation currency. Такая двухуровневая запись делает restaking-позицию проверяемой даже после нескольких изменений интерфейса.

Риск-бюджет restaking удобнее задавать в капитале, а не в количестве сервисов

Пользователь может заранее ограничить не число AVS или networks, а максимальную долю портфеля, которая зависит от restaking. Например, базовый ETH stake составляет одну часть долгосрочного портфеля, а только часть этого stake допускается к дополнительным slashable commitments. Такой подход не утверждает, что выбранный процент безопасен; он просто не позволяет интерфейсу автоматически превратить весь staking-баланс в restaking collateral.

Внутри restaking-бюджета можно ввести ещё один лимит на одного operator, curator или service cluster. Если новый продукт требует превысить лимит, это отдельное решение о концентрации, а не техническая кнопка. Особенно важно пересчитывать лимиты после рыночного движения: доля LRT в портфеле может вырасти без нового депозита, если другие активы упали сильнее.

Цена reward-токена и его эмиссия требуют двух разных стрессов

Restaking reward может увеличиваться в токенах именно тогда, когда его денежная цена снижается. Поэтому сценарий «reward rate +50%» нельзя автоматически считать улучшением. Сначала проверьте, почему увеличилась эмиссия: выросла оплачиваемая работа сервиса или программа раздаёт больше токенов для привлечения security. Затем отдельно оцените ликвидность и supply schedule.

В журнале полезно хранить token reward per unit of stake и realized U-value per unit of stake. Первый показывает производительность распределения, второй — экономический результат после цены и исполнения. Если количество rewards растёт, а realized value падает, пользователь видит, что источник изменения находится не в underlying staking, а в экономике incentive token.

Oracle price LRT может отличаться от фактического market exit

Если LRT используется в кредитовании, протокол может оценивать его через oracle, TWAP или иное правило. Эта цена нужна для health factor, но не обязана совпадать с количеством ETH, которое можно получить немедленной продажей большого объёма. При stress ликвидность может ухудшаться быстрее, чем обновляется сглаженная оценка, либо наоборот oracle может резко снизить collateral value.

Поэтому для сложной restaking-позиции существуют как минимум три ценовые серии: accounting underlying-equivalent, oracle valuation в зависимом протоколе и executable market price. Их нельзя подменять одной цифрой. Если collateral близок к liquidation threshold, используйте методы из материала о DeFi-ликвидации и моделируйте изменение обеих ценовых координат.

Ethereum validator и restaking operator могут быть разными участниками

В некоторых маршрутах владелец или базовый validator продолжает выполнять обязанности Ethereum, а дополнительные restaking-задачи делегируются другому оператору. Тогда базовый staking performance и дополнительный service performance зависят от разных субъектов. Это полезно для разделения ответственности, но создаёт ещё одну связь и ещё один набор ключей, обновлений и мониторинга.

При таком устройстве не переносите репутацию одного участника на другого. Хорошая история Ethereum validator не доказывает качество restaking operator, и наоборот. В отчёте reward также разделяется: какая часть связана с base validation, какая — с extra services, кто удерживает fee на каждом уровне и какой участник контролирует выбор дополнительных обязательств.

Изменение набора services должно считаться изменением инвестиционного тезиса

Пользователь мог войти в vault, когда он обеспечивал два понятных сервиса, а через governance или curator allocation получить экспозицию уже к пяти. Даже если contract address доли не изменился, экономический объект стал другим. Поэтому whitelist новых networks, увеличение лимитов и подключение adapters нужно рассматривать как события пересмотра позиции.

Хорошая операционная политика требует уведомления и времени на реакцию, но конкретные гарантии различаются. Не предполагайте, что любой vault обязан дать пользователю возможность выйти до изменения. Сохраняйте governance proposals, timestamps и фактическую дату вступления правил в силу. Если изменение произошло быстрее withdrawal window, это отдельный governance/liquidity risk.

Upgradeability влияет на значение аудита

Аудит конкретной версии contracts не гарантирует свойства будущей реализации, если upgrade authority может заменить logic. Поэтому при чтении отчёта безопасности смотрите commit/version, scope и дату, а затем сравнивайте с текущим implementation. Для proxy-системы важно понимать, кто имеет право upgrade и существует ли timelock.

Не нужно считать immutable contract автоматически безопасным: неизменяемая ошибка тоже остаётся ошибкой. Но immutability и upgradeability создают разные модели контроля. В первом случае основной вопрос — качество исходного кода; во втором добавляются governance keys и process. Restaking часто объединяет несколько contract layers, поэтому version map полезнее одного логотипа аудиторской компании.

Кастодиальный restaking меняет тип риска даже при той же экономической идее

Если restaking доступен через централизованный сервис, пользователь может не взаимодействовать с vault или operator напрямую. Вместо on-chain claim он получает обязательство платформы показать баланс и выполнить вывод. Это добавляет counterparty, custody, compliance и withdrawal risk. Наличие underlying restaking strategy не делает клиентский баланс self-custody.

Сравнивая self-custody и custodial маршруты, не ограничивайтесь APY. Проверьте, кто юридически и технически контролирует актив, можно ли независимо увидеть underlying allocation, что произойдёт при ограничении аккаунта и доступен ли on-chain proof of position. Удобство интерфейса является отдельной характеристикой, а не доказательством сохранности.

Attribution результата нужен не только для отчётности, но и для решения продолжать стратегию

Если итог портфеля вырос, необходимо понять вклад base staking, service rewards, reward-token price, ETH price, LRT discount и fees. Без attribution положительный рынок может скрыть слабый restaking layer. Например, ETH вырос на 25%, а restaking rewards после расходов дали только 0,2% добавки при заметном усложнении. Общая прибыль выглядит сильной, но второй слой может не оправдывать себя.

Обратная ситуация тоже возможна: ETH упал, общая денежная позиция в минусе, но restaking добавил положительную разницу к staking-only control. Тогда нельзя называть сам restaking убыточным только из-за рынка underlying. Контрольная ветка и component attribution позволяют принимать решение по механизму, а не по эмоциональному итогу кошелька.

Сравнивайте restaking с альтернативой простого staking на том же горизонте

Альтернатива должна быть реалистичной. Если пользователь в любом случае собирался держать ETH шесть месяцев, сравнивать restaking с хранением наличных некорректно: основной вопрос — что добавляет второй слой к уже выбранному staking. Если же restaking требует продлить горизонт из-за withdrawal queue, контрольный сценарий должен учитывать, что без restaking капитал мог быть свободен раньше.

В таблице решения полезно хранить две дельты: restaking minus staking-only и restaking minus fully liquid alternative. Первая оценивает эффективность второго слоя, вторая — цену отказа от ликвидности. Они отвечают на разные вопросы и могут иметь разные знаки.

Небольшой reward может быть рациональным только на крупном и устойчивом капитале

Фиксированные расходы claim, withdrawal и monitoring почти не зависят от размера позиции. Поэтому дополнительная доходность на 0,5 ETH может полностью исчезнуть после gas, тогда как на 50 ETH те же операции становятся относительно небольшими. Но крупная сумма одновременно увеличивает абсолютный capital-at-risk. Масштабирование не превращает плохую модель в хорошую — оно меняет соотношение fixed cost и потенциального loss.

Перед увеличением суммы проведите sensitivity: как меняется net add-on yield при разных размерах, сколько стоит один полный цикл выхода и какой абсолютный ущерб создаёт заданный slash. Если рост размера нужен только для того, чтобы «оправдать газ», но абсолютный риск становится неприемлемым, стратегия не соответствует вашему бюджету риска.

Временная доходность от кампании не должна определять постоянную архитектуру портфеля

Рестейкинговые кампании могут запускать повышенные incentives на ограниченный период. Пользователь ради них меняет custody, добавляет LRT, approvals и новый withdrawal route, а после завершения кампании сложная позиция остаётся. Поэтому ещё до входа нужен план обратного упрощения: какие токены вернуть в underlying, какие vault shares погасить и какие разрешения отозвать.

Если post-campaign базовый reward не покрывает текущие costs и monitoring, продолжать позицию только потому, что «она уже настроена», — эффект sunk cost. Решение принимают по будущим денежным потокам и рискам, а не по уже потраченному gas или времени.

Портфельный отчёт должен показывать один underlying только один раз

Особенно легко удвоить капитал в таблице, когда есть ETH, LST, restaking vault shares и LRT. Если каждое представление записать как самостоятельную строку активов, итоговый NAV может превышать реальный капитал в несколько раз. Поэтому сначала строится ownership tree и выбирается конечный объект оценки — например, underlying-equivalent claim по каждой независимой ветке.

Отдельные токены добавляются к NAV только тогда, когда они не являются representation той же позиции: например, реально начисленный reward token, который можно продать независимо. Такой учёт полезен не только для красоты отчёта. Без него невозможно корректно вычислить долю restaking в портфеле, концентрацию у одного оператора и реальный размер потенциального slash.

Лучший результат проверки — иногда отказ от второго слоя

Инвестор не обязан использовать каждый новый механизм, даже если технология интересна. Если документация не позволяет понять slashing, если operator allocation непрозрачна, если LRT market exit слишком тонкий или если withdrawal timing не соответствует плану расходов, отказ сохраняет простую staking-позицию и уменьшает число зависимостей.

Такой вывод особенно важен в обучении: цель статьи не подобрать «лучший restaking», а дать процедуру, при которой пользователь способен доказать, почему дополнительная награда стоит новой сложности именно для его капитала. Если доказать это нельзя, baseline staking или даже простой self-custody остаётся полноценной альтернативой.

Контрольная проверка перед любой реальной суммой должна занимать больше времени, чем само нажатие кнопки Restake. Пользователь должен уметь назвать underlying, operator, service set, slashable amount, reward source, fee, withdrawal route и сценарий срочного выхода. Если хотя бы одно из этих полей неизвестно, сначала уменьшают сложность позиции и возвращаются к документации, а не компенсируют пробел большей ожидаемой доходностью.

8. Учебные задачи: проверяем restaking вручную

Задача 1. Отделите базовый staking reward от restaking reward

Условие. 10 ETH за период получили 0,20 ETH базового staking reward и токены дополнительного сервиса стоимостью 90 U после продажи. Цена ETH на дату сравнения — 2 500 U. Сколько добавил именно restaking слой до дополнительных costs?

Разбор. Базовые 0,20 ETH принадлежат staking-only control. Restaking layer добавил 90 U. Нельзя назвать весь результат 0,20 ETH × 2 500 + 90 = 590 U «доходом restaking»: 500 U возникли бы и без второго слоя.

Задача 2. Учтите operator fee только один раз

Условие. Service начислил gross 500 R. Operator получает 12%, а интерфейс после распределения показывает 440 R пользователю. Нужно ли дополнительно вычитать 60 R?

Разбор. Нет. 500 × (1 − 0,12) = 440 R. Если интерфейс уже показывает net distribution, повторный вычет создаст двойной счёт. В журнале сохраняют gross, fee и net отдельно.

Задача 3. Сравните slash и дополнительную награду

Условие. 8 ETH restaked. Дополнительные rewards реализованы на 160 U. Затем slash уменьшил claim на 0,08 ETH. ETH стоит 2 400 U.

Разбор. Потеря underlying по текущей оценке = 0,08 × 2 400 = 192 U. Добавочный слой дал 160 − 192 = −32 U относительно staking-only, до прочих fees. Положительный reward не компенсировал loss капитала.

Задача 4. Market exit LRT и redemption — разные ответы

Условие. LRT представляет 5 ETH-equivalent. Немедленная продажа даёт 0,97 ETH на единицу эквивалента после price impact, redemption обещает 5 ETH через очередь.

Разбор. Market exit = 4,85 ETH сегодня. Redemption = 5 ETH позже при выполнении условий. Нельзя выбрать «5 ETH лучше» без срока и потребности в ликвидности. Это две разные временные позиции.

Задача 5. Заблокированный reward не равен доступному

Условие. Начислено 1 000 R, из них claimable 600, 400 заблокированы. Исполнимая цена 0,25 U, продажа claimable части стоит 5 U.

Разбор. Доступный денежный результат сегодня = 600 × 0,25 − 5 = 145 U. Заблокированные 400 R показывают отдельно как будущую позицию, а не добавляют ещё 100 U в текущие деньги.

Задача 6. Найдите break-even дополнительных costs

Условие. Restaking добавляет четыре операции сверх staking-only общей стоимостью 36 U. За период получено 120 R. Какая минимальная цена R нужна только для покрытия этих дополнительных costs без учёта риска?

Разбор. 36 / 120 = 0,30 U за R. Это лишь break-even расходов. Он ничего не говорит о slashing, underlying price или ликвидности.

Задача 7. Проверьте double counting LRT

Условие. 10 ETH внесены в restaking и получены LRT, которые представляют ту же позицию. Интерфейс показывает underlying-equivalent 10,1 ETH. Можно ли считать активы как 10,1 ETH + стоимость LRT?

Разбор. Нет, если LRT является представлением того же требования. Нужно выбрать один уровень учёта — например, LRT × redemption rate или underlying-equivalent claim — и отдельно учитывать только действительно внешние rewards.

Задача 8. Совместный stress лучше одной красивой цифры

Условие. Позиция имеет 10,2 ETH-equivalent, но после slash остаётся 10,0 ETH. ETH падает с 3 000 до 2 500 U, а срочная продажа LRT даёт ещё 3% скидки. Дополнительный реализованный reward — 120 U.

Разбор. Underlying value после slash = 25 000 U. Срочный LRT exit ≈ 24 250 U. После добавления 120 U = 24 370 U. Сравнивать нужно с control и исходным капиталом; отдельно видно влияние slash, рынка, скидки и reward.

9. Итоговый практикум: от staking-only до restaking, slash и срочного выхода

Шаг 1. Задаём контрольную staking-позицию

Учебный инвестор начинает с 10 ETH по условной цене 3 000 U за ETH. Исходная денежная оценка — 30 000 U. За 180 дней базовый staking gross reward по заданной учебной модели составляет 0,24 ETH. Комиссия базового оператора равна 10% reward, поэтому net staking reward = 0,24 − 0,024 = 0,216 ETH. Контрольная staking-only позиция перед рыночной переоценкой содержит 10,216 ETH.

На конец периода ETH стоит условные 2 700 U. Денежная оценка staking-only control = 10,216 × 2 700 = 27 583,20 U. Относительно исходных 30 000 U это убыток 2 416,80 U, несмотря на положительный staking reward. Эта ветка нужна как baseline: рынок ETH и базовый staking не относятся к добавочной ценности restaking.

Шаг 2. Добавляем restaking rewards

Restaking-ветка использует тот же базовый stake. Дополнительный сервис начислил 300 токенов R, но к дате сравнения доступны 80%, то есть 240 R. Исполнимая цена продажи — 0,40 U за R. Комиссия и gas для claim + продажи вместе составляют 4 U. Доступный restaking reward = 240 × 0,40 − 4 = 92 U. Остальные 60 R заблокированы и в доступный итог не включаются.

Если никаких дополнительных потерь нет, restaking-ветка на ту же дату стоит 27 583,20 + 92 = 27 675,20 U. Она превосходит staking-only на 92 U. Это корректный добавочный gross/net эффект второго слоя в заданной модели. Нельзя говорить, что restaking дал 27 675 U дохода: почти вся стоимость — исходный ETH и базовый staking.

Шаг 3. Добавляем отдельный slashing-сценарий

Теперь рассматривается отдельный stress-сценарий: дополнительный сервис приводит к уменьшению underlying claim на 0,15 ETH. Мы не назначаем этому событию вероятность и не утверждаем, что конкретный протокол применяет такой размер. Это просто проверка последствия. После slash количество ETH-equivalent = 10,216 − 0,15 = 10,066 ETH.

При цене ETH 2 700 U стоимость underlying после slash = 10,066 × 2 700 = 27 178,20 U. После доступного reward 92 U итог restaking-ветки = 27 270,20 U. Относительно staking-only control она хуже на 313 U: потеря 0,15 ETH стоит 405 U, из которых reward компенсировал только 92 U.

Шаг 4. Проверяем срочный выход через LRT

Допустим, позиция представлена LRT, а срочная продажа на рынке в stress-сценарии даёт ещё 3% скидки к underlying-equivalent после всех price impact внутри заданной модели. Тогда рыночная стоимость claim 27 178,20 U превращается примерно в 26 362,85 U. После доступного reward 92 U пользователь получает около 26 454,85 U.

Скидка LRT здесь не добавляется как отдельный «slash». Это liquidity/depeg effect срочного выхода. Если пользователь способен дождаться redemption и правила протокола позволяют получить underlying-equivalent без этой скидки, итог может быть другим. Поэтому market exit и redemption должны оставаться двумя сценариями, а не смешиваться в одном результате.

Шаг 5. Сравниваем четыре результата

Итоговая таблица показывает, почему одна цифра APY недостаточна. Staking-only заканчивает период на 27 583,20 U. Restaking без дополнительной потери — 27 675,20 U. Restaking со slash — 27 270,20 U. Та же позиция со slash и срочной продажей LRT с 3% скидкой — около 26 454,85 U. Все четыре ветки используют одинаковую цену ETH на конец периода.

Ключевой вопрос инвестора — не «сколько процентов добавляет restaking», а какие условия должны выполниться, чтобы дополнительные 92 U оправдали новый набор зависимостей. Ответ зависит от суммы, горизонта, operator/service allocation, условий slashing, liquidity и целей самого пользователя. На другой позиции цифры будут другими, но порядок проверки остаётся тем же.

Шаг 6. Проверяем доступность, а не только стоимость

Предположим дополнительно, что во время withdrawal доступно только 0,8 ETH свободного резерва, а остальная позиция находится в очереди. При цене 2 700 U это 2 160 U ликвидного резерва. Если через три дня нужно выполнить обязательство на 5 000 U, нехватка составляет 2 840 U, даже если расчётная стоимость restaking-позиции намного выше.

Этот пример показывает разницу между solvency и liquidity. Позиция может иметь положительную расчётную стоимость и одновременно не обеспечивать нужную дату платежа. Поэтому в карточке restaking всегда храните отдельные поля «total claim», «market exit now», «claimable now» и «expected withdrawal finalization».

Шаг 7. Что должно остаться в журнале после закрытия

После завершения стратегии сохраняются: исходный stake, net base rewards, service rewards, operator/protocol fees, slash events, withdrawal request, final claim, LRT swaps, фактические fills, remaining locked rewards и остаточные approvals. Внешние пополнения для спасения позиции отмечаются как capital flow, а не как прибыль стратегии.

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

Шаг 8. Итоговая формула принятия решения

Упрощённая методика выглядит так: staking-only control → добавить доступные restaking rewards → вычесть дополнительные fees → применить отдельные capital-loss scenarios → проверить market-exit discount → проверить timing и доступность → только затем сравнивать варианты. Если стратегия выглядит привлекательной только без stress или только при высокой цене reward token, это слабая конструкция.

Restaking полезен как инфраструктурная идея и может создавать реальную оплату за дополнительную экономическую безопасность. Но для инвестора его ценность появляется только тогда, когда новый reward измерим, обязанности понятны, slashing ограничен и проверяем, а выход соответствует горизонту. Необходимость отказаться от restaking при непонятной модели — нормальное решение, а не упущенная гарантированная доходность.