A primeira vez que simulei o Babylon TBV, passei 20 minutos redimensionando dois Vaults... e percebi que eu tinha entendido o jogo errado desde o começo.
Tentei 10.000 USD em colateral de BTC, com um Collateral Factor de 78%, tomando 7.000 USD.
O Health Factor ficou em torno de 1,11.
queda de preço de 15% → HF cai para aproximadamente 0,95 → Estado Liquidável.
parece simples, né?
não.
O problema real começou quando eu dividi a posição em um Vault Sacrificial e um Vault Protected.
Um Vault equivale a um UTXO, então a Indivisibilidade do UTXO transforma a Liquidação numa questão da ordem de execução, não apenas do tamanho do colateral.
Um Vault único é mais fácil de entender, mas esbarra no Liquidation Cliff.
A divisão em dois Vaults suaviza o impacto, mas introduz Risco de Configuração do Vault, Risco de Ordenação dos Vaults e até Risco Operacional.
Eu inverti os dois Vaults algumas vezes... uma mudança pequena foi suficiente para alterar a Minimum Liquidation Unit, o Target Seizure Amount e quais ativos poderiam ser reivindicados primeiro.
Honestamente, é aqui que o TBV fica fascinante e irritante ao mesmo tempo.
@BabylonLabs_io
pode otimizar a UI, sugerir Reordenação de Vaults e calcular Target Health Factor ou Liquidation Bonus.
mas o Oracle Price não pergunta se você entendeu o sistema.
A velocidade do Liquidation Bot não vai esperar você terminar seu café.
O tempo de confirmação se importa ainda menos com o fato de você planejar ajustar um Vault cinco minutos depois.
O Fairness Payment pode devolver o Sobre-Sequestro (Over-Seizure Surplus), e eu respeito isso.
mas compensação é compensação, caminho de execução é caminho de execução... não é a mesma coisa.
O que eu quero observar agora é a Average Over-Seizure Ratio, o Liquidation Count, o tempo de liquidação e o que acontece quando um verdadeiro Mainnet Stress Test chegar.
porque, para mim, o melhor protocolo não é o que esconde a complexidade da melhor forma.
é o que faz os usuários entenderem qual parte dos ativos deles recebe prioridade na execução.
se a Liquidação de Posição Parcial não puder existir naturalmente por causa da estrutura do UTXO, o protocolo deve absorver essa complexidade... ou os usuários devem gerenciá-la sozinhos?
#baby $BABY @BabylonLabs_io $BEAT $COTI
Tentei 10.000 USD em colateral de BTC, com um Collateral Factor de 78%, tomando 7.000 USD.
O Health Factor ficou em torno de 1,11.
queda de preço de 15% → HF cai para aproximadamente 0,95 → Estado Liquidável.
parece simples, né?
não.
O problema real começou quando eu dividi a posição em um Vault Sacrificial e um Vault Protected.
Um Vault equivale a um UTXO, então a Indivisibilidade do UTXO transforma a Liquidação numa questão da ordem de execução, não apenas do tamanho do colateral.
Um Vault único é mais fácil de entender, mas esbarra no Liquidation Cliff.
A divisão em dois Vaults suaviza o impacto, mas introduz Risco de Configuração do Vault, Risco de Ordenação dos Vaults e até Risco Operacional.
Eu inverti os dois Vaults algumas vezes... uma mudança pequena foi suficiente para alterar a Minimum Liquidation Unit, o Target Seizure Amount e quais ativos poderiam ser reivindicados primeiro.
Honestamente, é aqui que o TBV fica fascinante e irritante ao mesmo tempo.
@BabylonLabs_io
pode otimizar a UI, sugerir Reordenação de Vaults e calcular Target Health Factor ou Liquidation Bonus.
mas o Oracle Price não pergunta se você entendeu o sistema.
A velocidade do Liquidation Bot não vai esperar você terminar seu café.
O tempo de confirmação se importa ainda menos com o fato de você planejar ajustar um Vault cinco minutos depois.
O Fairness Payment pode devolver o Sobre-Sequestro (Over-Seizure Surplus), e eu respeito isso.
mas compensação é compensação, caminho de execução é caminho de execução... não é a mesma coisa.
O que eu quero observar agora é a Average Over-Seizure Ratio, o Liquidation Count, o tempo de liquidação e o que acontece quando um verdadeiro Mainnet Stress Test chegar.
porque, para mim, o melhor protocolo não é o que esconde a complexidade da melhor forma.
é o que faz os usuários entenderem qual parte dos ativos deles recebe prioridade na execução.
se a Liquidação de Posição Parcial não puder existir naturalmente por causa da estrutura do UTXO, o protocolo deve absorver essa complexidade... ou os usuários devem gerenciá-la sozinhos?
#baby $BABY @BabylonLabs_io $BEAT $COTI