O robô de liquidação não tem tesoura: só sabe levar tudo em caixas. Quando vi que a rede de testes atual com o número @BabylonLabs_io transformou cada Vault em um UTXO independente, entendi: dual-Vault não é uma opção de depósito bonita — é algo feito para transformar perdas de liquidação em “partículas”.
Em DeFi comum, o colateral pode ser dividido proporcionalmente. Mas, em transações do Bitcoin, você só consegue gastar uma saída por vez. Suponha que a posição tenha 0,4 BTC: a liquidação só precisaria lidar com cerca de 0,25 BTC. Se esses 0,4 BTC estiverem inteiramente dentro de um único Vault, o protocolo não consegue “recortar” dali os 0,25 BTC; só pode incluir o Vault inteiro na liquidação. O valor excedente não desaparece magicamente: o mecanismo de justiça primeiro reduz a dívida restante do usuário; se ainda houver saldo, devolve em WBTC. Mas “receber compensação equivalente” e “manter BTC nativo ainda na própria posição” obviamente não são a mesma coisa.
É aí que o dual-Vault realmente é útil. Pelos parâmetros atuais da rede de testes pública, o fator de colateral é de 78%, o fator de saúde alvo é 1,24 e, quando a posição acaba de tocar a liquidação, a estimativa da documentação indica que a quantidade alvo a ser retirada equivale a cerca de 62% do valor em BTC. O Portal, de acordo com os parâmetros em tempo real, coloca primeiro os Vaults de sacrifício maiores; o BTC restante vai para o Vault de proteção. O procedimento de liquidação verifica, a partir do início da lista, Vault por Vault: quando o primeiro já é suficiente, ele para; o segundo continua na posição.
Portanto, não é um “anti-liquidação” do tipo神器; é mais como uma porta estanque no porão: ainda haverá perdas se acontecer algum problema, mas tenta impedir que a perda afunde o navio inteiro. Se a queda de mercado for rápida demais, se o tamanho do Vault de sacrifício não for suficiente ou se a ordem estiver trocada, o sistema ainda pode continuar levando o próximo Vault; 62/38 também não é uma fórmula permanente — após mudanças de parâmetros, é preciso revisar novamente como o Portal fará a divisão.
Eu prefiro chamar esse design de gerenciamento de granularidade de perdas. O que o tomador realmente precisa observar, além do fator de saúde, é o tamanho do seu Vault e a ordem de disposição. Você aceitaria um gerenciamento de posição mais complexo para preservar o Vault de BTC nativo da segunda casa?
#baby $BABY
Em DeFi comum, o colateral pode ser dividido proporcionalmente. Mas, em transações do Bitcoin, você só consegue gastar uma saída por vez. Suponha que a posição tenha 0,4 BTC: a liquidação só precisaria lidar com cerca de 0,25 BTC. Se esses 0,4 BTC estiverem inteiramente dentro de um único Vault, o protocolo não consegue “recortar” dali os 0,25 BTC; só pode incluir o Vault inteiro na liquidação. O valor excedente não desaparece magicamente: o mecanismo de justiça primeiro reduz a dívida restante do usuário; se ainda houver saldo, devolve em WBTC. Mas “receber compensação equivalente” e “manter BTC nativo ainda na própria posição” obviamente não são a mesma coisa.
É aí que o dual-Vault realmente é útil. Pelos parâmetros atuais da rede de testes pública, o fator de colateral é de 78%, o fator de saúde alvo é 1,24 e, quando a posição acaba de tocar a liquidação, a estimativa da documentação indica que a quantidade alvo a ser retirada equivale a cerca de 62% do valor em BTC. O Portal, de acordo com os parâmetros em tempo real, coloca primeiro os Vaults de sacrifício maiores; o BTC restante vai para o Vault de proteção. O procedimento de liquidação verifica, a partir do início da lista, Vault por Vault: quando o primeiro já é suficiente, ele para; o segundo continua na posição.
Portanto, não é um “anti-liquidação” do tipo神器; é mais como uma porta estanque no porão: ainda haverá perdas se acontecer algum problema, mas tenta impedir que a perda afunde o navio inteiro. Se a queda de mercado for rápida demais, se o tamanho do Vault de sacrifício não for suficiente ou se a ordem estiver trocada, o sistema ainda pode continuar levando o próximo Vault; 62/38 também não é uma fórmula permanente — após mudanças de parâmetros, é preciso revisar novamente como o Portal fará a divisão.
Eu prefiro chamar esse design de gerenciamento de granularidade de perdas. O que o tomador realmente precisa observar, além do fator de saúde, é o tamanho do seu Vault e a ordem de disposição. Você aceitaria um gerenciamento de posição mais complexo para preservar o Vault de BTC nativo da segunda casa?
#baby $BABY
