O controle de casacos no casamento em que trabalhei usava tíquetes de papel numerados — rasgue uma metade, mantenha a outra, um casaco por número. Simples, desde que a máquina só imprimisse cada número uma vez.
Travou na metade da noite e começou a reimprimir números que já tinham sido liberados. Duas pessoas apareceram segurando o tíquete #114. Só havia um único casaco pendurado sob aquele número.
A palavra que melhor se encaixa, tanto quanto consigo dizer: o tíquete extra — uma reivindicação emitida mais de uma vez, porque o que imprime as reivindicações não verifica o que está realmente pendurado atrás. Tokens de liquid-staking de Bitcoin carregam a mesma exposição: um recibo é cunhado contra um depósito, apenas tão honesto quanto o código que o cunha.
Em março, a vault BRO da Solv Protocol permitiu que um único depósito de 1 BTC cunhasse mais SolvBTC do que deveria. Um bug de reentrância fez com que um único depósito de NFT disparasse um callback que emitia um segundo lote de tokens antes do primeiro mint terminar — a empresa de segurança Halborn rastreou isso até esse caminho de dupla emissão, cerca de US$ 2,7 milhões. Os usuários foram reembolsados, mas por um tempo o token do recibo ficou correndo mais rápido do que o Bitcoin por trás dele.
A integração de staking da Babylon pula a etapa do token-recibo exatamente por esse motivo. Uma vault de BTC apostado leva três condições de gasto pré-assinadas na criação — unstake, liquidate e slashing — aplicadas diretamente pelo próprio script do Bitcoin, e não por um contrato inteligente cunhando uma reivindicação em cima do depósito. Não existe um segundo token que poderia ser emitido duas vezes, porque não há token.
O que eu fico ponderando: a Solv poderia corrigir seu contrato após o exploit e reembolsar os usuários. Uma vault pré-assinada não pode ser corrigida — quaisquer condições que foram assinadas na criação são as condições para a vida daquela vault. Trocar um bug que você consegue corrigir por um erro que você não consegue corrigir é um tipo próprio de risco.
O tíquete #114 é o número que eu ainda lembro, mais do que o casaco em si.
Meu próprio pedido de saque do testnet ainda está parado no período de challenge — vou dar retorno assim que de fato cair na carteira, não apenas no painel.
@BabylonLabs_io $BABY #baby
Travou na metade da noite e começou a reimprimir números que já tinham sido liberados. Duas pessoas apareceram segurando o tíquete #114. Só havia um único casaco pendurado sob aquele número.
A palavra que melhor se encaixa, tanto quanto consigo dizer: o tíquete extra — uma reivindicação emitida mais de uma vez, porque o que imprime as reivindicações não verifica o que está realmente pendurado atrás. Tokens de liquid-staking de Bitcoin carregam a mesma exposição: um recibo é cunhado contra um depósito, apenas tão honesto quanto o código que o cunha.
Em março, a vault BRO da Solv Protocol permitiu que um único depósito de 1 BTC cunhasse mais SolvBTC do que deveria. Um bug de reentrância fez com que um único depósito de NFT disparasse um callback que emitia um segundo lote de tokens antes do primeiro mint terminar — a empresa de segurança Halborn rastreou isso até esse caminho de dupla emissão, cerca de US$ 2,7 milhões. Os usuários foram reembolsados, mas por um tempo o token do recibo ficou correndo mais rápido do que o Bitcoin por trás dele.
A integração de staking da Babylon pula a etapa do token-recibo exatamente por esse motivo. Uma vault de BTC apostado leva três condições de gasto pré-assinadas na criação — unstake, liquidate e slashing — aplicadas diretamente pelo próprio script do Bitcoin, e não por um contrato inteligente cunhando uma reivindicação em cima do depósito. Não existe um segundo token que poderia ser emitido duas vezes, porque não há token.
O que eu fico ponderando: a Solv poderia corrigir seu contrato após o exploit e reembolsar os usuários. Uma vault pré-assinada não pode ser corrigida — quaisquer condições que foram assinadas na criação são as condições para a vida daquela vault. Trocar um bug que você consegue corrigir por um erro que você não consegue corrigir é um tipo próprio de risco.
O tíquete #114 é o número que eu ainda lembro, mais do que o casaco em si.
Meu próprio pedido de saque do testnet ainda está parado no período de challenge — vou dar retorno assim que de fato cair na carteira, não apenas no painel.
@BabylonLabs_io $BABY #baby