Чому інтеграція Kelp DAO ламається на виведенні коштів
Позиція в ліквідному рестейкінгу відкрита, активи задіяні й приносять дохід, а виведення не проходить: заявка стає в чергу виходу й висить без руху.
В інтерфейсі баланс відображається, але забрати його не можна — рестейкінг-сертифікат залишається вимогою на базовий актив, доки той не звільниться зі стейкінгу.
Причина в тому, що інтеграція Kelp DAO спирається одразу на дві неузгоджені черги: вихід із протоколу ліквідного рестейкінгу та вихід валідаторів із мережі, де розміщено базовий актив.
Перша закривається за заявками, друга — за внутрішніми циклами й лімітами на кількість виходів на добу, і за перевантаження обидві розтягуються на дні.
Якщо сертифікат устиг піти на вторинний ринок або був прийнятий у заставу, на момент виходу тримач вимоги й адреса, що подала заявку, уже не збігаються.
Операційна ціна завислої позиції вища, ніж здається: облікові системи тримають її як ліквідний резерв, хоча закрити її до потрібної дати не можна. Терміновий вихід через вторинний ринок означає дисконт до номіналу, а нарахований за час очікування дохід цей дисконт не покриває. Для казначейства виникає розрив між цифрою у звіті та реально доступними коштами.
Розбираємо, як це закривається: які перевірки ставити до відкриття позиції, як вести чергу виведення й що моніторити, щоб зависла позиція виявлялася в перші години, а не в момент, коли кошти знадобилися.
Що дає ліквідний рестейкінг крім дохідності
Ліквідний рестейкінг цінний не сам собою: він дозволяє тримати позицію в захисті мережі EigenLayer і водночас залишати ті самі активи в обігу.
Під час підключення через Kelp DAO закладений актив перетворюється на токен-квитанцію, яку можна використовувати далі — у заставі, у пулах ліквідності або як забезпечення. Нижче — ефекти, які видно у звітності, а не в презентації.
- Обіг активів не переривається. Дохідність на закладені активи нараховується, а капітал не простоює весь строк блокування — він продовжує працювати в інших стратегіях.
- Ліквідність позиції зберігається. Право на частку в стейкінгу обертається як звичайний токен: частину позиції можна вивести, не виходячи з рестейкінгу повністю.
- Облік рестейкінг-позицій сходиться автоматично. Нарахування, ре-делегування та комісії збираються з одного джерела, тому звірки з ручними вивантаженнями зникають з регулярних завдань.
- Зменшення ручних операцій. Заявки на виведення та розподіл нагород ідуть за регламентом і розкладом, а не за листом від оператора.
- Передбачуваний режим виведень. Черги та ліміти відомі заздалегідь — незаплановані збої переходять у зрозумілий строк очікування.
Перевіряємо це на етапі підключення: спочатку тестова позиція на мінімальному обсязі, потім звірка даних із реєстром, і лише потім виведення решти активів. Так ефект видно до того, як під рестейкінг піде весь портфель.
Схеми підключення: прямий контур, обгортка, гібрид
Інтеграція Kelp DAO впирається не в сам протокол, а у вибір схеми підключення: вона визначає, де проходить межа довіри й хто тримає ключі від позиції в рестейкінгу.
Прямий контур, контракт-обгортка та гібрид закривають різні профілі інфраструктури — від «уже є відповідальне зберігання та облік часток» до «потрібен свій шар обліку поверх зовнішнього».
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Прямий контур | Облік часток і ключі вже під контролем, є досвід роботи із зовнішніми протоколами напряму | Залежність від змін на боці протоколу, виписки та звітність збираються вручну |
| Контракт-обгортка | Потрібні свої ліміти на виведення, ролі операторів і єдиний облік часток усередині системи | Додатковий шар контрактів: його потрібно перевіряти, оновлювати й тримати в згоді з базовим |
| Гібридна схема | Частина активів іде напряму, частина — під обгорткою, розподіл задається політикою ризику | Дві книги обліку: звірка складніша, потрібен спільний реєстр операцій та однозначні правила зведення залишків |
Далі вирішує розподіл ролей: той, хто керує ключами, і той, хто веде облік часток, — це різні контури з різними правами, і змішувати їх не варто.
Окремо перевіряємо сумісність із поточним стеком: формати виписок, порядок відображення нарахувань, інтерфейси обміну з тим, що вже працює. Розбіжності за цими точками дешевше знаходити на етапі проєктування — коли схема ще не закріплена в контрактах.
Порядок інтеграції: від аудиту позицій до передачі
Етапи йдуть строго послідовно: кожен наступний спирається на результат попереднього, і перескочити аудит позицій не вийде — розбіжності в обліку спливають уже на бойових обсягах, коли розбирати їх найдорожче.
- Аудит позицій. Зводимо, що й де розміщено: внесені активи, отримані розписки, нараховані винагороди, незакриті заявки на виведення. Звіряємо гаманці зі станом Kelp DAO — розбіжність у частки відсотка після першого перерозподілу стає неврахованим залишком.
- Схема потоків активів. Описуємо маршрут кожного активу: звідки надходить, де обліковується, у якому вигляді повертається під час виведення. Схема одразу показує точки, де потрібен ручний підпис, а де достатньо автоматики.
- Налаштування ролей доступу. Розділяємо права на читання позицій, керування та виведення; великі операції виводимо за багатопідписний контур. Право на виведення не видаємо тим самим ключам, що виконують регулярні дії.
- Перевірка на малих обсягах. Проганяємо повний цикл — внесення, розписка, нарахування, часткове виведення. Тут видно округлення та мережеві витрати, а розсинхрон між нашим обліком і даними протоколу ловиться до того, як у контур потраплять робочі позиції.
- Приймання контуру. Звіряємо контрольні показники: суми позицій, нараховані винагороди, час реакції на зміну стану. Приймаємо не «працює», а з числами — частка шляхів під перевірками та відсутність ручних кроків у регулярному циклі.
- Передача. Віддаємо конфігурації, схему, регламенти виведення та відновлення доступу, інструкції для чергової зміни. Окремо фіксуємо сценарій відкату: як повернути активи до вихідного вигляду.
Що залишається в команди після впровадження
Впровадження закінчується не запуском, а передачею контуру супроводу: інженери замовника повинні вміти самі провести операцію, відкликати позицію та відновити її після збою.
Тому на виході — комплект налаштувань і документів, за якими робота йде без нас: від конфігурацій вузлів до порядку дій під час зупинки виведення.
- Схеми інтеграції — як рухаються кошти між кастодіальним гаманцем, контрактами рестейкінгу та обліковим шаром: де випускається похідний токен, де фіксується частка і в якій точці можливий розрив.
- Конфігурації контуру — адреси контрактів за мережами, параметри вузлів, ліміти на одну операцію та добовий обсяг, окремі набори для тестового й робочого контуру.
- Політики доступу — матриця ролей: хто готує операцію, хто підтверджує, хто змінює ліміти; гаманець із кількома підписами та операторський ключ з урізаними правами.
- Регламент виведення — порядок виходу з позиції з урахуванням черги та періоду розблокування, з контрольними точками, де операцію можна зупинити без втрати частки.
- Порядок відновлення позиції — дії при завислій транзакції, розбіжності балансу або зупинці валідатора: точки входу, пріоритет кроків, кому ескалювати.
- Інструкції для команди — розбір типових операцій з очікуваним результатом на кожному кроці, чек-ліст приймання після змін і таблиця частих помилок.
Комплект залишається в замовника та оновлюється в міру зростання позиції.
Кейс: рестейкінг-контур для оператора вузлів
Оператор вузлів тримав рестейк-позицію в Kelp DAO: rsETH розподілено за операторами EigenLayer, винагороди нараховуються, але вихід і перерозподіл частки інженери проводили вручну.
Заявка на вихід збиралася скриптом, черга звірялася очима, підписи — в мультипідписі, а непідтверджена транзакція йшла повторно тим самим тілом.
До: ручне виведення та плаваючі стани
Середнє виведення займало до трьох діб — не через пропускну здатність мережі, а через ручні кроки та очікування кворуму підписантів. Небезпечнішим за затримку було інше: повторна подача заявки створювала другий запис у черзі, і частина частки зависала між станами.
Реєстр розходився з реальною позицією в мережі, а розбір кожного такого випадку займав ще кілька днів.
Після: ідемпотентний контур і метрики
Кейс інтеграції будувався навколо виведення: спостерігач черги, ідемпотентна подача заявок із ключем-ідентифікатором, розподіл ролей між ініціатором і підтверджувачем, реєстр заявок зі станами та журнал операцій. Ручні кроки прибрано, повтор більше не створює нову заявку, а лише підтверджує наявну.
- Час виведення коштів: з трьох діб до десятків хвилин.
- Усунений клас відмов — «дублювальна заявка на вихід»: зник повністю.
- Розбіжність реєстру та позиції в мережі: з поодиноких випадків на місяць до нуля.
- Розбір інциденту: за журналом за хвилини замість листування та ручної звірки.
Чим ліквідний рестейкінг відрізняється від звичайного стейкінгу
Звичайний стейкінг блокує активи: доки частка працює на валідаторі, забрати її не можна — лише вийти з черги та дочекатися розрахунку. Актив приносить дохід, але випадає з обігу: його не можна продати, закласти або перевести в іншу стратегію.
Це блокування активів — не налаштування, а умова роботи мережі, і саме втрачену гнучкість вам оплачують нагородою.
Ліквідний рестейкінг розриває зв’язок між участю в мережі та блокуванням. Внесені активи йдуть у стейкінг, а натомість ви отримуєте токен-квитанцію — обліковий токен на конкретну позицію, що підтверджує право на вкладене та на накопичену нагороду. Квитанція обертається вільно: її тримають, продають, закладають, віддають як забезпечення.
Звідси другий шар — рестейкінг, коли ту саму позицію закладають повторно в сторонні сервіси. Kelp DAO працює як обгортка над такою схемою: розподіляє позицію між операторами та видає учаснику квитанцію, яка й стає його ліквідним інструментом.
Управління ліквідністю змінюється принципово. Раніше заблоковану позицію не можна було переоцінити або закрити частково — лише чекати виходу.
Тепер рішення ухвалюється на вторинному ринку, але разом із гнучкістю приходять нові ризики: розбіжність ціни квитанції та базового активу, ліквідація при заставі, помилка в коді контракту.
Тому під час інтеграції передусім перевіряють, за якою ціною квитанція враховується в розрахунках, як проходить виведення з позиції та що з нею відбувається при різкому падінні ринку. Ці три точки визначають, чи залишиться схема керованою.
Часті технічні питання перед стартом робіт
Перед стартом робіт інженерні сумніви повторюються: скільки чекати виведення з черги, що відбувається при слешингу оператора, як відновлюється позиція після збою, чи уживеться новий контур з уже розгорнутими сервісами та які права потрібні на доступ до ключів. Відповідаємо по суті — без маркетингових формулювань.
Скільки реально займає виведення коштів?
Виведення з Kelp DAO іде через чергу виходу рестейкінгу: доки оператор не завершив процедуру, токени не розблоковуються. Ми рахуємо строк за поточною глибиною черги та закладаємо його в план, а не обіцяємо миттєве повернення.
Що відбувається при слешингу?
Слешинг — це списання частини частки за порушення правил валідації, і він б'є по всіх, хто делегував. Тому розподіляємо позицію між кількома операторами з різним профілем ризику та налаштовуємо повідомлення про падіння частки.
Як відновлюється позиція після збою?
Тримаємо знімок стану та ключові адреси в захищеному сховищі: при відмові вузла позиція перезбирається за журналом подій, а не з нуля. Сценарій відкату проганяємо на тестовому контурі до запуску на основному.
Чи сумісно це з уже розгорнутим контуром?
Так. Інтеграція не вимагає переписувати наявні сервіси та змінювати сховище ключів — вона підключається окремим шаром і працює через уже прийняті інтерфейси. Перевірку контрактів і розмежування прав доступу робимо до першого переказу коштів.
Обговоримо задачу та повернемося з планом робіт
Щоб оцінка обсягу робіт була точною, а не «плюс-мінус», опишіть задачу в розрізі активів, ролей і сценаріїв. Нижче — мінімальний набір даних, якого нам достатньо, щоб повернутися з планом інтеграції та складом робіт за етапами.
- Активи та мережі. Які активи готові приймати в рестейкінг, у якій мережі працює продукт, чи потрібне виведення позиції назад у ліквідну форму і в якому вигляді.
- Сценарії використання. Депозит, виведення, нарахування та реклейм винагород, відображення частки в пулі — що з цього потрібно в інтерфейсі, що у звітності, а що закривається вручну.
- Ролі та доступи. Хто підписує операції, чи є кастодіальний або некастодіальний сценарій, чи потрібні ліміти, мультипідпис і розмежування прав між співробітниками.
- Облік і звітність. Як позиція має відображатися у внутрішньому балансі, чи потрібна переоцінка частки та вивантаження даних для бухгалтерії або комплаєнсу.
- Обмеження та вимоги. Юрисдикції користувачів, вимоги комплаєнсу, клас відмов, який обов'язково потрібно обробити, і те, що робити не можна.
- Поточний стан. Які напрацювання вже є, що з доступами та кодом, хто на вашому боці приймає результат і підписує приймання.
- Строки та пріоритети. Що потрібно до запуску, а що можна винести другим етапом без втрати цінності.
Надішліть це у вільній формі — не потрібно готувати документ. Ми повернемося з оцінкою обсягу робіт і планом інтеграції: склад робіт за етапами, зона відповідальності вашої та нашої команди, точки приймання та порядок звернення за змінами.
Обговоримо задачу коротко, щоб уточнити деталі, і зафіксуємо домовленості письмово — так очікування не розійдуться вже на старті.
