Entrei no guia da ponte DuskEVM em busca de informações sobre o timing de saques.
A linha da taxa foi o que me fez parar.
Mover DUSK para o fluxo atual de teste do DuskEVM é relativamente simples: envie o depósito na Dusk L1 e depois aguarde o saldo aparecer no DuskEVM.
Voltar é diferente.
Um saque exige três ações separadas:
Iniciar no DuskEVM.
Comprovar na Dusk L1.
Finalizar na Dusk L1.
A carteira pode passar por “Aguardando proposta de saída”, “Pronto para comprovar”, “Prova enviada” e “Aguardando finalização” antes que o DUSK seja liberado.
Essa parte faz sentido. A jornada de retorno é onde o DuskDS verifica o estado que vem da camada EVM.
Mas então notei que o usuário também precisa ter DUSK não blindado suficiente na L1 para pagar tanto a transação de prova quanto a de finalização.
Ou seja, alguém pode manter DUSK dentro do DuskEVM, começar a movê-lo de volta e ainda assim precisar de um saldo utilizável separado na L1 para concluir a saída.
Os fundos não estão necessariamente presos. O usuário pode simplesmente estar sem o ativo necessário para finalizar a comprovação de que tem permissão para recuperá-los.
Isso parece um requisito técnico pequeno até que o DuskEVM seja usado por alguém que nunca mexeu diretamente com a Dusk L1.
Um desenvolvedor de Solidity pode entender contratos e MetaMask perfeitamente, enquanto o usuário final só vê um saque parado em “Aguardando finalização.”
A documentação do Dusk é cuidadosa aqui. Ela orienta os usuários a seguirem o status da carteira, em vez de estimar a prontidão apenas pelo tempo decorrido.
Agora estou observando o quanto disso sobrevive até a experiência final em produção.
Os usuários ainda vão gerenciar manualmente três transações e duas taxas da L1, ou a carteira vai abstrair o processo sem esconder em qual etapa de liquidação o dinheiro deles realmente chegou?
A ponte não está apenas movendo DUSK entre camadas. É onde a interface familiar do DuskEVM encontra a liquidação nativa do Dusk, e onde essa diferença se torna impossível de ignorar.
@Dusk $DUSK #dusk
A linha da taxa foi o que me fez parar.
Mover DUSK para o fluxo atual de teste do DuskEVM é relativamente simples: envie o depósito na Dusk L1 e depois aguarde o saldo aparecer no DuskEVM.
Voltar é diferente.
Um saque exige três ações separadas:
Iniciar no DuskEVM.
Comprovar na Dusk L1.
Finalizar na Dusk L1.
A carteira pode passar por “Aguardando proposta de saída”, “Pronto para comprovar”, “Prova enviada” e “Aguardando finalização” antes que o DUSK seja liberado.
Essa parte faz sentido. A jornada de retorno é onde o DuskDS verifica o estado que vem da camada EVM.
Mas então notei que o usuário também precisa ter DUSK não blindado suficiente na L1 para pagar tanto a transação de prova quanto a de finalização.
Ou seja, alguém pode manter DUSK dentro do DuskEVM, começar a movê-lo de volta e ainda assim precisar de um saldo utilizável separado na L1 para concluir a saída.
Os fundos não estão necessariamente presos. O usuário pode simplesmente estar sem o ativo necessário para finalizar a comprovação de que tem permissão para recuperá-los.
Isso parece um requisito técnico pequeno até que o DuskEVM seja usado por alguém que nunca mexeu diretamente com a Dusk L1.
Um desenvolvedor de Solidity pode entender contratos e MetaMask perfeitamente, enquanto o usuário final só vê um saque parado em “Aguardando finalização.”
A documentação do Dusk é cuidadosa aqui. Ela orienta os usuários a seguirem o status da carteira, em vez de estimar a prontidão apenas pelo tempo decorrido.
Agora estou observando o quanto disso sobrevive até a experiência final em produção.
Os usuários ainda vão gerenciar manualmente três transações e duas taxas da L1, ou a carteira vai abstrair o processo sem esconder em qual etapa de liquidação o dinheiro deles realmente chegou?
A ponte não está apenas movendo DUSK entre camadas. É onde a interface familiar do DuskEVM encontra a liquidação nativa do Dusk, e onde essa diferença se torna impossível de ignorar.
@Dusk $DUSK #dusk
