Когда человек впервые слышит про liquid staking, это часто звучит почти магически: «застейкал ETH, получил токен-заменитель, и теперь этот же капитал можно использовать дальше в DeFi».
Вторая волна усложняет картину ещё сильнее: restaking обещает, что тот же базовый стейкинговый актив можно использовать как экономическую безопасность для дополнительных сервисов и сетей.
Но если убрать маркетинговый слой, механика довольно земная.
Есть базовый актив. Есть доходность от стейкинга. Есть производный токен, который отражает право на этот актив и связанные с ним денежные потоки. И есть большой операционный слой вокруг депозитов, делегации, учёта, очередей вывода, price feeds, risk checks и автоматизации.
Именно поэтому liquid staking и restaking интересны не только как инвестиционный инструмент, но и как инженерный класс DeFi-протоколов. Здесь хорошо видно, как из одного довольно понятного базового процесса вырастает целая архитектура: контракты, оракулы, индексаторы, очереди, keepers, алерты, risk limits и operator tooling.
Ниже — практический разбор без рекламы: какие игроки есть на рынке, как это работает простыми словами, как двигаются деньги, где основные риски и как собрать похожий прототип или MVP.
Что это за класс протоколов и кто есть на рынке
Liquid staking protocols
Liquid staking protocol принимает базовый актив, размещает его в стейкинге и выпускает пользователю ликвидный токен-представитель позиции.
Самые известные примеры на рынке:
- Lido — один из самых заметных игроков в liquid staking для Ethereum, где пользователь получает stETH;
- Rocket Pool — модель с сильным акцентом на более распределённую операторскую структуру и rETH;
- Frax Ether / sfrxETH — сочетание liquid staking и собственной DeFi-экономики вокруг токена;
- различные LST-модели в экосистемах Solana, Cosmos и других сетей, где идея та же: застейканный актив становится ликвидным представлением, пригодным для дальнейшего использования.
Restaking и LRT
Restaking — следующий слой. Он пытается использовать уже застейканный или liquid-staked актив как базу для дополнительной экономической безопасности.
На рынке эта тема обычно ассоциируется с:
- EigenLayer как одним из самых обсуждаемых restaking-layer подходов;
- ether.fi, Renzo, Kelp, Puffer и другими проектами, которые строят продукты вокруг restaked ETH, LRT и делегации в AVS-подобные модели;
- инфраструктурными сервисами, которые связывают стейкинг, валидаторские операции, учёт reward-потоков и пользовательский DeFi-интерфейс.
Если упростить совсем сильно:
- LST — это ликвидная обёртка над застейканным активом;
- LRT — это токенизированная обёртка над liquid staking / restaking-позицией, часто с дополнительным уровнем риска и более сложной экономикой.
Как liquid staking работает простыми словами
Представим пользователя с 10 ETH.
В классическом staking-сценарии он отправляет ETH в стейкинг и фактически «запирает» капитал в модели, где ликвидность ограничена правилами выхода, очередями и инфраструктурой валидаторов.
Liquid staking меняет UX и экономику.
Путь обычно выглядит так:
deposit ETH -> protocol stakes via validator set -> protocol mints LST -> user holds/trades/uses LST in DeFi
То есть:
- пользователь приносит ETH в протокол;
- протокол распределяет депозит в валидаторскую инфраструктуру;
- пользователю выпускается токен вроде stETH или rETH;
- этот токен можно держать, использовать как collateral, добавлять в liquidity pool или применять в других DeFi-стратегиях.
Смысл в том, что базовый актив продолжает работать в стейкинге, а пользователь не теряет полностью ликвидность на уровне интерфейса портфеля.
Откуда берётся доходность
Доходность в liquid staking в основе идёт из staking rewards базовой сети.
Протокол:
- агрегирует депозиты;
- распределяет их по валидаторам или операторам;
- получает staking rewards;
- удерживает комиссию протокола и операторов;
- отражает оставшийся экономический результат в цене или балансе liquid token.
Дальше всё зависит от конкретной модели токена.
Rebase vs exchange rate
Обычно используются две базовые модели.
Rebase-модель
Баланс токена у пользователя растёт сам по себе.
Например, вчера было 10 stToken, сегодня 10.02 stToken. Количество токенов меняется, потому что награда распределяется через rebasing.
Exchange-rate модель
Количество токенов у пользователя не меняется, но растёт их внутренняя стоимость относительно базового актива.
Например, у пользователя всё ещё 10 rToken, но теперь каждый такой токен можно обменять не на 1 ETH, а условно на 1.002 ETH.
Для пользователя разница кажется косметической, но для интеграций, индексации, учёта и налоговой логики это очень важный архитектурный выбор.
Как работает restaking простыми словами
Restaking добавляет ещё один этаж риска и доходности.
Базовая идея такая:
- у пользователя уже есть ETH или LST;
- он отправляет актив в restaking-протокол;
- этот актив становится частью дополнительного security layer для внешних сервисов;
- пользователь рассчитывает получать не только базовую staking доходность, но и дополнительные reward-потоки.
Если совсем по-человечески, liquid staking говорит: «дай нам актив, и мы дадим ликвидную форму твоего staking-права».
Restaking говорит: «твой staking-капитал может обеспечивать не только базовую сеть, но и дополнительные сервисы — за это ты потенциально получишь ещё одну доходность, но и ещё один класс рисков».
Где двигаются деньги
Деньги и права требований обычно движутся по нескольким уровням:
- пользовательский депозит;
- staking layer / validator set;
- liquid token layer;
- restaking layer, если он есть;
- DeFi-интеграции, где LST или LRT используются как collateral или ликвидность;
- withdrawal / exit layer, где всё это должно сойтись обратно в понятный redeem flow.
Чем больше слоёв, тем выше требования к учёту и риск-контролю.
Основные компоненты архитектуры
Если смотреть на liquid staking / restaking как на инженерную систему, почти всегда появляются следующие части.
1. Deposit contract
Принимает базовый актив от пользователей, ведёт первичный учёт и инициирует mint производного токена.
2. Token contract
Выпускает LST или LRT:
- ERC-20 логика;
- rebase или exchange-rate модель;
- mint / burn правила;
- учёт комиссий.
3. Validator / operator management layer
Где-то должна жить логика, которая определяет:
- каким валидаторам или операторам идут новые депозиты;
- как распределяется stake;
- какие лимиты на одного оператора;
- как отключать проблемных операторов.
4. Accounting and NAV layer
Протоколу нужно считать:
- сколько базового актива реально контролируется;
- сколько активов находится в pending deposit или pending withdrawal;
- сколько reward уже заработано;
- какая цена или redeem ratio у производного токена;
- какие комиссии удержаны.
5. Withdrawal queue
Это один из самых недооценённых компонентов.
Пользователь хочет думать, что LST или LRT всегда ликвиден. Но реальная ликвидность не бесплатна. Если много людей одновременно хотят выйти в базовый актив, протоколу нужен механизм:
- очереди вывода;
- батчинга заявок;
- частичного исполнения;
- расчёта доступной ликвидности;
- unwind-процедур из валидаторского или restaking-слоя.
6. Oracle / pricing layer
Если LST или LRT используется как collateral в DeFi, нужно аккуратно определять его цену и состояние.
Протоколы и интеграции смотрят на:
- exchange rate;
- secondary market price;
- discount/premium к базовому активу;
- условия ликвидности в пулах;
- расхождение между внутренней стоимостью и рыночной ценой.
7. Automation / keeper layer
Кто-то должен запускать операционные действия:
- распределение новых депозитов по операторам;
- rebalance между операторами или vault-слоями;
- обновление accounting snapshots;
- обработку withdrawal queue;
- claim и распределение reward;
- emergency responses, если какой-то оператор или интеграция деградирует.
Какие trade-offs и риски тут главные
Liquid staking и restaking часто продаются через слово yield, но инженерно важнее понимать именно риск-профиль.
1. Slashing risk
Если валидатор нарушает правила сети или работает плохо, часть stake может быть потеряна.
Для пользователя это не «где-то там ошибка оператора», а прямой риск для backing токена.
2. Smart contract risk
Даже если базовый staking-слой надёжен, у пользователя появляется дополнительный смарт-контрактный риск:
- mint/burn логика;
- withdrawal queue;
- accounting ошибки;
- governance и upgrade механизмы.
3. Liquidity mismatch
Самая практическая проблема: токен выглядит ликвидным, а базовый актив выводится медленно.
Если secondary market проседает или очередь на выход растёт, пользователь внезапно понимает, что «1 токен не всегда мгновенно равен 1 ETH по хорошей цене».
4. Oracle and collateral risk
Если LST/LRT используется как collateral в lending или margin-системах, критично важно:
- как считается цена;
- учитывается ли discount к NAV;
- что происходит при сильном отклонении secondary market price от внутренней оценки.
5. Restaking contagion risk
Restaking добавляет риск заражения между слоями.
Если базовый staking-продукт был относительно понятным, то restaking создаёт дополнительные вопросы:
- кто именно получает право на дополнительную доходность;
- кто несёт риск дополнительных санкций или потери доходности;
- насколько прозрачен механизм делегации и распределения reward;
- что будет, если один из внешних сервисов или операторских маршрутов станет проблемным.
6. Governance and key management risk
У протокола почти всегда есть чувствительные операции:
- смена операторов;
- изменение fee-параметров;
- emergency pause;
- обновление withdrawal logic;
- изменение лимитов на маршрутизацию капитала.
И здесь очень уместен инженерный угол, который регулярно всплывает и в более широких HN-обсуждениях вокруг инфраструктуры: долгоживущие ключи и неограниченные права почти всегда рано или поздно становятся операционной проблемой. Для staking и restaking это особенно чувствительно, потому что ошибка на уровне прав доступа быстро превращается в финансовый и репутационный ущерб.
Как сделать похожий прототип или MVP
Если задача — не построить сразу «новый Lido», а собрать понятный demo/MVP, то лучше резко упростить дизайн.
Хороший MVP для liquid staking должен доказывать три вещи:
- пользователь может внести базовый актив и получить производный токен;
- система умеет учитывать backing и менять redeem ratio;
- вывод и базовый automation flow работают предсказуемо.
MVP-границы, которые разумно взять
Для демо достаточно:
- одна сеть, лучше EVM testnet;
- один базовый актив;
- один synthetic LST-токен;
- упрощённый staking adapter вместо реального валидаторского back-end;
- централизованный operator/keeper слой для управления очередями и accounting;
- минимальный UI для deposit / redeem / queue status.
Базовый набор компонентов
Контракты
-
Vault / Depository contract
- принимает базовый актив;
- mint-ит LST;
- хранит информацию о pending withdrawal;
- вызывает adapter-слой.
-
LST token contract
- ERC-20;
- либо exchange-rate модель, либо rebasing;
- role-based mint/burn.
-
Staking adapter
- в demo может быть мок-контрактом;
- имитирует доходность и задержки вывода;
- позже может быть заменён на реальную интеграцию.
-
Withdrawal queue contract или модуль
- регистрирует заявки;
- батчит погашение;
- хранит статус
requested -> claimable -> claimed.
-
Risk / admin module
- pause;
- лимиты на дневной mint/redeem;
- allowlist операторов;
- max deviation checks.
Индексация и данные
Нужен индексатор или ingestion service, который собирает:
- события deposit/redeem;
- текущий total backing;
- состояние withdrawal queue;
- effective exchange rate;
- operator allocation;
- ошибки автоматических джобов.
Для MVP можно обойтись:
- Postgres;
- простой indexer на Go, Python или Node;
- периодическим reconciler job.
Бэкенд-джобы
Минимально полезный набор:
allocation_job— распределяет свежие депозиты в adapter;accounting_job— пересчитывает backing и current rate;withdrawal_processor— продвигает очередь вывода;alert_job— сигналит о large queue, stale accounting, rate anomaly;reconciliation_job— сверяет onchain и внутренний учёт.
Оракулы и pricing
Для MVP не обязательно поднимать полноценный oracle network, но нужно хотя бы:
- публиковать текущий exchange rate;
- хранить timestamp последнего обновления;
- проверять, что UI и интеграции не используют устаревшие данные;
- в проде — отделять внутреннюю стоимость токена от secondary market price.
UI
Для демо хватит пяти экранов или блоков:
- deposit;
- balance и текущий rate;
- submit withdrawal;
- queue / claim status;
- protocol status: backing, pending withdrawals, last accounting update.
Как выглядел бы MVP restaking-протокола
Restaking-MVP лучше строить только после базового LST-слоя.
Упрощённый поток может быть таким:
user deposits LST -> protocol mints LRT -> protocol tracks delegated security buckets -> rewards/penalties reflected in exchange rate
Для демо не нужно реализовывать настоящий сложный AVS-мир. Достаточно симулировать:
- несколько security buckets;
- разную reward rate по ним;
- отдельный penalty event;
- лимиты на аллокацию;
- управление очередью выхода.
Дополнительные компоненты для restaking MVP
- Delegation manager — хранит, куда распределён restaked backing;
- Penalty simulator / slashing model — имитирует негативные события;
- Multi-source accounting — считает доходность и убытки по разным направлениям;
- Risk score engine — ограничивает аллокацию в слишком рискованные buckets.
Что можно автоматизировать поверх такого протокола
Вот здесь как раз появляется реальный прикладной automation layer.
1. Allocation automation
Если в систему приходят новые депозиты, не хочется каждый раз вручную решать, как их распределить.
Automation может:
- раскладывать капитал по операторам по лимитам;
- не давать одному оператору получить слишком большую долю;
- временно исключать деградировавших операторов.
2. Withdrawal queue management
Система может автоматически:
- батчить заявки;
- оценивать доступную ликвидность;
- приоритизировать частичный unwind;
- оповещать, если очередь растёт быстрее нормы.
3. Monitoring и alerting
Критично мониторить:
- stale accounting updates;
- отклонение market price от internal rate;
- рост discount у LST/LRT;
- ошибки allocation jobs;
- превышение operator concentration limit;
- всплеск pending withdrawals.
4. Risk controls перед исполнением
Перед любым автоматическим действием полезно проверять:
- не превышен ли лимит на одну операцию;
- не находится ли протокол в degraded mode;
- актуальны ли входные данные;
- не конфликтует ли новый job с уже идущим workflow.
5. Reconciliation и audit trail
В зрелой системе важно не просто что-то сделать, а потом доказать:
- почему решение было принято;
- на каких данных;
- каким оператором или сервисом оно исполнено;
- как изменилось состояние после транзакции.
Это превращает «ботов вокруг staking-протокола» в нормальный control plane.
Практическая архитектура automation layer
Если собрать это в понятную схему, получается такой набор:
- State collector — тянет onchain balances, queue state, allocation state и rate data.
- Policy engine — хранит лимиты по операторам, суточные cap, emergency флаги, max queue thresholds.
- Job orchestrator — запускает accounting, allocation, withdrawal processing и reconciliation workflows.
- Execution gateway — единственная точка, которая отправляет чувствительные транзакции.
- Alerting layer — Telegram/Slack/email события по отклонениям и сбоям.
- Operator dashboard — показывает backing, pending queue, allocation drift, failed jobs и manual override actions.
Для Alex-подобной практичной продуктовой команды ценность тут не в красивом токене как таковом, а в том, что система становится управляемой: видно, где риск, где очередь, где завис job и где нужен ручной intervention.
Где такой MVP полезен на практике
Даже если не запускать публичный протокол, похожий MVP может быть полезен как:
- внутренняя demo-система для команды, которая хочет понять механику liquid staking;
- sandbox для проверки DeFi-integrations с LST/LRT collateral;
- учебный прототип для treasury automation вокруг staking-активов;
- foundation для сервиса мониторинга, risk controls и operator tooling вокруг существующих staking-продуктов.
Главное, что стоит запомнить
Liquid staking — это способ сделать застейканный актив ликвидным и пригодным для дальнейшего использования в DeFi.
Restaking — это попытка заставить тот же капитал обеспечивать дополнительные сервисы и получать за это ещё одну доходность, но вместе с ней и новый слой риска.
Если упростить механику до сути, получается следующее:
- пользователь вносит базовый актив;
- протокол стейкает его через операторскую инфраструктуру;
- выпускается LST или LRT;
- учёт и withdrawal queue поддерживают обещание redeemability;
- automation layer следит за аллокацией, лимитами, очередями, обновлением rate и сбоями;
- риск лежит не только в доходности, но и в операционной дисциплине всей системы.
Именно поэтому liquid staking и restaking — это хороший пример DeFi-класса, где value рождается не только в смарт-контрактах, но и в том, насколько хорошо построены monitoring, orchestration, key management, policy checks и recovery paths вокруг них.