Я прошёл процедуру совместного стейкинга Babylon ещё раз, и самое неприятное в том, что многие ключевые условия пользователь замечает только тогда, когда награду не получил.
Официально процесс сводят к двум шагам: BTC делегируется Finality Provider, а BABY затем делегируется валидатору. Но при реальном выполнении BTC должен пройти путь PENDING → VERIFIED → ACTIVE, и награда засчитывается только в состоянии ACTIVE; при этом BTC и BABY должны использовать один и тот же адрес BABY. Если адреса различаются, награда за кросс-стейкинг обнуляется. Чтобы выжать максимум эффективности по наградам, нужно помнить: примерно 1 BTC соответствует 20,000 BABY.
Проблема в том, что обычные пользователи, увидев «отправлено» или «верифицировано», легко думают, что всё уже сделано. А где именно всё застряло, почему нет награды, выбранный Finality Provider всё ещё активен или нет, совпадают ли два адреса — страница должна объяснять это прямо, а не заставлять пользователя самому перелистывать документы и гадать.
Сейчас панель Babylon показывает, что примерно 51 342 BTC уже застейканы, среди 132 Finality Provider активны только 36, а годовая доходность BTC находится в диапазоне от 0.04% до 0.70%. Масштаб уже набран, но со стороны пользователей всё ещё приходится заниматься самостоятельной отладкой.
И этап выхода тоже не так прост, как выглядит. Официальная документация по разстейкингу BTC указывает минимальное время ожидания в 301 биткоин-блок; а troubleshooting в CLI может затрагивать параметры gas, настройки RPC и GRPC — и если не получается решить, нужно идти за помощью в Discord.
Моё сомнение по поводу @BabylonLabs_io очень прямое: сложность протокола можно понять, но продукт не должен просто «вываливать» эту сложность на пользователя в первозданном виде.
Точно чего не хватает — объяснения статусов, точного определения ошибок и чёткого пути действий. Иначе так называемый «self-custody» легко превращается в ситуацию, где — все непонятные вопросы остаются на ответственности пользователя.
#baby $BABY @BabylonLabs_io
Официально процесс сводят к двум шагам: BTC делегируется Finality Provider, а BABY затем делегируется валидатору. Но при реальном выполнении BTC должен пройти путь PENDING → VERIFIED → ACTIVE, и награда засчитывается только в состоянии ACTIVE; при этом BTC и BABY должны использовать один и тот же адрес BABY. Если адреса различаются, награда за кросс-стейкинг обнуляется. Чтобы выжать максимум эффективности по наградам, нужно помнить: примерно 1 BTC соответствует 20,000 BABY.
Проблема в том, что обычные пользователи, увидев «отправлено» или «верифицировано», легко думают, что всё уже сделано. А где именно всё застряло, почему нет награды, выбранный Finality Provider всё ещё активен или нет, совпадают ли два адреса — страница должна объяснять это прямо, а не заставлять пользователя самому перелистывать документы и гадать.
Сейчас панель Babylon показывает, что примерно 51 342 BTC уже застейканы, среди 132 Finality Provider активны только 36, а годовая доходность BTC находится в диапазоне от 0.04% до 0.70%. Масштаб уже набран, но со стороны пользователей всё ещё приходится заниматься самостоятельной отладкой.
И этап выхода тоже не так прост, как выглядит. Официальная документация по разстейкингу BTC указывает минимальное время ожидания в 301 биткоин-блок; а troubleshooting в CLI может затрагивать параметры gas, настройки RPC и GRPC — и если не получается решить, нужно идти за помощью в Discord.
Моё сомнение по поводу @BabylonLabs_io очень прямое: сложность протокола можно понять, но продукт не должен просто «вываливать» эту сложность на пользователя в первозданном виде.
Точно чего не хватает — объяснения статусов, точного определения ошибок и чёткого пути действий. Иначе так называемый «self-custody» легко превращается в ситуацию, где — все непонятные вопросы остаются на ответственности пользователя.
#baby $BABY @BabylonLabs_io