Relembrei e revi o guia de migração da rede principal do @Dusk e há um detalhe fácil de ignorar: clicar em <Approve> na carteira não significa que o $DUSK já tenha sido migrado para a rede principal da Dusk. O que realmente dispara a migração é a <Execute transaction> seguinte. Entre as duas etapas, qualquer interrupção pode fazer o usuário achar que os ativos “ficaram travados”.
O procedimento oficial é bloquear o ERC-20 na Ethereum ou o BEP-20 na BNB Chain do DUSK em um contrato de migração e, então, creditar os respectivos tokens nativos na conta da rede principal da Dusk designada. Para isso, o usuário precisa preparar uma carteira EVM auto-hospedada, uma conta na Dusk e pagar as taxas da cadeia de origem em ETH ou BNB; após confirmar a execução da transação, geralmente ainda é necessário aguardar o processamento. Contas de corretoras normalmente não conseguem concluir essa operação diretamente via WalletConnect; é preciso primeiro conectar/indicar uma carteira que a pessoa controle.
O mecanismo em si não é difícil, mas os “buracos” estão todos nos limites de operação. Primeiro, a autorização apenas concede um limite ao contrato; ela não transfere moedas automaticamente. Segundo, o token na cadeia de origem tem 18 casas decimais, enquanto o DUSK na rede principal tem 9; o valor da migração é arredondado para baixo até a menor unidade LUX. A fração menor que 1 LUX fica na carteira original. Terceiro, ao ver que o saldo não chegou, o correto é verificar se a transação <Execute> foi bem-sucedida, em vez de repetir a autorização.
Esse desenho de travamento unidirecional seguido de liberação é mais claro do que fazer o usuário encontrar uma “piscina”/pool cross-chain, mas ainda assim coloca duas redes, duas carteiras e duas confirmações no mesmo fluxo. Para usuários antigos, basta um olhar a mais; para iniciantes, porém, pode levar a entender “autorização concluída” como “migração concluída”. Se o mecanismo de segurança não for explicado claramente pela interface, no fim ainda vira erro humano.
Então, ao migrar meus ativos, o que eu observo na migração da rede principal #dusk não é apenas se o contrato tem auditoria, mas também se a carteira exibe simultaneamente o passo atual, o hash da cadeia de origem, o status de processamento previsto e o endereço de recebimento. A documentação oficial fornece um caminho de verificação bem definido—isso já é um ponto positivo. O próximo passo deve ser incorporar esses avisos em cada botão-chave, em vez de esperar o usuário falhar e então mandar consultar o Central de Ajuda.
Ao migrar seus ativos, qual etapa você teme mais: a autorização, escolher a rede errada ou o status de recebimento não ser transparente? Conte quais “armadilhas” você já encontrou ao operar.
$ACE $BTC
O procedimento oficial é bloquear o ERC-20 na Ethereum ou o BEP-20 na BNB Chain do DUSK em um contrato de migração e, então, creditar os respectivos tokens nativos na conta da rede principal da Dusk designada. Para isso, o usuário precisa preparar uma carteira EVM auto-hospedada, uma conta na Dusk e pagar as taxas da cadeia de origem em ETH ou BNB; após confirmar a execução da transação, geralmente ainda é necessário aguardar o processamento. Contas de corretoras normalmente não conseguem concluir essa operação diretamente via WalletConnect; é preciso primeiro conectar/indicar uma carteira que a pessoa controle.
O mecanismo em si não é difícil, mas os “buracos” estão todos nos limites de operação. Primeiro, a autorização apenas concede um limite ao contrato; ela não transfere moedas automaticamente. Segundo, o token na cadeia de origem tem 18 casas decimais, enquanto o DUSK na rede principal tem 9; o valor da migração é arredondado para baixo até a menor unidade LUX. A fração menor que 1 LUX fica na carteira original. Terceiro, ao ver que o saldo não chegou, o correto é verificar se a transação <Execute> foi bem-sucedida, em vez de repetir a autorização.
Esse desenho de travamento unidirecional seguido de liberação é mais claro do que fazer o usuário encontrar uma “piscina”/pool cross-chain, mas ainda assim coloca duas redes, duas carteiras e duas confirmações no mesmo fluxo. Para usuários antigos, basta um olhar a mais; para iniciantes, porém, pode levar a entender “autorização concluída” como “migração concluída”. Se o mecanismo de segurança não for explicado claramente pela interface, no fim ainda vira erro humano.
Então, ao migrar meus ativos, o que eu observo na migração da rede principal #dusk não é apenas se o contrato tem auditoria, mas também se a carteira exibe simultaneamente o passo atual, o hash da cadeia de origem, o status de processamento previsto e o endereço de recebimento. A documentação oficial fornece um caminho de verificação bem definido—isso já é um ponto positivo. O próximo passo deve ser incorporar esses avisos em cada botão-chave, em vez de esperar o usuário falhar e então mandar consultar o Central de Ajuda.
Ao migrar seus ativos, qual etapa você teme mais: a autorização, escolher a rede errada ou o status de recebimento não ser transparente? Conte quais “armadilhas” você já encontrou ao operar.
$ACE $BTC
