¿Qué riesgos reales asumes al aprobar un contrato 'infinito' en una DEX?
Analizamos la mecánica técnica detrás del permiso de gasto ilimitado en Ethereum y por qué dar un cheque en blanco a un router descentralizado puede ser la brecha de seguridad más ignorada del ecosistema.


Hacer clic en "Aceptar" sin leer ha sido la tumba de muchos ahorros cripto. Sin embargo, en 2026, a pesar de la madurez del ecosistema y la proliferación de soluciones de cuenta abstracta, el modelo de token estándar (ERC-20) sigue dominando la interacción en Ethereum, Polygon o Arbitrum. Cada vez que deseas intercambiar un token en una DEX descentralizada, tu wallet te obliga a realizar una pausa: debes aprobar el contrato inteligente para que pueda mover tus fondos a tu nombre. La gran mayoría de interfaces presenta una opción predeterminada que aterroriza a los novatos y relaja a los veteranos: el botón "Aprobar Infinito".
¿Qué sucede realmente en la blockchain cuando marcas esa casilla? No es solo una formalidad. Estás firmando un mensaje digital que otorga a la dirección del contrato de la DEX —generalmente un Router— la autorización para mover una cantidad específica de tokens. Si seleccionas la opción ilimitada, estás escribiendo en el ledger inmutable un permiso de acceso total a tu saldo de ese activo, presente y futuro, hasta que revokes ese permiso manualmente. El riesgo no es que Uniswap o PancakeSwap roben tu dinero; sus contratos son inmutables y han resistido la prueba del tiempo. El peligro real es la arquitectura de confianza implícita: si el contrato sufre un exploit, o si la interfaz web que visitas es una imitación perfecta (phishing) que apunta a una dirección maliciosa, nadie te detendrá. El atacante no necesita tu clave privada; solo necesita que le hayas dado permiso previo para drenar tu cuenta.
La mecánica del allowance y la paradoja del gas
Para comprender la magnitud del riesgo, debemos diseccionar la función approve(spender, amount) del estándar ERC-20. Cuando interactúas con una DEX, tu wallet no envía tokens directamente al intercambio. Primero, le dices al contrato del token: "Permite que la dirección 0x... (el Router de la DEX) retire hasta X cantidad de mis tokens". El contrato de la DEX luego ejecuta el transferFrom para tomar los tokens y realizar el swap. Este proceso de dos pasos es seguro, pero costoso en términos de tarifas de red (gas). Hacer una aprobación por cada operación individual (por ejemplo, aprobar 100 DAI para comprar ETH) obliga al usuario a pagar dos transacciones: la aprobación y el swap.
Aquí es donde entra la "optimización" del approval infinito. Al establecer el amount en el número máximo posible que admite un entero de 256 bits (específicamente $2^{256}-1$, una cifra astronómica), el usuario evita volver a pagar la tarifa de aprobación en futuros intercambios. Es un cálculo económico racional en capas como Ethereum Mainnet, donde una transacción simple puede costar varios dólares. Sin embargo, esta conveniencia crea una superficie de attack permanente. Mientras tengas saldo, esa aprobación infinita permanece viva. Aunque cambies de dispositivo o pierdas el acceso a tu wallet hardware si no has revocado los permisos, la dirección maliciosa (o comprometida) sigue teniendo el "poder legal" en la blockchain para vaciar tus fondos.

