Cómo entender los límites de aprobación de tokens
Qué significan las aprobaciones limitadas e ilimitadas antes de firmar.
Este artículo puede contener enlaces de afiliados. Las relaciones comerciales se detallan en la política de afiliados.
Cuando conectas una billetera por primera vez, casi todas las Interfaces piden una aprobación antes de dejarte mover tus tokens. Esa aprobación lleva un límite, y el límite es la parte que casi nadie lee. Entender qué significan “ilimitado” y “una cantidad exacta” es lo que separa una conexión rutinaria de una que deja la puerta abierta.
Qué es realmente una aprobación
Una aprobación no es un movimiento de fondos. Es un permiso: le dices a un contrato que puede retirar tokens de tu dirección hasta cierta cantidad, sin volver a preguntarte.
Lee la pantalla como una frase con tres partes: “el contrato X puede mover hasta Y cantidad del token Z desde tu dirección”.
- El contrato. Aprobar una aplicación y aprobar el contrato actual de esa aplicación son dos aprobaciones distintas. Una aplicación puede actualizar su implementación y cambiar de comportamiento sin que tengas que aprobar nada nuevo.
- La cantidad. Una aprobación ilimitada es el valor por defecto en muchas Interfaces, porque resulta más cómoda para el usuario. No es una señal de peligro por sí sola, pero elimina el techo que habría limitado el daño.
- El token. Las aprobaciones son por token. La misma aplicación puede tener varios permisos abiertos, uno por cada activo que has movido con ella.
Limitado frente a ilimitado
Una aprobación limitada te protege de una forma concreta: si el contrato fuera comprometido, solo podría llevarte la cantidad que firmaste. En la práctica ese techo casi nunca se alcanza, porque las Interfaces piden la cantidad exacta que vas a mover.
Una aprobación ilimitada no es distinta en estructura, solo en alcance. Con la misma aplicación abierta, un atacante que controle el contrato podría vaciar el token aprovado por completo.
Aquí está el matiz que suele pasarse por alto: una aprobación ilimitada de un contrato que ya no usas es un riesgo abierto. Un contrato abandonado sigue teniendo permiso. Las aprobaciones se acumulan en silencio, y una billetera con treinta permisos activos después de dos años de uso no es nada raro.
Cuándo conviene revisar y revocar
Revoca cuando una posición está cerrada, cuando una aplicación lleva meses sin usarse, o cuando no puedes explicar qué hace un contrato concreto. La tercera razón es la más común.
La revisión se hace desde un registro, no desde la memoria. Exporta la lista de aprobaciones desde un explorador de bloques o desde la vista de permisos de tu propia billetera, y ordénala por contrato. Para cada entrada, hazte dos preguntas:
- ¿Sigo usando esta aplicación?
- ¿Sé decir qué hace con el token?
Una aprobación que no puedas explicar no se deja en pie: se revoca. Una aprobación de una aplicación que usas de verdad puede quedarse, siempre que entiendas qué controla.
Lo que la revocación no hace
Revocar elimina el permiso hacia adelante. No deshace una transferencia ya realizada, no recupera tokens que ya se movieron y no avisa a nadie.
Dos consecuencias prácticas salen de ahí. Revocar cuesta gas, así que hacerlo treinta veces de golpe cuesta más que hacerlo solo con las dos que importan. Y revocar puede romper una aplicación legítima que dependía de una aprobación antigua, por lo que conviene cerrar la posición antes de revocar, no después.
Anota lo que cambiaste
Escribe el contrato, el token, la fecha y el motivo. La próxima vez que uses esa aplicación no recordarás qué aprobaciones quitaste, y volver a aprobar sin comprobar es exactamente la forma en que regresan los permisos viejos.
Este texto es informativo y no sustituye la documentación oficial de ninguna billetera ni de ningún protocolo.