Eu estava tentando responder uma pergunta básica sobre os Babylon Trustless Bitcoin Vaults (TBV): depois de um tomador quitar o empréstimo, quanto tempo até o BTC nativo voltar a ser utilizável?
A quitação não o libera. Ela apenas inicia o resgate. Então, o TBV faz uma solicitação na rede Bitcoin, pedindo que o cofre libere o BTC.
Essa solicitação permanece aberta por 432 blocos de Bitcoin. Cerca de 3 dias.
Nesse intervalo, os Universal Challengers e Vault Keepers inspecionam a solicitação. Uma falha válida pode interromper o pagamento. Se não encontrarem nada, o BTC é liberado depois que a janela fecha.
A configuração de 432 blocos pertence à versão atual em public-testnet do Babylon. Por enquanto, diferentes tamanhos de resgate usam a mesma janela.
Um cofre de 0,01 BTC espera 432 blocos. Um cofre de 0,1 BTC também.
Isso pareceu razoável. Todo sistema otimista precisa de tempo para que alguém levante uma objeção.
Depois percebi o que o parâmetro realmente está fazendo.
O TBV não mede uma solicitação, decide o quão arriscada ela parece e então escolhe quanto tempo esperar. A espera já existe. A solicitação chega depois e herda isso.
Assim, uma saída pequena e uma saída muito maior compram a mesma quantidade de tempo de verificação. Não porque os riscos são iguais. Mas porque o protocolo escolheu um único preço fixo para a incerteza.
O usuário paga esse preço com a perda de acesso ao BTC.
A posição de empréstimo é encerrada. O ativo nativo ainda fica bloqueado. Por cerca de 3 dias, ele não consegue suportar outro empréstimo, cobrir uma chamada de margem, fazer hedge de uma posição ou sair durante uma queda.
O número de blocos fica fixo. O custo não.
Um mercado tranquilo pode tornar 432 blocos “baratos”. Um mercado violento pode tornar a mesma espera brutal.
Entendo a compensação. Uma janela fixa é mais fácil de auditar. O timing dinâmico poderia criar novas superfícies de ataque se alguém manipulasse os sinais usados para rotular uma solicitação como baixo risco.
Ainda assim, a escolha de design é direta.
O TBV aplica o mesmo imposto de tempo a riscos que não são iguais.
Mais do que isso, ele faz com que toda saída honesta financie, por padrão, a pior desconfiança possível do protocolo.
Se o TBV não consegue precificar cada resgate separadamente, então cada usuário deveria pagar como se o seu pudesse ser o arriscado?
$ON $BABY #baby @BabylonLabs_io
A quitação não o libera. Ela apenas inicia o resgate. Então, o TBV faz uma solicitação na rede Bitcoin, pedindo que o cofre libere o BTC.
Essa solicitação permanece aberta por 432 blocos de Bitcoin. Cerca de 3 dias.
Nesse intervalo, os Universal Challengers e Vault Keepers inspecionam a solicitação. Uma falha válida pode interromper o pagamento. Se não encontrarem nada, o BTC é liberado depois que a janela fecha.
A configuração de 432 blocos pertence à versão atual em public-testnet do Babylon. Por enquanto, diferentes tamanhos de resgate usam a mesma janela.
Um cofre de 0,01 BTC espera 432 blocos. Um cofre de 0,1 BTC também.
Isso pareceu razoável. Todo sistema otimista precisa de tempo para que alguém levante uma objeção.
Depois percebi o que o parâmetro realmente está fazendo.
O TBV não mede uma solicitação, decide o quão arriscada ela parece e então escolhe quanto tempo esperar. A espera já existe. A solicitação chega depois e herda isso.
Assim, uma saída pequena e uma saída muito maior compram a mesma quantidade de tempo de verificação. Não porque os riscos são iguais. Mas porque o protocolo escolheu um único preço fixo para a incerteza.
O usuário paga esse preço com a perda de acesso ao BTC.
A posição de empréstimo é encerrada. O ativo nativo ainda fica bloqueado. Por cerca de 3 dias, ele não consegue suportar outro empréstimo, cobrir uma chamada de margem, fazer hedge de uma posição ou sair durante uma queda.
O número de blocos fica fixo. O custo não.
Um mercado tranquilo pode tornar 432 blocos “baratos”. Um mercado violento pode tornar a mesma espera brutal.
Entendo a compensação. Uma janela fixa é mais fácil de auditar. O timing dinâmico poderia criar novas superfícies de ataque se alguém manipulasse os sinais usados para rotular uma solicitação como baixo risco.
Ainda assim, a escolha de design é direta.
O TBV aplica o mesmo imposto de tempo a riscos que não são iguais.
Mais do que isso, ele faz com que toda saída honesta financie, por padrão, a pior desconfiança possível do protocolo.
Se o TBV não consegue precificar cada resgate separadamente, então cada usuário deveria pagar como se o seu pudesse ser o arriscado?
$ON $BABY #baby @BabylonLabs_io