Diferencia entre aprobación de token y transferencia
Una explicación clara de dos acciones que suelen confundirse en una billetera.
Este artículo puede contener enlaces de afiliados. Las relaciones comerciales se detallan en la política de afiliados.
Aprobar un token y transferir un token son dos acciones distintas en una billetera, y confundirlas es el origen de muchas pérdidas. En una transferencia, los tokens salen de tu cuenta hacia un destinatario en ese mismo momento. En una aprobación, no sale nada: lo que haces es escribir un límite que permite a un contrato mover tokens tuyos más adelante, hasta esa cantidad, mientras el permiso siga vigente.
La diferencia parece técnica pero decide cuánto pierdes si te equivocas. Una transferencia incorrecta se puede intentar recuperar contacting al destinatario. Una aprobación incorrecta entrega una capacidad que otro puede ejercer cuando quiera, y por eso la pantalla de aprobación deserve una lectura más lenta que la de transferencia.
Qué hace cada acción
Transferir llama a la función de transferencia del contrato del token y mueve la cantidad indicada a la dirección receptora. El saldo baja en el momento, el receptor lo ve subido, y la operación queda registrada en la red de forma definitiva.
Aprobar escribe un valor en la tabla de permisos del contrato: ese contrato queda autorizado a mover tu saldo de ese token hasta el límite fijado. Tu saldo no cambia. No hay receptor. La operación también queda registrada, y también es definitiva.
Por eso una pantalla de aprobación puede parecer inofensiva. No hay importe saliendo, no hay destinatario, y el saldo sigue igual cuando la cierras. El riesgo queda desplazado hacia adelante.
Por qué el límite es el número que importa
Como la aprobación no transfiere nada, el número que aparece en la pantalla no es un pago: es un techo. Si ese techo es mayor que tu saldo completo, el contrato podría vaciar tu billetera entera de ese token, y lo podría hacer más adelante sin pedirte nada.
La recomendación de seguridad publicada por Ethereum es explícita: al interactuar con contratos inteligentes, no concedas límites de gasto ilimitados. Un permiso ilimitado no es una comodidad neutral, es una autorización sin techo que sobrevive a la sesión en la que la concediste.
Muchas interfaces piden permiso ilimitado para ahorrarte una segunda aprobación más adelante. Es cómodo para la interfaz y mala para ti. Si una aplicación no acepta un límite concreto, esa negativa es información: no es una función de seguridad trabajando a tu favor.
El riesgo se activa en otra transacción
Este es el punto que más confunde. Una aprobación por sí sola no mueve fondos, pero deja una autorización lista para ser usada. La operación que la aprovecha es otra transacción, que puede originarse en esa misma aplicación o en cualquiera que tenga el permiso.
Las estafas conairdrops funcionan exactamente así: la página de reclamo te pide “aprobar” una transacción, y esa aprobación entrega tus claves privadas o tu límite de gasto. En la variante más común, tras aprobar te piden confirmar una segunda operación que ya vacía la cuenta, y esa segunda pantalla parece la acción de verdad.
Por eso el número de pantallas no es una garantía. Dos pantallas consecutivas no equivalen a dos decisiones informadas.
Cómo reducir el permiso
Pon un límite concreto. Da solo lo que la operación necesita. Si vas a intercambiar una cantidad determinada, ese es el límite.
Revisa las aprobaciones con periodicidad. Revocar un permiso es otra transacción, con su coste, y solo tiene sentido sobre aprobaciones que ya no necesitas.
Revoca por red. Una aprobación en la red principal y la misma en una red secundaria son permisos separados. Revocar una no anula la otra.
Guarda un registro. Anota protocolo, dirección del contrato, activo, límite y fecha. Cinco entradas son manejables; una lista que nunca escribiste es la razón por la que una aprobación vieja sobrevive un año.
Lo que esta diferencia no cubre
Entender la diferencia entre aprobar y transferir no te dice qué hará el contrato con el permiso. Una aprobación prudente puede entregarse a un contrato con una lógica que no puedes verificar desde la interfaz, y ese contrato puede ejercer el límite de una forma que no tenías prevista.
Tampoco te dice si el protocolo es solvente o ha sido auditado. Son dos preguntas distintas: una es sobre permisos, la otra sobre el proyecto. Si las mezclas, asumes que un protocolo conocido vuelve seguro cualquier contrato que muestre su nombre.
Lecturas relacionadas
- Qué revisar antes de conectar una billetera a una aplicación
- Cómo revisar los permisos de una aplicación descentralizada
- Cómo verificar un contrato de token antes de usarlo