Cofres de Bitcoin sem confiança: após a integração do Aave v4, o lado da Ethereum não obtém um “BTC embrulhado” livremente negociável, mas sim um registro interno de garantia com restrições.
O BTC nativo permanece bloqueado no cofre Bitcoin Taproot. Após a ativação do cofre, o Vault Manager informa o adaptador do Aave v4, que, por sua vez, cria registros de garantia de acordo com a quantidade bloqueada, entregando-os ao Babylon Core Spoke para reconhecer e utilizar.
Esse registro não pode ser transferido para qualquer endereço, não existe mercado secundário e ele não sai do contrato do adaptador. Ele serve apenas para provar “quantos BTC de fato estão bloqueados no Bitcoin”, sem reemitir o BTC como um token negociável. Portanto, o Aave consegue usar esses registros para realizar empréstimos e liquidações, mas não pode transferir, emprestar novamente ou desviar os BTC subjacentes.
Aqui também há concessões claras: cada cofre é vinculado a um aplicativo específico no momento de sua criação e, depois disso, não pode ser migrado diretamente para outros protocolos; no futuro, ao integrar stablecoins, opções ou seguros, será necessário ter adaptadores próprios e cofres correspondentes. O caminho dos fundos fica mais curto e o espaço para reestabelecimento e contágio de riscos diminui, mas a liquidez entre aplicações também fica limitada.
Se algum “BTC nativo em garantia” ainda permitir que a mesma quantia de BTC circule livremente entre vários aplicativos, então é preciso revalidar o caminho dos fundos — pois isso já não é o modelo de registro restrito descrito aqui.
Ao avaliar TBV, o ponto-chave não é apenas “se o BTC foi para a Ethereum”, mas sim diferenciar: a Ethereum recebe o próprio ativo ou apenas um registro de garantia que só pode ser usado dentro do aplicativo especificado.
@BabylonLabs_io $BABY #baby
O BTC nativo permanece bloqueado no cofre Bitcoin Taproot. Após a ativação do cofre, o Vault Manager informa o adaptador do Aave v4, que, por sua vez, cria registros de garantia de acordo com a quantidade bloqueada, entregando-os ao Babylon Core Spoke para reconhecer e utilizar.
Esse registro não pode ser transferido para qualquer endereço, não existe mercado secundário e ele não sai do contrato do adaptador. Ele serve apenas para provar “quantos BTC de fato estão bloqueados no Bitcoin”, sem reemitir o BTC como um token negociável. Portanto, o Aave consegue usar esses registros para realizar empréstimos e liquidações, mas não pode transferir, emprestar novamente ou desviar os BTC subjacentes.
Aqui também há concessões claras: cada cofre é vinculado a um aplicativo específico no momento de sua criação e, depois disso, não pode ser migrado diretamente para outros protocolos; no futuro, ao integrar stablecoins, opções ou seguros, será necessário ter adaptadores próprios e cofres correspondentes. O caminho dos fundos fica mais curto e o espaço para reestabelecimento e contágio de riscos diminui, mas a liquidez entre aplicações também fica limitada.
Se algum “BTC nativo em garantia” ainda permitir que a mesma quantia de BTC circule livremente entre vários aplicativos, então é preciso revalidar o caminho dos fundos — pois isso já não é o modelo de registro restrito descrito aqui.
Ao avaliar TBV, o ponto-chave não é apenas “se o BTC foi para a Ethereum”, mas sim diferenciar: a Ethereum recebe o próprio ativo ou apenas um registro de garantia que só pode ser usado dentro do aplicativo especificado.
@BabylonLabs_io $BABY #baby