WATS Wallet logoWATS Wallet
Técnico8 min de leitura

Por que sua carteira mostra endereços diferentes: os formatos EVM, Solana e TON

Uma seed phrase, três endereços que não se parecem em nada — 0x na EVM, base58 na Solana, EQ/UQ na TON. A WATS deriva os três de uma única frase de recuperação não-custodial. Veja por que os formatos diferem, o que as verificações realmente pegam e os hábitos que evitam erros de rede errada e de endereços parecidos.

Sua carteira mostra um endereço diferente em cada cadeia porque cada ecossistema deriva e codifica endereços de forma diferente a partir da mesma seed: as cadeias EVM reduzem uma chave pública secp256k1 por hash a 0x mais 40 caracteres hexadecimais, a Solana codifica uma chave pública ed25519 diretamente como 32–44 caracteres base58, e a TON empacota um hash de conta em uma string EQ/UQ de 48 caracteres. Nenhum desses formatos codifica a rede à qual pertence, e é por isso que o mesmo endereço 0x é seu no Ethereum, Arbitrum, Optimism, Base, Polygon e BNB Chain, e por isso que envios para a cadeia errada são tão comuns. As verificações embutidas são desiguais: o uso misto de maiúsculas e minúsculas da EIP-55 pega um endereço 0x digitado errado, o CRC16 da TON pega um endereço EQ/UQ digitado errado, e o alfabeto base58 da Solana apenas evita caracteres parecidos em vez de verificá-los. A WATS cobre Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana e TON — você tem as chaves e a WATS nunca guarda uma chave — e ela não oferece suporte a Bitcoin, então nenhum endereço bc1 faz parte deste quadro.

Uma seed phrase, três endereços que não se parecem em nada

Sua carteira mostra endereços diferentes em cada cadeia porque cada cadeia os constrói de forma diferente a partir da mesma seed. As cadeias EVM reduzem uma chave pública secp256k1 por hash a um endereço hexadecimal 0x; a Solana codifica uma chave pública ed25519 diretamente em base58; a TON envolve um hash de conta em um formato base64 com checksum e um flag de bounce. Curvas e caminhos de derivação diferentes — os endereços não têm como coincidir.

Nada disso é um bug, e nenhuma carteira está mostrando o endereço errado para você. É uma única identidade, escrita de forma diferente em cada cadeia — e saber qual grafia pertence a onde importa, porque enviar para o endereço certo na rede errada é uma das formas mais comuns de as pessoas perderem cripto.

Por que uma única seed phrase gera endereços diferentes em cada cadeia?

Todo endereço desta página pode vir de uma única seed phrase. A seed vira uma chave mestra e, a partir dela, carteiras multi-rede derivam um par de chaves separado para cada cadeia ao longo de um caminho de derivação — uma rota padronizada definida pelo BIP-44, com um coin type registrado por ecossistema no SLIP-44: 60 para Ethereum, 501 para Solana, 607 para TON. (Carteiras de uma só cadeia, notadamente na TON, às vezes usam seus próprios esquemas mnemônicos.) Aí duas coisas separam os resultados. As cadeias EVM assinam com a curva secp256k1; Solana e TON assinam com ed25519 — uma matemática completamente diferente, então os pares de chaves não têm relação entre si, mesmo tendo nascido da mesma seed. E até cadeias que compartilham a mesma curva usam caminhos diferentes e codificações diferentes por cima. Como uma seed se ramifica em toda essa árvore de chaves está explicado em o que é uma carteira HD.

EcossistemaFormato típicoCurva de assinaturaVerificação embutida
EVM (Ethereum, Polygon, Arbitrum…)0x + 40 caracteres hexadecimaissecp256k1Checksum EIP-55 com maiúsculas e minúsculas mistas
Solana32–44 caracteres base58ed25519Nenhuma — apenas alfabeto seguro
TON (user-friendly)48 caracteres base64, prefixo EQ/UQed25519Checksum CRC16 + flag de bounce

O que é um endereço 0x e o que faz o checksum da EIP-55?

Em toda cadeia EVM — Ethereum, Polygon, Arbitrum, BNB Chain e as demais — seu endereço são os últimos 20 bytes de um hash Keccak-256 da sua chave pública, escrito como 0x mais 40 caracteres hexadecimais. A EIP-55 acrescenta um checksum sem mudar o endereço: o padrão de letras maiúsculas e minúsculas é derivado do próprio endereço, então uma carteira consegue sinalizar um caractere digitado errado antes de você enviar. Um endereço todo em minúsculas continua válido — ele apenas não carrega nenhum checksum a verificar.

