Інтеграція EtherFi: де ламається облік частки та нарахувань
У ліквідному рестейкінгу баланс перестає бути 1:1 з ETH: EtherFi видає частку, вартість якої змінюється разом із курсом обміну.
Якщо інтеграція EtherFi веде облік у номінальних ETH і не перераховує частку до базового активу, залишок в особистому кабінеті розходиться з фактичним балансом у контракті.
На малих сумах помилка непомітна, а випливає під час першого великого виведення, коли розбіжність доводиться покривати за власний рахунок.
Нарахування за стейкінгом — друга точка відмови. Їхнє джерело — події контракту та періодичний перерахунок курсу, а не вивантаження з біржового звіту.
Ручні звірки ламаються на пропущеній події, повторній доставці або реорганізації ланцюжка: нарахування або задвоюються, або губляться, і відновити картину постфактум уже нема чим.
Третя точка відмови — виведення коштів. Заявка стає в чергу й залишається прив'язаною до адреси та квитанції, а не до запису в обліковій системі.
Типові помилки виведення коштів починаються з того, що інтеграція вважає виведення миттєвою операцією: статус заявки не відстежується, власник квитанції не перевіряється — кошти зависають у черзі, а право на них губиться під час зміни гаманця.
Спільний корінь усіх трьох збоїв один: облік частки, нарахувань за стейкінгом і прав на виведення має будуватися на даних контракту, а не на проміжних таблицях. Розбираємо, як це закривається.
Що змінюється після підключення ліквідного рестейкінгу
Позиція в стейкінгу перестає бути «замороженою»: замість ETH на балансі з'являється токен-квитанція, який представляє ту саму частку, але обертається як звичайний актив.
Валідатори продовжують працювати та приносити дохідність рестейкінгу, а квитанція в цей час бере участь у розрахунках, слугує забезпеченням або йде в іншу стратегію. Таку модель дає EtherFi, і вона змінює не розмір винагороди, а ліквідність уже вкладеного ETH.
Виведення перестає вимагати зупинки валідаторів. Раніше вихід означав очікування в черзі та втрату нагород на весь цей час; тепер позиція закривається обміном квитанції, а валідатор продовжує приносити дохід до моменту реального виходу.
Час виведення вимірюється однією транзакцією замість годин і діб очікування, і інженерний результат тут — передбачуваність: обсяг доступної ліквідності відомий заздалегідь, а не залежить від завантаження мережі.
Облік нарахувань переїжджає в реєстр. Події контракту читаються напряму, нагороди та курси перерахунку потрапляють у базу автоматично, і частка ручних операцій падає до звірки винятків.
Зникає цілий клас відмов — розбіжність між внутрішнім балансом і фактичним станом позиції: раніше його ловили наступного дня, тепер розбіжність видно в момент операції.
Для замовника це означає, що дохідність рестейкінгу стає керованою величиною, а не звітом за фактом. Ми закриваємо такі інтеграції повністю: контрактна частина, читання подій, перерахунок курсу квитанції в базі, обробка граничних станів і вивантаження для бухгалтерії.
Формати підключення: контракт протоколу, шлюз, посередник
Формати підключення різняться не інтерфейсом, а тим, у кого залишаються ключі та де ведеться облік позицій. Прямий контракт протоколу дає максимум контролю: ваші ролі, ваші підтвердження, між кодом і EtherFi немає чужої логіки.
Шлюз-обгортка додає на вашому боці тонкий шар перевірок — ліміти на одну операцію, добовий поріг, розмежування ролей оператора та того, хто виводить. Схема з посередником передає утримання позицій зовнішній стороні, а вам залишає лише облік.
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Прямий контракт протоколу | Ключі та політика виведення залишаються всередині; потрібен повний контроль над ролями та паузою операцій | Самостійно обробляєте затримки виведення, зміну курсу обміну й оновлення на боці протоколу; розподіл прав проєктуєте з нуля |
| Шлюз-обгортка | У внутрішньому обліку вже є ролі та ліміти — потрібна єдина точка перевірок перед викликом протоколу | Додає крок виконання та витрати на газ; власний код потребує аудиту й оновлюється слідом за інтерфейсом протоколу |
| Схема з посередником | Швидкий старт, немає команди, яка постійно тримає ключі, облік важливіший за пряме володіння позицією | Ризик контрагента, затримки під час виведення, обмежені права, залежність від чужої звітності |
Практично вибір зводиться до трьох питань: хто тримає ключі, у якій системі сходиться облік і скільки ролей потрібно розвести. Якщо ролі не розділені, жоден формат не рятує: один ключ на депозит і виведення обнуляє будь-які ліміти. Опишіть вашу модель прав і обліку — повернемося з оцінкою та планом переходу.
Порядок інтеграції EtherFi: від аудиту до передачі
Інтеграція з EtherFi — не разова транзакція, а зміни в зберіганні ключів, моделі ролей і лімітах на виведення. Спочатку збираємо схему потоків: звідки ETH іде в стейкінг, куди надходять підтверджувальні токени й яким шляхом повертаються. Далі робота йде етапами — від аудиту поточного контуру до передачі регламентів команді.
- Аудит гаманців. Інвентаризація адрес, ключів і доступів, схем підпису та виданих дозволів на контракти — включно з тими, що залишилися від минулих завдань.
- Схема потоків. Фіксуємо рух ETH і підтверджувальних токенів між гаманцями, стейкінгом і казначейством, позначаючи, де потрібен ручний підпис.
- Налаштування ролей і лімітів. Ініціація, підтвердження та виведення розводяться за різними ролями; разові та добові ліміти плюс поріг підтверджень не дають вивести всю суму одним підписом.
- Перевірка виведення. Проганяємо повний шлях виходу з урахуванням очікування виходу з рестейкінгу та аварійних сценаріїв: затримка, відмова підпису, повернення коштів у холодне зберігання.
- Тестовий контур. Повторюємо схему з реальною моделлю ролей та обмеженими сумами — перевіряємо, що ліміти спрацьовують, а кожна дія потрапляє в журнал.
- Моніторинг. Налаштовуємо оповіщення на великі рухи коштів, зміну дозволів та аномалії у виведеннях.
- Передача регламентів. Віддаємо карту ролей, політику лімітів, інструкції з виведення та порядок дій під час інцидентів.
Що передаємо на руки: політики доступу та регламенти
Передача — це не архів із ключами, а комплект артефактів, за яким ваша команда проводить операції та розбирає інциденти без нашої участі. Кожен документ прив'язаний до конкретної дії, а не написаний «для повноти».
- Політики доступу. Ролі та права на контракти, пороги підтверджень для мультипідписних гаманців, матриця «хто що підписує», порядок зміни ключів і виведення учасника зі схеми.
- Схема інтеграції. Адреси контрактів, маршрути руху токенів між гаманцями та стратегією, зовнішні залежності — із зазначенням точки відмови та дії в разі неї.
- Регламент виведення. Покроковий порядок, ліміти на операцію та на добу, хто підтверджує, чим фіксується факт і причина відхилення запиту.
- Документація з обліку. Які події читаються з мережі, як вони перетворюються на проводки з нарахувань, довідники відповідності та правила округлення.
- Моніторинг нарахувань. Оповіщення про розбіжність очікуваної та фактичної винагороди, зростання черги виведення, простій — з порогами, каналом і відповідальним.
- Перевірка та відновлення. Чек-лист приймання, де зберігаються резервні копії конфігурацій, порядок відкату до попередньої робочої версії.
Список закриває питання команди та зовнішнього аудиту: чому нараховано стільки, хто має право вивести кошти, що робити в разі розбіжності. Інтеграція з EtherFi перестає залежати від однієї людини — знання живуть у документах, а не в листуванні.
Кейс: як виведення з рестейкінгу перестало потребувати ручної роботи
До: черга виведення та ручні звірки
Клієнт тримав велику частку позицій у ліквідному рестейкінгу — в основі EtherFi з його чергою виведення. Кожну заявку оператор збирав вручну: вивантажував список, звіряв із внутрішнім обліком, перевіряв доступний залишок і лише потім надсилав транзакцію. Десятки заявок на тиждень, по дві-три звірки на кожну.
Ціна помилки виявилася вищою за трудовитрати. Ліміти виведення перевірялися вже після надсилання: якщо запит перевищував доступний обсяг, його відхиляли, і оператор перезбирав його з нуля.
На повтор ішла приблизно третина заявок, середній строк виведення сягав двох діб, а розбіжність між кабінетом і обліком шукали вручну.
Після: оркестратор із передвалідацією
Ми винесли процес у сервіс-оркестратор: він сам опитує чергу, зіставляє заявку із записом обліку та перевіряє ліміти до надсилання. Завдання ідемпотентні та зберігають стан, тому повтор після збою не створює дубль.
Відхилені запити надсилаються заново автоматично, з наростаючою паузою, а сходженість рахується за хешами операцій замість ручної таблиці.
Метрики до та після: частка заявок, що проходять через оператора, — зі 100% до нуля; строк виведення — з двох діб до двох-трьох годин; проходження з першого разу — з 65% до 99%; ручні звірки — нуль замість десятків на тиждень. Усунувся окремий клас відмов: запити понад ліміт більше не доходять до мережі.
Чим ліквідний рестейкінг відрізняється від звичайного стейкінгу?
У звичайному стейкінгу частка залишається заблокованою: актив приносить винагороду, але до виходу з черги не бере участі в жодних інших операціях і не може бути переданий.
Ліквідний рестейкінг видає на вкладену частку токен-розписку — ліквідність частки залишається у власника, а сама частка працює не лише в захисті мережі, а й у додаткових сервісах.
Різниця підходів проявляється в режимах виведення: замість однієї черги з'являються два шляхи — обмін токена-розписки на ринку (одразу, але за курсом, який може відхилятися від вартості базової частки) і виведення через мережу (за розрахунковою вартістю, але із затримкою). Це різні профілі ризику, і вибір залежить від сценарію, а не від швидкості.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Звичайний стейкінг | Довге утримання, ліквідність не потрібна | Частка заблокована до виходу, вихід за загальною чергою |
| Ліквідний стейкінг | Потрібна передавана частка та швидкий вихід | Винагорода лише від базового стейкінгу, додається шар контрактів |
| Ліквідний рестейкінг | Частка повинна працювати в додаткових сервісах | Ризик контрактів і розбіжності курсу токена-розписки |
До ризику слешингу та затримки виходу додаються ризик контрактів і курсове розходження: токен-розписка торгується окремо від базового активу, і дисконт розширюється саме тоді, коли ліквідність потрібна найбільше. Звичайний стейкінг цих шарів не створює, але й гнучкості не дає.
В обліку різниця не менш відчутна.
Звичайна частка — одна позиція з нарахуванням у тому самому активі; під час інтеграції з EtherFi з'являються два об'єкти: базова частка та токен-розписка, який потрібно переоцінювати, звіряти з курсом базового активу й вести окремо від винагороди.
Часті технічні сумніви перед підключенням
Перед стартом замовник і його фінансова служба піднімають те саме коло тем: як швидко повертаються активи, хто несе ризик штрафів валідаторів, де лежать ключі й чи не розійдеться облік із даними протоколу. Нижче — що саме ми налаштовуємо за кожним пунктом.
Скільки чекає виведення з черги?
Черга виведення — властивість самого протоколу, а не затримка інтеграції: активи звільняються після розблокування валідатора, і в пікові періоди черга розтягується. В інтерфейсі показуємо фактичний статус заявки та її позицію, а не розрахункову дату. Якщо ліквідність потрібна раніше, передбачаємо обмін токена рестейкінгу з урахуванням прослизання.
Хто відповідає за штрафні списання?
Штраф виникає в разі порушення правил валідатором, а не під час відкликання коштів. Щоб ризик не лягав на баланс клієнта, розподіляємо активи між кількома операторами й обмежуємо частку одного — збій в одного не просаджує загальну дохідність.
Де зберігаються ключі й хто ними розпоряджається?
Приватні ключі залишаються у власника: інтеграція працює через підписані операції та ролі в контрактах. Налаштовуємо розподіл прав — хто поповнює, хто виводить, хто змінює параметри, — і описуємо процедуру зміни власника, щоб звільнення співробітника не блокувало доступ.
Як це зійдеться з поточним обліком і що буде під час оновлення контрактів?
Токен рестейкінгу — не ETH: у нього власне котирування, і в обліку він іде окремою позицією. Віддаємо події за кожною операцією та звіряємо нарахування з даними протоколу, щоб розбіжність випливала одразу, а не в кінці періоду.
Адреси та параметри зовнішніх контрактів тримаємо в конфігурації: під час оновлення протоколу змінюється налаштування, а не код.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Щоб повернутися з оцінкою та планом, нам потрібен не загальний задум, а ваш контур: мережі, ролі, ключі, обсяги та обмеження. Інтеграція з EtherFi майже завжди зачіпає чужі смарт-контракти та потоки ETH, тому розбіжність в одній вхідній змінює і архітектуру, і строки.
- Старт робіт. Фіксуємо мету: що саме робимо з ETH — розміщуємо, виводимо, показуємо баланс і нараховану винагороду в інтерфейсі — і яким сценарієм користується людина.
- Вхідні дані щодо контуру. Потрібні мережі, адреси контрактів, ролі та політика підпису транзакцій, поточні потоки, ліміти й вимоги до доступів.
- Оцінка та план. Повертаємося з декомпозицією робіт, етапами, залежностями від зовнішніх сервісів і критеріями готовності, за якими ви приймете результат.
- Пілотний контур. Збираємо мінімальний обсяг на тестовій мережі: розміщення, виведення, нарахування винагороди та поведінку системи в разі відмови зовнішнього сервісу.
- Передача знань. Віддаємо схеми взаємодії, конфігурації, інструкції з експлуатації та розбір інцидентів — команда супроводжує рішення без нас.
Опишіть задачу у вільній формі — зі схемою потоків або без неї. Повернемося з оцінкою, планом робіт і списком питань, які варто закрити до старту.
