Quando vi pela primeira vez a frase “BTC como garantia DeFi do Ethereum”, eu, sem pensar muito, achei que o processo ainda era do jeito antigo: primeiro transferir o BTC e, depois, gerar na outra rede um ativo correspondente. Só depois que alinhei de ponta a ponta o processo de depósito e resgate do TBV é que percebi que a maior fonte de confusão aqui é justamente para onde o BTC vai.
Quando o usuário cria um Vault, o BTC é bloqueado em uma saída Taproot na rede Bitcoin; ao mesmo tempo, o lado do Ethereum registra um Vault correspondente. O que as aplicações externas leem é se esse BTC ainda está bloqueado sob as condições estabelecidas e se pode continuar sendo usado como garantia, e não o recebimento de um novo BTC que possa ser transferido livremente. A emissão de empréstimos, a devolução e a gestão da garantia acontecem no lado da aplicação; o BTC de verdade permanece sempre no Bitcoin.
A diferença parece um pouco abstrata, mas na prática corresponde a duas lógicas de confiança completamente diferentes. O empacotamento do BTC depende de quem emite garantir que “há mesmo moedas por trás do token on-chain”; a ponte entre cadeias depende de operadores ou validadores manterem corretamente o estado dos dois lados; o objetivo do TBV é permitir que a aplicação valide o próprio Vault, em vez de confiar no balanço patrimonial de alguma instituição.
Acho que essa também é a etapa mais crucial para usuários comuns entenderem o TBV: ele não “leva” o BTC para o DeFi, e sim fornece ao DeFi o estado de garantia do BTC que pode ser verificado.
Claro que o fato de o BTC não atravessar a cadeia não significa automaticamente que a experiência fique mais simples. O usuário ainda precisa lidar com confirmações do Bitcoin, interação com o Ethereum, saúde do empréstimo e o tempo de espera para o resgate. No nível mais baixo, falta uma camada de confiança terceirizada; já no nível de aplicação, aumenta a complexidade operacional. Se o futuro do TBV vai alcançar mais usuários, no fim depende de o projeto conseguir tornar esse fluxo de duas cadeias suficientemente claro—para que a pessoa saiba a qualquer momento onde estão as moedas, qual é o valor da dívida e em que condições é possível resgatar. #baby $BABY @BabylonLabs_io
Quando o usuário cria um Vault, o BTC é bloqueado em uma saída Taproot na rede Bitcoin; ao mesmo tempo, o lado do Ethereum registra um Vault correspondente. O que as aplicações externas leem é se esse BTC ainda está bloqueado sob as condições estabelecidas e se pode continuar sendo usado como garantia, e não o recebimento de um novo BTC que possa ser transferido livremente. A emissão de empréstimos, a devolução e a gestão da garantia acontecem no lado da aplicação; o BTC de verdade permanece sempre no Bitcoin.
A diferença parece um pouco abstrata, mas na prática corresponde a duas lógicas de confiança completamente diferentes. O empacotamento do BTC depende de quem emite garantir que “há mesmo moedas por trás do token on-chain”; a ponte entre cadeias depende de operadores ou validadores manterem corretamente o estado dos dois lados; o objetivo do TBV é permitir que a aplicação valide o próprio Vault, em vez de confiar no balanço patrimonial de alguma instituição.
Acho que essa também é a etapa mais crucial para usuários comuns entenderem o TBV: ele não “leva” o BTC para o DeFi, e sim fornece ao DeFi o estado de garantia do BTC que pode ser verificado.
Claro que o fato de o BTC não atravessar a cadeia não significa automaticamente que a experiência fique mais simples. O usuário ainda precisa lidar com confirmações do Bitcoin, interação com o Ethereum, saúde do empréstimo e o tempo de espera para o resgate. No nível mais baixo, falta uma camada de confiança terceirizada; já no nível de aplicação, aumenta a complexidade operacional. Se o futuro do TBV vai alcançar mais usuários, no fim depende de o projeto conseguir tornar esse fluxo de duas cadeias suficientemente claro—para que a pessoa saiba a qualquer momento onde estão as moedas, qual é o valor da dívida e em que condições é possível resgatar. #baby $BABY @BabylonLabs_io
