Интеграция с Kelp DAO: жидкий рестейкинг на EigenLayer

Почему интеграция Kelp DAO ломается на выводе средств

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

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

Операционная цена зависшей позиции выше, чем кажется: учётные системы держат её как ликвидный резерв, хотя закрыть её к нужной дате нельзя. Срочный выход через вторичный рынок означает дисконт к номиналу, а начисленный за время ожидания доход этот дисконт не покрывает. Для казначейства возникает разрыв между цифрой в отчёте и реально доступными средствами.

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

Что даёт жидкий рестейкинг помимо доходности

Жидкий рестейкинг ценен не сам по себе: он позволяет держать позицию в защите сети EigenLayer и одновременно оставлять те же активы в обороте. При подключении через Kelp DAO заложенный актив превращается в токен-квитанцию, которую можно использовать дальше — в залоге, в пулах ликвидности или как обеспечение. Ниже — эффекты, которые видно в отчётности, а не в презентации.

• Оборот активов не прерывается. Доходность на заложенные активы начисляется, а капитал не простаивает на весь срок блокировки — он продолжает работать в других стратегиях.
• Ликвидность позиции сохраняется. Право на долю в стейкинге обращается как обычный токен: часть позиции можно вывести, не выходя из рестейкинга целиком.
• Учёт рестейкинг-позиций сходится автоматически. Начисления, ре-делегирование и комиссии собираются из одного источника, поэтому сверки с ручными выгрузками уходят из регулярных задач.
• Снижение ручных операций. Заявки на вывод и распределение наград идут по регламенту и расписанию, а не по письму от оператора.
• Предсказуемый режим выводов. Очереди и лимиты известны заранее — незапланированные сбои переходят в понятный срок ожидания.

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

Схемы подключения: прямой контур, обёртка, гибрид

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

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

Порядок интеграции: от аудита позиций до передачи

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

1. Аудит позиций. Сводим, что и где размещено: внесённые активы, полученные расписки, начисленные вознаграждения, незакрытые заявки на вывод. Сверяем кошельки с состоянием Kelp DAO — расхождение в доли процента после первого перераспределения становится неучтённым остатком.
2. Схема потоков активов. Описываем маршрут каждого актива: откуда приходит, где учитывается, в каком виде возвращается при выводе. Схема сразу показывает точки, где нужна ручная подпись, а где достаточно автоматики.
3. Настройка ролей доступа. Разделяем права на чтение позиций, управление и вывод; крупные операции уводим за многоподписной контур. Право на вывод не выдаём тем же ключам, что выполняют регулярные действия.
4. Проверка на малых объёмах. Прогоняем полный цикл — внесение, расписка, начисление, частичный вывод. Здесь видны округления и сетевые издержки, а рассинхрон между нашим учётом и данными протокола ловится до того, как в контур попадут рабочие позиции.
5. Приёмка контура. Сверяем контрольные показатели: суммы позиций, начисленные вознаграждения, время реакции на изменение состояния. Принимаем не «работает», а с числами — доля путей под проверками и отсутствие ручных шагов в регулярном цикле.
6. Передача. Отдаём конфигурации, схему, регламенты вывода и восстановления доступа, инструкции для дежурной смены. Отдельно фиксируем сценарий отката: как вернуть активы в исходный вид.

Что остаётся у команды после внедрения

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

• Схемы интеграции — как движутся средства между кастодиальным кошельком, контрактами рестейкинга и учётным слоем: где выпускается производный токен, где фиксируется доля и в какой точке возможен разрыв.
• Конфигурации контура — адреса контрактов по сетям, параметры узлов, лимиты на одну операцию и суточный объём, отдельные наборы для тестового и рабочего контура.
• Политики доступа — матрица ролей: кто готовит операцию, кто подтверждает, кто меняет лимиты; кошелёк с несколькими подписями и операторский ключ с урезанными правами.
• Регламент вывода — порядок выхода из позиции с учётом очереди и периода разблокировки, с контрольными точками, где операцию можно остановить без потери доли.
• Порядок восстановления позиции — действия при зависшей транзакции, расхождении баланса или остановке валидатора: точки входа, приоритет шагов, кому эскалировать.
• Инструкции для команды — разбор типовых операций с ожидаемым результатом на каждом шаге, чек-лист приёмки после изменений и таблица частых ошибок.

Комплект остаётся у заказчика и обновляется по мере роста позиции.

Кейс: рестейкинг-контур для оператора узлов

Оператор узлов держал рестейк-позицию в Kelp DAO: rsETH распределён по операторам EigenLayer, вознаграждения начисляются, но выход и перераспределение доли инженеры проводили вручную. Заявка на выход собиралась скриптом, очередь сверялась глазами, подписи — в мультиподписи, а неподтвердившаяся транзакция уходила повторно тем же телом.

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

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

После: идемпотентный контур и метрики

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

• Время вывода средств: с трёх суток до десятков минут.
• Устранённый класс отказов — «дублирующая заявка на выход»: исчез полностью.
• Расхождение реестра и позиции в сети: с единичных случаев в месяц до нуля.
• Разбор инцидента: по журналу за минуты вместо переписки и ручной сверки.

Чем жидкий рестейкинг отличается от обычного стейкинга

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

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

Отсюда второй слой — рестейкинг, когда ту же позицию закладывают повторно в сторонние сервисы. Kelp DAO работает как обёртка над такой схемой: распределяет позицию между операторами и выдаёт участнику квитанцию, которая и становится его ликвидным инструментом.

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

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

Частые технические вопросы перед стартом работ

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

Что происходит при слэшинге?

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

Как восстанавливается позиция после сбоя?

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

Совместимо ли это с уже развёрнутым контуром?

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

Обсудим задачу и вернёмся с планом работ

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

• Активы и сети. Какие активы готовы принимать в рестейкинг, в какой сети работает продукт, нужен ли вывод позиции обратно в ликвидную форму и в каком виде.
• Сценарии использования. Депозит, вывод, начисление и реклейм вознаграждений, отражение доли в пуле — что из этого нужно в интерфейсе, что в отчётности, а что закрывается вручную.
• Роли и доступы. Кто подписывает операции, есть ли кастодиальный или некастодиальный сценарий, нужны ли лимиты, мультиподпись и разграничение прав между сотрудниками.
• Учёт и отчётность. Как позиция должна отражаться во внутреннем балансе, нужна ли переоценка доли и выгрузка данных для бухгалтерии или комплаенса.
• Ограничения и требования. Юрисдикции пользователей, требования комплаенса, класс отказов, который обязательно нужно обработать, и то, что делать нельзя.
• Текущее состояние. Какие наработки уже есть, что с доступами и кодом, кто на вашей стороне принимает результат и подписывает приёмку.
• Сроки и приоритеты. Что нужно к запуску, а что можно вынести вторым этапом без потери ценности.

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