Los riesgos ocultos de las aprobaciones de tokens — Lo que todo usuario de DeFi debe saber en 2026

Resumen Ejecutivo 1. La Anatomía de la Autorización

1. La anatomía de la autorización: cómo funcionan realmente las aprobaciones de tokens

La economía descentralizada depende de que lossmart contractsinteractúen con los activos en posesión del usuario. Pero la Ethereum Virtual Machine (EVM) impone una separación estricta entre las cuentas de usuario (Externally Owned Accounts o EOA) y las cuentas de contrato. Para que un protocolo — un exchange descentralizado, una plataforma de préstamos, un agregador de rendimiento — mueva tus tokens, primero se le debe otorgar permiso explícito a través de la funciónapprove.

Este diseño es una característica, no un error. Garantiza que ningún contrato pueda acceder unilateralmente a tus fondos. El problema es lo que sucededespuésde otorgar ese permiso — y qué tan amplio es el permiso que otorgas.

ERC-20: el problema de la aprobación "ilimitada"

En el mundo de los tokens fungibles (ERC-20), la funciónapprove(spender, amount)te permite especificar un límite numérico de gasto. En teoría, podrías aprobar que un DEX gaste exactamente 100 USDC para un solo intercambio. En la práctica, la mayoría de lasaplicaciones descentralizadassolicitan por defecto aprobaciones "ilimitadas", estableciendo la cantidad en 2²⁵⁶−1, el entero máximo posible. Esto se hace para minimizar los costos de gas y la fricción: en lugar de requerir una nueva transacción de aprobación para cada intercambio, una única aprobación ilimitada otorga al contrato derechos permanentes para drenar todo tu saldoactual y futurode ese token específico.

La conveniencia es real. El riesgo es que esta aprobación nunca expira. Si ese contrato se ve comprometido más adelante — ya sea por un bug, un exploit de actualización o una acción de gobernanza maliciosa — cada usuario que le haya otorgado una aprobación ilimitada queda expuesto.

ERC-721 y ERC-1155: acceso binario a colecciones completas

En el sector de los NFT, el perfil de riesgo es aún más severo. La funciónsetApprovalForAll(operator, bool)en los estándares ERC-721 y ERC-1155 no es cuantitativa, es binaria. Una vez otorgada, un "operador" (típicamente un contrato de marketplace) puede transferircada tokendentro de esa dirección de contrato específica que esté actualmente en tu cartera, así como cualquier token que adquieras posteriormente. No hay granularidad por token. Es todo o nada.

ERC-2612: la aprobación "sigilosa"

La introducción de EIP-2612 y la funciónpermitañadió una peligrosa capa de abstracción. Este estándar permite a los usuarios firmar un mensaje fuera de la cadena (off-chain) que incluye los parámetros de aprobación y una fecha límite. Un tercero puede entonces enviar esta firma a la blockchain, pagando el gas en nombre del usuario. Si bien esto permite un onboarding sin gas y una mejor experiencia de usuario (UX), crea un vector de aprobación sigilosa: la aprobación no aparece en tus transacciones pendientes on-chain hasta el momento de la explotación. Firmas lo que parece un mensaje inofensivo, y un actor malicioso lo envía más tarde para drenar tu cartera.

La evolución de estos estándares fue impulsada por el deseo de reducir la "fricción de UX". La consecuencia no deseada ha sido una sobre-autorización sistémica. Para 2026, el valor acumulado de "aprobación latente" — la cantidad total de capital quepodríaser movido por contratos de terceros en todo el ecosistema EVM — se estima que es órdenes de magnitud superior al TVL líquido real deDeFi.

2. El Panorama de Amenazas 2025-2026

2. El panorama de amenazas 2025–2026: abuso de autorización en cifras

El año 2025 y los primeros meses de 2026 fueron testigos de un cambio definitivo en las tácticas de los cibercriminales. En lugar de buscar errores complejos de reentrada o vulnerabilidades de préstamos relámpago (flash loans), los atacantes pivotaron hacia la "Capa de Autorización": las aprobaciones que permanecen inactivas en millones de carteras. Las estafas de suplantación de identidad experimentaron un crecimiento interanual del 1,400%. El fraude habilitado por IA aumentó un 89%. Elescala total de las pérdidasfue asombrosa.

En enero de 2026, la tendencia se intensificó. CertiK informó que de los$370.3 millonesperdidos en enero de 2026, aproximadamente$311.3 millones(84%) estuvieron vinculados al phishing, incluido un único incidente de ingeniería social que sumó $284 millones.

