Verificador de endereços de carteira

Por que detectar tipo de wallet

Quando seu usuário cola um endereço, você precisa saber em qual chain operar antes de iniciar uma transação. Mandar USDT-TRX para um endereço EVM perde o dinheiro permanentemente. Validação no lado client antes do submit evita esse desastre.

Esta ferramenta detecta por padrão (regex + comprimento + checksum) sem fazer chamada on-chain. Roda local, instantâneo.

Formatos por chain

Chain	Prefixo / Padrão	Comprimento
EVM (ETH, BSC, Polygon, Arbitrum, etc.)	0x + 40 hex chars	42
Bitcoin legacy	começa com 1	26–35
Bitcoin script (P2SH)	começa com 3	26–35
Bitcoin bech32 (segwit)	bc1...	39–62
Solana	base58, sem prefixo	32–44
Tron	começa com T	34
Cosmos / Atom	cosmos1... (bech32)	variável
BNB Beacon Chain	bnb1... (bech32)	variável

Validação de checksum

• EVM: EIP-55 capitaliza letras hex para incluir checksum. 0xAbC... capitalizado errado é detectado. Esta ferramenta sinaliza checksum mismatch.
• Bitcoin legacy: Base58Check inclui 4 bytes de SHA256 double-hash no fim. Inválido se mudar uma letra.
• Bech32: BCH code com 6 bytes de detecção de erro. Catches typos comuns.
• Solana: base58 sem checksum embedded; só validação de comprimento e charset.

Ambiguidade: SOL vs BTC legacy

Solana usa base58 (alfabeto Bitcoin), sem prefixo fixo. Endereços de programa de sistema do Solana começam com 1 (ex: 11111111111111111111111111111111 = system program). Esses colidem com BTC legacy.

Heurística: comprimento. BTC legacy tem 26–35 chars; Solana tem 32–44. Quando ambíguo (comprimento 32–35 começando com 1), priorizamos SOL se for válido em base58 de 32 bytes; senão BTC. Esta heurística não é 100% — em casos limítrofes, peça o tipo explicitamente ao usuário.

O que NÃO fazemos

• Não verificamos se o endereço existe on-chain. Wallets podem ser válidas em formato mas nunca terem sido usadas.
• Não fazemos lookup de saldo, histórico, ou ENS reverse.
• Não validamos assinaturas.

Se você precisa dessas funções, integre RPC providers (Alchemy, Infura, Helius) no seu app.

Caso de uso típico

Formulário de "Enviar tokens": usuário cola um endereço. Antes do submit, valida tipo + checksum + matching com a chain selecionada. Bloqueia o submit se houver mismatch ou checksum inválido. Salva o usuário de perder fundos.

Limitações

• Endereços novos de chains menos comuns podem não ter pattern conhecido
• ENS / Lens / Solana Name Service (name.eth, name.sol) não são validados aqui — resolva via RPC primeiro
• Multisigs e smart contract wallets aparecem como EVM normal (o tipo "wallet" vs "contract" exige eth_getCode)

Tudo client-side

Regex puro no JS. Nenhuma RPC, nenhuma chamada à internet.

Verifica saldo on-chain?

Não. Apenas valida formato e checksum. Para saldo, integre um RPC provider (Alchemy para EVM, Helius para Solana, BTCpay para BTC) no seu app.

Por que checksum inválido em EVM?

EIP-55 codifica checksum nas maiúsculas/minúsculas das letras hex. 0xAbC123... com capitalização errada é tecnicamente um endereço válido (lowercase funciona), mas wallets modernas alertam. Se vier de copy-paste de um explorer, deveria estar capitalizado corretamente.

Como diferencio Solana de BTC?

Heurística por comprimento e charset. Solana = 32–44 chars base58. BTC legacy = 26–35. Em casos ambíguos (1... com 32–35 chars), priorizamos SOL se válido. Sempre confirme pelo contexto (qual chain seu usuário disse usar).

Suporta ENS (name.eth)?

Não. ENS exige lookup on-chain (RPC). Resolva primeiro via ethers.resolveName() ou viem, depois passe o endereço resolvido aqui.

Funciona com endereços de contrato?

Sim, mas trata como EVM normal. Não diferenciamos wallet vs contract (isso exige eth_getCode != "0x" via RPC).

Algum dado é enviado?

Não. Regex puro no JS. Network tab vazio. Funciona offline.