Saltar al contenido
Financial Context Wiki

¿Por qué una cartera puede mostrar un saldo de tokens incorrecto?

Descubre por qué los saldos divergen entre carteras e indexadores, cómo influyen el bloque y la contabilidad del token, y cómo verificar el estado en cadena con seguridad.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Los activos digitales y las transacciones en cadena pueden causar pérdidas irreversibles.

Respuesta directa

El saldo de una cartera es una vista derivada, no la autoridad sobre la propiedad del token. Suele combinar lecturas RPC, un índice de eventos, metadatos, precios, filtros de spam y caché local. Cualquier capa puede estar desactualizada, apuntar a otra red o contrato, o interpretar mal el token. Que no aparezca no prueba que se haya perdido; ver una cifra tampoco prueba que sea transferible, canjeable o valiosa.

Para un ERC-20 convencional, el mejor punto de partida es el resultado de balanceOf para la cuenta exacta, en un bloque concreto y en la cadena correcta. Aun así, solo expresa unidades bajo las reglas del contrato. Los tokens con rebase, participaciones de bóvedas, activos envueltos y posiciones de protocolos pueden requerir otra conversión para conocer el derecho económico o importe canjeable.

Cómo funciona

La pantalla suele combinar cuatro rutas de datos:

  • Estado del contrato: un nodo RPC ejecuta balanceOf mediante eth_call sobre el bloque elegido.
  • Índice de eventos: un servicio escanea registros Transfer para descubrir tokens, crear historial y actualizar tenencias en caché.
  • Metadatos y valoración: decimals, símbolo, listas, tipos de cambio y precios convierten el entero bruto en cantidad y valor fiduciario.
  • Política de interfaz: la cartera puede ocultar activos no verificados o spam, agrupar cuentas, retrasarse respecto a la cadena o conservar caché.

ERC-20 define balanceOf y exige Transfer en transferencias estándar. Sin embargo, una base basada en eventos puede omitir o duplicar registros, empezar tarde, procesar mal una reorganización o desconocer contabilidad específica. Los eventos prueban cambios, pero no sustituyen la lectura del estado actual. Un decimals erróneo también deforma una cifra bruta correcta.

El bloque importa. JSON-RPC de Ethereum acepta latest, safe y finalized, y los proveedores pueden estar en cabeceras distintas. EIP-1898 permite consultar por hash de bloque para fijar lecturas relacionadas a un mismo bloque y, si se solicita, exigir que sea canónico. Sin una referencia común, dos lecturas válidas pueden describir estados diferentes durante sincronización o reorganización.

Sigue esta secuencia:

  1. Confirma red y chainId; los saldos de origen y destino de un puente pertenecen a libros distintos.
  2. Obtén el contrato de una fuente fiable del proyecto o registro verificado. Nunca identifiques un token solo por el símbolo.
  3. Confirma cuenta, estándar y si el activo es token base, envuelto, participación de bóveda o recibo de protocolo.
  4. Consulta balanceOf con dos RPC independientes en el mismo número o hash de bloque. Guarda por separado el entero bruto y decimals.
  5. Revisa recibo, estado, contrato, registros y bloque canónico. Compara estados anteriores y posteriores en bloques explícitos.
  6. Para activos con rebase o participaciones, usa la conversión y el canje documentados. En ERC-4626, balanceOf informa participaciones y convertToAssets estima subyacentes, no necesariamente un canje exacto.

Ejemplo

Un explorador muestra que la transferencia a Lina tuvo éxito, pero su cartera sigue en cero. Dos RPC independientes devuelven el mismo saldo bruto positivo con balanceOf en el mismo bloque finalizado; el recibo es canónico y el registro pertenece al contrato esperado. Esto apunta a índice, filtro o caché retrasados. Importar el contrato verificado o esperar es mejor que reenviar.

En otro caso, la cartera muestra saldo para un símbolo conocido, pero balanceOf del contrato verificado devuelve cero. Puede ser otro contrato con igual símbolo o datos viejos de otra red. En una bóveda, balanceOf puede ser correcto y la valoración diferir porque se muestran participaciones sin la conversión actual.

Riesgos y controles

  • Cadena o dirección equivocada: verifica chainId, cuenta y contrato completos antes de corregir nada.
  • RPC obsoleto o incoherente: compara proveedores en un bloque explícito; no mezcles lecturas latest de momentos distintos.
  • Reorganización: trata bloques recientes como provisionales según la finalidad de la cadena y vuelve a comprobar el recibo.
  • Huecos del indexador: reescanea desde un bloque conocido y concilia registros con estado; revierte bloques huérfanos.
  • Contabilidad no estándar: no reconstruyas rebase, bóvedas o recibos sumando Transfer salvo que el protocolo lo documente.
  • Error de metadatos o precio: separa unidades brutas, cantidad y valoración. El precio no cambia el saldo; decimals sí cambia su visualización.
  • Token o interfaz maliciosos: ver un token no requiere aprobar ni firmar. Rechaza enlaces, permisos o transacciones para «actualizar» el saldo.

Si persiste la discrepancia, detén transferencias y conserva red, cuenta, contrato, número y hash de bloque, respuestas RPC y hash de transacción. Comprueba soporte del bloque y posibles actualizaciones, pausas, rebase, migraciones o finalización del puente. Usa canales públicos sin compartir frase semilla ni clave privada.

Un saldo correcto no garantiza salida. Verifica por separado restricciones, canje, liquidez, comisiones y permisos. Simula o prueba poco solo tras verificar el contrato; aumentar gas o deslizamiento no arregla un índice.

Errores comunes

  • «La pantalla es la cadena de bloques». Es una vista creada con datos dentro y fuera de la cadena.
  • «Los registros Transfer siempre suman el saldo». Pueden indexarse mal y algunos tokens requieren estado o conversión específica.
  • «Más confirmaciones actualizan la cartera». Reducen incertidumbre de liquidación, pero no fuerzan caché ni indexador.
  • «Un saldo positivo se puede vender». Reglas, pausas, límites, liquidez o contratos maliciosos pueden impedirlo.
  • «Debo firmar para ver mi saldo». Una lectura pública no requiere aprobación, firma ni frase semilla.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...