Un proyecto se muda a un nuevo contrato de token, anuncia una ventana de canje y la ventana se cierra. Meses después abres una cartera vieja y el saldo del token antiguo sigue ahí. Que pueda convertirse todavía no es una pregunta con una sola respuesta. En una migración caducan tres cosas distintas, cada una se aplica en un sitio distinto y solo una de ellas la aplica el código.
Qué mueve realmente una migración de token
Una migración no mueve tus tokens a ninguna parte. El contrato antiguo sigue funcionando en su propia dirección y tu saldo permanece en su registro mientras funcione la cadena. Lo que ofrece una migración es un canje: entregas unidades antiguas a un contrato de canje o a una plataforma y esta te acredita el derecho equivalente en un registro nuevo.
Ese canje corre sobre la fontanería habitual de los tokens. En el estándar ERC-20, `approve` permite a un gastador retirar de tu cuenta hasta un importe fijado, y `transferFrom` mueve tokens de una dirección a otra; el estándar presenta ese par como un flujo de retirada que permite a los contratos mover tokens en tu nombre. Un contrato de canje es uno de esos gastadores y la cadena no le da ningún estatus especial.
De ahí se siguen dos cosas. Tu saldo antiguo no se degrada ni caduca por sí solo, y el plazo nunca es una propiedad de los tokens que tienes. El plazo pertenece a quien está al otro lado del canje, dispuesto a pagar. La pregunta no es, entonces, si tus tokens caducaron. Es qué le pasó a la contraparte.
Tres cosas pueden caducar y no son lo mismo
En un anuncio de migración típico, la palabra plazo hace demasiado trabajo. Si la separas, hay varios relojes distintos y cada uno se aplica en otro sitio.
El primero es la fecha anunciada, una línea en un blog o un banner en una aplicación. Nada en la cadena la lee. El segundo es una comprobación escrita en el contrato de canje, que se niega a ejecutarse en cuanto la marca de tiempo del bloque actual supera un valor fijado en el código. El tercero es la reserva de tokens nuevos con la que paga el contrato, y quien la aportó puede retirarla cuando el proyecto dé la migración por terminada.
| Qué caducó | Dónde se aplica | Qué haría falta para reabrirlo |
|---|---|---|
| La fecha anunciada | En ningún sitio de la cadena | Nada, el contrato nunca la comprobó |
| Una comprobación de marca de tiempo en el contrato de canje | El código del contrato | Una vía de actualización, si se dejó prevista |
| La reserva de tokens nuevos | Un saldo en la cadena | Que alguien vuelva a fondear el contrato |
| Un servicio de migración en una plataforma | La política interna de esa plataforma | Una decisión de esa plataforma |
Todo lo que sigue sirve para averiguar en qué fila estás.
Lee el contrato antes de darlo por cerrado
Las dos primeras filas puedes resolverlas tú mismo y gratis. Abre el contrato de canje en un explorador de bloques y lee su código fuente verificado. Si la función de canje no contiene ninguna comparación con una marca de tiempo de bloque, en el código no hay plazo y la fecha anunciada nunca fue más que una comunicación. En ese caso, un canje enviado un año tarde se ejecuta igual que uno enviado el primer día.
Si hay una comprobación de marca de tiempo, ese es otro hallazgo, y firme. El código de un contrato hace lo que se escribió en él, y una condición que revierte pasado un momento fijado seguirá revirtiendo. Ningún ticket de soporte cambia eso, porque no hay a quién convencer: el rechazo es una línea de código ejecutándose como estaba previsto.
La única matización es la actualizabilidad. Si el canje está detrás de un proxy cuya lógica puede sustituirse, quien tenga ese poder puede en principio levantar el plazo. Eso es una decisión del proyecto y no un derecho tuyo, pero es la diferencia entre una puerta cerrada y una puerta soldada, y leer el contrato es como se distinguen.
Cuando el contrato está abierto pero la reserva está vacía
Un contrato sin plazo tampoco puede pagar desde una cuenta vacía. Los tokens nuevos tienen que salir de una reserva guardada en la dirección de canje, y si el proyecto escribió una función que barre lo que queda al cerrarse la ventana, puede vaciar esa reserva. Tras ese barrido, la función de canje quizá siga aceptando tus tokens antiguos y siga fallando, porque detrás de la pata del pago ya no hay nada.
Veamos un ejemplo. Un proyecto consolida a razón de una unidad nueva por cada diez antiguas, y una cartera tiene 25.000 unidades antiguas, de modo que el derecho es de 2.500 nuevas. Supongamos que el 96% de la oferta antigua pasó durante la ventana; el 4% restante es la parte que reclaman los rezagados, y que el contrato pueda atender esas reclamaciones es sencillamente el saldo de tokens nuevos en la dirección de canje. Ese saldo es público. Compruébalo antes de enviar nada.
Este es el caso que castiga el optimismo. Enviar tokens antiguos a un contrato que no puede pagarte no te deja donde estabas: las unidades antiguas se fueron a una dirección que nunca se escribió para devolverlas, y no tienes nada nuevo. Lee primero la reserva y, si está vacía, no envíes.
Migraciones que una plataforma hizo por ti
Algunas migraciones no tocaron tu cartera. Si tenías el token antiguo en una plataforma centralizada durante el canje, la plataforma convirtió su propio saldo agrupado y reescribió el apunte de tu cuenta, así que la migración apareció en tu cuenta como un cambio de ticker y nada más.
Esa vía tiene su propio reloj y es una política, no una regla de la cadena. Una plataforma anuncia una ventana de conversión, acredita los saldos que llegan dentro y en algún momento deja de hacerlo. La forma resulta familiar por el deslistado de tokens: un aviso, una ventana y después el acceso cerrado, y la recuperación posterior depende de si esa casa sigue manteniendo un proceso manual para los rezagados.
Aquí hay, por tanto, dos preguntas y no una, y tienen respuestas distintas. Si la plataforma acreditará un depósito tardío de tokens antiguos es una pregunta de soporte. Si el contrato de canje en cadena seguirá pagando es una pregunta de código. Respóndelas por separado, porque un no en una no dice nada sobre la otra.
Qué queda cuando la vía en cadena se cierra del todo
Supongamos que el código está cerrado, la reserva barrida y ningún servicio tramitará una reclamación tardía. El token antiguo no ha dejado de existir. Es un saldo en un contrato que sigue funcionando, se puede seguir transfiriendo y, por tanto, vender a quien quiera comprarlo, al precio que dé el mercado de un registro abandonado.
No busques un atajo enviando las unidades antiguas a algún sitio que parezca prometedor. Enviarlas al nuevo contrato del token, o al propio contrato antiguo, es el mismo tipo de error que enviar cripto a la dirección equivocada: un contrato no tiene clave privada y, si nadie escribió una función que saque los tokens extraviados, nadie puede. El estándar ERC-223 se escribió justo alrededor de este fallo y señala que los tokens enviados a un contrato con una transferencia simple llegan como un saldo del que el contrato nunca se entera.
El resumen honesto de este caso es que el tamaño de la pérdida ya está fijado y cada transacción adicional solo puede aumentarlo. Mantener la posición no cuesta nada. Adivinar un rescate puede costar el resto.
El plazo de migración es cebo para suplantadores
Una ventana que caduca crea urgencia, un caudal de titulares desorientados y un motivo legítimo para que un proyecto pida a la gente que conecte una cartera. Los atacantes no tienen que inventar nada de eso. Solo necesitan un sitio calcado. Esa es la forma de la suplantación de identidad, y por eso un resultado de búsqueda es la manera equivocada de llegar a un portal de migración.
El mecanismo que busca un portal falso es el mismo que usa un canje real. Una migración genuina pide una autorización para que el contrato pueda retirar tus tokens antiguos, y las aprobaciones de tokens concedidas a un atacante hacen exactamente lo que dicen: dejan que esa dirección se lleve el saldo que aprobaste. Concede una autorización limitada en vez de ilimitada, coteja la dirección del contrato con el anuncio publicado por el propio proyecto y llega al sitio por tu propio marcador.
Una regla atraviesa toda la categoría. Cada dato que necesitas en una migración tardía se lee gratis en un explorador público: el código fuente del contrato, la comprobación de la marca de tiempo, el saldo de la reserva. Quien cobre por reabrir una migración cerrada, o pida una frase de recuperación para hacerlo, te está vendiendo la segunda pérdida y no el arreglo de la primera.
En resumen
Los tokens antiguos no caducan. Las contrapartes sí. Una fecha anunciada no obliga a nadie en la cadena; una comprobación de marca de tiempo en el contrato de canje obliga a todos, incluido el proyecto; y una reserva barrida cierra la puerta con la misma firmeza, dejando el picaporte en su sitio. Esos tres casos se ven idénticos en la pantalla de una cartera y por debajo son completamente distintos.
El orden de trabajo es fijo. Lee el contrato de canje en un explorador, busca la comprobación de marca de tiempo, luego lee el saldo de la reserva en esa dirección y, si hubo una plataforma implicada, pregúntale aparte. Si todo eso vuelve cerrado, el saldo antiguo sigue siendo tuyo y sigue siendo transferible, y ninguna urgencia debería llevarte a enviarlo a un sitio que no puede devolver nada. Para seguir aprendiendo los fundamentos, sigue leyendo Bitbase Academy.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Cómo revocar una delegación de gobernanza
- Por qué una migración de token pide una aprobación en la billetera
- Migración de tokens completada pero los nuevos tokens no aparecen
- Cómo calcular la autonomía de la tesorería de un token
- Futuros con margen en moneda frente a futuros con margen en USDT: qué contrato operar
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, los métodos approve y transferFrom (estado: Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model, sección Motivation (estado: Final) eips.ethereum.org