Address poisoning: el aumento del 15,000%

El envenenamiento de direcciones (address poisoning) ha surgido como una forma particularmente insidiosa de riesgo adyacente a las autorizaciones. Los atacantes utilizan bots para monitorear billeteras de alto volumen y luego envían una transacción "dust" (una cantidad insignificante de tokens) desde una dirección generada programáticamente para que parezca casi idéntica a la del usuario o a la de un contacto frecuente.

El exploit psicológico se basa en que muchas interfaces de billeteras truncan las direcciones, mostrando solo los primeros y últimos cuatro caracteres. Cuando un usuario copia una dirección de su historial de transacciones para una nueva transferencia, copia inadvertidamente la dirección similar del atacante. El31 de enero de 2026, una sola víctima perdió4,556 ETH(aproximadamente $12.25 millones) mediante este método exacto. El historial de transacciones, algo en lo que los usuarios confían implícitamente, se convirtió en el propio vector de ataque.

3. Caso de estudio: 10 de enero

3. Caso de estudio: el robo de $282 millones en una billetera de hardware

El ejemplo más ilustrativo de las limitaciones de las modernasprácticas de seguridadocurrió el 10 de enero de 2026. El usuario de una billetera de hardware perdió aproximadamente$282 millones en BTC y LTC. A pesar de que los fondos estaban en almacenamiento en frío (cold storage), el estándar de oro de la autocustodia, el atacante manipuló con éxito al usuario para que firmara una serie de autorizaciones.

Este incidente desmitificó una creencia generalizada: que las billeteras de hardware son una defensa absoluta contra el robo basado en aprobaciones. Como señalaron los investigadores de seguridad, el almacenamiento en frío protege las claves privadas "en reposo", pero no ofrece protección a los usuarios "bajo presión" que son engañados para proporcionar firmas legítimas con fines maliciosos. El dispositivo ejecutó fielmente las instrucciones recibidas. La vulnerabilidad era el humano que lo sostenía.

4. Phishing-as-a-Service

4. Phishing-as-a-Service: la industrialización del robo de aprobaciones

La eficiencia del robo basado en aprobaciones en 2026 no es obra de hackers solitarios. Está impulsada por una cadena de suministro madura de software malicioso. Grupos como la "Tríada Smishing" aprovechan plataformas como "Lighthouse", un proveedor en idioma chino que ofrece "phishing para principiantes", con cientos de plantillas para sitios web falsos, registro automatizado de dominios y herramientas de evasión que pueden eludir filtros avanzados de navegadores.

La superficie de ataque móvil

Los atacantes se han volcado hacia los dispositivos móviles como un punto único de falla. Las suites de malware modernas ahora incluyen herramientas diseñadas específicamente para recolectar aprobaciones y claves:

• Scrapers de memoria:Programas que escanean la RAM de un dispositivo en busca de claves privadas no cifradas o frases de recuperación durante la inicialización de la billetera.
• Secuestradores de portapapeles (Clipboard hijackers):Malware que monitorea el portapapeles del sistema y reemplaza una dirección de destino copiada por una similar controlada por el atacante, a menudo utilizado junto con el envenenamiento de direcciones.
• Keyloggers:Malware de vigilancia tradicional adaptado para teclados móviles, dirigido a PINs y contraseñas utilizadas para desbloquear billeteras calientes (hot wallets).

Una vez obtenida la aprobación, la red de "compradores" facilita el lavado de dinero mediante la adquisición de bienes de lujo o NFTs de alta liquidez que luego se revenden para ofuscar la huella digital. Todo el proceso, desde el phishing hasta el lavado, está profesionalizado, compartimentado y disponible para alquiler.

5. Fallos a nivel de protocolo

5. Cuando los protocolos fallan: cómo se instrumentalizan las aprobaciones existentes

Quizás el riesgo más contraintuitivo de las aprobaciones de tokens es este: incluso siustedhace todo correctamente, el protocolo en el que confió podría no hacerlo. Varios incidentes de alto perfil en 2025–2026 demostraron que las aprobaciones existentes pueden ser instrumentalizadas a través de vulnerabilidades a nivel de protocolo, convirtiendo su confianza pasada en una responsabilidad presente.

Aperture Finance y Swapnet: $16.67 millones

