Aprobaciones de tokens en cripto: allowances, permisos ilimitados, Permit2 y cómo revocarlos

Las aprobaciones de tokens son permisos que permiten a otra dirección de Ethereum —normalmente un smart contract— mover una cantidad determinada de un token ERC-20 desde tu wallet. El mecanismo forma parte del propio estándar: la especificación ERC-20 define approve(spender, value), allowance(owner, spender) y transferFrom(from, to, value). Esa combinación permite que un DEX, protocolo de lending, bridge, aplicación de staking u otro contrato utilice tokens que siguen en tu wallet hasta que la aplicación realmente necesita transferirlos.

El problema de seguridad es que una aprobación puede seguir siendo válida después de cerrar la web, desconectar la wallet o incluso olvidar la interacción. Si el spender aprobado es malicioso o más adelante resulta comprometido, el allowance restante puede seguir utilizándose. Por eso una aprobación no es simplemente una pantalla de confirmación puntual: es un estado de autorización onchain.

Puntos clave

• Conectar una wallet a una dapp y aprobar gasto de tokens son acciones distintas.
• Desconectar la wallet de una web no revoca allowances ERC-20 ya registrados.
• Una aprobación depende de tres elementos: contrato del token, wallet del owner y dirección del spender.
• El allowance es un límite de permiso, no necesariamente una transferencia inmediata.
• Los permisos ilimitados reducen transacciones de aprobación repetidas, pero aumentan el impacto de un spender comprometido.
• Revocar un allowance ERC-20 normalmente requiere otra transacción onchain que reduzca el permiso, frecuentemente a cero.
• EIP-2612 permit puede crear o cambiar un allowance mediante una firma, mientras Permit2 introduce otra capa de permisos con firmas y límites temporales.
• Una hardware wallet protege la clave de firma; no convierte una aprobación peligrosa en segura.
• Revisa permisos por red y dirección de contrato, no solo por nombre de dapp o ticker.
• Si detectas una aprobación sospechosa antes de que sea utilizada, revocarla puede reducir el riesgo; no recupera tokens ya transferidos.

Cómo funciona una aprobación ERC-20

El flujo ERC-20 separa propiedad y gasto delegado.

Imagina que una wallet tiene 1.000 USDC y quiere depositar 250 USDC en un protocolo DeFi. El protocolo no puede tomar los tokens directamente. Un flujo habitual es:

1. La wallet llama al contrato USDC y aprueba la dirección spender del protocolo.
2. El protocolo utiliza después transferFrom para mover hasta la cantidad autorizada.

Si el owner aprueba exactamente 250 USDC y el protocolo gasta los 250, el allowance puede quedar agotado según la implementación. Si aprueba 1.000 y se gastan 250, puede permanecer permiso para 750.

La aprobación se almacena en el contrato del token, no en la página web. Cerrar la pestaña no la elimina.

Esto también importa con smart wallets. La guía de BTC-Pulse sobre monederos smart contract explica cómo ERC-4337 y otras arquitecturas introducen autorización programable. Los token allowances son otra capa: una wallet puede tener reglas sofisticadas de owners y, al mismo tiempo, conceder a un spender una autorización independiente sobre un token.

Aprobar no es transferir

Una aprobación modifica permiso. Una transferencia modifica propiedad.

Supongamos una wallet con 10.000 unidades de Token X que aprueba a Router Y por 2.000.

Justo después:

• la wallet sigue teniendo 10.000;
• Router Y tiene allowance de hasta 2.000;
• no necesariamente ha ocurrido ninguna transferencia de 2.000.

Si Router Y usa transferFrom para 600, puede quedar un allowance de 1.400.

Esta diferencia es importante al investigar incidentes. Un evento Approval no demuestra que el dinero ya haya salido. Una transferencia posterior es un evento separado.

También explica por qué una wallet puede mostrar un spending cap enorme sin que esa cantidad haya sido robada. Lo que muestra es autoridad potencial.

Por qué las dapps piden permisos grandes o ilimitados

Las aprobaciones repetidas cuestan gas y añaden pasos. Una persona que intercambia el mismo token cada semana puede no querer aprobar el router en cada sesión.

Por eso muchas aplicaciones solicitan un allowance muy grande, a veces equivalente a ilimitado. En Solidity suele representarse mediante el máximo valor de uint256.

La ventaja:

• una aprobación funciona para muchas acciones;
• se ahorra gas;
• el flujo es más sencillo.

