--- title: "Cómo verificar los decimales de un token" description: "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." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Cómo verificar los decimales de un token > 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 - [Verificación del contrato del token](/crypto/token-contract-verification/) - [Decodificación de calldata en la cartera](/crypto/calldata-decoding-wallet/) - [Verificación de tokens de puente](/crypto/bridge-token-verification/) - [Riesgo de tokens con comisión de transferencia](/crypto/fee-on-transfer-token-risk/) - [Contrato proxy](/crypto/proxy-contract/) ## Fuentes - [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultado: 2026-08-21) - [ERC-20](https://docs.openzeppelin.com/contracts/5.x/erc20) - OpenZeppelin Docs (consultado: 2026-08-21) - [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - ethereum.org (consultado: 2026-08-21) - [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consultado: 2026-08-21) - [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (consultado: 2026-08-21) Source: https://wiki.fcontext.com/es/crypto/token-decimals-verification/index.mdx