$ICNT $BLESS
aquilo que continuo a encarar não é nem a própria liquidação.
é que a ordem de um vault dentro da posição Babylon Aave v4 pode, silenciosamente, se tornar uma ordem de prejuízo. o health factor cai abaixo de 1 e o Babylon Core Spoke calcula quanto de colateral precisa ser liquidado.
número limpo.
mas o Bitcoin se importa com o quão “limpo” esse número é?
não realmente.
um único Babylon Trustless Bitcoin Vault ainda é um único UTXO Taproot completo. a camada base do Bitcoin não pode liberar metade dele só porque o déficit do lado do Ethereum saiu como uma fração bem certinha. então o fluxo de liquidação do Babylon começa na lista de vaults ordenados do depositante e pega vaults completos até que a meta de liquidação seja coberta.
pelo visto, aquela pequena reordenação nunca foi apenas cosmética.
ela já estava definindo a prioridade de liquidação.
talvez o primeiro vault seja deliberadamente menor e “sacrificável”, colocado ali para que o vault maior protegido sobreviva.
parece controlado o bastante.
mas e se o vault sacrificial não for suficiente? então o Babylon pega também o próximo vault completo. “Aave calcula o déficit. Bitcoin responde em UTXOs inteiros.”
dívida continua precisa.
o prejuízo ainda chega em pedaços do tamanho de vaults no Babylon, moldados por uma decisão de ordenação feita antes, provavelmente enquanto o health factor parecia completamente bem. e é essa parte que parece um pouco errada na minha cabeça.
porque o evento de liquidação acontece depois. mas a ordem do dano já estava lá antes de qualquer coisa parecer quebrada. então quando é que o risco de liquidação começou de verdade no Babylon?
quando o health factor caiu abaixo de 1?
ou quando eu coloquei, em silêncio, um vault de Bitcoin que seria o primeiro a ir?
@BabylonLabs_io $BABY #baby
aquilo que continuo a encarar não é nem a própria liquidação.
é que a ordem de um vault dentro da posição Babylon Aave v4 pode, silenciosamente, se tornar uma ordem de prejuízo. o health factor cai abaixo de 1 e o Babylon Core Spoke calcula quanto de colateral precisa ser liquidado.
número limpo.
mas o Bitcoin se importa com o quão “limpo” esse número é?
não realmente.
um único Babylon Trustless Bitcoin Vault ainda é um único UTXO Taproot completo. a camada base do Bitcoin não pode liberar metade dele só porque o déficit do lado do Ethereum saiu como uma fração bem certinha. então o fluxo de liquidação do Babylon começa na lista de vaults ordenados do depositante e pega vaults completos até que a meta de liquidação seja coberta.
pelo visto, aquela pequena reordenação nunca foi apenas cosmética.
ela já estava definindo a prioridade de liquidação.
talvez o primeiro vault seja deliberadamente menor e “sacrificável”, colocado ali para que o vault maior protegido sobreviva.
parece controlado o bastante.
mas e se o vault sacrificial não for suficiente? então o Babylon pega também o próximo vault completo. “Aave calcula o déficit. Bitcoin responde em UTXOs inteiros.”
dívida continua precisa.
o prejuízo ainda chega em pedaços do tamanho de vaults no Babylon, moldados por uma decisão de ordenação feita antes, provavelmente enquanto o health factor parecia completamente bem. e é essa parte que parece um pouco errada na minha cabeça.
porque o evento de liquidação acontece depois. mas a ordem do dano já estava lá antes de qualquer coisa parecer quebrada. então quando é que o risco de liquidação começou de verdade no Babylon?
quando o health factor caiu abaixo de 1?
ou quando eu coloquei, em silêncio, um vault de Bitcoin que seria o primeiro a ir?
@BabylonLabs_io $BABY #baby