La desventaja es autoridad persistente. Si el spender es explotable, se actualiza de forma maliciosa, es controlado por governance inseguro o simplemente era la dirección equivocada, la exposición puede superar ampliamente el importe de una sola operación.

El mejor valor no siempre es “cantidad exacta” ni siempre “ilimitado”. Depende del riesgo. Para un contrato conocido y utilizado con frecuencia, algunas personas aceptan más allowance por comodidad. Para una dapp desconocida, un default ilimitado no debería aprobarse sin entenderlo.

Desconectar no equivale a revocar

La conexión permite normalmente que una web vea la dirección pública y solicite firmas o transacciones. Desconectar termina esa relación interactiva en la interfaz.

No cambia el estado ERC-20.

La documentación de MetaMask distingue claramente ambos conceptos: una aprobación puede seguir activa después de desconectar una dapp.

Regla práctica:

desconectar = cerrar la sesión/interacción con la web

revocar = cambiar el permiso del token onchain

Si sospechas de una web, desconectarla tiene sentido, pero no completa la remediación.

Qué hace realmente una revocación

En allowances ERC-20 normales, revocar suele significar enviar una transacción que cambia el allowance, normalmente a cero. Como modifica estado de blockchain, requiere gas.

La guía de MetaMask para revocar approvals explica que pueden revisarse permisos mediante la propia wallet o block explorers y enviar una transacción de revocación.

Revocar afecta al uso futuro del allowance. No:

• recupera tokens ya enviados;
• revierte swaps;
• elimina contratos maliciosos;
• cancela permisos en otras redes;
• invalida necesariamente otros sistemas de firmas.

Esto último es clave con permit y Permit2.

Un approve(spender, 0) ordinario no invalida por sí solo una firma EIP-2612 pendiente: normalmente no incrementa el nonce de permit. Si el nonce firmado sigue vigente y no ha pasado el deadline, cualquiera que tenga la firma puede presentarla y restablecer el allowance firmado. EIP-2612 no exige una función específica para cancelar nonces. Usa únicamente un mecanismo de cancelación verificado del token, si existe, o un permit de sustitución presentado con éxito usando el mismo nonce vigente; las presentaciones pueden competir por inclusión. El deadline limita la presentación de la firma, no la duración del allowance ERC-20 resultante.

EIP-2612 permit: autorización mediante firma

La especificación EIP-2612 añade permit a ERC-20. En lugar de enviar directamente una transacción approve, el owner firma datos estructurados con spender, valor, nonce y deadline. Otra parte puede presentar la firma onchain.

La experiencia mejora porque aprobación y acción pueden agruparse o ser relayed.

Pero cambia lo que el usuario debe reconocer como peligroso. Una firma puede crear autoridad de gasto aunque la wallet no muestre una transacción approve tradicional.

EIP-2612 utiliza un nonce contra replay y un deadline para limitar la validez. Si el deadline es extremadamente lejano, la ventana de autorización también lo es.

La conclusión no es que “firmar sea inseguro”. La conclusión es que “solo es una firma” no significa “no puede autorizar tokens”.

Permit2 añade otra capa

La documentación de Permit2 de Uniswap describe:

• SignatureTransfer, para transferencias mediante firmas de un solo uso;
• AllowanceTransfer, para permisos con cantidad y duración.

En un flujo típico, el token concede primero permiso ERC-20 al contrato Permit2. Después, firmas Permit2 autorizan spenders específicos según las reglas de Permit2.

Hay por tanto dos capas:

1. token → Permit2;
2. Permit2 → aplicación/spender.

Al investigar riesgo, revisar solo una puede ser insuficiente.

Una firma maliciosa también puede ser peligrosa aunque no genere una transacción onchain en el momento de firmarla. La guía de MetaMask sobre signature phishing incluye Permit2 precisamente porque los atacantes pueden intentar obtener permisos firmados en vez de la seed phrase.

AllowanceTransfer guarda un allowance reutilizable en Permit2, indexado por owner, token y spender, con cantidad, expiración y nonce. Puede establecerse mediante approve onchain de Permit2 o un permit firmado. SignatureTransfer no crea ese allowance persistente para el spender: consume una autorización firmada de un solo uso al transferir. Ambos flujos siguen necesitando una aprobación ERC-20 token→Permit2 suficiente. Una firma de un solo uso puede seguir siendo utilizable hasta su deadline si su nonce no se ha utilizado ni invalidado.

