Quando eu desmontava o processo de liquidação do TBV do @BabylonLabs_io , a sensação mais direta era esta: o liquidador não ganha “arbitragem em nível de segundos”, e sim assume uma parte do risco por um certo período.
Suponha que o BTC caia até a linha de liquidação. O liquidator primeiro adianta USDC para pagar a dívida do tomador. O fluxo do contrato e as assinaturas podem ser rápidos. Mas o problema está mais adiante: a documentação menciona o claim delay e o challenge period. Isso significa que o liquidator não recebe imediatamente o BTC dado em garantia; ele precisa esperar o fim da janela. O dinheiro já foi adiantado, o BTC ainda não foi recebido — e, entre um e outro, como o preço se move, o risco fica basicamente com o liquidator.$BTC
Isso é bem diferente da lógica de liquidação do DeFi tradicional. Muitos protocolos de empréstimo fazem em um passo só: quitar a dívida, receber a garantia e capturar o desconto — a janela de risco é bem curta. O TBV, por precisar manter o mecanismo de desafio do BitVM3, divide o fluxo em duas etapas: primeiro paga, depois reclama. Os limites de segurança ficam mais fortes, mas as contas econômicas do liquidator ficam mais complexas.$BABY
Por isso, não dá para olhar apenas o BitVM3 e imaginar que, por ele reduzir muito o custo do desacordo, a liquidação também fica barata. Dispute on-chain é barato, mas não significa que a liquidação também seja barata. O liquidator realmente se importa com alocação de capital, volatilidade do BTC, Gas, custo de oportunidade e se esse período de espera tem compensação suficiente.#baby
Se a compensação não for suficiente, o liquidator pode exigir um desconto maior; com desconto alto, o tomador fica pressionado; se o desconto for baixo demais, talvez ninguém queira liquidar — e o risco de bad debt vai se acumulando no sistema.
O design de liquidação do Babylon TBV não está tentando copiar a experiência “em segundos” do Aave. Em vez disso, ele usa um modelo de segurança mais forte para trocar por um patamar mais alto de exigência de participação. Só quem consegue aceitar o período de espera e a volatilidade do preço vai topar ser esse liquidator.$ETH
Suponha que o BTC caia até a linha de liquidação. O liquidator primeiro adianta USDC para pagar a dívida do tomador. O fluxo do contrato e as assinaturas podem ser rápidos. Mas o problema está mais adiante: a documentação menciona o claim delay e o challenge period. Isso significa que o liquidator não recebe imediatamente o BTC dado em garantia; ele precisa esperar o fim da janela. O dinheiro já foi adiantado, o BTC ainda não foi recebido — e, entre um e outro, como o preço se move, o risco fica basicamente com o liquidator.$BTC
Isso é bem diferente da lógica de liquidação do DeFi tradicional. Muitos protocolos de empréstimo fazem em um passo só: quitar a dívida, receber a garantia e capturar o desconto — a janela de risco é bem curta. O TBV, por precisar manter o mecanismo de desafio do BitVM3, divide o fluxo em duas etapas: primeiro paga, depois reclama. Os limites de segurança ficam mais fortes, mas as contas econômicas do liquidator ficam mais complexas.$BABY
Por isso, não dá para olhar apenas o BitVM3 e imaginar que, por ele reduzir muito o custo do desacordo, a liquidação também fica barata. Dispute on-chain é barato, mas não significa que a liquidação também seja barata. O liquidator realmente se importa com alocação de capital, volatilidade do BTC, Gas, custo de oportunidade e se esse período de espera tem compensação suficiente.#baby
Se a compensação não for suficiente, o liquidator pode exigir um desconto maior; com desconto alto, o tomador fica pressionado; se o desconto for baixo demais, talvez ninguém queira liquidar — e o risco de bad debt vai se acumulando no sistema.
O design de liquidação do Babylon TBV não está tentando copiar a experiência “em segundos” do Aave. Em vez disso, ele usa um modelo de segurança mais forte para trocar por um patamar mais alto de exigência de participação. Só quem consegue aceitar o período de espera e a volatilidade do preço vai topar ser esse liquidator.$ETH