Я как-то раз пропустил голосование по предложению в сети Cosmos, потому что решил, что моя небольшая делегация все равно ничего не изменит. А потом выяснилось, что предложение прошло с таким крошечным перевесом, что я реально пожалел о том, что не участвовал. Именно этот момент вернулся ко мне, когда я начал читать, как Babylon Genesis выстраивает своё управление.

Я предполагал, что управление BABY будет работать как большинство токеновых голосований, с которыми мне доводилось сталкиваться: когда доминируют киты, а мелкие держатели — просто декорация. Но здесь картина не такая. В этой конструкции участвовать могут как прямые держатели, так и их делегированные валидаторы. Это значит, что ваш голос не исчезает только потому, что вы застейкали вместо того, чтобы самим активно голосовать: голос вашего валидатора может нести ваш вес, если вы его не переопределите.

Вот деталь, которая поменяла для меня всё местами. Babylon связывает ончейн-голосование через модуль governance Cosmos SDK с обязательным офчейн-обсуждением в структурированном форуме перед тем, как что-либо вообще будет вынесено на голосование. Это не просто косметика. Это означает, что предложения сначала обсуждают и подвергают проверке публично, прежде чем они станут обязательными, что снижает риск внезапных голосов, проскальзывающих во время скоординированного захода китов.

Чего я пока действительно не знаю, так это фактический порог кворума или длительность периода голосования именно для предложений BABY. В документации говорится о форуме как источнике деталей по управлению, но числа там прямо не расписаны, так что я не буду гадать.

Настоящая проверка для $BABY — покажут ли делегаторы себя в нужный момент и реально переопределят голоса своих валидаторов, а не будут относиться к делегации как к постоянному прокси.

Кто-то из вас активно переопределяет голос своего валидатора в сетях Cosmos, или просто оставляет всё как есть?

@BabylonLabs_io #baby $BABY