El 26 de enero de 2026, Aperture Finance y Swapnet sufrieron pérdidas combinadas de aproximadamente$16.67 millones. Estos no fueron ataques de phishing tradicionales. Los atacantes explotaron una vulnerabilidad en loscontratos inteligentesque permitía "llamadas externas arbitrarias". Al manipular la lógica del contrato, activaron operacionestransferFrom()utilizando lasaprobaciones legítimasque los usuarios habían otorgado previamente a estos protocolos.

Este incidente cristaliza un riesgo oculto crítico:una aprobación no es solo un permiso para que un contrato realice una tarea específica; es un puente permanente.Si la lógica de ese contrato se ve comprometida posteriormente o se descubre que contiene una "vía de escape", cada usuario que haya interactuado con él está en riesgo, independientemente de cuánto tiempo hace que se realizó su transacción.

TrueBit: $26.6 millones de un contrato heredado

El 8 de enero de 2026, una vulnerabilidad matemática en la lógica de precios del contrato de acuñación heredado de TrueBit permitió a un atacante acuñar grandes cantidades de tokens TRU a un costo casi nulo. El atacante luego utilizó estos tokens para extraer ETH de las reservas del protocolo. La pérdida total ascendió a aproximadamente$26.6 millones.

MakinaFi: $4.1 millones mediante manipulación de precios

El 20 de enero de 2026, los atacantes manipularon los precios de los pools para inflar el valor de los tokens LP, permitiendo un arbitraje rentable que drenó$4.1 millonesdel protocolo.

6. Restaking y Seguridad Compartida

6. Restaking y seguridad compartida: una nueva capa de riesgo de aprobación

El panoramaDeFide 2026 está dominado por la "Revolución del Restaking". Protocolos como EigenLayer, Symbiotic y Karak han introducido un modelo donde la seguridad del staking de Ethereum se "alquila" para asegurar otros servicios (Servicios Validados Activamente, o AVS). Si bien esto aumenta el rendimiento para los stakers, crea una capa completamente nueva de riesgo de autorización y slashing.

EigenLayer: la delegación como una aprobación de "todo o nada"

La participación en EigenLayer implica ya sea el "Restaking Nativo" (redirigiendo las credenciales de retiro del validador) o el "Restaking Líquido" (depositando LSTs en contratos inteligentes). La principal preocupación es la naturaleza binaria de la delegación:

• Delegación de operador:Los restakers delegan su saldo a un Operador que ejecuta software para AVS. Esta es una operación de todo o nada: no se puede delegar parcialmente ni dividir el saldo de un solo EigenPod entre múltiples Operadores.
• Amplificación del slashing:Un restaker hereda las condiciones de slashing decadaAVS en el que su Operador decida participar. Si un Operador se comporta de forma maliciosa o se ve comprometido, los fondos del restaker pueden ser objeto de slashing (quemados o redistribuidos).

Para 2025, el TVL de EigenLayer era de aproximadamente14.200 millones de dólares, lo que representaba el 63% del mercado de restaking. Tal concentración crea un riesgo sistémico: si las claves de un Operador principal se ven comprometidas, el evento de slashing resultante podría desencadenar un choque de liquidez masivo en todo el ecosistema de Ethereum.

Incluso en el "Native ETH Restaking" —donde el ETH permanece en los contratos de la Beacon Chain en lugar de ser transferido a contratos inteligentes específicos de EigenLayer— el "EigenPod Owner" posee permisos de alto riesgo que pueden ser utilizados indebidamente si la billetera del propietario y sus aprobaciones asociadas se ven comprometidas.

7. Soluciones Arquitectónicas

7. Soluciones arquitectónicas: la hoja de ruta de Ethereum para 2026

La Fundación Ethereum ha respondido a la crisis de las aprobaciones institucionalizando una hoja de ruta que prioriza la experiencia del usuario y la seguridad nativa. Las prioridades del protocolo para 2026 se organizan en tres pilares:Escalar,Mejorar la UX, yFortalecer la L1.

EIP-7702: el puente temporal de contratos inteligentes

Introducido por Vitalik Buterin en 2024 y desplegado en la actualización Pectra, el EIP-7702 permite que una EOA estándar actúe temporalmente como un contrato inteligente durante la duración de una sola transacción. El mecanismo central es el tipo de transacciónSetCode: una EOA crea una "lista de autorización" que delega su poder de ejecución a un contrato inteligente específico.

El beneficio clave para la seguridad de las aprobaciones es elagrupamiento de transacciones (batching). Un usuario puede agrupar una aprobación de token y un swap en una sola acción atómica. Debido a que la aprobación se otorga y se consume en el mismo bloque, la ventana de tiempo para que un atacante explote esa aprobación es efectivamentecero.

