Tentei hoje apontar o mesmo cofre de testnet do TBV para um segundo mercado de empréstimos, depois de encerrar minha posição no Aave v4 — achei que poderia apenas reaplicar o mesmo registro de colateral em outro lugar sem precisar refazer todo o peg-in. Não existe essa opção em lugar nenhum no app. Fui clicando e procurando uma configuração que talvez tivesse perdido, alguma opção para adicionar um segundo protocolo a um cofre existente. Fiz um peg-in totalmente novo do zero só para checar se um cofre recém-criado se comportava de forma diferente. Mesma barreira nas duas vezes.
Fiquei com isso na cabeça até finalmente “clicar”: não é uma funcionalidade ausente, é um limite colocado de propósito. Um cofre, um app, ponto final — e se você quiser um segundo caso de uso, você faz o peg-in de novo do zero.
Eu tinha assumido que o objetivo inteiro de "colateral programável em Bitcoin" era empilhá-lo — o mesmo BTC conectado a quantos protocolos aceitarem, quanto mais composável, melhor. Na prática, é o contrário. Um único cofre exposto a dois apps ao mesmo tempo significa duas lógicas diferentes de liquidação e dois conjuntos diferentes de regras de saída, ambos reivindicando o mesmo BTC. A Babylon não deixou essa porta meio aberta por acidente. Ela está fechada.
Me pareceu como um proprietário que não deixa você sublocar um imóvel enquanto seu próprio contrato ainda está ativo, mesmo para alguém confiável, mesmo que seja por pouco tempo. Não porque o segundo inquilino é arriscado. Mas porque duas pessoas com uma reivindicação simultânea e ativa sobre o mesmo imóvel é o risco real, independentemente de quem sejam.
Faz sentido quando pensei especificamente no Bitcoin. A composabilidade geralmente é o discurso principal do DeFi, mas as condições de gasto de um UTXO ficam fixas no momento em que ele é criado. Dois protocolos em funcionamento significam dois conjuntos de regras de saída tentando governar um único bloqueio ao mesmo tempo, e se em algum momento eles discordarem sobre quem consegue disparar o quê, não existe um “patch” que corrija isso depois — o Bitcoin não faz upgrades em um script que já foi comprometido.
Ainda não tenho certeza se isso é uma limitação da fase de testnet que afrouxa depois, ou um tradeoff permanente — composabilidade que foi deixada de lado de propósito, especificamente porque tem Bitcoin por trás e não um ativo de EVM que consegue absorver esse tipo de complexidade com segurança.
@BabylonLabs_io $BABY #baby
Fiquei com isso na cabeça até finalmente “clicar”: não é uma funcionalidade ausente, é um limite colocado de propósito. Um cofre, um app, ponto final — e se você quiser um segundo caso de uso, você faz o peg-in de novo do zero.
Eu tinha assumido que o objetivo inteiro de "colateral programável em Bitcoin" era empilhá-lo — o mesmo BTC conectado a quantos protocolos aceitarem, quanto mais composável, melhor. Na prática, é o contrário. Um único cofre exposto a dois apps ao mesmo tempo significa duas lógicas diferentes de liquidação e dois conjuntos diferentes de regras de saída, ambos reivindicando o mesmo BTC. A Babylon não deixou essa porta meio aberta por acidente. Ela está fechada.
Me pareceu como um proprietário que não deixa você sublocar um imóvel enquanto seu próprio contrato ainda está ativo, mesmo para alguém confiável, mesmo que seja por pouco tempo. Não porque o segundo inquilino é arriscado. Mas porque duas pessoas com uma reivindicação simultânea e ativa sobre o mesmo imóvel é o risco real, independentemente de quem sejam.
Faz sentido quando pensei especificamente no Bitcoin. A composabilidade geralmente é o discurso principal do DeFi, mas as condições de gasto de um UTXO ficam fixas no momento em que ele é criado. Dois protocolos em funcionamento significam dois conjuntos de regras de saída tentando governar um único bloqueio ao mesmo tempo, e se em algum momento eles discordarem sobre quem consegue disparar o quê, não existe um “patch” que corrija isso depois — o Bitcoin não faz upgrades em um script que já foi comprometido.
Ainda não tenho certeza se isso é uma limitação da fase de testnet que afrouxa depois, ou um tradeoff permanente — composabilidade que foi deixada de lado de propósito, especificamente porque tem Bitcoin por trás e não um ativo de EVM que consegue absorver esse tipo de complexidade com segurança.
@BabylonLabs_io $BABY #baby
