Aprobaste el contrato de canje, enviaste el saldo del token antiguo y el explorador marcó la transacción en verde. El ticker anterior ha desaparecido y nada ha ocupado su lugar. O las nuevas unidades no existen, o existen y nada las está dibujando. Esos dos casos se ven idénticos en la pantalla de una billetera y exigen respuestas completamente distintas.
Qué certifica realmente un canje completado
Una transacción de canje confirmada te dice que tu llamada llegó a un bloque y que la parte más externa de la ejecución no se revirtió. Eso es todo. Un estado del recibo satisfactorio es una afirmación sobre la llamada, no un inventario de lo que esa llamada acreditó.
Un canje de migración tiene dos patas, y por eso esa distancia importa aquí más que en otros sitios. Una pata retira tus unidades antiguas. La otra paga unidades nuevas. El recibo cubre la transacción en conjunto, y un contrato puede escribirse de forma que la segunda pata haga menos de lo esperado, o nada, sin que la primera se deshaga.
Así que la pregunta a responder no es si el canje funcionó. Es si ahora existe un saldo nuevo escrito contra tu dirección y, de ser así, por qué nada lo dibuja. Son dos investigaciones separadas, y hacerlas en ese orden te evita discutir con un servicio de atención sobre un saldo que ya posees.
Dónde queda registrado realmente el nuevo saldo
El nuevo token es un contrato corriente con su propio libro, y el estándar de tokens ERC-20 registra tu posición dos veces: una como evento en el momento del abono y otra como valor que el contrato devuelve cuando se le pregunta.
El evento es Transfer, que según el estándar DEBE dispararse cuando se transfieren tokens, incluidas las transferencias de valor cero. Añade que un contrato de token que crea tokens nuevos DEBERÍA disparar un evento Transfer con la dirección del remitente fijada en 0x0. Una migración que acuña contra tu dirección deja por tanto una transferencia desde la dirección cero hacia ti, y otra que paga desde una reserva prefinanciada deja una transferencia desde esa reserva. En ambos casos hay una línea que buscar.
El valor es balanceOf, que el estándar describe como el saldo de la cuenta de otra cuenta con una dirección de propietario dada. Es una lectura, no cuesta nada y responde por el presente, no por el momento del canje. Abre el nuevo contrato en un explorador de bloques y llama a balanceOf con tu propia dirección. La cifra que devuelve es la respuesta que manda.
| Qué puedes leer | Qué resuelve |
|---|---|
| El estado del recibo del canje | Solo que la llamada externa no se revirtió |
| Un evento de transferencia a tu dirección | Que entonces se te acreditaron nuevas unidades |
| La lectura de balanceOf en el nuevo contrato | Cuánto tienes en ese libro ahora |
| La lista de activos de tu billetera | Nada sobre la propiedad |
Por qué el saldo puede ser tuyo y la billetera no mostrar nada
La última fila resuelve la versión de esto que se arregla sin coste. Una billetera no rastrea cada contrato de la cadena buscando tu dirección. Dibuja una lista de activos que le dijeron que siguiera, y un contrato desplegado la semana pasada no está en esa lista hasta que algo lo pone ahí.
Es un hueco conocido, no un fallo. EIP-747, el estándar detrás del método wallet_watchAsset, lo describe como una forma de permitir que un cliente sugiera a la billetera del usuario un token que seguir, y afirma que sin él cada billetera necesita precargar una lista de activos aprobados o los usuarios deben añadir activos manualmente. Una migración produce exactamente ese caso.
El arreglo es añadir el contrato a mano, con la dirección tomada del anuncio del propio proyecto y no de un resultado de búsqueda o un mensaje de chat. En cuanto la billetera lo siga, el saldo aparece de inmediato si ya estaba ahí, porque nada de tu posición cambió. Si sigue leyendo cero, la visualización queda descartada y todo lo demás está en la cadena.
Cuando el canje acreditó una dirección que no es tuya
Un contrato de canje debe decidir a quién paga, y esa dirección no siempre es la que tenías en mente. Si el contrato acredita a quien llama, la cuenta que firmó es la cuenta que recibió, y esa es la equivocada cuando hay dos cuentas abiertas en el mismo perfil del navegador.
La versión más difícil implica a un intermediario. Las unidades antiguas depositadas en una plataforma centralizada están bajo la dirección de esa plataforma, y un canje enviado desde una dirección de depósito paga a quien sea su dueño. Lo mismo vale para una billetera de contrato inteligente o un multifirma. Lee el evento de transferencia y fíjate en el campo del destinatario: nombra la dirección acreditada, y si no es una de las tuyas, los tokens nunca iban a aparecer donde estás mirando.
Conviene descartar primero un caso puramente administrativo. Algunas migraciones emiten el nuevo token en una cadena distinta a la antigua, de modo que el abono cae en una red a la que tu billetera no apunta. Cambiar de red lo resuelve en segundos.
Cuando las unidades antiguas se fueron y no volvió nada
Si el evento de transferencia no está y balanceOf lee cero mientras el saldo antiguo ha desaparecido de verdad, la pata del pago no corrió, y las razones son pocas.
La primera es una reserva vacía. Un canje que paga con tokens prefinanciados en vez de acuñarlos puede aceptar tu depósito y no pagar, porque la cuenta desde la que paga ha sido vaciada. De ese fallo protege el plazo de la ventana de canje, y por eso leer la reserva antes de enviar pesa más que leer el anuncio.
La segunda es una cantidad menor de lo esperado, no una ausente. Comprueba el ratio de conversión y los decimales de ambos contratos antes de concluir que no llegó nada. Una billetera con 40.000 unidades antiguas, en una consolidación de una unidad nueva por cada cuatro antiguas, tiene derecho a 10.000 unidades nuevas, es decir el 25 % de la cifra a la que estaba acostumbrada. En un contrato con otro valor de decimals, un abono correcto también puede mostrarse con la coma en un lugar poco familiar.
La tercera es que las unidades antiguas fueron a un sitio sin pata de pago asociada. Enviar tokens directamente a una dirección de contrato en lugar de pasar por la interfaz que lo llama no dispara el canje. El estándar lo hace posible porque approve permite a un gastador retirar de tu cuenta hasta un importe fijado, y transferFrom sirve a un flujo de retirada que permite a los contratos transferir tokens en tu nombre. Un contrato de canje espera tomar de ti, no recibir algo de lo que nunca se le habló.
Migraciones que una plataforma ejecutó por tu cuenta
Otro camino produce la misma queja por razones muy distintas. Si tenías el token antiguo en una plataforma centralizada durante la migración, esa plataforma convirtió su propio saldo agrupado y reescribió la entrada de tu cuenta, y el suceso apareció como un cambio de ticker sin ninguna transacción tuya.
En ese camino no hay transacción de canje que inspeccionar, así que ninguna de las comprobaciones en cadena aplica. Aplica el calendario de la plataforma: una suspensión de depósitos y retiros del token antiguo, una conversión aplicada a los saldos de cuenta y una reanudación bajo el nuevo ticker. Un saldo aún no convertido durante esa suspensión está en pausa, no perdido.
Los dos caminos también escalan distinto. Una plataforma que no te ha acreditado es una consulta de soporte con una contraparte con nombre. Un canje en cadena que no pagó no tiene contraparte en el circuito, porque el contrato ejecutó lo que le escribieron.
Qué comprobar y en qué orden
| Orden | Qué comprobar | Qué descarta una respuesta negativa |
|---|---|---|
| 1 | Si tu billetera está en la red donde se emitió el nuevo token | Un problema de visualización por cadena errónea |
| 2 | Si has añadido a mano la dirección del nuevo contrato | Que la billetera no siga un contrato nuevo |
| 3 | Si balanceOf responde para tu dirección | Cualquier explicación restante de visualización |
| 4 | Si el canje lleva un evento de transferencia hacia ti | Un abono que ocurrió y luego se movió |
| 5 | Qué dirección nombra ese evento | Un pago hecho a una dirección de depósito |
| 6 | Si el ratio y los decimales cuadran con lo llegado | Un abono correcto leído como equivocado |
| 7 | Si una plataforma ejecutó la migración por ti | Una revisión en cadena que nunca aplicó |
Recorre esa lista hacia abajo, no a lo ancho. Cada fila elimina una clase de explicación, y las de abajo solo tienen sentido cuando las de arriba están resueltas. Las tres primeras no cuestan nada.
Una advertencia acompaña a todo el ejercicio. Una billetera que parece haber perdido un saldo es justo la condición que buscan los suplantadores, y cada comprobación de arriba es una lectura pública que puedes hacer gratis. Nadie necesita tu frase de recuperación para leer un saldo, y una oferta de recuperar tokens migrados desaparecidos a cambio de ella es una segunda pérdida disfrazada de arreglo de la primera.
En resumen
Una transacción de canje en verde certifica que una llamada se ejecutó, y nada más. El nuevo saldo queda registrado en el nuevo contrato, como evento de transferencia en el momento del abono y como lectura de balanceOf después, y ambos son legibles sin preguntar a nadie. Hasta que los hayas leído, no sabes si esto es un problema de visualización o de pago.
Cuando es de visualización la secuencia es corta: cambia a la red correcta, añade a mano la dirección del contrato y el saldo ya está ahí. Cuando no lo es, el evento de transferencia nombra la dirección realmente acreditada, y ese campo separa un pago enviado a la cuenta equivocada de un pago que nunca ocurrió. Resuelve cuál de los dos tienes delante antes de enviar cualquier otra cosa a ninguna parte. Para seguir aprendiendo los fundamentos, sigue leyendo Bitbase Academy.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Cómo calcular la autonomía de la tesorería de un token
- Mecánica del suministro de un token
- ¿Qué es un token cripto? Tokens frente a monedas
- Muros de compra, muros de venta y profundidad del libro de órdenes
- La estrategia de trading de rupturas
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en septiembre de 2026; consulta la información oficial más reciente.
Fuentes
[1] Ethereum Improvement Proposals, ERC-20: Token Standard (EIP-20, estado Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-747: wallet_watchAsset RPC Method (estado Final) eips.ethereum.org
