Un proyecto se muda a un contrato nuevo, abres la página de migración y, antes de que se haya movido un solo token, tu billetera te pide aprobar el antiguo. La solicitud parece un paso extra que alguien añadió al flujo. No lo es. En ERC-20 es la única forma de entregar un saldo a alguien que no seas tú, y leerla bien separa una migración de una billetera vaciada.
Qué concede realmente la aprobación
Una aprobación es una escritura en un registro que vive dentro del contrato del token antiguo. Anota un único número para un par de direcciones: cuánto de ese token puede sacar de tu cuenta un gastador con nombre propio. Firmarla no mueve nada, no envía nada al proyecto y no te compromete a ningún canje.
En el estándar token ERC-20 se llega a ese registro por dos funciones. `approve` permite a un gastador retirar de tu cuenta de forma repetida, hasta un importe fijado, y `transferFrom` es la llamada que mueve realmente los tokens de una dirección a otra. La especificación presenta el par como un flujo de retirada que deja a los contratos transferir tokens en tu nombre, y un contrato de migración es uno de esos contratos, sin ninguna posición especial.
Dónde se guarda la anotación pesa más de lo que parece. El permiso queda en el token antiguo, no en el contrato de migración, así que sobrevive a la página de migración, al canje mismo y al proyecto. Cerrar la pestaña no lo borra.
Por qué el contrato de canje tiene que pedirlo
Un canje tiene que tomar las unidades antiguas antes de poder acreditar las nuevas. El contrato no puede meter la mano en tu cuenta por su cuenta, y sobre tu saldo el contrato del token solo escucha a la cuenta que lo tiene.
La alternativa aparente es enviar tú mismo los tokens antiguos al contrato con una transferencia corriente. Eso sí mueve los tokens, y también falla: una transferencia simple llega como saldo sin ninguna llamada que la acompañe, así que al contrato nunca se le comunica la transferencia y no tiene contra qué acreditar. El estándar ERC-223 se escribió justo alrededor de este fallo. Tirar con `transferFrom` le da al contrato una sola llamada en la que recibe las unidades antiguas y paga las nuevas, y esa llamada necesita antes un permiso.
Dos transacciones, y solo la segunda canjea
La aprobación y el canje son transacciones separadas, cada una con su propio gas. ERC-2612 lo plantea sin rodeos: si un usuario necesita interactuar con un contrato inteligente, entonces tiene que hacer 2 transacciones, `approve` y la llamada al contrato que internamente llamará a `transferFrom`.
Como están separadas, la primera puede salir bien y la segunda fallar igualmente. Una ventana de canje ya cerrada, una reserva de pago vaciada, un contrato en pausa: nada de eso lo ve la aprobación, que solo escribe un número y vuelve. Que una aprobación se confirme no prueba que funcione la migración que hay detrás.
La trampa inversa está un paso más allá. Un canje tras una simulación correcta puede revertirse igualmente en cadena, porque la simulación responde a una pregunta sobre el estado en un momento y no sobre el estado en el que aterriza tu transacción. Cuando el canje revierte, el permiso que concediste queda intacto y sigue en pie.
Migraciones que no tienen motivo para pedirlo
No toda migración funciona con un permiso. La forma que te anunciaron debería coincidir con la solicitud que recibiste.
| Cómo se ejecuta la migración | Qué envías tú | ¿Corresponde aquí una aprobación? |
|---|---|---|
| Un contrato de canje tira de tus unidades antiguas | Una aprobación y luego la llamada de canje | Sí |
| Transfieres los tokens antiguos a una dirección publicada | Una transferencia corriente | No |
| Se acredita a los tenedores registrados según una instantánea | Nada | No |
| Una plataforma convierte su propio saldo agrupado | Nada | No |
La fila que debería detenerte es la tercera. Un reparto anunciado como automático no tiene ningún mecanismo que necesite tu permiso, así que una página que lo pide está pidiendo algo que la migración descrita no usa. Notar ese desajuste no cuesta nada y no depende del juicio de nadie sobre el sitio.
Los tres campos de la solicitud que lo deciden todo
Toda solicitud de aprobación lleva los mismos tres campos, los llame como los llame tu billetera.
| Campo | Qué concede | Con qué contrastarlo |
|---|---|---|
| Token | En el registro de qué contrato se escribe la anotación | La dirección del contrato antiguo del anuncio propio del proyecto |
| Gastador | Qué dirección puede tirar de tu cuenta | La dirección del contrato de migración de ese mismo anuncio |
| Importe | El techo de lo que esa dirección puede llevarse | El tramo que piensas canjear ahora |
Compara las direcciones enteras. Una dirección parecida puede compartir con la real los primeros y últimos caracteres, y la diferencia está en el medio.
El campo del gastador es el que carga con la pérdida, y por eso un drainer de billeteras no necesita romper nada. Pone su propia dirección en ese campo y te deja firmar una aprobación válida y bien formada. La transacción sale bien exactamente como está escrita, y el saldo se va después, según el calendario del atacante y no el tuyo.
Cuando lo que piden es una firma y no una transacción
Un permiso no siempre llega como transacción. ERC-2612 amplía el estándar ERC-20 con una función `permit` que permite a los usuarios modificar el mapeo allowance mediante un mensaje firmado, en lugar de a través de `msg.sender`; un permit válido fija el permiso de ese gastador en el valor indicado, incrementa un nonce y emite un evento de aprobación.
La consecuencia es que una pantalla con un simple mensaje que firmar, sin gas y sin transacción pendiente, puede conceder exactamente lo que concede una transacción de aprobación. Además, en el momento de firmar no deja nada en tu propio historial de transacciones, porque el mensaje firmado lo envía otra persona.
Así que lee una solicitud de firma por esos mismos tres campos. Un permit nombra al gastador y el valor que fija, más un deadline en el que la especificación exige que el tiempo de bloque actual esté por debajo o justo encima. Si una página presenta la firma como un inicio de sesión o una confirmación mientras los datos tipados nombran un gastador y un importe, lo que se ejecutará son los datos tipados.
Importe exacto o ilimitado, y el permiso que se queda
Un ejemplo. Una billetera tiene 10.000 unidades antiguas y el proyecto ha abierto un canje. Aprobar 2.500, canjear ese tramo y contrastar lo que llega con la ratio anunciada convierte la migración en algo observado y no supuesto. Las 7.500 restantes necesitan luego una segunda aprobación, es decir un pago de gas más, y ese es todo el coste del método.
Una aprobación ilimitada elimina ese segundo pago y lo cambia por un permiso permanente sobre ese token mientras la anotación siga viva. El contrato de migración conserva el derecho a tirar de cualquier unidad antigua que llegue a tu cuenta después, incluido un saldo de tokens antiguos que recuperes años más tarde de una billetera vieja.
Termina limpiando lo que quede. Una aprobación por el importe exacto la consume el canje para el que se concedió, mientras que cualquier cosa mayor deja una anotación viva, y una aprobación de tokens que sobrevive a su propósito es un permiso que ya nadie vigila. Poner el permiso a cero es en sí una transacción con su propio gas, así que hazlo de forma deliberada cuando la migración haya terminado.
En resumen
Una migración pide una aprobación porque ERC-20 no le da otra vía para tomar tus tokens antiguos. La aprobación es un número escrito en el contrato del token antiguo que nombra una dirección y un techo: no mueve nada, no prueba nada sobre la migración que hay detrás y no caduca cuando cierras la página.
Eso reduce todo el trabajo a tres comprobaciones. Si esta forma de migración necesita realmente un permiso, si el gastador es la dirección que publicó el proyecto y si el importe es el tramo que querías canjear. Una solicitud de firma responde a las mismas tres, y un permiso concedido sobrevive a todo lo que lo rodea, así que retíralo cuando el canje esté hecho. 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
- Cómo calcular la autonomía de la tesorería de un token
- Mecánica del suministro de un token
- El ATR y cómo medir la volatilidad
- Las bandas de Bollinger explicadas
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-2612: Permit Extension for EIP-20 Signed Approvals, secciones Abstract y Specification (estado: Final) eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model, sección Motivation (estado: Final) eips.ethereum.org
