Casi toda interacción con una aplicación descentralizada, desde operar en un exchange descentralizado hasta hacer staking de un token, requiere conceder a esa aplicación permiso para mover un token específico en nombre del propietario de la billetera. Este permiso se llama aprobación de token, y es una parte legítima y necesaria de cómo funcionan la mayoría de las aplicaciones de blockchain. El problema no es que las aprobaciones existan. El problema es que la mayoría de las interfaces de billetera las presentan de forma breve y técnica, y la mayoría de los usuarios las confirman rápidamente sin entender exactamente qué están autorizando.
Según el Informe de Delitos Cripto 2026 de Chainalysis, las estafas en cadena generaron al menos catorce mil millones de dólares en 2025, frente a doce mil millones el año anterior, y el phishing basado en aprobaciones ha sido un contribuyente constante a esa cifra, con más de mil millones de dólares en pérdidas acumuladas reportadas desde 2021 atribuidas específicamente a esta técnica.
Lo que realmente concede una aprobación de token
Cuando una aplicación solicita una aprobación, está pidiendo a la billetera que autorice a un contrato inteligente a transferir hasta una cantidad especificada de un token, en nombre del propietario, en el momento que el contrato elija. Muchas aplicaciones solicitan una aprobación ilimitada por defecto, ya que es más conveniente para la aplicación y evita tener que pedir al usuario que vuelva a aprobar cada transacción futura. Esa conveniencia es exactamente lo que hace peligroso el permiso si el contrato que lo recibe es malicioso o se ve comprometido más tarde, porque la aprobación en sí no caduca y no requiere ninguna confirmación adicional para ser ejercida.
Una aprobación no es una transacción única. Es una autorización permanente que permanece activa indefinidamente, en la cadena, hasta que se revoca manualmente, sin importar si el sitio que la solicitó se vuelve a visitar alguna vez.
Aprobaciones ERC-20, Permit y Permit2 explicadas
La función estándar approve
El estándar original de token ERC-20 incluye una función llamada approve, que el propietario de la billetera llama para autorizar a una dirección de contrato específica a gastar hasta una cantidad especificada de ese token. Esto requiere una transacción en cadena, lo que significa que cuesta una comisión de red y se registra de forma permanente en la blockchain en el momento en que se confirma. Debido a que es una transacción visible y separada, la mayoría de las interfaces de billetera mostrarán al menos una advertencia genérica de que se está solicitando una interacción con un contrato, en lugar de una simple transferencia.
Permit y firmas fuera de cadena
Un estándar más reciente, comúnmente llamado Permit, permite conceder el mismo tipo de aprobación mediante un mensaje firmado en lugar de una transacción en cadena. La firma en sí no cuesta ninguna comisión de red y no necesita transmitirse de inmediato, ya que el contrato receptor puede presentarla a la blockchain en cualquier momento posterior para activar la aprobación. Esto es conveniente para las aplicaciones legítimas, ya que permite a un usuario aprobar y completar una acción, como un intercambio de tokens, en una sola interacción en lugar de dos transacciones separadas. También es exactamente lo que hace que el phishing basado en Permit sea más difícil de notar, ya que una solicitud de firma a menudo se ve visualmente similar a firmar un mensaje inofensivo, y muchas interfaces de billetera históricamente han mostrado menos detalle para una solicitud de firma que para una transacción completa.
Permit2 y aprobaciones universales
Permit2, una extensión adicional adoptada ampliamente en los exchanges descentralizados, permite que una sola aprobación concedida a un contrato central Permit2 se reutilice después en muchas aplicaciones distintas sin una aprobación separada para cada una. Esto reduce la fricción y las comisiones para los usuarios legítimos, pero también significa que una sola firma Permit2 víctima de phishing puede potencialmente exponer un token a cualquier aplicación construida para interactuar con el sistema Permit2, ampliando el radio de impacto práctico de un solo intento de phishing exitoso en comparación con una aprobación de contrato único al estilo antiguo.
Un escenario realista: un reclamo de airdrop falso que concede una aprobación ilimitada
- Circula un mensaje en una comunidad cripto que afirma que un proyecto de token conocido está distribuyendo un airdrop sorpresa a los poseedores de un activo relacionado, con un enlace a una página de reclamo.
- La página de reclamo pide al visitante que conecte su billetera y haga clic en un botón etiquetado Reclamar ahora, lo que activa una ventana emergente de la billetera solicitando aprobación para el token del proyecto, descrita solo como una interacción con un contrato.
- La cantidad de aprobación solicitada se fija en el valor máximo posible que permite el estándar del token, en lugar de una cantidad específica de reclamo, aunque este detalle no se muestra de forma destacada en la vista de confirmación predeterminada de la billetera.
- La víctima confirma, no recibe ningún token ya que nunca hubo un airdrop real, y cierra la pestaña asumiendo que el reclamo simplemente falló o ya se había agotado.
- Semanas después, una vez que el precio del token ha subido o la víctima ha acumulado un saldo mayor, el atacante ejerce la aprobación permanente y transfiere el saldo completo en una sola transacción que la víctima nunca aprobó directamente.
El retraso entre la interacción de phishing original y la pérdida eventual es deliberado. Desconecta el robo de su causa en la memoria de la víctima y hace que sea mucho menos probable que se reporte la página de phishing específica o se conecte con la pérdida cuando finalmente ocurre.
Por qué el phishing de aprobaciones es más difícil de notar que una transferencia directa por drainer
Un drainer directo de billetera, tratado en nuestra guía complementaria, normalmente vacía una billetera en cuestión de segundos tras confirmarse una firma, lo cual al menos hace obvia la causa y el efecto para la víctima inmediatamente después. El phishing de aprobaciones está estructurado de forma distinta. La propia transacción de aprobación no mueve nada, por lo que una víctima que revisa su saldo justo después de confirmar no ve ningún cambio y concluye razonablemente que no pasó nada. La pérdida real puede ocurrir días, semanas o meses después, ejecutada por el atacante en el momento que elija, lo que significa que la víctima con frecuencia nunca llega a establecer la conexión entre la página de phishing original y el robo eventual. Esta es también la razón por la que las auditorías de aprobaciones rutinarias importan más para esta amenaza específica que para los ataques drainer directos, ya que existe una ventana real, aunque de duración incierta, durante la cual revocar la aprobación evita por completo cualquier pérdida.
Cómo se lleva a cabo típicamente el ataque
Páginas falsas de reclamo y verificación
La configuración más común es una página que imita un reclamo de airdrop, un paso de verificación de billetera o una interacción rutinaria de protocolo. La víctima conecta su billetera esperando una simple confirmación, y el sitio en cambio solicita una aprobación que cubre un token valioso, enmarcada en la ventana emergente de la billetera como una interacción genérica con un contrato en lugar de algo alarmante.
Phishing de firmas Permit y Permit2
Una variante más reciente y más difícil de detectar abusa de un estándar de firma, a menudo llamado Permit o Permit2, que permite conceder una aprobación mediante un mensaje firmado fuera de cadena en lugar de una transacción en cadena. Debido a que firmar un mensaje no siempre activa las mismas advertencias visuales que una transacción, y no cuesta una comisión de red, las víctimas son más propensas a firmarlo sin un escrutinio cercano. Un caso ampliamente reportado involucró a un trader que perdió aproximadamente un millón de dólares en una sola firma Permit2 al confundirla con una confirmación rutinaria en la interfaz de un exchange descentralizado.
Explotación retrasada
Debido a que una aprobación no necesita usarse de inmediato, los atacantes con frecuencia cosechan grandes cantidades de aprobaciones en muchas billeteras y las ejercen más tarde, en lotes, a menudo sincronizados con periodos en los que el precio de un token ha subido o cuando es menos probable que la víctima esté monitoreando activamente esa billetera. Este retraso es parte de por qué las víctimas a veces no pueden conectar una pérdida con la interacción de phishing original, ya que pueden separar los dos eventos semanas o meses.
Cómo revisar y revocar aprobaciones existentes
- Use una herramienta de verificación de aprobaciones de buena reputación que lea el historial de aprobaciones en cadena de su billetera y liste cada permiso activo, junto con qué contrato lo posee y qué cantidad cubre.
- Revoque cualquier aprobación que no reconozca o ya no necesite, en particular las aprobaciones ilimitadas vinculadas a contratos desconocidos o rara vez usados.
- Preste especial atención a las aprobaciones de estilo Permit2, ya que son menos visualmente obvias en la mayoría de las interfaces de billetera que una transacción de aprobación en cadena estándar.
- Convierta la revocación en una práctica rutinaria después de interactuar con cualquier aplicación descentralizada nueva o desconocida, no solo algo que se hace de forma reactiva después de descubrir una pérdida.
Más allá de revisar las aprobaciones existentes, vale la pena tratar unas pocas señales específicas en el momento en que se solicita una nueva aprobación como una señal de alto inmediato en lugar de algo que revisar más tarde.
- La cantidad solicitada mostrada para la aprobación es el valor máximo que permite el estándar del token, en lugar de un número específico vinculado a la acción reclamada.
- La página pide una aprobación antes de mostrar cualquier beneficio, recompensa o servicio tangible, en lugar de como un segundo paso natural de una interacción que usted inició.
- La ventana emergente de la billetera describe la solicitud solo como una firma o una interacción genérica con un contrato, sin un resumen legible para humanos de lo que se está autorizando.
- El sitio combina urgencia, como un temporizador de cuenta regresiva o una ventana de reclamo limitada, con una solicitud de aprobación de billetera en lugar de una transacción directa.
Un recorrido completo del propio proceso de revocación, incluyendo qué herramientas se usan comúnmente y cómo interpretar lo que autoriza realmente cada aprobación, se trata en nuestra guía dedicada sobre revocación de aprobaciones de tokens. Ese proceso es uno de los pocos pasos defensivos genuinamente eficaces disponibles para el titular de una billetera, ya que cierra directamente el acceso permanente en lugar de depender únicamente de evitar futuros intentos de phishing.
Cuando una aprobación ya ha sido explotada
Si los fondos ya se han movido a través de una aprobación explotada, la propia aprobación debe revocarse de inmediato para evitar que cualquier asignación restante se use de nuevo, incluso después de un robo inicial. La transacción que ejecutó el robo, junto con la transacción de aprobación original, debe documentarse con marcas de tiempo e identificadores, ya que esa secuencia es a menudo lo que permite a un investigador establecer cómo ocurrió el compromiso y si se conecta con un patrón más amplio de actividad drainer, tratado con más detalle en nuestra guía sobre ataques de vaciado de billeteras.
Preguntas frecuentes
La mayoría de las herramientas de verificación de aprobaciones de buena reputación ahora admiten ver y revocar aprobaciones basadas en Permit2 junto con las estándar, aunque la interfaz puede separarlas en una sección distinta. Vale la pena revisar ambas categorías específicamente, ya que las aprobaciones Permit2 son menos visualmente obvias en muchas interfaces de billetera.
No. La revocación solo impide que una aprobación existente se use de nuevo en el futuro. No tiene ningún efecto sobre los fondos ya transferidos, ya que las transacciones de blockchain no se pueden revertir una vez confirmadas.
La mayoría de las interfaces de billetera están diseñadas para uso general y muestran las aprobaciones como una interacción estándar con un contrato en lugar de señalar la cantidad o duración específica. Las herramientas especializadas de verificación de aprobaciones generalmente ofrecen un detalle más claro que la pantalla de confirmación predeterminada de una billetera.
Puede serlo. Las aprobaciones basadas en firmas, en particular las solicitudes de estilo Permit2, pueden conceder el mismo acceso de gasto que una transacción de aprobación en cadena, pero a menudo se presentan con una advertencia menos visible y sin comisión de red, lo que facilita pasarlas por alto.
Una práctica razonable es revisar las aprobaciones activas cada pocas semanas para una billetera de uso activo, e inmediatamente después de interactuar con cualquier aplicación descentralizada, reclamo de airdrop o página de acuñación nueva o desconocida.
Fuentes y lecturas adicionales
- What are token approvals · MetaMask
- 2026 Crypto Crime Report: Scams · Chainalysis
- Uniswap Permit2 Phishing: $1 Million Loss Highlights Risk · Cryptonomist