Revoke token approvals: cómo revocar permisos de tokens y por qué

Qué es un token approval y por qué es un riesgo, cómo un permiso vacía una wallet, cómo ver y revocar permisos de tokens con revoke.cash y qué no arregla.

Por el equipo editorial de CoinDropster · Actualizado:

Revoke token approvals es una acción que conviene realizar con la misma regularidad que revisar el saldo si participas en airdrops. Cada swap, staking y depósito deja detrás un permiso: el derecho de un contrato a disponer de tus tokens. Esos permisos no caducan solos. Revocar permisos de tokens significa cerrar los canales por los que los fondos pueden salir sin una nueva firma tuya, y este artículo explica cómo surgen, cómo verlos y cuándo la revocación no ayuda.

Aquí se describe la mecánica de los permisos en redes compatibles con EVM y las herramientas generales para revisarlos. No es una guía de seguridad exhaustiva ni un consejo financiero: revocar reduce el riesgo, pero no lo elimina por completo.

Qué es un token approval

Los tokens del estándar ERC-20 (y los NFT de los estándares ERC-721/1155) no pueden ser «tomados» por un contrato por sí solos. Para que un DEX intercambie tus USDC o un pool acepte tu liquidez, primero debes permitir al contrato retirar tokens de tu dirección: eso es el approval. Técnicamente es una transacción approve(spender, amount) que registra en el contrato del token: la dirección spender puede retirar hasta amount unidades.

El problema está en dos propiedades. Primero, las interfaces piden por defecto un importe ilimitado (max uint256) para no solicitar permiso en cada operación. Segundo, el permiso es indefinido: vive hasta que lo sobrescribes. Un año después de haber usado un protocolo una sola vez, su contrato sigue teniendo derecho a retirar todo tu saldo de ese token.

Aparte están las firmas permit y permit2: el permiso se concede con una firma fuera de la cadena, sin transacción, y aparece en la red solo cuando el spender lo utiliza. Es más cómodo y barato, pero aún menos visible.

Cómo un approval se convierte en un vaciado

Hay varios escenarios, y no todos tienen que ver con fraude:

  • Un sitio de phishing. Firmaste un approve al contrato de un drainer creyendo que era un claim o un mint. El drainer llama a transferFrom y se lleva todo aquello para lo que obtuvo permiso. Cómo son esos sitios se explica en el artículo sobre sitios de claim falsos.
  • Una vulnerabilidad en un contrato legítimo. El protocolo que usaste ha sido hackeado. El atacante obtiene la capacidad de llamar a transferFrom en nombre del contrato y retira fondos de todos los que dejaron un permiso ilimitado. Ha ocurrido con protocolos importantes más de una vez.
  • Un contrato actualizable. Un contrato proxy cuya lógica se puede sustituir. Si el equipo, o quien consiga las claves, cambia la implementación, el permiso antiguo sigue vigente para el código nuevo.
  • Un protocolo abandonado. El proyecto cerró, el dominio caducó, las claves de administrador están en algún sitio. El permiso sigue activo.

Lo común a todos los casos: el retiro ocurre sin una nueva firma tuya. No verás una solicitud en la wallet, solo una transacción saliente en el historial.

Cómo ver y revocar los permisos

Los permisos se guardan en los contratos de los tokens, por lo que la wallet normalmente no los muestra. Hacen falta herramientas externas:

  1. Servicios de revisión de permisos. Por ejemplo, revoke.cash: conectas la wallet o simplemente introduces la dirección, y el servicio muestra todos los approvals activos por red: token, spender, importe, fecha de concesión. La revocación es una transacción approve(spender, 0) que el servicio construye por ti. Estos servicios existen también fuera de las redes EVM; el principio es el mismo.
  2. Exploradores. La mayoría de los exploradores de blockchain tienen una sección «Token Approvals» (Approval Checker) que hace lo mismo sin un sitio de terceros.
  3. Manualmente. Llamar a approve con importe cero en el contrato del token a través de la interfaz del explorador. Más lento, pero no exige confiar en ningún frontend.

Lo importante al revocar: es una transacción, cuesta gas y hay que hacerla en la red donde se concedió el permiso. La revocación de firmas permit que aún no se han usado funciona de otra forma: hay que invalidar el nonce o revocar el permiso sobre el propio contrato permit2; los servicios de revisión normalmente también lo muestran. Y antes comprueba que el servicio con el que revocas es el auténtico: existen «sitios de revoke» falsos que piden exactamente la firma de la que quieres deshacerte.

Rutina de revocación entre campañas

Revocar no es una acción puntual tras un incidente, sino un hábito. Un calendario razonable:

  • Al terminar una campaña. El proyecto pasó a Distributed, ya retiraste los tokens: revoca los permisos sobre sus contratos y sobre todo lo que conectaste para su checklist.
  • Después del claim. El sitio de claim pudo pedir permisos que no eran necesarios para recibir los tokens. Compruébalo de inmediato.
  • Cada pocas semanas. Revisión general en todas las redes donde la wallet esté activa. Atención especial a los permisos ilimitados y a las direcciones spender que no reconoces.
  • Antes de una transferencia grande a la wallet. Si vas a mantener en la dirección más de lo habitual, asegúrate primero de que no tiene permisos activos.

La prevención es más barata que la revocación: al conceder un permiso, fija el importe exacto en lugar de ilimitado si la interfaz de la wallet lo permite, y mantén en la wallet activa solo lo necesario para las acciones en curso. Cómo se organiza esa arquitectura se explica en el artículo sobre la configuración de la wallet para airdrops.

Qué no arregla la revocación

Revocar permisos cierra un vector concreto: el retiro mediante approve/permit. No ayuda en situaciones que se confunden con él:

  • Frase semilla o clave privada filtrada. Quien tiene la semilla es dueño pleno de la wallet. Puede conceder nuevos permisos, transferir fondos directamente y anular tus revocaciones. La única solución es una wallet nueva con una semilla nueva y trasladar lo que quede.
  • Una transferencia ya ejecutada. Si el transferFrom ya se realizó, la revocación protege solo el resto. Lo que salió no vuelve.
  • El token nativo de la red. ETH, BNB y similares no requieren approve. Solo se pueden perder con una transacción directa firmada por ti; la revocación no tiene nada que ver.
  • Delegación de cuenta. En redes donde una cuenta puede delegar la ejecución de código a otro contrato, revocar permisos de tokens no cancela la delegación. Es un ajuste aparte.
  • Tokens scam en la wallet. Los tokens que «llegaron» solos son inofensivos mientras no interactúes con ellos. No hay nada que revocar; simplemente no los toques ni sigas los enlaces de sus nombres.

En resumen: revocar permisos es una parte obligatoria, pero no la única, de la higiene. Junto con una wallet separada, la verificación de enlaces y la lectura de lo que firmas, convierte la participación en airdrops en una actividad de riesgo limitado. Los estados de proyecto tras los que conviene hacer una revisión — Reward available y Distributed — se rastrean en CoinDropster. Ver airdrops rastreados →