Voltei ontem à seção de DEX dos devidos no whitepaper assumindo que seria apenas a lógica de margem de Lendings rebatizada. Está mais perto do que eu esperava, mas não é idêntica.$BABY
@BabylonLabs_io Um trader deposita BTC IN em um Trustless Bitcoin Vaults (TBV) vault, igual ao lending. Os metadados do vault sincronizam com uma cadeia compatível com perps por meio de uma infraestrutura de light client, e o collBTC é cunhado ali; mas, em vez de lastrear um Loan, ele vira margem para posições longas ou curtas, com o motor de margem dos Protocolos acompanhando PnL e limites de risco diretamente.
A liquidação espelha o padrão de reDemption do lending: queimar o token de margem, enviar uma prova ao vault, aguardar o tempo limite e receber o BTC de volta. A liquidação funciona do mesmo jeito do outro lado, com liquidadores comprando e queimando collBTC quando uma posição cai abaixo dos limites de manutenção.
Eu tinha assumido que o reaproveitamento do primitivo do vault entre lending, stablecoins e perps fazia com que o perfil de risco fosse basicamente o mesmo em todo lugar. Não é: perps carregam volatilidade de PnL que uma posição de lending com valor fixo de Loan não possui.
Na verdade, acho que esta é a escolha de design mais interessante aqui — uma única primitiva de colateral sustentando formatos de risco genuinamente diferentes, em vez de precisar de um design de vault separado para cada caso de uso.
Isso é descrito como um design proposto no whitepaper, e não como algo confirmado ao vivo em algum lugar ainda. Então, o que eu ainda não resolvi é se o acompanhamento de PnL dos motores de margem roda totalmente onchain ou se depende de um componente offchain; o paper não detalha.
#DoYouKnowThis
$EUL $BANK
#baby
@BabylonLabs_io Um trader deposita BTC IN em um Trustless Bitcoin Vaults (TBV) vault, igual ao lending. Os metadados do vault sincronizam com uma cadeia compatível com perps por meio de uma infraestrutura de light client, e o collBTC é cunhado ali; mas, em vez de lastrear um Loan, ele vira margem para posições longas ou curtas, com o motor de margem dos Protocolos acompanhando PnL e limites de risco diretamente.
A liquidação espelha o padrão de reDemption do lending: queimar o token de margem, enviar uma prova ao vault, aguardar o tempo limite e receber o BTC de volta. A liquidação funciona do mesmo jeito do outro lado, com liquidadores comprando e queimando collBTC quando uma posição cai abaixo dos limites de manutenção.
Eu tinha assumido que o reaproveitamento do primitivo do vault entre lending, stablecoins e perps fazia com que o perfil de risco fosse basicamente o mesmo em todo lugar. Não é: perps carregam volatilidade de PnL que uma posição de lending com valor fixo de Loan não possui.
Na verdade, acho que esta é a escolha de design mais interessante aqui — uma única primitiva de colateral sustentando formatos de risco genuinamente diferentes, em vez de precisar de um design de vault separado para cada caso de uso.
Isso é descrito como um design proposto no whitepaper, e não como algo confirmado ao vivo em algum lugar ainda. Então, o que eu ainda não resolvi é se o acompanhamento de PnL dos motores de margem roda totalmente onchain ou se depende de um componente offchain; o paper não detalha.
#DoYouKnowThis
$EUL $BANK
#baby