Eu fiquei acordado a noite toda ontem conferindo esses detalhes de liquidação e, no caso de <b>BabylonLabs Trustless Bitcoin Vaults</b>, a concepção não é a mesma que eu tinha entendido inicialmente. A maioria das pessoas acha que, quando se combinam vários vaults, fazer empréstimos e, na liquidação, é só descontar uma fatia proporcional de cada vault até completar o valor — mas não é bem assim. O protocolo organiza os vaults que pertencem a cada depositante em uma lista, e na liquidação ele começa descontando um trecho de um "prefixo" (prefix) a partir do começo da lista, até cobrir exatamente a quantia que precisa ser reembolsada. Não é uma distribuição do tipo "chuva para todos" entre todos os vaults. Isso significa que os vaults que ficam no começo da lista têm uma exposição ao risco maior — se você adicionar, aos poucos, vários vaults ao mesmo contrato de empréstimo, provavelmente a primeira leva que entrou é a mais provável de ser liquidada primeiro. Pense como um estoque que é abatido em FIFO (first-in, first-out), em vez de dividir a perda/abatimento de forma média. Essa regra de ordenação é baseada no horário de depósito ou no ID do vault? A documentação não deixa isso bem definido; eu também não encontrei uma definição clara. #baby
Pelo que eu entendo desse mecanismo, na prática eu vou tentar evitar montar um contrato usando muitos vaults pequenos — prefiro poucos vaults maiores correspondendo a esse contrato. O motivo é que, quanto maior a cadeia, mais difícil fica prever em que posição você está na lista. A limitação é que eu também não testei em ambiente real a ordem exata de execução durante uma liquidação. @BabylonLabs_io
Sobre a trajetória posterior a $BABY , minha visão é que esse tipo de detalhe de camada de base dificilmente será precificado diretamente a curto prazo; ele funciona mais como um "relatório de check-up" para instituições que virão depois fazer integração em grande escala. Quanto mais o mecanismo aguentar bem quando alguém se aprofunda nos detalhes, menor fica o limite para que os fluxos de capital maiores queiram se conectar. É uma variável lenta (slow variable), não um catalisador que apareça e se reflita imediatamente em um candle/linha K. Eu não vou rebalancear só porque entendi essa parte — vou mais registrar isso e, quando saírem dados da mainnet e o número de participantes/integrantes, eu reavaliar. Vocês, quando montam contratos com muitos vaults, controlam intencionalmente a quantidade? #baby $BABY $ETH
Pelo que eu entendo desse mecanismo, na prática eu vou tentar evitar montar um contrato usando muitos vaults pequenos — prefiro poucos vaults maiores correspondendo a esse contrato. O motivo é que, quanto maior a cadeia, mais difícil fica prever em que posição você está na lista. A limitação é que eu também não testei em ambiente real a ordem exata de execução durante uma liquidação. @BabylonLabs_io
Sobre a trajetória posterior a $BABY , minha visão é que esse tipo de detalhe de camada de base dificilmente será precificado diretamente a curto prazo; ele funciona mais como um "relatório de check-up" para instituições que virão depois fazer integração em grande escala. Quanto mais o mecanismo aguentar bem quando alguém se aprofunda nos detalhes, menor fica o limite para que os fluxos de capital maiores queiram se conectar. É uma variável lenta (slow variable), não um catalisador que apareça e se reflita imediatamente em um candle/linha K. Eu não vou rebalancear só porque entendi essa parte — vou mais registrar isso e, quando saírem dados da mainnet e o número de participantes/integrantes, eu reavaliar. Vocês, quando montam contratos com muitos vaults, controlam intencionalmente a quantidade? #baby $BABY $ETH