Ir para o conteúdo
Financial Context Wiki

Como verificar as casas decimais de um token

Verifique os decimais de um ERC-20 no contrato e bloco corretos e concilie saldos brutos, transferências, aprovações e conversões entre redes sem erros de ponto flutuante.

Atualizado

Somente para fins educacionais; não é aconselhamento de investimento ou segurança. Os decimais não comprovam identidade, valor, lastro ou segurança de um token.

Resposta direta

Em um token ERC-20, decimals() é um metadado opcional que informa às interfaces como exibir unidades inteiras. Se retornar d, o valor exibido por convenção é raw / 10^d. Isso não altera a aritmética do contrato nem autentica o token. Antes de confiar no resultado, verifique a rede, o endereço exato, o código ou implementação do proxy e o bloco.

Leia decimals() diretamente por um RPC independente em um bloco definido, decodifique o retorno ABI como uint8 e compare com o registro oficial do emissor e um explorador confiável. Depois confira a escala com valores brutos de balanceOf, transferências, aprovações, recibos e eventos. Não presuma 18 se a chamada não existir, reverter, retornar dados malformados ou divergir de outras evidências.

Como funciona

O ERC-20 armazena e transfere valores inteiros sem sinal. A camada de exibição insere o separador decimal; o contrato continua recebendo inteiros. Converta entradas com strings decimais ou inteiros de precisão arbitrária, nunca com ponto flutuante binário. Uma quantidade só é representável quando a multiplicação por 10^d gera um inteiro.

Como decimals() é opcional, um token compatível pode omiti-lo. Uma implementação personalizada ou atualizável pode retornar valor inesperado ou mudar após uma atualização. Em um proxy ERC-1967, examine endereço proxy, implementação ou beacon, administrador e eventos de atualização; leia o estado do token no endereço proxy e fixe comparações no mesmo bloco.

Aprovações e valores ERC-2612 permit também são inteiros brutos. Uma transferência exibida corretamente não prova que aprovação, mínimo do roteador, valor da ponte ou banco contábil usou a mesma escala. Contratos de origem e destino de uma ponte podem usar decimais diferentes; compare valor legível e unidades brutas em cada lado conforme as regras documentadas de conversão e arredondamento.

Use este processo:

  1. Fixe ID da rede ou domínio, contrato do token, número do bloco, endpoint RPC e horário de observação.
  2. Confirme o endereço no registro oficial do emissor; nome, símbolo, ícone e busca não são evidências autorizadas.
  3. Verifique o código implantado e se o endereço é proxy; registre implementação ou beacon, administrador e atualizações recentes.
  4. Chame decimals(), decodifique uint8 por ABI e registre sucesso, reversão, vazio ou saída malformada sem substituir um padrão.
  5. Leia balanceOf, totalSupply, aprovação, calldata, recibo e eventos brutos em blocos compatíveis; formate-os com a escala observada.
  6. Recalcule transferências, aprovações, cotações e pontes com inteiros, incluindo taxas, arredondamento, resíduos, rebases ou taxas de transferência.
  7. Simule e envie uma operação pequena e concilie saldos brutos antes e depois; pare diante de divergência entre interface, RPC, evento ou saldo.

Exemplos

  • Um valor bruto, duas escalas. Com raw = 123456789, d = 6 exibe 123.456789; com d = 18, 0.000000000123456789. A diferença é um fator de 10^12.
  • A representabilidade importa. Com d = 6, 1.25 tokens são 1250000 unidades brutas. 0.0000001 token é menor que uma unidade e deve ser rejeitado ou arredondado por regra explícita.
  • Escala errada na aprovação. Uma aprovação de 100 tokens com d = 6 é 100000000. Codificá-la com d = 18 gera 100000000000000000000, uma aprovação 10^12 vezes maior.
  • Reescala na ponte. Se uma rota documentada 1:1 converte token de origem com d = 6 para representação de destino com d = 18, 2500000 bruto representa 2.5 tokens e 2500000000000000000 no destino representa 2.5. Taxas, limites, resíduos e saldo recebido ainda precisam ser verificados.

Riscos

  • O endereço correto é consultado na rede errada.
  • Nome, símbolo ou ícone copiado esconde outro contrato.
  • A implementação proxy ou beacon muda após a verificação.
  • RPC ou explorador entrega estado antigo, não finalizado ou inconsistente.
  • Metadados ausentes ou malformados são substituídos silenciosamente por 18.
  • Ponto flutuante binário arredonda valor grande ou preciso.
  • A carteira formata a transferência corretamente, mas erra aprovação ou permit.
  • Um banco de dados mistura unidades brutas e valores legíveis.
  • Uma ponte presume decimais iguais ou não revela arredondamento de resíduos.
  • Taxa de transferência, rebase, emissão, queima, pausa ou congelamento rompe a conciliação simples.
  • Calldata, eventos, recibos e alterações reais de saldo não coincidem.
  • A checagem de decimais é confundida com prova de emissor, reservas, liquidez ou segurança.

Equívocos comuns

  • Todo ERC-20 tem 18 decimais. O metadado é opcional e uma implementação pode retornar outro valor.
  • Decimais são bits de precisão usados pela EVM. São uma convenção decimal de exibição; a aritmética continua inteira.
  • O saldo formatado do explorador é confirmação independente. Pode depender da mesma chamada e compartilhar o mesmo erro.
  • Símbolo e decimais iguais identificam o mesmo ativo. Também são necessários rede correta, contrato exato e evidência do emissor.
  • Uma transferência pequena valida todas as integrações. Aprovações, roteadores, pontes, exchanges e contabilidade podem aplicar escalas separadamente.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...