Saltar al contenido
Financial Context Wiki

Cómo verificar los decimales de un token

Verifica los decimales de un ERC-20 en el contrato y bloque correctos y concilia saldos brutos, transferencias, autorizaciones y conversiones entre cadenas sin errores de coma flotante.

Actualizado

Solo con fines educativos; no es asesoramiento de inversión ni de seguridad. Los decimales no demuestran la identidad, el valor, el respaldo ni la seguridad de un token.

Respuesta directa

En un token ERC-20, decimals() es un metadato opcional que indica a las interfaces cómo mostrar unidades enteras. Si devuelve d, el importe mostrado por convención es raw / 10^d. No modifica la aritmética del contrato ni autentica el token. Antes de confiar en el resultado, verifica la red, la dirección exacta, el código o implementación del proxy y el bloque.

Lee decimals() directamente mediante un RPC independiente en un bloque concreto, decodifica el resultado ABI como uint8 y compáralo con el registro oficial del emisor y un explorador fiable. Después contrasta la escala con valores brutos de balanceOf, transferencias, autorizaciones, recibos y eventos. No supongas 18 si la llamada no existe, revierte, devuelve datos malformados o contradice otras pruebas.

Cómo funciona

ERC-20 almacena y transfiere cantidades enteras sin signo. La capa de visualización inserta la coma decimal; el contrato sigue recibiendo enteros. Convierte la entrada con cadenas decimales o enteros de precisión arbitraria, nunca con coma flotante binaria. Una cantidad solo es representable si al multiplicarla por 10^d se obtiene un entero.

Como decimals() es opcional, un token conforme puede omitirlo. Una implementación personalizada o actualizable puede devolver un valor inesperado o cambiar tras una actualización. En un proxy ERC-1967, inspecciona la dirección proxy, implementación o beacon, administrador y eventos de actualización; consulta el estado en la dirección proxy y fija todas las comparaciones al mismo bloque.

Las autorizaciones y los valores ERC-2612 permit también son enteros brutos. Que una transferencia se muestre bien no prueba que una autorización, mínimo del router, importe del puente o base contable use la misma escala. Los contratos de origen y destino de un puente pueden tener distintos decimales: compara valor legible y unidades brutas en cada lado según sus reglas documentadas de conversión y redondeo.

Sigue este proceso:

  1. Fija ID de red o dominio, contrato del token, número de bloque, endpoint RPC y hora de observación.
  2. Confirma la dirección en el registro oficial del emisor; nombre, símbolo, icono y resultados de búsqueda no son pruebas autorizadas.
  3. Comprueba el código desplegado y si la dirección es un proxy; registra implementación o beacon, administrador y actualizaciones recientes.
  4. Llama a decimals(), decodifica uint8 por ABI y registra éxito, reversión, vacío o salida malformada sin sustituir un valor predeterminado.
  5. Lee balanceOf, totalSupply, autorización, calldata, recibo y eventos brutos en bloques compatibles; formatéalos con la escala observada.
  6. Recalcula transferencias, autorizaciones, cotizaciones y puentes con enteros, incluyendo comisiones, redondeo, residuos, rebases o impuestos de transferencia.
  7. Simula y envía una operación pequeña y concilia saldos brutos antes y después; detente ante cualquier desacuerdo entre interfaz, RPC, evento o saldo.

Ejemplos

  • Un valor bruto, dos escalas. Con raw = 123456789, d = 6 muestra 123.456789; con d = 18, 0.000000000123456789. La diferencia es un factor de 10^12.
  • Importa que sea representable. Con d = 6, 1.25 tokens son 1250000 unidades brutas. 0.0000001 token es menor que una unidad y debe rechazarse o redondearse con una regla explícita.
  • Autorización mal escalada. Una autorización de 100 tokens con d = 6 es 100000000. Codificarla con d = 18 produce 100000000000000000000, una autorización 10^12 veces mayor.
  • Reescalado en un puente. Si una ruta documentada 1:1 convierte un token origen con d = 6 a una representación destino con d = 18, 2500000 bruto representa 2.5 tokens y 2500000000000000000 en destino representa 2.5. Aun hay que verificar comisiones, límites, residuos y saldo recibido.

Riesgos

  • Se consulta la dirección correcta en la red equivocada.
  • Un nombre, símbolo o icono copiado oculta otro contrato.
  • La implementación proxy o el beacon cambia después de la revisión.
  • El RPC o explorador entrega estado antiguo, no finalizado o incoherente.
  • Los metadatos ausentes o malformados se sustituyen silenciosamente por 18.
  • La coma flotante binaria redondea una cantidad grande o precisa.
  • La cartera formatea bien una transferencia pero mal una autorización o permit.
  • Una base de datos mezcla unidades brutas con importes legibles.
  • Un puente supone decimales iguales u oculta el redondeo de residuos.
  • Comisiones de transferencia, rebase, acuñación, quema, pausa o congelación rompen la conciliación simple.
  • Calldata, eventos, recibos y cambios reales de saldo no coinciden.
  • La revisión de decimales se confunde con prueba de emisor, reservas, liquidez o seguridad.

Errores comunes

  • Todos los ERC-20 tienen 18 decimales. El metadato es opcional y una implementación puede devolver otro valor.
  • Los decimales son bits de precisión del EVM. Son una convención decimal de visualización; la aritmética sigue siendo entera.
  • El saldo formateado del explorador es una confirmación independiente. Puede depender de la misma llamada y compartir el mismo error.
  • Símbolo y decimales iguales identifican el mismo activo. También hacen falta la red correcta, el contrato exacto y pruebas del emisor.
  • Una transferencia pequeña valida todas las integraciones. Autorizaciones, routers, puentes, exchanges y contabilidad pueden escalar por separado.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...