En Permit2 AllowanceTransfer, reducir el allowance o llamar a lockdown no invalida por sí solo firmas permit pendientes. invalidateNonces(token, spender, newNonce) incrementa el nonce de ese permiso; no elimina por sí solo un allowance existente. SignatureTransfer utiliza otro sistema de nonces, un bitmap sin orden: invalidateUnorderedNonces(wordPos, mask) invalida los bits seleccionados. Revocar token→Permit2 bloquea las transferencias mientras esa aprobación siga en cero, pero no borra el estado de Permit2 ni las firmas; restaurarla puede volver a exponer permisos aún válidos.

Mapa práctico de permisos

Los botones exactos de las wallets pueden cambiar; la arquitectura es lo importante.

El permiso está limitado por token y red

Un allowance ERC-20 pertenece a un contrato de token concreto en una cadena concreta.

Aprobar un spender para USDC en Ethereum no lo aprueba automáticamente para USDC en Base. Aprobar USDC tampoco concede autoridad sobre todos los demás tokens de la wallet.

Ese aislamiento ayuda, pero también crea errores: una persona puede revisar el ticker correcto en la red incorrecta.

La guía de BTC-Pulse sobre USDC y USDC.e explica por qué un token nativo y una representación bridged pueden ser económicamente parecidos y aun así ser contratos distintos. Al revisar approvals, la dirección exacta importa por la misma razón.

Ejemplo: permiso exacto frente a ilimitado

Imagina una wallet con 5.000 Token A que quiere depositar 400 en Protocol B. Suponemos una implementación ordinaria que reduce los allowances finitos al gastar, sin cambios posteriores mediante approve o permit.

Opción 1: aprobación exacta

Aprueba 400.

Si el protocolo gasta los 400, el permiso puede quedar sin saldo restante.

La exposición está cerca del objetivo, aunque el contrato aprobado todavía puede comportarse mal dentro de ese límite.

Opción 2: aprobación de 5.000

El protocolo deposita 400 y puede quedar permiso por 4.600.

Si la wallet recibe después otros 3.000 Token A, el saldo pasa a 7.600, pero el allowance restante no aumenta automáticamente a 7.600: sigue siendo 4.600, salvo que cambie el estado del permiso. Ese permiso puede seguir siendo utilizable aunque el usuario haya olvidado el depósito original.

Opción 3: aprobación prácticamente ilimitada

La wallet concede un número enorme.

El usuario deposita 400 hoy y olvida el permiso. Si el spender conserva autoridad y luego es comprometido, futuros saldos del mismo token pueden quedar expuestos hasta el allowance.

Ese es el motivo operativo para revisar permisos antiguos.

Árbol de decisión: ¿deberías revocar?

1. ¿Reconoces al spender?

Si no, verifica la dirección de contrato de forma independiente.

Si sí, continúa.

2. ¿Sigues usando la aplicación?

Si no, eliminar permisos innecesarios reduce superficie de ataque.

3. ¿El allowance es mucho mayor que tu uso previsto?

Si sí, considera reducir el cap cuando el flujo lo permita.

4. ¿El spender es upgradeable o depende de governance?

Si sí, también estás confiando en el mecanismo que puede cambiar su código.

5. ¿Es ERC-20, Permit2 u otra firma?

Identifica la capa antes de asumir que una sola revocación cubre todo.

6. ¿El contrato ha sufrido un incidente?

Sigue instrucciones verificadas del proyecto y confirma por separado la dirección antes de firmar una revocación.

Cómo auditar approvals con seguridad

1. Selecciona la red que realmente utilizas.
2. Abre una herramienta de approvals de confianza, wallet o block explorer oficial.
3. Comprueba tu dirección pública.
4. Revisa token, spender, cantidad y contexto.
5. Marca spenders desconocidos u obsoletos.
6. Revoca o reduce uno por uno.
7. Verifica cada transacción en el explorer.
8. Repite en otras redes donde hayas usado la wallet.

Etherscan dispone de un token approval checker para Ethereum. Otros explorers ofrecen herramientas similares.

Nunca introduzcas seed phrase ni private key en un approval checker. Para leer permisos basta una dirección pública; para revocar, una herramienta legítima utiliza el flujo normal de firma/transacción de la wallet.

Errores frecuentes

“Ya desconecté la web, así que no puede gastar”

Incorrecto. El allowance puede seguir activo.

“Una hardware wallet evita exploits de approvals”

Protege la clave contra extracción. Si autorizas conscientemente una aprobación dañina, el hardware la firma.

“Revocar un token protege toda la wallet”

No. Otros tokens, NFT operators, redes, Permit2 o módulos de smart wallet pueden seguir activos.

“Approval significa que los fondos ya se movieron”

