Como Testar a Cópia de Segurança da Sua Seed Phrase Sem Arriscar os Seus Fundos (Dry Run numa Carteira de Software)

Uma cópia de segurança que nunca foi testada não é uma cópia de segurança. Para a testar em segurança, mantenha a sua carteira original intacta. Restaure apenas a partir da frase escrita, num segundo dispositivo (ou, no caso de uma extensão, num perfil de browser separado) enquanto o original continua instalado, e depois verifique se o primeiro endereço de cada cadeia que utiliza (EVM, Solana, TON) coincide exatamente com o original. Nunca escreva a frase num site nem num "verificador de seed". Apague a cópia de teste depois e, se os endereços não coincidirem, corrija a cópia de segurança ou mova os seus fundos para uma nova carteira com uma cópia verificada.

Porque deve testar a cópia de segurança da seed phrase antes de precisar dela?

Deve testá-la porque uma má cópia de segurança só se revela quando precisa dela, e nessa altura já é tarde para a corrigir. As falhas típicas são uma palavra mal escrita, duas palavras trocadas, uma palavra omitida, uma caligrafia que se lê como outra letra (por exemplo rn e m, ou l e i), ou uma passphrase opcional (por vezes chamada 25.ª palavra) que nunca foi escrita. A documentação da KeepKey lista exemplos como "flat" escrito em vez de "float".

A soma de verificação BIP-39 apanha muitos erros de escrita, mas não todos. Uma frase de 12 palavras tem apenas 4 bits de verificação e uma de 24 palavras tem 8, pelo que algumas frases erradas continuam a passar como válidas e limitam-se a abrir uma carteira diferente e vazia. O BIP-39 diz também que qualquer passphrase produz uma carteira válida, pelo que uma passphrase errada ou esquecida não dá erro, apenas uma carteira vazia. Por isso se comparam endereços em vez de confiar em "frase aceite".

Os acontecimentos de 2026 mostram quando isto importa. A Exodus terminou o suporte da sua extensão Web3 Wallet em 1 de outubro de 2026, e a Trust Wallet removeu um conjunto de redes integradas em 15 de setembro de 2026. Movimentos como estes levam as pessoas a restaurar uma seed phrase noutra carteira, que é precisamente quando uma má cópia de segurança vem a lume. Veja o que fazer quando uma carteira abandona uma rede ou encerra.

O que fazem as carteiras de hardware, e porque precisam as carteiras de software de uma versão manual?

Muitas carteiras de hardware oferecem uma verificação da cópia de segurança, enquanto as carteiras de software normalmente só lhe pedem algumas palavras na configuração e não têm uma verificação que possa executar mais tarde. O "Check backup" da Trezor (um dry run) pede-lhe que volte a introduzir as palavras, compara-as com a cópia de segurança guardada no dispositivo e não conserva as palavras reintroduzidas. A Ledger introduziu em 2018 uma aplicação RecoveryCheck para confirmar uma frase de 24 palavras sem repor o dispositivo (consulte as páginas de suporte atuais da Ledger para o método em vigor). A KeepKey pede-lhe que introduza palavras da sua cópia em papel e não de memória.

O equivalente manual para uma carteira de software é uma restauração em paralelo: restaurar numa instância separada enquanto a original se mantém intacta e depois comparar os endereços derivados. Há uma regra inegociável. Nunca apague nem reponha a sua única carteira funcional para testar a cópia de segurança, porque, se a cópia estiver má, é essa eliminação que perde os fundos.

Que ambiente de teste é seguro?

O ambiente mais seguro é um dispositivo que controla, sem extensões desconhecidas nem ferramentas de acesso remoto. Use um segundo telemóvel ou computador, se tiver. Se não tiver um segundo telemóvel, use um segundo computador ou, num desktop, um perfil de browser separado com uma instalação nova da extensão oficial a partir da loja ou do site oficial (veja como instalar apenas a aplicação oficial). Nunca desinstale nem reponha a aplicação original para fazer espaço ao teste. Num único telemóvel, sem outro dispositivo, não execute o teste nesse telemóvel. Fique offline durante a restauração, sempre que for prático.

A contrapartida é que cada restauração de teste cria outra cópia das suas chaves nesse dispositivo enquanto existir. Apague-a logo a seguir e nunca use um computador partilhado, de trabalho ou público.

Nunca use "validadores de seed", "verificadores BIP39" ou sites de "sincronização de carteira" online, e nunca ponha a frase em chats, notas na cloud, capturas de ecrã, email ou chatbots de IA. Qualquer coisa que receba a frase pode esvaziar a sua carteira, e este é um padrão clássico de phishing.

Como executar uma restauração dry run, passo a passo?

Uma restauração dry run consiste em restaurar a sua carteira a partir da cópia escrita numa instância separada, apenas para comparar endereços, e depois apagar essa cópia. Não move fundos.

