Ao migrar de uma versão antiga do DUSK da Ethereum ou BSC para a mainnet, o momento mais fácil de deixar usuários comuns em pânico é este: a carteira já exibiu uma confirmação uma vez, e a blockchain também mostrou sucesso. Então por que o saldo do Dusk na mainnet não mudou?
No processo oficial de migração, essa primeira confirmação pode ser apenas um Approve (autorização). O que realmente inicia a migração é o Execute migration (execução).
Eu entendo essas duas etapas como a autorização de débito pelo banco. Primeiro você permite que uma determinada instituição faça cobranças dentro de um limite; isso não significa que o dinheiro já foi debitado. É necessário também um comando real de débito. Na blockchain, é igual: o Approve apenas concede ao contrato de migração uma quantia autorizada suficiente. O Execute é o que vai travar a quantidade selecionada e começar a migrar. Se o limite já tiver sido suficiente antes, essa etapa de autorização pode até ser ignorada. Por isso, algumas pessoas assinam apenas uma vez, enquanto outras precisam assinar duas vezes — e isso não quer dizer necessariamente que o fluxo de alguém tenha falhado.
Isso é bem diferente da intuição comum de uma transferência no BTC. Não existe a mesma lógica de “primeiro dar limite para o contrato de tokens e depois executar a transferência”. O ponto mais fácil de cair em armadilha é: depois que a primeira autorização é bem-sucedida, normalmente os ativos originais ainda estão na carteira. O usuário vê o status de sucesso e começa a esperar que a mainnet chegue. Na prática, a migração nem chegou a iniciar. O processo oficial exige que você execute a segunda etapa e use a confirmação dessa transação de execução como ponto inicial da contagem do tempo da migração — normalmente cerca de uma hora. Esta etapa é crucial.
Se os ativos vierem da rede ETH, tanto a autorização quanto a execução na cadeia de origem podem gerar custos de rede, então é melhor reservar Gas nativo suficiente. No lado BSC, paga-se com BNB. Além disso, a documentação oficial lembra que contas de exchanges geralmente não conseguem se conectar diretamente a esse fluxo de migração; é necessário primeiro transferir os tokens para uma carteira autocustodiada que consiga ser conectada.
Os passos extras acontecem porque a autorização de tokens na cadeia de origem e a própria migração são duas ações diferentes, e não se trata de uma cobrança duplicada pela mainnet do Dusk.
Mas a analogia tem limites: o limite de autorização on-chain não é uma autorização única “em papel”; o limite pode continuar existindo. Na próxima migração, quando a cota for suficiente, não será exigido um novo Approve. Para o fluxo de @Dusk , o que eu mais espero é que a interface mostre três estados completamente diferentes: “autorização concluída”, “migração iniciada” e “mainnet já creditada”. Para o usuário de $DUSK , quando a primeira etapa foi bem-sucedida, mas não houve crédito, confirmar se o Execute foi realmente enviado para a blockchain é mais importante do que ficar atualizando o saldo repetidamente.
#dusk
No processo oficial de migração, essa primeira confirmação pode ser apenas um Approve (autorização). O que realmente inicia a migração é o Execute migration (execução).
Eu entendo essas duas etapas como a autorização de débito pelo banco. Primeiro você permite que uma determinada instituição faça cobranças dentro de um limite; isso não significa que o dinheiro já foi debitado. É necessário também um comando real de débito. Na blockchain, é igual: o Approve apenas concede ao contrato de migração uma quantia autorizada suficiente. O Execute é o que vai travar a quantidade selecionada e começar a migrar. Se o limite já tiver sido suficiente antes, essa etapa de autorização pode até ser ignorada. Por isso, algumas pessoas assinam apenas uma vez, enquanto outras precisam assinar duas vezes — e isso não quer dizer necessariamente que o fluxo de alguém tenha falhado.
Isso é bem diferente da intuição comum de uma transferência no BTC. Não existe a mesma lógica de “primeiro dar limite para o contrato de tokens e depois executar a transferência”. O ponto mais fácil de cair em armadilha é: depois que a primeira autorização é bem-sucedida, normalmente os ativos originais ainda estão na carteira. O usuário vê o status de sucesso e começa a esperar que a mainnet chegue. Na prática, a migração nem chegou a iniciar. O processo oficial exige que você execute a segunda etapa e use a confirmação dessa transação de execução como ponto inicial da contagem do tempo da migração — normalmente cerca de uma hora. Esta etapa é crucial.
Se os ativos vierem da rede ETH, tanto a autorização quanto a execução na cadeia de origem podem gerar custos de rede, então é melhor reservar Gas nativo suficiente. No lado BSC, paga-se com BNB. Além disso, a documentação oficial lembra que contas de exchanges geralmente não conseguem se conectar diretamente a esse fluxo de migração; é necessário primeiro transferir os tokens para uma carteira autocustodiada que consiga ser conectada.
Os passos extras acontecem porque a autorização de tokens na cadeia de origem e a própria migração são duas ações diferentes, e não se trata de uma cobrança duplicada pela mainnet do Dusk.
Mas a analogia tem limites: o limite de autorização on-chain não é uma autorização única “em papel”; o limite pode continuar existindo. Na próxima migração, quando a cota for suficiente, não será exigido um novo Approve. Para o fluxo de @Dusk , o que eu mais espero é que a interface mostre três estados completamente diferentes: “autorização concluída”, “migração iniciada” e “mainnet já creditada”. Para o usuário de $DUSK , quando a primeira etapa foi bem-sucedida, mas não houve crédito, confirmar se o Execute foi realmente enviado para a blockchain é mais importante do que ficar atualizando o saldo repetidamente.
#dusk