Wallet Address Checker

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.