Tentei fixar um único detalhe específico do design dos Trustless Bitcoin Vaults e acabei com duas respostas diferentes de dois textos distintos sobre o mesmo Temp Check. Uma conta descreve o passo pós-liquidação como aberto a liquidadores sem permissão (permissionless), que podem trocar um vault sequestrado por WBTC com um pequeno prêmio para liquidar a dívida do tomador. Outra conta da proposta idêntica descreve um conjunto permissionado de arbitrageurs comprando esses vaults em custódia (escrow). Mesmo mecanismo, mesmo registro de 25 de maio, duas palavras diferentes para quem pode participar.
Isso importa porque permissionless e permissioned não são sinônimos estilísticos em DeFi; eles descrevem quem precisa de aprovação para capturar o spread da liquidação. Se for permissionless, qualquer pessoa com capital pode competir para liquidar, mais próximo de como o Aave já opera hoje. Se for permissioned, algum grupo allowlisted fica entre um vault inadimplente e sua resolução, o que reintroduz exatamente o tipo de gatekeeper que todo o pitch foi construído para evitar.
Eu inclino para que seja permissionless o design pretendido, já que os próprios materiais da Babylon descrevem a camada de vault como removendo consórcios de signatários e controle discricionário em todo o restante do sistema. Mas intenção não é a mesma coisa que uma especificação publicada, e o design de oráculo mais pressupostos completos de confiança foram explicitamente empurrados para um estágio ARFC posterior, em vez de estarem resolvidos agora.
Então qual é: como posso chamar um sistema de trustless quando até o relato externo sobre o seu registro de governança não consegue concordar sobre quem está autorizado a tocar o último passo dele?
O design de liquidação da Babylon provavelmente é permissionless no espírito, mas ainda não é inequívoco no registro público, e essa lacuna entre intenção e documentação vale ser observada antes que o estágio ARFC o bloqueie definitivamente.
@BabylonLabs_io $BABY #baby $BANK
Isso importa porque permissionless e permissioned não são sinônimos estilísticos em DeFi; eles descrevem quem precisa de aprovação para capturar o spread da liquidação. Se for permissionless, qualquer pessoa com capital pode competir para liquidar, mais próximo de como o Aave já opera hoje. Se for permissioned, algum grupo allowlisted fica entre um vault inadimplente e sua resolução, o que reintroduz exatamente o tipo de gatekeeper que todo o pitch foi construído para evitar.
Eu inclino para que seja permissionless o design pretendido, já que os próprios materiais da Babylon descrevem a camada de vault como removendo consórcios de signatários e controle discricionário em todo o restante do sistema. Mas intenção não é a mesma coisa que uma especificação publicada, e o design de oráculo mais pressupostos completos de confiança foram explicitamente empurrados para um estágio ARFC posterior, em vez de estarem resolvidos agora.
Então qual é: como posso chamar um sistema de trustless quando até o relato externo sobre o seu registro de governança não consegue concordar sobre quem está autorizado a tocar o último passo dele?
O design de liquidação da Babylon provavelmente é permissionless no espírito, mas ainda não é inequívoco no registro público, e essa lacuna entre intenção e documentação vale ser observada antes que o estágio ARFC o bloqueie definitivamente.
@BabylonLabs_io $BABY #baby $BANK