No. Approval crea autoridad; una acción de gasto separada mueve los tokens.

“Allowance cero significa que no existe ningún permiso”

Solo demuestra que ese allowance ERC-20 es cero. No prueba que no existan otras autorizaciones.

Casos límite

Spenders upgradeables

Un contrato puede ser seguro hoy y cambiar mañana. Revisa quién controla upgrades, timelocks y governance.

Proxies

La dirección aprobada puede ser un proxy y no el implementation contract. Buscar solo la implementación puede hacerte revisar la dirección equivocada.

Tokens no estándar

Hay muchas implementaciones ERC-20 desplegadas con comportamientos particulares. No asumas que todos modifican allowances exactamente igual.

Cambiar un allowance no nulo por otro valor no nulo con approve puede competir con el gasto: el spender puede usar el permiso antiguo antes del cambio y después gastar el nuevo. EIP-20 recomienda que las interfaces pongan el allowance a cero antes de fijar otro valor para el mismo spender. Confirma la transacción que lo pone a cero y vuelve a comprobar el estado antes de conceder un nuevo límite; esto no revierte gastos anteriores ni garantiza que la revocación gane la carrera. Algunos tokens desplegados, como USDT, exigen ese reinicio a cero para cambios entre valores no nulos, y otros no devuelven un booleano. Comprueba la implementación del token en vez de asumir que funcionará un flujo estándar de wallet.

Transacción maliciosa ya pendiente

Si un atacante ya ha enviado una operación usando tu allowance, tu revoke puede competir por inclusión. No existe garantía de que la revocación confirme primero.

Smart wallets

Una smart wallet puede tener políticas internas además de token approvals. Revocar ERC-20 no necesariamente desactiva un módulo o session key.

Política sencilla de higiene

Para una wallet DeFi activa:

• separa fondos de largo plazo de cuentas experimentales cuando sea práctico;
• usa cantidades o duraciones limitadas cuando la interfaz lo permita;
• verifica spender addresses en aplicaciones desconocidas;
• revisa allowances antiguos periódicamente;
• trata firmas como permisos potencialmente importantes;
• revoca después de interacciones puntuales cuando mantener el permiso no aporta valor;
• no dejes reservas de largo plazo en una cuenta que acumula permisos amplios de dapps.

Esto reduce riesgo, pero no garantiza seguridad.

Preguntas frecuentes

¿Qué es una aprobación de token?

Es una autorización que permite a un spender mover una cantidad específica del token del owner según las reglas del contrato o del sistema de permisos.

¿Revocar approvals cuesta gas?

Una revocación ERC-20 onchain sí, porque modifica el estado del contrato.

¿Debo revocar después de cada swap?

No necesariamente. Depende de frecuencia, gas, valor de la wallet y riesgo del contrato. Los permisos amplios y sin uso son los candidatos más claros.

¿Un permiso ilimitado puede afectar depósitos futuros?

Sí. Si permanece un allowance suficientemente grande, tokens que lleguen después pueden seguir expuestos hasta ese límite.

¿Permit2 es más seguro que approvals normales?

Ofrece controles útiles como permisos temporales y firmas, pero es otro modelo de autorización. La seguridad depende de lo que se firma y del spender autorizado.

BTC-Pulse Take

Las aprobaciones muestran la diferencia entre poseer una wallet y autorizar el movimiento de sus tokens. Puedes mantener la seed offline y usar hardware, pero aun así dar a un contrato permiso peligroso.

Comprueba tanto los allowances registrados como las autorizaciones firmadas pendientes: la autoridad puede residir en el contrato del token, en el estado de Permit2 o en una firma aún no presentada. Comprueba token, red, spender, cantidad, duración y capa de permisos.

En protocolos usados con frecuencia, un allowance puede ser un trade-off razonable de usabilidad. En interacciones puntuales o desconocidas, una autoridad más estrecha y corta suele ser más fácil de defender.

Este artículo es educativo y no constituye asesoramiento financiero ni garantía de seguridad.

Fuentes

• Ethereum Improvement Proposals — ERC-20 Token Standard
• Ethereum Improvement Proposals — ERC-2612 Permit Extension
• Uniswap Developers — Permit2 Overview
• MetaMask Help Center — What is a token approval?
• MetaMask Help Center — How to revoke allowances/token approvals
• MetaMask Help Center — Disconnecting vs revoking

• Etherscan — Token Approval Checker

• Uniswap Permit2 — AllowanceTransfer implementation

• Uniswap Permit2 — SignatureTransfer implementation