Aprobaciones y allowances de tokens: cómo revisar y revocar ERC-20

Conectar una web suele permitir que la aplicación vea una dirección pública y solicite firmas. Eso no la autoriza por sí solo a mover todos los tokens ERC-20. La allowance se guarda aparte en el contrato del token. MetaMask también distingue entre desconectar una dapp y revocar aprobaciones de tokens.

Una allowance ERC-20 corresponde al contrato del token, la cadena, la dirección propietaria y la dirección spender. Aprobar en Ethereum no equivale a aprobar el mismo símbolo en Polygon ni otro token. Recordar solo «aprobé este sitio» puede ocultar qué token y red mantienen un permiso activo.

Esta guía trata approve, allowance y transferFrom de ERC-20 en Ethereum y redes compatibles. Las transferencias de ETH nativo, setApprovalForAll de NFT, otros estándares y la conexión de inicio de sesión usan modelos distintos. Para copias de seguridad y recuperación de claves, consulta la guía de frase semilla y recuperación de cartera.

Con approve(spender, amount), el titular puede permitir que un spender use hasta cierta cantidad de tokens. transferFrom permite que ese spender mueva tokens en nombre del titular. Por eso approve normalmente no cambia el saldo en ese momento, aunque una llamada posterior al contrato puede consumir la allowance. Así funciona el flujo definido por el estándar ERC-20.

Por ejemplo, si una cartera tiene 300 tokens y da a un router una allowance de 80, en un ERC-20 convencional el límite efectivo es el menor entre la allowance restante y el saldo. El permiso puede abarcar más de una operación: un contrato puede llamar a transferFrom varias veces. Si se abusa del contrato autorizado o de su ruta de ejecución, los tokens pueden moverse de una forma que el usuario no esperaba. También importan los comportamientos no estándar del token.

La aprobación suele ser una transacción en cadena dirigida al contrato del token y puede tener una comisión de red. Algunas aplicaciones separan aprobación e intercambio; otras combinan una firma de permiso con una transacción posterior. Revisa lo que la cartera pide firmar y la red elegida, no solo el botón «Approve».

La etiqueta «Unlimited» suele representar una allowance cercana al entero máximo del token. No crea tokens infinitos ni transfiere el saldo al aprobar. Pero el spender podría usar el permiso más adelante con tokens que lleguen a esa misma cartera para ese token y cadena. Algunas implementaciones mantienen el valor máximo sin descontarlo; comprueba cómo se comporta el token.

Una aplicación puede pedir un límite amplio para evitar aprobaciones repetidas, pero la comodidad y la exposición van juntas. Una vulnerabilidad o un abuso del control del contrato spender puede hacer relevante una aprobación antigua. La guía de revocación de Ethereum.org explica por qué un límite amplio puede seguir importando incluso después de devolver los activos a la cartera.

Un límite menor no elimina todos los riesgos. Aprobar un token falso o el spender equivocado puede causar pérdidas aunque el importe sea pequeño; aprobar de nuevo en cada operación también añade comisiones y oportunidades de error. Considera la cantidad prevista, la frecuencia de uso, la confianza en el contrato y si puedes revisar el permiso después.

Antes de firmar, comprueba cuatro cosas: que la red seleccionada coincide con la aplicación; que la dirección del contrato del token es correcta y no solo el símbolo; que el spender coincide con la documentación oficial o datos verificables del contrato; y que el límite tiene sentido para la acción prevista, sin dejar un permiso amplio innecesario.

No conectes la cartera desde enlaces de mensajes directos, códigos QR, chats de soporte o anuncios no verificados. Una web de phishing puede copiar una aplicación real. Entra desde un dominio oficial guardado o desde la documentación del proyecto. Un nombre de contrato familiar no demuestra que la dirección sea correcta; una marca de verificación en un explorador tampoco garantiza que el contrato sea seguro.

Un firmante de hardware puede mantener la clave privada separada del navegador, pero no determina si el spender o el importe son seguros. Si el dispositivo no presenta la solicitud de forma comprensible, detente y consulta la explicación oficial del proveedor de la cartera. Menos detalles visibles también significan menos capacidad de revisión.

Algunos ERC-20 admiten ERC-2612 permit. En lugar de enviar una transacción approve normal, el titular firma datos tipados; otra parte puede presentar esa firma para fijar la allowance. El mensaje estándar incluye titular, spender, importe, nonce y deadline, además de un dominio que vincula la firma con la cadena y el contrato.