Sin embargo, el EIP-7702 introduce sus propios riesgos. Los analistas de seguridad han señalado las "vulnerabilidades de contratos delegados" y las "colisiones de almacenamiento" como nuevas superficies de ataque que surgen cuando las EOAs comienzan a "tomar prestado" código de contratos externos. Para un análisis más profundo de estos riesgos, consulte nuestroInforme de Seguridad Crypto 2025–2026.

EIP-8141 y la actualización Hegota: el fin de la era de la "billetera simple"

La actualización Hegota, programada para el segundo semestre de 2026, se centra en el EIP-8141, una propuesta "ómnibus" que busca unificar las EOAs y las cuentas de contratos inteligentes en un marco único. Si se implementa con éxito, esto marcará el comienzo de la era de las "Smart Accounts". El EIP-8141 introduce varias características que mitigan directamente los riesgos de aprobación:

• Transacciones de marco (Frame transactions):Esta arquitectura separa la aprobación de la firma de la ejecución. El usuario firma un "marco" que especifica exactamente qué puede suceder dentro de una transacción, evitando que un contrato realice llamadas adicionales no autorizadas.
• Flexibilidad de gas y transacciones patrocinadas:Los usuarios pueden pagar las tarifas de gas en tokens ERC-20 o hacer que la propia dApp patrocine el gas. Esto elimina la "barrera del gas" que impide a los usuarios revocar aprobaciones antiguas por falta de ETH en su billetera.
• Raíles de seguridad programables:Las cuentas inteligentes admitirán requisitos de multifirma integrados, límites de retiro (por ejemplo, "no más de 5 ETH cada 24 horas") y mecanismos de recuperación social como parte del protocolo central.

8. Comparativa de Herramientas de Revocación

8. El stack de seguridad de 2026: herramientas de revocación y firewalls on-chain

A medida que crece la complejidad de los ataques, las herramientas utilizadas para gestionar las aprobaciones han evolucionado de simples sitios web de "revocación" a paneles de seguridad integrales y firewalls on-chain. Revoke.cash sigue siendo una piedra angular del conjunto de herramientas defensivas, pero ahora forma parte de un ecosistema más amplio de más de 56 herramientas de seguridad blockchain.

El avance más significativo ha sido la integración de "Active ASPM" (Gestión de la Postura de Seguridad de Aplicaciones) en los flujos de trabajo institucionales. Plataformas como OX Security vinculan los problemas de los contenedores con el código fuente, asegurando que las claves privilegiadas utilizadas por los administradores de puentes no queden expuestas en los pipelines de CI/CD.

9. Respuesta Regulatoria

9. Respuesta regulatoria: MiCA, ENS y el fin de las "aprobaciones ilimitadas" por diseño

Para los usuarios europeos, los "Riesgos Ocultos de las Aprobaciones de Tokens" se están abordando mediante una combinación de mandatos de la UE (MiCA) y marcos de seguridad nacional.

Implementación de MiCA: la fecha límite de junio de 2026

El reglamento de Mercados de Criptoactivos (MiCA) ha cambiado fundamentalmente los requisitos operativos para los proveedores de servicios. España es el único Estado miembro de la UE que ha ampliado su período de transitoriedad (grandfathering) a 18 meses, lo que significa que los VASPs registrados en el Banco de España pueden operar hasta el30 de junio de 2026, sin una licencia MiCA completa.

A medida que se acerca esta fecha límite, la CNMV está aplicando cada vez más las protecciones del estándar MiCA que abordan directamente los riesgos de aprobación:

• Segregación de activos:Se prohíbe estrictamente a los proveedores de servicios utilizar los activos de los clientes por cuenta propia, una respuesta directa al modelo de "aprobación ilimitada" donde las plataformas anteriormente tenían la capacidad técnica de mover los fondos de los usuarios a voluntad.
• Responsabilidad por hackeos:Bajo MiCA, los CASPs son responsables de la pérdida de criptoactivos resultante de ciberataques o fallos operativos, a menos que puedan demostrar que el incidente estuvo fuera de su control. Esto obliga a los proveedores a implementar herramientas rigurosas de monitoreo de aprobaciones.
• Trazabilidad (TFR):El Reglamento de Transferencia de Fondos exige que los CASPs recopilen y verifiquen información sobre ordenantes y beneficiarios, incluidas las transferencias que involucran billeteras no custodias.

