Інтеграція Puffer Finance: ліквідний рестейкінг pufETH для DeFi

Puffer Finance інтеграція: де розривається стейкінг-контур

Ліквідний рестейкінг виглядає просто: вносиш ETH — на балансі з'являється pufETH. Але Puffer Finance інтеграція ламається в трьох типових місцях, і кожне дає або застряглі кошти, або неправильний баланс у звітності.

Перше — розсинхрон курсу обміну. pufETH не дорівнює ETH один до одного: курс зростає в міру нарахування нагород за стейкінг і рестейкінг.

Якщо облік бере його з кешу, зі зрізу на початок доби або вважає 1:1, позиція в системі розходиться з ончейн-балансом — і розходження накопичується з кожним днем.

Друге — затримка виведення зі стейкінгу. Виведення не миттєве: заявка стає в чергу на анстейк і виконується, коли дійде її черга і в буфері вистачить ліквідності. Інтерфейс, який показує pufETH як вільні кошти, обіцяє виведення, якого прямо зараз немає.

Третє — облік стейкінг-позицій. При підключенні pufETH до сторонніх протоколів позиція перестає бути просто балансом на гаманці: вона дробиться, закладається, мігрує між контрактами.

Без прив'язки до адреси власника та історії операцій така позиція випадає з обліку — її не можна ні показати у звіті, ні коректно повернути власнику.

Далі розбираємо, як цей контур закривається: звірка курсу, обробка черги виведення та наскрізний облік позицій.

Що змінюється після підключення ліквідного стейкінгу

Після підключення ліквідного стейкінгу застава перестає бути замороженим активом: та сама позиція приносить винагороду і водночас залишається робочою. Нижче — два зрушення, які видно і у звітності, і в поведінці системи. Puffer Finance дає ліквідне представлення частки, і саме з нього починається подальша інтеграція.

Застава більше не блокується

Користувач вносить забезпечення один раз і отримує ліквідний токен частки — pufETH. Цю частку можна закласти, обміняти або вивести, не закриваючи стейкінг-позицію.

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

Прозорий облік і швидкість виведення

Нарахування за стейкінгом та операції з часткою зводяться в один реєстр зі спільним курсом обміну. Бухгалтерія бачить не розрізнені перекази, а позицію з історією: скільки нараховано, скільки виведено, скільки залишилося в роботі.

Це прибирає окремий клас відмов — подвійний облік однієї частки при перенесенні між контурами та розходження курсу при перерахунку.

Швидкість виведення тепер задається чергою виходу, а не ручним розблокуванням позиції: ліквідна частина виходить одразу через обмін частки, решта — у передбачувані строки.

Капітал перестає простоювати, а кожен рух фіксується в спільному реєстрі, тому розходження знаходяться на етапі звірки, а не після звітного періоду.

Формати роботи з Puffer Finance: прямий контур і посередник

Протокол Puffer Finance видає pufETH за внесений актив, і формат підключення визначає, хто відповідає за коректність подальших операцій: ваш сервіс, зовнішня платформа чи обидві сторони.

Різниця видна не на першому депозиті, а на виведенні, при нарахуванні нагород і в момент збою — там помилка обліку коштує найдорожче. Нижче — три схеми, між якими реально обирають.

Обмеження інтеграції майже завжди лежать в одному місці — синхронізація балансу pufETH із внутрішнім обліком. Підхожий варіант підключення той, де ця синхронізація перевіряється: є журнал операцій, зрозумілий порядок відкату та відтворюваний тест на розходження. Опишіть задачу — повернемося з оцінкою та планом.

Порядок робіт: від розбору позицій до виведення в мережу

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

Нижче — маршрут інтеграції ліквідного рестейкінгу: від аудиту позицій до передачі працюючого контуру вашій команді.

До виведення в мережу

1. Аудит поточних позицій — інвентаризація гаманців і облікових записів: які активи беруть участь, де вже лежать похідні токени, які ліміти й ролі видані.
2. Схема контуру — описуємо потоки: отримання pufETH, розподіл за стратегіями, виведення та облік винагород. Узгоджуємо схему до початку робіт, щоб розходження не спливали на перевірці.
3. Налаштування інтеграції — реалізуємо виклики, обробку відмов, повторні спроби та журналювання операцій; ключі й ролі розносимо за рівнями доступу.

Перевірка та передача

• Тестовий запуск — прогін повного циклу на ізольованій мережі: випуск, облік, виведення, сценарії збою та відновлення стану після нього.
• Передача контуру в роботу — розгортаємо в основній мережі, вмикаємо моніторинг, фіксуємо регламент оновлень і порядок відкату.
• Віддаємо документацію та розбираємо контур із вашою командою: що де налаштовано, як читати метрики і що робити при відхиленнях.

Документація та артефакти, які залишаються у вас

Документація — частина постачання, а не додаток до нього. Ми фіксуємо все, що спроєктували й налаштували, так, щоб інженер, який не брав участі в проєкті, відтворив середовище і повторив будь-яку операцію — від випуску контракту до виведення коштів.

Схеми та реєстри

• Схема контуру: контракти, їхні зв'язки, зовнішні точки виклику і те, яка адреса чим керує.
• Реєстр адрес: контракти, гаманці ролей, адреси розподілу виплат і резервні ключі — із призначенням кожного.
• Схема потоків: маршрут депозиту, випуску та зворотного обміну Puffer Finance з ділянками, де можливі затримки виведення.
• Карта залежностей: зовнішні контракти й оракули, відмова яких впливає на роботу протоколу.

Регламенти та передача