Como o endereço vem apenas da sua chave, a mesma conta tem o mesmo endereço 0x em todas as cadeias EVM. Isso é conveniente — um endereço só para compartilhar em qualquer lugar — e perigoso, porque o endereço não codifica a rede. Tokens enviados na cadeia EVM errada chegam ao mesmo endereço em uma rede diferente: se você controla a chave, normalmente consegue recuperá-los trocando de rede; se o endereço pertence a uma exchange ou a um contrato, eles podem estar perdidos. Na WATS esse é o caso do dia a dia, e não um caso extremo, já que seis das oito cadeias suportadas — Ethereum, Arbitrum, Optimism, Base, Polygon e BNB Chain — compartilham aquele único endereço 0x.

Como funcionam os endereços da Solana?

Um endereço Solana é a própria chave pública: 32 bytes de uma chave ed25519, codificados em base58 — um alfabeto escolhido porque descarta os caracteres facilmente confundíveis 0, O, I e l. O resultado tem 32–44 caracteres e diferencia maiúsculas de minúsculas. Não existe checksum no estilo da EIP-55; o alfabeto seguro reduz erros de digitação, mas não os detecta, o que é mais um motivo para copiar em vez de digitar. Um detalhe que vale conhecer: os tokens SPL não ficam diretamente no seu endereço — cada token vive em uma associated token account derivada dele. Sua carteira gerencia essas contas nos bastidores; você continua compartilhando um único endereço.

O que são os endereços bounceable e não-bounceable da TON?

A TON dá duas grafias a uma mesma conta. O formato raw é o número da workchain, dois-pontos e um hash hexadecimal de 64 caracteres — preciso, mas nada amigável. O formato user-friendly empacota os mesmos dados em 48 caracteres base64 com bits de flag e um checksum CRC16, de modo que erros de digitação são detectados. O flag que importa é o bounceable: endereços que normalmente começam com EQ dizem à rede para devolver as moedas se o destino não conseguir processá-las, o que serve bem a contratos; endereços não-bounceable começando com UQ entregam de qualquer forma, o que serve bem a carteiras pessoais — e carteiras modernas costumam exibir a forma UQ para elas. As duas grafias apontam para a mesma conta, então ver um prefixo diferente em outro lugar não significa um destino diferente.

Por que as exchanges pedem um memo ou destination tag?

Em algumas cadeias, as exchanges juntam todos os depósitos dos clientes sob um único endereço compartilhado — algo comum na TON, na XRP e na Stellar — e usam um memo (ou destination tag) para direcionar cada depósito à conta certa. O memo não é enfeite: se você o omitir, suas moedas caem na carteira compartilhada da exchange sem serem creditadas. Normalmente são recuperáveis por meio de um chamado no suporte, mas devagar e sem garantia. A regra é simples: se uma página de depósito exibe um memo, trate-o como parte do endereço. Enviar para sua própria carteira de autocustódia não exige memo algum.

Como evitar enviar para a cadeia errada — ou para um endereço parecido?

Três hábitos cobrem a maior parte do risco. Primeiro, combine a cadeia, não o formato: um endereço 0x não diz nada sobre qual rede o remetente selecionou, então confirme a rede explicitamente nas duas pontas antes que qualquer coisa se mova. Segundo, envios de teste: em uma primeira transferência para um endereço novo ou por uma rota nova, envie um valor pequeno, confirme que chegou e depois envie o resto — um seguro barato contra suposições caras. Terceiro, respeite o envenenamento de endereço: atacantes geram endereços parecidos que coincidem nos primeiros e últimos caracteres com os que você realmente usa e então lhe enviam poeira, para que o falso apareça no seu histórico de transações — esperando que você o copie. Nunca copie endereços do histórico; use contatos salvos e confira os caracteres do meio, não só as pontas. Uma boa carteira multi-rede coloca o rótulo da rede ao lado de cada endereço, e manter Ethereum, Solana e TON em um só aplicativo sem confundi-los é exatamente para isso que esse design existe.

Onde a WATS se encaixa

