#baby $BABY Eu foquei em “2 tipos de expiração, 2 conjuntos de responsabilidade, e a mesma via de reembolso do principal” e reestruturei para uma versão mais parecida com um relato real de operação:
Eu organizei o processo de abertura (build) da rede de testes pública atual em ordem cronológica e só então percebi que o que mais costuma confundir não é “quanto tempo esperar”, e sim “quem não completou a ação”: a expiração de ~24 horas ou a de ~48 horas. Em ambos os casos, o cofre (vault) acaba expirando, mas o resultado do custo é diferente. Em condições normais, o Pre-PegIn primeiro espera 12 confirmações na Bitcoin Signet, o que leva cerca de 120 minutos; as assinaturas off-chain e a confirmação das partes envolvidas acontecem em paralelo, então a estimativa de uma abertura completa fica em ~2 horas.
O 1º tipo de expiração acontece na fase de ACK. Se as partes necessárias não tiverem concluído o preparo em cerca de 24 horas, isso significa que o fluxo do lado do protocolo não foi concluído e a taxa de build na rede de testes é automaticamente reembolsada. O BTC do usuário não “some”; ele apenas fica temporariamente parado na saída do Pre-PegIn e precisa aguardar a abertura do bloqueio de tempo para o reembolso.
O 2º tipo é diferente: o preparo off-chain já foi concluído e o estado já entrou em Verified, mas o usuário não ativou ativamente dentro de ~48 horas após a criação. Nesse caso, o cofre também expira, porém o trabalho de coordenação anterior já ocorreu, então a taxa de build não é reembolsada. O que se perde é a taxa da rede de testes — não o principal em BTC.
Atualmente, o tRefund está configurado para 3 dias. Depois que o bloqueio de tempo expira, o usuário só precisa assinar com a chave Bitcoin original para retirar o BTC pelo caminho de reembolso predefinido, sem precisar de Vault Provider ou outras partes envolvidas. Esses 3 dias também não são um “atraso de propósito”: é para deixar o período de ativação normal terminar primeiro, evitando que a mesma transação de BTC exista simultaneamente em duas rotas conflitantes — “continuar construindo” e “reembolsar antecipadamente”. @BabylonLabs_io , na prática, separa bem as responsabilidades: se o sistema não estiver pronto, devolve a taxa; se o usuário não concluir a última etapa, não devolve — mas o principal fica preservado e o usuário consegue recuperar pelo caminho de saída unilateral. O front-end realmente deveria mostrar não só “expirado”, mas também em que etapa ele ficou, se há reembolso de taxa, quanto tempo falta para recuperar e qual assinatura a próxima etapa exige.#baby $BABY
Eu organizei o processo de abertura (build) da rede de testes pública atual em ordem cronológica e só então percebi que o que mais costuma confundir não é “quanto tempo esperar”, e sim “quem não completou a ação”: a expiração de ~24 horas ou a de ~48 horas. Em ambos os casos, o cofre (vault) acaba expirando, mas o resultado do custo é diferente. Em condições normais, o Pre-PegIn primeiro espera 12 confirmações na Bitcoin Signet, o que leva cerca de 120 minutos; as assinaturas off-chain e a confirmação das partes envolvidas acontecem em paralelo, então a estimativa de uma abertura completa fica em ~2 horas.
O 1º tipo de expiração acontece na fase de ACK. Se as partes necessárias não tiverem concluído o preparo em cerca de 24 horas, isso significa que o fluxo do lado do protocolo não foi concluído e a taxa de build na rede de testes é automaticamente reembolsada. O BTC do usuário não “some”; ele apenas fica temporariamente parado na saída do Pre-PegIn e precisa aguardar a abertura do bloqueio de tempo para o reembolso.
O 2º tipo é diferente: o preparo off-chain já foi concluído e o estado já entrou em Verified, mas o usuário não ativou ativamente dentro de ~48 horas após a criação. Nesse caso, o cofre também expira, porém o trabalho de coordenação anterior já ocorreu, então a taxa de build não é reembolsada. O que se perde é a taxa da rede de testes — não o principal em BTC.
Atualmente, o tRefund está configurado para 3 dias. Depois que o bloqueio de tempo expira, o usuário só precisa assinar com a chave Bitcoin original para retirar o BTC pelo caminho de reembolso predefinido, sem precisar de Vault Provider ou outras partes envolvidas. Esses 3 dias também não são um “atraso de propósito”: é para deixar o período de ativação normal terminar primeiro, evitando que a mesma transação de BTC exista simultaneamente em duas rotas conflitantes — “continuar construindo” e “reembolsar antecipadamente”. @BabylonLabs_io , na prática, separa bem as responsabilidades: se o sistema não estiver pronto, devolve a taxa; se o usuário não concluir a última etapa, não devolve — mas o principal fica preservado e o usuário consegue recuperar pelo caminho de saída unilateral. O front-end realmente deveria mostrar não só “expirado”, mas também em que etapa ele ficou, se há reembolso de taxa, quanto tempo falta para recuperar e qual assinatura a próxima etapa exige.#baby $BABY