Hoje dei uma olhada nas faixas de recompensa de bug da Babylon que foram atualizadas em 27 de julho e, depois de ler, fiquei ainda menos à vontade.
A recompensa máxima é de US$ 500 mil, com 16 itens de ativos incluídos, e à primeira vista parece haver um investimento forte em segurança. Mas, ao olhar mais a fundo, algumas categorias de riscos que realmente poderiam arrastar o sistema para um grande incidente foram explicitamente excluídas: risco de centralização, o relé entre o Bitcoin e a Babylon ficando temporariamente inoperante, mais de um terço de um Finality Provider malicioso, o Comitê de Covenant atingindo maioria maliciosa ou não conseguindo reunir assinaturas, e parâmetros de configuração como profundidade definidos abaixo do ideal.
O que chama ainda mais atenção é que as regras de bug bounty também proíbem testar oráculos e contratos inteligentes de terceiros.
Isso entra em choque direto com a direção recentemente impulsionada pelo <t-2/>@BabylonLabs_io </t-2/>. A Babylon já anunciou que pretende integrar as Trustless Bitcoin Vaults ao Aave V4 e ao Aegis, com o lançamento de empréstimos nativos de BTC com taxa fixa no quarto trimestre.
A cadeia do produto vai ficar assim: a Babylon cuida da infraestrutura de custódia de BTC, o Aave cuida do mercado de empréstimos, o Aegis cuida do produto de taxa fixa; do lado de fora, talvez ainda seja necessário conectar carteiras, front-end, oráculos e mecanismos de liquidação.
O que o usuário vê é “BTC nativo, auto-custódia, sem ponte”. O que o atacante vê, porém, são “emendas” e pontos de responsabilidade entre múltiplos sistemas.
Os problemas de segurança da Babylon divulgados pela OpenZeppelin este ano justamente se concentram nesse tipo de junção: colateral vencido ainda mantém poder de voto, Finality Provider contorna a prisão, anomalias na contabilidade de Co-Staking levam à congelação de fundos e até ao colapso do validador. A equipe corrigiu a tempo, de fato, mas isso só reforça que problemas de fronteira não são risco meramente teórico.
Eu não questiono se a Babylon tem auditoria; eu questiono quem fica responsável por incidentes “entre componentes” quando o negócio continua empilhando componentes de terceiros.
Segurança não pode ser medida apenas por saber se um repositório isolado tem vulnerabilidades. Quando o problema realmente acontece, muitas vezes cada parte consegue provar que o próprio código está correto — mas no fim ninguém consegue garantir que o dinheiro do usuário esteja seguro.
#baby $BABY @BabylonLabs_io
A recompensa máxima é de US$ 500 mil, com 16 itens de ativos incluídos, e à primeira vista parece haver um investimento forte em segurança. Mas, ao olhar mais a fundo, algumas categorias de riscos que realmente poderiam arrastar o sistema para um grande incidente foram explicitamente excluídas: risco de centralização, o relé entre o Bitcoin e a Babylon ficando temporariamente inoperante, mais de um terço de um Finality Provider malicioso, o Comitê de Covenant atingindo maioria maliciosa ou não conseguindo reunir assinaturas, e parâmetros de configuração como profundidade definidos abaixo do ideal.
O que chama ainda mais atenção é que as regras de bug bounty também proíbem testar oráculos e contratos inteligentes de terceiros.
Isso entra em choque direto com a direção recentemente impulsionada pelo <t-2/>@BabylonLabs_io </t-2/>. A Babylon já anunciou que pretende integrar as Trustless Bitcoin Vaults ao Aave V4 e ao Aegis, com o lançamento de empréstimos nativos de BTC com taxa fixa no quarto trimestre.
A cadeia do produto vai ficar assim: a Babylon cuida da infraestrutura de custódia de BTC, o Aave cuida do mercado de empréstimos, o Aegis cuida do produto de taxa fixa; do lado de fora, talvez ainda seja necessário conectar carteiras, front-end, oráculos e mecanismos de liquidação.
O que o usuário vê é “BTC nativo, auto-custódia, sem ponte”. O que o atacante vê, porém, são “emendas” e pontos de responsabilidade entre múltiplos sistemas.
Os problemas de segurança da Babylon divulgados pela OpenZeppelin este ano justamente se concentram nesse tipo de junção: colateral vencido ainda mantém poder de voto, Finality Provider contorna a prisão, anomalias na contabilidade de Co-Staking levam à congelação de fundos e até ao colapso do validador. A equipe corrigiu a tempo, de fato, mas isso só reforça que problemas de fronteira não são risco meramente teórico.
Eu não questiono se a Babylon tem auditoria; eu questiono quem fica responsável por incidentes “entre componentes” quando o negócio continua empilhando componentes de terceiros.
Segurança não pode ser medida apenas por saber se um repositório isolado tem vulnerabilidades. Quando o problema realmente acontece, muitas vezes cada parte consegue provar que o próprio código está correto — mas no fim ninguém consegue garantir que o dinheiro do usuário esteja seguro.
#baby $BABY @BabylonLabs_io