Na narrativa do TBV, é dado um peso grande ao “controle final” do usuário: “seu BTC está sempre no seu próprio endereço Taproot”. Mas, ao consultar a documentação técnica, encontrei uma zona cinzenta sobre “finalidade última”, o que faz com que esse “controle final” no eixo do tempo talvez não seja tão absoluto quanto é dito.
O problema está nas próprias características da blockchain do Bitcoin. O resgate e a liquidação do TBV dependem, em essência, da confirmação das transações no Bitcoin. A documentação oficial afirma que o peg-in leva cerca de 3 horas; por trás disso está a necessidade de aguardar 6 confirmações de blocos para garantir que a transação não seja reorganizada pela blockchain do Bitcoin. Essa suposição de segurança, em 99,9% do tempo, não costuma ser problema; porém, historicamente o Bitcoin não é completamente imune a reorganizações profundas. Em 2010 houve um ataque de valor, e em 2013 ocorreu uma bifurcação inesperada. Embora a probabilidade seja extremamente baixa, se uma reorganização profunda acontecer, as transações dos usuários que dependem de “6 confirmações de blocos” podem ser revertidas.
Imagine um cenário extremo: o usuário inicia uma operação de resgate, espera por 6 confirmações de blocos; então, no Aave, o pagamento é recebido e a posição é encerrada. Porém, uma hora depois, a blockchain do Bitcoin sofre uma reorganização profunda; a transação de resgate é revertida e o BTC volta ao endereço cross-chain, enquanto o passivo no Aave já foi zerado. Essa defasagem de tempo e a inconsistência do estado — em um sistema como o TBV que depende da finalidade última externa — é um “cisne negro” inerente, que não pode ser totalmente evitado. Independentemente de quão perfeita seja a lógica dos contratos off-chain, ela não consegue alterar a finalidade probabilística inerente ao Bitcoin.
Isso me fez repensar o pool de seguros ou os mecanismos de resposta a risco do #baby . Se, no futuro, ocorrer esse tipo de situação extrema, o pool de seguros ou os mecanismos de resposta a risco do BABY. Se, no futuro, ocorrer esse tipo de situação extrema, o pool de seguros ou os mecanismos de resposta a risco do BABY. Se, no futuro, ocorrer esse tipo de situação extrema, os detentores de $BABY seriam obrigados a assumir o papel de “emprestador de última instância”? Ou o protocolo tem reservas dedicadas? O modelo de segurança do @BabylonLabs_io , dentro da narrativa de “segurança absoluta”, precisa prever e explicar de forma mais clara esse risco de rabo, com probabilidade muito pequena.