Інтеграція Mantle Staked ETH (mETH) для ліквідного стейкінгу на Mantle L2

Mantle Staked ETH: де ламається рідкий стейкінг у продукті

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

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

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

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

Ціна для команди вимірюється не зверненнями до підтримки.

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

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

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

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

Економіка змінюється насамперед на рівні обліку. Нарахування не розмазується окремими проводками по журналу: дохідність зашита в сам mETH і проявляється в його курсі до ETH.

Одна величина описує і позицію, і нараховане — звірка зводиться до курсу на дату, а не до реєстру ручних нарахувань за кожен період.

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

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

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

Тепер позиція й нарахування — одне число, і питання «де осіло» просто не виникає. Це і є вимірюваний ефект: актив працює, поки триває нарахування, а не чекає на закінчення блокування.

Варіанти інтеграції: нативний стейкінг, обмін, ліквідний пул

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

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

Випуск Mantle Staked ETH (mETH) через контракт стейкінгу знімає питання ключів: депозит обмінюється за курсом, і токен одразу обліковується в балансі.

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

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

Етапи впровадження: аудит схеми, налаштування, перевірка, передача

Інженерний порядок робіт будується так, щоб облік частки в Mantle Staked ETH залишався перевірюваним на кожному кроці — від поточного стану до передачі в експлуатацію.

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

Порядок робіт

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

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

Артефакти впровадження: конфігурації, схеми обліку, регламенти

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

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

• Конфігурації середовищ — адреси контрактів Mantle Staked ETH, ліміти на обсяг операції, список дозволених вузлів і пороги вартості транзакції; до кожного параметра додано коментар: за що відповідає і як змінювати.
• Схема обліку — як відображаються внесений ETH, нарахований дохід, зміна курсу обміну mETH і виведення: рахунки, проводки, момент визнання доходу, порядок звірки з даними мережі.
• Політики доступу — ролі та розподіл обов'язків, поріг підписів, ротація ключів, добові ліміти, порядок видачі та відкликання прав при зміні відповідальних.
• Регламенти реагування — що робить чергова зміна при відхиленні курсу обміну, зупинці валідаторів, затримці виведення та планових змінах мережі.
• Інструкції для чергової зміни — покрокові сценарії: запуск операції, перевірка стану, відкат невдалої транзакції, точки ескалації.
• Звітність — вигрузки за операціями та нарахуваннями, щоденна й місячна звірка, шаблони для внутрішнього контролю та зовнішнього аудиту.
• Перевірочний лист приймання — набір перевірок, які ваш інженер проходить самостійно; ми присутні та підтверджуємо результат.

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

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

Кейс: звірка часток і виведення коштів без ручних операцій

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

За кількох сотень адрес це давало затримку виведення в 2–3 дні, а розбіжності знаходилися вже після нарахування — розбирати їх доводилося в підтримці, заднім числом.

Що змінили

Ми підключили потік подій за контрактом Mantle Staked ETH: обробник читає кожну підтверджену подію, перераховує частку адреси й записує її у власний реєстр.

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

Що вийшло

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

Що робити, якщо звичайний стейкінг уже розгорнуто в продукті

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

Нові надходження йдуть уже в mETH — ліквідний токен стейкінгу мережі Mantle, а старі позиції продовжують жити до природного виходу. Інтерфейс продукту читає сукупний баланс з єдиного реєстру часток, тому для користувача нічого не «блимає».

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

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

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

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

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

Технічні сумніви: ризики контракту, виведення, звітність

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

Що показує аудит і як контракт поводиться при збої?

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

Як виводяться кошти і що з ліквідністю?

Обмін Mantle Staked ETH на вторинному ринку швидший, але залежить від глибини пулу; погашення через контракт іде чергою, поки валідатор виходить з мережі. Глибину ринку й очікуваний обсяг виведень дивимося заздалегідь і тримаємо буфер, щоб великий вихід не зсував курс.

Як нарахування потрапляють у звітність?

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

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

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

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

• Цільовий контур: працюємо лише в L2-мережі, розгортаємо окремий контур чи підтримуємо кілька мереж — від цього залежить модель обліку та вибір моста.
• Поточний стек: мова контрактів, фреймворк, версія вузла, оркестрація деплою та те, що вже виведено в продакшн.
• Список операцій з mETH: випуск і погашення, передача токена як забезпечення, нарахування нагород, паузи та аварійні зупинки.
• Модель доступу й ключів: хто володіє правом випуску, як влаштований мультисиг, які ролі потрібно розвести.
• Інтеграції навколо: гаманці, кастодіальне зберігання, оракули ціни, аналітика та звітність для бухгалтерії.
• Вимоги до перевірок: чи потрібен зовнішній аудит, покриття тестами, обмеження за юрисдикціями та KYC-контур.
• Етапність: що має потрапити в перший реліз, а що можна винести в другий захід без ризику для основної логіки.

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