El deadline de ERC-2612 es el último momento para presentar el permit firmado. No significa que una allowance ya establecida caduque automáticamente en ese momento. Puede seguir activa hasta que se use, modifique o revoque. Algunos tokens tienen diseños permit distintos o reglas extra de expiración; no supongas que toda pantalla que diga «permit» sigue ERC-2612.

Una firma puede permitir que otra cuenta pague la comisión, pero no por ello es una comprobación inocua de inicio de sesión. Si la cartera no muestra claramente token, spender, importe y condiciones de tiempo —o no coinciden con la explicación de la aplicación—, recházala y consulta la documentación oficial. Otra persona podría presentar una firma aún no enviada antes de su deadline.

Cerrar sesión o desconectar la cartera cambia la sesión del navegador o el permiso de conexión. La allowance ERC-20 guardada en el contrato puede permanecer. A la inversa, revocarla no borra la dirección pública que conoce el sitio ni el historial en cadena. La guía de desconexión de MetaMask explica la diferencia.

Revocar suele requerir una transacción en cadena que pone a cero la allowance de ese token y spender. La transacción tiene una comisión de red y el permiso anterior puede seguir vigente hasta que se confirme. Después, actualiza la lista de aprobaciones o consulta otra vez el contrato para comprobar que el valor es cero para la misma cartera, cadena, token y spender. MetaMask y Ethereum.org describen comprobadores por red; verifica el dominio oficial y la cadena elegida.

Cada red guarda su propio estado. Poner a cero una allowance en Ethereum no cambia automáticamente el permiso del mismo token en otra cadena. Revisa cada cuenta, contrato de token, spender y red pertinente, y confirma el resultado después de procesarse la transacción. Una herramienta de revocación nunca necesita tu frase semilla ni tu clave privada.

Cuando se confirma una allowance cero, ese permiso ya no permite una nueva llamada transferFrom. No revierte transferencias ya completadas, no recupera tokens del destinatario ni elimina permisos de otros contratos. Si un spender sospechoso ya movió tokens, revocar no garantiza recuperarlos.

Si la clave privada de la cartera está expuesta, un atacante aún puede firmar transacciones por otros medios. También pueden seguir activas aprobaciones para otros spenders o tokens, permisos de operador de NFT, firmas permit y permisos propios de contratos. Interpreta el resultado solo dentro de la cartera y la cadena que revisaste.

Tras revocar, puede que necesites aprobar de nuevo al intercambiar, depositar o canjear. Antes, comprueba si hay una operación pendiente o una posición activa que use ese permiso y consulta la ayuda oficial del protocolo si hace falta. Lo importante es saber qué cambia en el siguiente paso.

El estándar ERC-20 recomienda que la interfaz ponga en cero una allowance no nula antes de cambiarla por otra cantidad no nula. Si una transacción del spender queda entre la aprobación antigua y la nueva, podría usar más de lo previsto. Por ejemplo, al cambiar 100 por 25, el spender podría usar los 100 antiguos antes de que se registre el nuevo 25 y luego usar también este último.

Confirmar primero el cero reduce la posibilidad de que ambos valores se superpongan, pero no deshace el uso del permiso antiguo antes de que se confirme la transacción a cero. Los dos pasos pueden generar comisiones y los tokens pueden comportarse de manera diferente. Sigue el procedimiento seguro documentado por la cartera o el token y espera la confirmación.

Si no sabes cuál es la allowance actual, consulta el contrato del token en la red seleccionada antes de reemplazarla. Si aparece vacía o inesperada, verifica que no estés mirando otra cadena o dirección. Deben coincidir tanto la dirección propietaria como la del contrato del token.

1. Confirma el dominio oficial del proyecto y la cadena seleccionada.
2. Comprueba las direcciones del contrato del token y del spender, y compara el límite con la cantidad necesaria.
3. Lee la transacción o los datos tipados reales en la cartera. No firmes una solicitud que no entiendas.
4. Revisa en la red correspondiente los spenders que ya no uses o no confíes; pon la allowance a cero cuando proceda y verifica el resultado.
5. Al comparar carteras, revisa no solo las redes compatibles, sino también cómo muestran las aprobaciones y si explican con claridad las actualizaciones y la recuperación.

Una cartera de hardware es una opción para guardar claves y revisar firmas, no una garantía de que el contrato sea seguro ni una barrera contra aprobar un límite amplio. Comprueba por ti mismo spender, token, red e importe. Entender que las allowances pueden persistir aparte de la conexión ayuda a comparar las funciones de seguridad de una cartera y sus límites reales.