• Регламент виведення коштів і відновлення доступу: покрокові процедури, пороги підтверджень, дії при компрометації ключа.
• Політика доступу до контрактів: матриця ролей, ліміти та затримки для критичних операцій.
• Розгортання в тестовій мережі та чек-лист приймання перед виведенням в основну.
• Акт передачі документації з версіями та точками актуалізації.

Схема контуру та реєстр адрес знімають головний ризик — ситуацію, коли зміни в контракті вміє вносити одна людина, а решта діють з пам'яті.

Регламенти перевіряємо на навчальному виведенні коштів: якщо процедура не відтворюється за документом за один прохід, повертаємося і правимо формулювання, поки вона не стане однозначною.

Кейс: як ми зняли затримки виведення зі стейкінгу

Позиції казначейства виводилися зі стейкінгу вручну: оператор відстежував статус заявки, звіряв його зі станом ліквідної квитанції та повторно надсилав операцію, якщо перша не проходила.

На піковому навантаженні частка завислих виведень сягала 11%, відновлення позиції займало близько години, і розрахунок за угодою зсувався разом із ним. Впровадження почали саме з цієї ділянки.

Метрики до і після

Ми підключили Puffer Finance і перевели виведення на ліквідну квитанцію pufETH: позиція більше не чекає розформування в черзі виходу, а одразу перетворюється на інструмент, який бере участь у розрахунках і може йти в заставу.

Перевірку статусу та повторні спроби перенесли в автоматичний контур — ручний крок оператора зі схеми прибрали зовсім.

Що змінилося в експлуатації

Усунений клас відмов — втрачена або двічі надіслана операція виведення, через яку позиція зависала між станами. Тепер такі випадки ловить автоматика і доводить до кінця без участі людини, тому повторні звернення за однією й тією самою позицією стали поодинокими. Звільнений час команда замовника витрачає на угоди, а не на звірку статусів.

Чим ліквідний рестейкінг відрізняється від класичного стейкінгу?

Класичний стейкінг блокує заставу в консенсусному шарі: актив перестає бути ліквідним і залишається прив'язаним до конкретного валідатора. Права на виведення застави не відокремлюються від депозиту — розпорядитися ними можна лише після виходу з черги активації. Дохідність при цьому нараховується на нерухомий баланс.

Ліквідний рестейкінг залишає заставу в мережі, але випускає проти неї похідний токен — в інтеграції з Puffer Finance це pufETH.

Токен тримає частку в спільному пулі та накопичену дохідність, а права на виведення застави залишаються в контракту-обгортки, який проводить депозит і зворотне виведення. Утримувач отримує ліквідний інструмент, не виводячи забезпечення з мережі.

Основне джерело розходжень в обліку — що вважати одиницею балансу. Курс обміну зростає в міру нарахування нагороди й не дорівнює одиниці, а ринкова ціна токена відхиляється від цього курсу в обидві сторони.

Розрахунок частки та розрахунок за вторинним ринком дають різні цифри для однієї й тієї самої позиції.

Працездатність застави визначається тим, як розподіляється штраф за порушення валідатора. Він зменшує спільний пул, а не окремий депозит поіменно, тому утримувач похідного токена ділить ризик пропорційно своїй частці.

У класичного стейкера ризик локалізований на одному валідаторі, тут він розмазаний по набору операторів — змінюється сама модель ризику.

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

Технічні сумніви перед виведенням у роботу

Перед виведенням контуру Puffer Finance у роботу замовник ставить ті самі питання: що буде при заморожуванні отримувача, як рахується курс обміну, чим підтверджується звітність. Нижче — короткі відповіді з оцінкою ризику та способом його зняти.

Як перевіряється курс обміну перед угодою?

Курс похідного токена зростає відносно базового активу, тому фіксуємо не цифру, а допустиме відхилення та глибину пулу. Якщо розрахункове прослизання виходить за межу, операція не виконується та йде на ручну перевірку.

Як підтверджується звітність за нарахуваннями?

Кожне нарахування потрапляє до реєстру з адресою, часом і посиланням на операцію в мережі. Звірка йде щодня, розходження збираються окремим списком і приходять разом із підсумком — без ручного перерахунку.

Навіщо зовнішній аудит контуру?

Аудит не замінює внутрішні перевірки, але дає незалежний висновок щодо коду, прав доступу та роботи з ключами. Звіт передаємо з описом ролей — його можна пред'явити партнерам і службі безпеки.

Обговоримо задачу і повернемося з оцінкою та планом

Щоб розрахунок спирався на факти, а не на припущення, на першому кроці потрібні ввідні: у яких мережах працює продукт, як планується поводитися з pufETH — тримати на балансі, закладати в забезпечення чи вбудовувати в стратегії — і які інтерфейси вже є в системи.

Зі свого боку повертаємося оцінкою та планом робіт: склад робіт, порядок етапів, строки запуску та точки, де знадобиться ваше рішення. Обсяг і послідовність видно до старту, а не по ходу інтеграції.

Що розбираємо на першій зустрічі:

• сценарії використання pufETH: приймання депозитів, випуск, обмін із урахуванням курсу й комісій, виведення коштів;
• ввідні для розрахунку: поточна архітектура, доступи до блокчейн-інфраструктури та вузлів, вимоги до зберігання ключів;
• обмеження: ідентифікація клієнтів, ліміти на операції, вимоги до звітності та зберігання історії;
• що вже зроблено: аудит контрактів, схеми резервування, відповідальні на вашому боці;
• що віддаємо у відповідь: схему інтеграції, склад робіт за етапами, строки запуску та порядок приймання;
• точки контролю: на яких етапах ви підтверджуєте результат і де можливий відкат.

Опишіть задачу та долучіть те, що є з поточної реалізації — повернемося з оцінкою та планом робіт.