Na primeira vez em que coloquei BTC nativo em Aave v4 na rede de testes e depois emprestei os ativos de teste, eu fiquei o tempo todo de olho no fator de saúde. Achei que, enquanto eu não tocasse na linha de liquidação, essa posição estaria segura. Só quando fui avançando até a etapa de pagamento e resgate é que percebi que tinha entendido apenas metade.

Nos Trustless Bitcoin Vaults (TBV) de @BabylonLabs_io , na verdade rodam algumas “camadas” ao mesmo tempo: do lado do Aave, monitora-se se a posição agora está ou não insolvente; a janela de prova e desafio precisa confirmar que estados como empréstimo, pagamento e liquidação não foram forjados; e a ordem de confirmação do Bitcoin, por sua vez, é o que “fixa” o resultado que já aconteceu. A primeira camada impede bagunça no momento; a segunda impede reviravoltas depois. Não é algo que se resolva simplesmente colocando mais ativos.

Isso também explica por que os TBVs me atraem mais do que BTC embalado ou empréstimos com custódia. Em soluções tradicionais, normalmente é necessário entregar primeiro $BTC e então depender do livro-razão da custódia ou de provas de saldo de ativos cross-chain; já o TBV não move o UTXO nativo. Em vez disso, ele usa condições predefinidas de gasto e provas criptográficas para responder: esse BTC, neste momento, pode ser gasto por quem e em que estado. $ETH

Mas a rede de testes também revelou um problema bem prático: durante a espera, se a página mostrar apenas “processando”, o usuário nem sabe se está esperando a confirmação do Bitcoin, a geração de prova, ou se está no período de desafio. Eu sugiro exibir separadamente as três etapas, o tempo restante e os riscos correspondentes. Senão, tecnicamente está tudo bem separado, mas para o usuário ainda parece uma grande sopa.
$BABY #baby

Se você usasse empréstimo com garantia de BTC nativo, o que você mais valoriza?