El problema se agrava cuando consideramos el software que gestionamos. Muchos usuarios conectan sus carteras a docenas de plataformas DeFi para farming, staking o préstamos. Cada una de esas plataformas requiere su propio permiso. Si un usuario utiliza una wallet caliente (software) en lugar de un dispositivo de hardware aislado, la exposición aumenta exponencialmente. Por ello, existen prácticas de seguridad críticas como Conectar Ledger a MetaMask: Firmar transacciones sin exponer tus 'seed phrases' en el navegador, ya que incluso con aprobaciones infinitas, la firma de cada transacción debe ser validada físicamente. Sin embargo, una vez otorgado el permiso infinito, la barrera de seguridad para el primer movimiento de fondos desaparece; si el contrato decide (o es hackeado para) mover todo tu saldo, no necesitarás volver a firmar con tu Ledger para autorizar la salida de esos tokens específicos.
El vector de ataque: Exploits de contrato y Phishing
A menudo, los usuarios se consuelan pensando: "Es Uniswap, es auditable". Si bien es cierto que los contratos de grandes DEXs son de código abierto y auditados, el vector de ataque rara vez es el core protocolo en 2026. El riesgo suele derivarse de integraciones de terceros, forks mal mantenidos o, más comúnmente, ingeniería social.
Imagina el escenario de un bridge o un agregador de liquidity que utiliza el mismo Router que has aprobado infinitamente. Si esa integración tiene una vulnerabilidad en la lógica de swap que permite a un atacante redirigir las llamadas a la función transferFrom del token, este puede drenar todos los fondos aprobados. Has dado al contrato un cheque en blanco; la Blockchain no distingue entre un intercambio legítimo y una ejecución maliciosa, siempre que la llamada esté firmada correctamente por el dueño de los tokens o cumpla con las reglas pre-autorizadas.
Aún más peligroso es el phishing avanzado. Un atacante puede crear un sitio web idéntico a una DEX popular, con una URL ligeramente modificada. Cuando intentas hacer un swap, el sitio te pide que apruebes el contrato. Si haces clic en "Infinito" sin verificar la dirección del contrato en Etherscan, has aprobado una cuenta controlada por el hacker. En cuanto apruebes, el script del sitio web ejecutará inmediatamente una transacción para transferir todo tu saldo a su billetera. No necesitas tu clave privada; les diste la llave de tu caja fuerte al firmar la aprobación.
Para mitigar esto, herramientas como 5 agregadores de cartera DeFi para ver tus rendimientos 'impermanentes' en tiempo real son útiles no solo para ver ganancias, sino porque a menudo incluyen dashboards de seguridad que enumeran todas las aprobaciones activas. Si ves una aprobación infinita en un contrato que no reconoces o que ya no usas, debes revocarla inmediatamente utilizando herramientas de seguridad específicas para evitar drenajes masivos.
El futuro: EIP-2612 y la desaparición de la aprobación
La industria no es ajena a este problema de diseño. La solución técnica adoptada por muchos protocolos modernos es la EIP-2612 (también conocida como "permit"). Este estándar añade una funcionalidad que permite a los usuarios firmar un mensaje off-chain (fuera de la cadena) que autoriza el gasto. La DEX puede entonces tomar esa firma y realizar el transferFrom en la misma transacción que el swap. Esto elimina por completo la necesidad de la transacción de aprobación previa y, por ende, el riesgo de dejar un permiso infinito abierto. El gasto es de un solo uso y limitado a la cantidad exacta firmada en ese momento.
En 2026, la adopción de tokens con "permit" integrado es mayor, pero la inercia del estándar ERC-20 original es masiva. La mayoría de los tokens blue chip (USDT, USDC, DAI, WBTC) funcionan bajo el modelo antiguo. Por lo tanto, el usuario debe tomar decisiones activas. Si el token no soporta EIP-2612 o la interfaz no la implementa, te enfrentas a la disyuntiva clásica: pagas más gas por seguridad o sacrificas seguridad por ahorro.
El uso de hardware wallets añade una capa de fricción que actúa como salvaguarda. En el debate sobre Ledger Nano X vs. Trust Wallet: ¿Cuándo sacrificar seguridad por portabilidad web?, la ventaja del hardware es clara: puedes aprobar cantidades exactas manualmente en la pantalla del dispositivo. Aunque es tedioso hacerlo cada vez, garantiza que ningún exploit pueda sacar más de lo que has decidido en ese preciso instante.
El coste oportunidad de la seguridad
No todo es blanco o negro. Si operas频繁mente en Mainnet con grandes volúmenes, pagar 5 dólares de gas en cada aprobación exacta puede erosionar tus beneficios. Existe un término medio: aprueba una cantidad ligeramente superior a la que necesitas para el trade actual, pero que no represente todo tu patrimonio. Por ejemplo, si tienes 10 ETH y quieres vender 1, aprueba 1.5 o 2 ETH. De esta forma, limitas la exposición en caso de ataque, pero te das un margen de error para fluctuaciones de precio o múltiples intentos de transacción sin tener que re-aprobar inmediatamente.
El error fatal es la complacencia. Aprobar un contrato infinito para un swap de 20 dólares en una DEX random es una asimetría de riesgo absurda. Estás arriesgando la totalidad de tus fondos en esa dirección para ahorrar quizás 50 centavos de gas. La seguridad en DeFi requiere una gestión activa de los permisos. Trata las aprobaciones como llaves físicas: no le das a un valet de parking la llave maestra de tu casa para que aparque tu coche; le das la llave del coche. Si necesitas hacer un swap, piensa si el ahorro en gas justifica entregar el control total de ese activo a una dirección que no controlas.
La transición hacia modelos de Account Abstraction (cuentas abstractas) promete eliminar estos dolores de cabeza, permitiendo sesiones lógicas, límites de gasto diarios y recuperación de cuentas sin frases semilla. Mientras esa infraestructura no sea el estándar universal y la capa base para la mayoría de usuarios, el "botón infinito" seguirá siendo una prueba de fuego para cualquier usuario de finanzas descentralizadas. La prudencia dicta que la economía de gas nunca debe superar a la economía de la custodia.