ENS y NIS2: la seguridad nacional se une a la autorización digital

ElEsquema Nacional de Seguridad(ENS), actualizado por el Real Decreto 311/2022, ahora se aplica directamente a las empresas del sector privado que participan en las cadenas de suministro de la administración pública. Las empresas deben tratar la seguridad como un "proceso integral", incluyendo la gestión basada en riesgos de todas las autorizaciones y credenciales digitales.

El borrador de la transposición de la directiva NIS2 a la legislación española hace que los órganos de gestión (consejos de administración) seansolidariamente responsablesde las infracciones de ciberseguridad. Las multas por infracciones "muy graves" pueden alcanzar los2.000.000 €. Esta presión regulatoria está impulsando un cambio en la forma en que los desarrolladores de dApps diseñan sus interfaces: la era de las aprobaciones ilimitadas por defecto está llegando a su fin en los mercados regulados.

10. Mejores Prácticas Institucionales

10. Mejores prácticas institucionales para la gestión de tesorería

Para las organizaciones que gestionan tesorerías de activos digitales en 2026, la estrategia ha ido más allá de los simples multisigs. Las estrategias de activos digitales de élite ahora miden el"Tiempo de Aislamiento" (Time-to-Isolate)—los minutos necesarios para congelar activos a través de complejos puentes cross-chain— en lugar de solo el volumen total.

• Examinar las transacciones antes de la aprobación:Desplazar el monitoreo a las etapas de "cotización" (quote) y "aprobación" en lugar de solo después de la liquidación. Esto permite a las instituciones bloquear flujos fraudulentos antes de que se alcance la finalidad (finality) on-chain.
• Tasa de detección conductual:Utilizar heurísticas impulsadas por IA para identificar enrutamientos rápidos e intrincados a través de routers DEX y múltiples puentes, un indicador de alto riesgo de blanqueo.
• Endpoint como infraestructura:Tratar los dispositivos de ejecutivos con autoridad de firma no como "IT de oficina", sino como infraestructura crítica de tesorería. Los endpoints ejecutivos comprometidos fueron responsables de varios drenajes masivos de tesorería a principios de 2026, incluyendo elincidente de 40 millones de dólares de Step Finance.

11. Lista de Verificación Práctica

11. Su lista de verificación de seguridad para aprobaciones de tokens en 2026

Ya sea un usuario individual de DeFi o un gestor de tesorería institucional, estos son los pasos concretos para reducir su exposición a las aprobaciones en 2026:

12. Conclusión

12. El futuro del consentimiento digital

A medida que avanzamos hacia la segunda mitad de 2026, los "Riesgos Ocultos de las Aprobaciones de Tokens" se han convertido en un pilar central de la conversación global sobreciberseguridad. La era de las aprobaciones ilimitadas, permanentes e invisibles está llegando a su fin debido a tres fuerzas convergentes:

1. El cambio arquitectónicohacia la abstracción de cuentas nativa en Ethereum (EIP-8141), que reemplaza los permisos abiertos con transacciones enmarcadas y rieles de seguridad programables.
2. El mandato regulatoriode MiCA, que impone responsabilidad por las pérdidas relacionadas con aprobaciones y prohíbe el modelo de "acceso ilimitado" para los proveedores de servicios.
3. La profesionalización de la industria de la seguridad, con firewalls on-chain, simuladores de transacciones y redes de monitoreo convirtiéndose en infraestructura estándar en lugar de complementos opcionales.

Los datos de 2025 y 2026 son inequívocos: las amenazas más peligrosas ya no están en el código, sino en la interfaz humana. Si bien el EIP-7702 y el procesamiento por lotes de transacciones reducirán la ventana de exposición, y herramientas como Harpie proporcionarán un "firewall on-chain", la responsabilidad última sigue recayendo en el usuario y la institución.

En palabras de investigadores de seguridad, la frase de recuperación y la firma de aprobación siguen siendo "puntos únicos de fallo disfrazados de autocustodia".

Para que el ecosistema prospere, la hoja de ruta de 2026 debe ejecutarse con un enfoque en eldiseño de seguridad centrado en el ser humano, minimizando la fricción operativa y maximizando la adopción de controles. Ya sea a través de iniciativas regulatorias regionales o actualizaciones de protocolos globales, el objetivo es el mismo: transformar los activos digitales de una herramienta de "último recurso" en una infraestructura financiera central y resiliente donde la autorización sea tan segura como la criptografía que la sustenta.

Lecturas Adicionales CTA