Sinceramente, mano, no começo eu achei que construir um cofre de Bitcoin seria algo que terminaria só com um depósito… trancar BTC, emprestar, que simples. Aí eu percebi que o depósito poderia ser dividido em dois cofres, e só essa ideia já abalou minha suposição anterior.

Eu entendi que existiria um cofre “sacrificial”, dimensionado para cobrir o valor esperado de sequestro (seize), e um cofre “protegido” que guardaria o restante do BTC. Como cada cofre é um único UTXO de Bitcoin, e o protocolo só consegue sequestrar o cofre inteiro, não uma parte dele. Só essa ideia… pareceu que poderia mudar totalmente a forma como eu entendi o modelo de liquidação.

Sem dividir, o depósito inteiro fica em um cofre, então até o menor sequestro leva tudo. Com dois cofres dimensionados do jeito certo, o menor sequestro talvez só toque no primeiro cofre.

Eu fiquei pensando nisso por um tempo porque significava que a proteção não é automática… ela depende de o depositante ter dimensionado a divisão com precisão e de a sequência dos cofres continuar correta ao longo do tempo. Parecia que adicionar um terceiro cofre depois, ou mudar o fator de saúde (health factor) alvo, poderia exigir reordenar essa sequência também. Isso quer dizer que não é uma estrutura “configura e esquece”… quem estiver com a posição pode precisar de gestão ativa.

É aí que a pergunta real ficou escondida pra mim. Se a segurança do BTC durante a liquidação depende de quão bem o cofre foi estruturado desde o início, então quanto disso é proteção de nível de protocolo, e quanto é simplesmente devolver a responsabilidade ao usuário, só que embrulhada em nomes técnicos.

Não estou chamando isso de falha, mas parece que existe um trade-off que vale a pena nomear diretamente antes de depositar BTC de verdade através de @BabylonLabs_io. Você confiaria em você mesmo para dimensionar essa divisão corretamente na primeira vez? 🤔🧵
@BabylonLabs_io #baby $BABY

$BTC

$DEXE