A WATS roda uma única carteira em Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana e TON, então os três formatos acima são exatamente os endereços que você acaba tendo lado a lado — um endereço 0x para as seis cadeias EVM, um endereço base58 na Solana, um endereço EQ/UQ na TON, todos a partir de uma única frase de recuperação. Ela permanece totalmente não-custodial nos quatro produtos — a extensão do Chrome, o aplicativo móvel, a Hot Wallet e o Cartão Metálico NFC: você tem as chaves, e a WATS nunca guarda uma chave. Em um artigo sobre endereços, vale deixar clara uma coisa sobre esse cartão — ele não armazena chaves privadas. Ele autentica por aproximação para chaves que permanecem dentro dos aplicativos WATS, com um ID de cartão exclusivo que é pareado a exatamente um dispositivo.

O Bitcoin é a lacuna honesta: a WATS não oferece suporte nativo a ele, então endereços bc1, 1 e 3 não fazem parte deste conjunto. Dentro das oito cadeias que ela cobre, as taxas de rede são pagas em um único token, o ATS, em vez de você manter o token de gas nativo de cada cadeia — abstração de conta ERC-4337 nas cadeias EVM, com o próprio ATS sendo um OFT da LayerZero, de modo que um único saldo funciona omnichain. Isso não é desconto; muda qual token paga a taxa. O fornecimento de ATS está sendo queimado de 100M para 30M.

Conclusão

Endereços diferentes em cadeias diferentes são uma propriedade de como as cadeias foram construídas, não um bug da carteira: uma seed, curvas diferentes, caminhos de derivação diferentes, codificações diferentes. Leia o formato se quiser, mas nunca confie nele para saber a rede — confirme a cadeia nas duas pontas, faça um pequeno envio de teste em qualquer rota nova, trate o memo de uma exchange como parte do endereço e copie de contatos salvos em vez do histórico de transações. Se você quer os três formatos em um só lugar em vez de em três aplicativos, o passo concreto é instalar a WATS pela página de download: uma única frase de recuperação não-custodial por trás das suas contas em Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana e TON, e taxas pagas em ATS em vez de um token de gas nativo separado em cada cadeia.

Perguntas frequentes

Meu endereço é o mesmo no Ethereum, na Polygon e na Arbitrum?

Sim — para uma conta comum de carteira, a mesma chave produz o mesmo endereço 0x em todas as cadeias EVM, então na WATS uma conta mostra o endereço idêntico em Ethereum, Arbitrum, Optimism, Base, Polygon e BNB Chain. O endereço, porém, não codifica a rede: você precisa escolher a cadeia correta ao enviar. Os endereços de depósito de exchanges são a exceção — uma exchange pode creditar apenas uma rede específica, então siga sempre as instruções dela exatamente.

Quais formatos de endereço a WATS mostra, e existe um endereço Bitcoin?

A WATS deriva todos os endereços de uma única frase de recuperação: um endereço 0x compartilhado entre Ethereum, Arbitrum, Optimism, Base, Polygon e BNB Chain, um endereço base58 de 32–44 caracteres na Solana, e um endereço EQ/UQ de 48 caracteres na TON. A WATS é totalmente não-custodial, então essas chaves são suas e a WATS nunca guarda uma chave. Não há endereço Bitcoin, porque a WATS não oferece suporte nativo ao Bitcoin — endereços bc1, 1 e 3 pertencem a um ecossistema que a WATS não cobre.

O que acontece se eu enviar para uma exchange sem o memo?

Suas moedas chegam à carteira de depósito compartilhada da exchange, mas não são creditadas à sua conta, porque é o memo que identifica você. Normalmente elas não estão perdidas — a maioria das exchanges consegue creditá-las manualmente por meio de um chamado no suporte —, mas o processo é lento e sem garantia. Se uma página de depósito exibe um memo ou destination tag, trate-o como parte obrigatória do endereço, nunca como um campo opcional. Enviar para uma carteira de autocustódia como a WATS não exige memo, porque o endereço é só seu, e não compartilhado.

O que é envenenamento de endereço e como evitá-lo?

Envenenamento de endereço é um ataque em que alguém gera um endereço parecido, coincidindo nos primeiros e últimos caracteres com um que você realmente usa, e então lhe envia uma transação de poeira para que o falso apareça no seu histórico. Se mais tarde você copiar um endereço desse histórico, os fundos vão para o atacante. Evite nunca copiando do histórico de transações, salvando contatos verificados e conferindo os caracteres do meio — não apenas as pontas — antes de assinar.