Интеграция 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-контур.
• Этапность: что должно попасть в первый релиз, а что можно вынести во второй заход без риска для основной логики.

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