Não existe uma chave de emergência escondida por trás do output de staking Taproot da Babylon.

Esse foi o detalhe para o qual eu voltava repetidamente.

A maioria das construções Taproot preserva um caminho de gasto de chave ao lado das suas condições de script. A Babylon faz o contrário. Ela usa o ponto Nothing-Up-My-Sleeve descrito no BIP341 como a chave interna do output.

Ninguém conhece a chave privada por trás desse ponto, o que torna o caminho de chave inutilizável.

Portanto, o BTC só pode se mover através dos três scripts comprometidos na criação: saque por timelock, desatrelamento com auxílio de covenant, ou slashing após as condições exigidas serem satisfeitas.

No início, remover o fallback parecia uma melhoria de segurança óbvia. Nenhum proprietário, operador ou signatário de emergência consegue burlar as regras de saída do protocolo mais tarde.

Mas essa certeza corta os dois lados.

Um caminho de chave utilizável dá a alguém discricionariedade quando o projeto original encontra uma falha inesperada. A Babylon elimina essa discricionariedade completamente e torna os scripts comprometidos a autoridade final sobre cada possível saída.

O design é mais difícil de contornar, mas também é menos tolerante.

Acho que a pergunta real não é se a chave ausente impede atalhos. Isso claramente impede. A questão é o que acontece quando um atalho é exatamente o que a recuperação teria precisado. Tomara que seja assim.
@BabylonLabs_io #baby $BABY
$ON $COTI