Я изначально думал, что Babylon сжал период анлока (разблокировки) для BABY, отдавшего в стейкинг, с обычных 21 дня примерно до 2 — уже очень быстро.
Но если смотреть с точки зрения исполнения сделок, я понял, что «короткий период анлока» и «возможность сразу выйти при возникновении риска» — вообще не одно и то же.
На Babylon Genesis размещение делегирования, отмена делегирования и повторное делегирование после отправки транзакции вроде бы сразу показываются как подтверждённые, но на деле они не вступают в силу мгновенно: сначала запрос попадает в очередь, и только после завершения текущего epoch он будет обработан целиком. Сейчас один epoch — это 360 блоков, примерно 1 час. После того как отмена делегирования проходит, ещё нужно дождаться 300 подтверждающих биткоин-блоков — это около 50 часов. И только тогда BABY действительно возвращается в состояние, когда его можно снова переводить.
Обычно смотрится так, будто час — это не так уж много.
Но стоит случиться аномалии валидатора, резкому падению цены или перегрузке сети — этот час превращается в полный период, когда риск полностью раскрыт. По официальным правилам, если валидатор уходит в дабл-сигн, BABY, делегированные ему, будут оштрафованы на 5%. Проблема в том, что когда пользователь замечает риск и нажимает «отменить делегирование», это всего лишь постановка в очередь: это не означает, что позиция уже снята.
А ещё общее/совместное стейкинг (сопричастное) раздувает эту проблему. Чтобы получить дополнительные 2,35% годовых в виде инфляционных наград, BTC и BABY должны одновременно сохранять действующее стейкинг-состояние и использовать один и тот же адрес BABY. Лучшее соотношение — примерно 2 0000 BABY на 1 BTC.
В итоге у пользователя в момент риска всё очень неловко: не двигаться — значит продолжать оставаться под риском у валидатора и из‑за колебаний цены; двигаться — значит, что изменение статуса стейкинга BABY может повлиять на доходность по совместному стейкингу.
Вот почему я сомневаюсь в @BabylonLabs_io : протокол очень ясно объясняет «как быстрее анлокать стейкинг», но так же прямолинейно не говорит о реальном времени выхода, изменениях статуса и влиянии на доход в экстремальных сценариях.
Механизмы безопасности могут быть медленными, но хотя бы страница должна позволять пользователю понимать, он «уже отправил запрос» или «действительно вышел».
#baby
$BABY
@BabylonLabs_io
Но если смотреть с точки зрения исполнения сделок, я понял, что «короткий период анлока» и «возможность сразу выйти при возникновении риска» — вообще не одно и то же.
На Babylon Genesis размещение делегирования, отмена делегирования и повторное делегирование после отправки транзакции вроде бы сразу показываются как подтверждённые, но на деле они не вступают в силу мгновенно: сначала запрос попадает в очередь, и только после завершения текущего epoch он будет обработан целиком. Сейчас один epoch — это 360 блоков, примерно 1 час. После того как отмена делегирования проходит, ещё нужно дождаться 300 подтверждающих биткоин-блоков — это около 50 часов. И только тогда BABY действительно возвращается в состояние, когда его можно снова переводить.
Обычно смотрится так, будто час — это не так уж много.
Но стоит случиться аномалии валидатора, резкому падению цены или перегрузке сети — этот час превращается в полный период, когда риск полностью раскрыт. По официальным правилам, если валидатор уходит в дабл-сигн, BABY, делегированные ему, будут оштрафованы на 5%. Проблема в том, что когда пользователь замечает риск и нажимает «отменить делегирование», это всего лишь постановка в очередь: это не означает, что позиция уже снята.
А ещё общее/совместное стейкинг (сопричастное) раздувает эту проблему. Чтобы получить дополнительные 2,35% годовых в виде инфляционных наград, BTC и BABY должны одновременно сохранять действующее стейкинг-состояние и использовать один и тот же адрес BABY. Лучшее соотношение — примерно 2 0000 BABY на 1 BTC.
В итоге у пользователя в момент риска всё очень неловко: не двигаться — значит продолжать оставаться под риском у валидатора и из‑за колебаний цены; двигаться — значит, что изменение статуса стейкинга BABY может повлиять на доходность по совместному стейкингу.
Вот почему я сомневаюсь в @BabylonLabs_io : протокол очень ясно объясняет «как быстрее анлокать стейкинг», но так же прямолинейно не говорит о реальном времени выхода, изменениях статуса и влиянии на доход в экстремальных сценариях.
Механизмы безопасности могут быть медленными, но хотя бы страница должна позволять пользователю понимать, он «уже отправил запрос» или «действительно вышел».
#baby
$BABY
@BabylonLabs_io