1. Prepare. Escolha o ambiente de teste acima e deixe a carteira original intacta.
2. Registe os originais. Na carteira original, anote o primeiro endereço de receção (conta 1) em cada cadeia onde detém fundos: um endereço EVM (na maioria das carteiras o mesmo em Ethereum, Arbitrum, Base e outras redes EVM, mas verifique cada rede que utiliza), um endereço Solana e um endereço TON. Os primeiros e os últimos 6 caracteres bastam, e os endereços são públicos. Se utiliza mais do que uma conta, compare também cada conta que detenha fundos. Uma conta que importou com uma chave privada não é recuperada pela seed phrase e precisa da sua própria cópia de segurança.
3. Restaure a partir do papel. Escreva as palavras apenas a partir da cópia escrita ou em metal, não de memória e não do ecrã de revelação da aplicação original. Testar a cópia física é precisamente o objetivo.
4. Compare. Verifique todos os caracteres, ou pelo menos os primeiros e os últimos 6. Na TON, uma carteira pode surgir como EQ… (bounceable) ou UQ… (non-bounceable), e as duas formas diferem no prefixo e nos caracteres da soma de verificação, por isso compare no mesmo formato (veja formatos de endereços cripto explicados). Opcionalmente, confirme que a carteira restaurada mostra o mesmo saldo, em vez de enviar uma transação de teste.
5. Resolva uma divergência. Se algum endereço diferir, siga a secção seguinte.
6. Apague a cópia. Terminado o teste, apague a carteira de teste do segundo dispositivo e limpe a área de transferência e os dados da aplicação.
7. Substitua uma cópia de segurança que não consegue corrigir. Crie uma nova carteira com uma cópia de segurança verificada e mova os seus fundos para ela.
8. Volte a testar mais tarde. Repita após qualquer alteração à cópia de segurança e com um lembrete no calendário.

E se os endereços restaurados não coincidirem?

Uma divergência significa normalmente que o papel e a carteira original diferem nalgum ponto, por isso suspeite primeiro de erro humano. Verifique a ordem das palavras, a ortografia face à lista BIP-39 de 2.048 palavras (as 4 primeiras letras identificam cada palavra), o número de palavras e se foi usada uma passphrase.

Se o endereço EVM coincidir mas os da Solana ou da TON diferirem, a causa é muitas vezes um caminho de derivação diferente ou uma versão diferente da carteira TON (v4R2 versus W5) entre carteiras, e não uma má cópia de segurança. Veja caminhos de derivação diferentes e versões de carteira TON. Se a carteira rejeitar a frase como inválida, ou se nenhum endereço coincidir mesmo depois de verificar a ordem das palavras, a ortografia, o número de palavras e a passphrase, considere que a cópia de segurança falhou.

O que fazer após um teste falhado?

Os seus fundos continuam seguros enquanto a carteira original funcionar, e o perigo é perder esse dispositivo mais tarde com uma cópia de segurança estragada. Se conseguir voltar a verificar a frase na aplicação original, corrija a cópia em papel e volte a testar.

Se não conseguir produzir uma cópia de segurança que passe, crie uma nova carteira, escreva a sua frase, verifique-a com este mesmo teste e depois mova os seus fundos para uma nova carteira com uma cópia de segurança verificada. A orientação da Trezor é a mesma: se a cópia de segurança falhar e não conseguir introduzir a correta, mova de imediato os seus fundos para uma nova carteira. Não espere por um telemóvel perdido; veja o que acontece se perder o telemóvel.

Como limpar tudo e quando voltar a testar?

Apague a carteira de teste na aplicação, desinstale-a ou limpe os dados da extensão e limpe qualquer histórico da área de transferência. Volte a testar após qualquer alteração à cópia de segurança (uma nova placa de metal, uma cópia para herança, um novo local) e com um lembrete no calendário, por exemplo uma vez por ano. Para conselhos de armazenamento, leia como guardar e proteger a sua seed phrase.

Como isto se aplica à WATS Wallet

A WATS Wallet, desenvolvida pela Alltoscan LLC, é totalmente não custodial e não é uma carteira sem seed. A WATS nunca guarda uma chave, pelo que a sua frase de recuperação é a única forma de restaurar a carteira, e é por isso que testá-la importa. Execute o dry run acima num segundo dispositivo, ou num perfil de browser separado para a extensão, enquanto o original continua instalado e intacto, e compare o endereço EVM, o endereço Solana e o endereço TON que a WATS Wallet mostra, em cada rede onde detém fundos.

O Cartão Metálico NFC da WATS, opcional, não guarda chaves privadas e não é uma cópia de segurança nem armazenamento a frio. Funciona por toque para autenticar na aplicação móvel e não faz parte deste teste. Restaurar e comparar não exige qualquer transação. Se mais tarde mover fundos, as taxas EVM são cobradas em ATS a partir de um só saldo na BSC (veja como funcionam as taxas em ATS), enquanto as taxas na TON também são pagas em ATS e a Solana paga em SOL.