Uma suposição pouco realista quando se considera apenas que o usuário pode estar online e assinar a qualquer momento: que o detentor do ativo nunca ficará “offline”.
Quem mantém BTC por longo prazo pode trocar de dispositivo, perder a chave ou, ainda, por situações imprevistas, temporariamente não conseguir lidar com os ativos. Nesse caso, o sistema não pode simplesmente transferir o controle para terceiros com facilidade, nem pode deixar o BTC preso para sempre em um estado em que ninguém consiga operá-lo.
Por isso, quando observo a exploração de TBV pelo @BabylonLabs_io , também penso em como o mecanismo de recuperação deve ser projetado. O usuário consegue definir com antecedência condições de contingência? O processo de recuperação precisa ter um período de espera suficientemente longo? Quando o titular original reaparece, ainda existe a chance de impedir uma execução não prevista? Essas regras devem ser definidas claramente antes do ativo entrar no Vault, e não decididas temporariamente depois de algum problema ocorrer.
Para o ecossistema do #baby , a capacidade de recuperação é tão importante quanto o uso diário. Uma trilha de recuperação excessivamente flexível enfraquece a auto custódia; por outro lado, não ter nenhuma trilha de recuperação pode transformar um único acidente em uma perda permanente.
Um caminho mais razoável é permitir que o usuário defina, antecipadamente, seus próprios limites de segurança: quem pode solicitar a recuperação, quais provas precisam ser atendidas e em quanto tempo isso passa a valer.
À medida que as aplicações relacionadas ao $BABY passam a suportar cada vez mais ativos de longo prazo, o sistema não precisa apenas responder “quem controla o BTC agora”, mas também “como o controle é mantido com segurança quando o titular original não consegue operar”.
Quem mantém BTC por longo prazo pode trocar de dispositivo, perder a chave ou, ainda, por situações imprevistas, temporariamente não conseguir lidar com os ativos. Nesse caso, o sistema não pode simplesmente transferir o controle para terceiros com facilidade, nem pode deixar o BTC preso para sempre em um estado em que ninguém consiga operá-lo.
Por isso, quando observo a exploração de TBV pelo @BabylonLabs_io , também penso em como o mecanismo de recuperação deve ser projetado. O usuário consegue definir com antecedência condições de contingência? O processo de recuperação precisa ter um período de espera suficientemente longo? Quando o titular original reaparece, ainda existe a chance de impedir uma execução não prevista? Essas regras devem ser definidas claramente antes do ativo entrar no Vault, e não decididas temporariamente depois de algum problema ocorrer.
Para o ecossistema do #baby , a capacidade de recuperação é tão importante quanto o uso diário. Uma trilha de recuperação excessivamente flexível enfraquece a auto custódia; por outro lado, não ter nenhuma trilha de recuperação pode transformar um único acidente em uma perda permanente.
Um caminho mais razoável é permitir que o usuário defina, antecipadamente, seus próprios limites de segurança: quem pode solicitar a recuperação, quais provas precisam ser atendidas e em quanto tempo isso passa a valer.
À medida que as aplicações relacionadas ao $BABY passam a suportar cada vez mais ativos de longo prazo, o sistema não precisa apenas responder “quem controla o BTC agora”, mas também “como o controle é mantido com segurança quando o titular original não consegue operar”.