Guía de seguridad para EIP-7702: 5 puntos ciegos mortales del nuevo mecanismo, revelados tras el robo de 6300 millones de dólares en Binance
El 30 de octubre, Binance informó un robo de 6300 millones de dólares que conmocionó al mundo. El análisis posterior reveló que los atacantes no usaro…
El 30 de octubre, Binance sufrió un robo de 6300 millones de dólares estadounidenses, lo que conmocionó al mundo entero. El análisis posterior reveló que los atacantes no utilizaron el método tradicional de robo de claves privadas, sino la autorización por delegación EIP-7702, un nuevo mecanismo de Ethereum activado este año. Esto no es una «nueva vulnerabilidad», sino un «punto ciego de diseño» inherente al mecanismo que chocó frontalmente con los hábitos de seguridad humanos. Tanto usuarios comunes como desarrolladores pueden verse afectados. En este artículo desglosamos toda la cadena de ataque, explicamos en términos sencillos qué es exactamente la EIP-7702 y, finalmente, ofrecemos dos listas prácticas de cinco medidas cada una para evitar caer en estas trampas.
1. ¿Qué papel jugó la EIP-7702 en el robo a Binance?
Volvamos primero al suceso. En la madrugada del 30 de octubre, el monitor on-chain «Shen Yu» publicó en X un detalle inquietante: las 14 direcciones de hot wallet de Binance, tras la actualización Pectra de Ethereum, habían firmado una «transacción extraña» —una transacción de tipo 4. Además, dichas wallets mantenían autorizaciones de delegación válidas hacia contratos controlados por los atacantes.
Actualmente, la comunidad ha reconstruido aproximadamente la siguiente cadena completa de ataque:
- Punto de entrada: un portátil de algún desarrollador o ingeniero de operaciones internos de Binance fue comprometido mediante phishing o malware;
- Inyección de transacciones maliciosas: los atacantes obtuvieron acceso a un canal interno de firma, lo que les permitió insertar transacciones de tipo 4 en las hot wallets;
- Delegación masiva: en cuestión de horas, 50 hot wallets firmaron, una tras otra, cediendo su capacidad de ejecución de código a un contrato controlado por los atacantes;
- Usurpación del control: una vez activa la delegación, los atacantes pudieron invocar esas hot wallets como si fueran sus propios contratos: el sistema de firmas solo veía un «resumen de transacción» de 32 bytes, pero lo que realmente se firmaba era una «carta de autorización» que entregaba las llaves del coche a un tercero.
Afortunadamente, tras la difusión del incidente, el equipo on-chain de Binance implementó con urgencia transacciones de revocación. Actualmente, aproximadamente 3000 millones de dólares estadounidenses en activos robados han sido bloqueados con éxito —lo que demuestra que la delegación bajo EIP-7702 no es irreversible, pero solo si aún puedes firmar la transacción de revocación. Para ver la cronología completa del evento, consulta nuestro reportaje profundo anterior: Robo de 6300 millones de dólares: las hot wallets de Binance víctimas de una usurpación por delegación EIP-7702.
Vale la pena destacar que Binance no es la primera entidad atacada mediante EIP-7702: ya en septiembre, algunos inversores minoristas perdieron sus fondos tras firmar transacciones de tipo 4 en DApp desconocidos. Sin embargo, el caso de Binance llevó este problema de seguridad a nivel de mecanismo directamente a la palestra pública.
2. Resumen rápido del mecanismo central de la EIP-7702 (3 minutos para entenderlo)
En Ethereum tradicional existen únicamente dos tipos de cuentas: cuentas EOA (externally owned accounts) y cuentas de contrato. Una EOA funciona como una tarjeta bancaria: con su clave privada firmas una transacción y gastas un importe concreto; una cuenta de contrato es lógica de código desplegada en la cadena. La EIP-7702 busca resolver una pregunta clave: ¿es posible otorgarle temporalmente a una EOA capacidades propias de una cuenta de contrato?
La respuesta es la «delegación»: imagina que prestas tu coche (EOA) a un amigo (contrato objetivo). No cambias la matrícula, sino que firmas digitalmente un documento de delegación en la cadena, donde especificas claramente «quién tendrá temporalmente las llaves del coche».
Técnicamente, la EIP-7702 introduce dos cambios fundamentales:
- Transacción de tipo 4: un nuevo tipo de transacción diseñado específicamente para «firmar una delegación». El firmante no necesita enviar ETH alguno a la dirección objetivo: basta con publicar el documento de delegación en la cadena.
- La delegación permanece vigente de forma indefinida hasta que se revoca explícitamente. Esta es la regla más importante —y también la más fácil de pasar por alto—: no existe ningún «vencimiento automático», ni tampoco una opción de «uso único».
Suena bien, ¿verdad? En teoría podrías delegar temporalmente tu wallet a un contrato que pague tus fees de gas, o concederle a una DApp permisos automatizados limitados en el tiempo. Pero precisamente ese diseño de «vigencia indefinida» es la semilla de casi todos los incidentes de seguridad.
3. Cinco puntos ciegos mortales (donde los usuarios comunes suelen caer)
A continuación enumeramos los cinco puntos ciegos en los que los usuarios comunes tropiezan con mayor frecuencia. Cada uno tiene casos reales documentados.
1. Las autorizaciones por delegación no expiran automáticamente: si no las revocas, ¡entregas las llaves de forma permanente!
Muchas DApp sugieren a los usuarios «haz clic en «delegate» para disfrutar de un 20 % de descuento en las comisiones de transferencia», y los usuarios firman y luego lo olvidan. Como resultado, esa delegación sigue activa en la cadena indefinidamente: si la DApp cambia de equipo o incluso vende su dirección, ¡tus llaves siguen en manos de terceros!
2. Las interfaces de las wallets no muestran a quién has delegado
Este es, actualmente, el punto más incómodo de todo el ecosistema. A octubre de 2026, la mayoría de las wallets principales (Trust Wallet, Exodus e incluso algunas interfaces asociadas a hardware wallet) carecen de una página de «gestión de delegaciones». Si has firmado 17 transacciones de tipo 4, lo único que probablemente veas en tu wallet es una serie de «resúmenes de transacción», sin saber jamás a quién le diste las llaves.
La buena noticia es que etherscan.io acaba de actualizar su interfaz: ahora, al abrir la página de tu dirección, puedes acceder a la pestaña «Delegations» para ver todos tus registros históricos de delegación. etherscan.io es actualmente la herramienta más fiable para hacer esta verificación.
3. La firma entra en vigor inmediatamente, sin confirmación adicional
Cuando haces clic en «confirmar» en una DApp y tu wallet muestra una ventana emergente indicando «fee de gas: 0,001 ETH», y tú firmas —lo que ocurre en la cadena es que tu EOA publica una delegación permanente a favor del contrato del atacante. No hay una segunda ventana emergente, ni ninguna confirmación adicional. Lo único que ves como firmante es un resumen de transacción de 32 bytes, incapaz de distinguir entre una transferencia normal y una transacción de tipo 4.
4. Las delegaciones pueden anidarse, y el firmante original no se entera de nada
A delega a B, B delega a C, C delega a D: en teoría, esto puede anidarse indefinidamente. En el incidente de Binance ya se observaron indicios de cadenas de delegación anidadas. Si un contrato malicioso ha tomado el control de tu wallet, puede ceder ese control a más direcciones sin tu consentimiento.
5. Cancelar una delegación también requiere una firma
Este es el punto más desesperanzador. Si un atacante ya obtuvo tu autorización de delegación, puede congelar tus activos o convertir tu wallet en un modo de contrato malicioso. ¿Quieres cancelarla? Cancelar una delegación también exige una firma. Y es posible que el canal por el que firmas ya haya sido tomado por el atacante mediante una delegación anidada.
Cuatro. Lista de verificación práctica para usuarios comunes
Tras tanta información, ¿qué debes hacer ahora mismo? Realiza esta revisión en 5 pasos, en orden:
✅ Paso 1: Revisa inmediatamente el historial de delegaciones de tu wallet.
Abre etherscan.io, ingresa tu dirección de wallet y ve a la pestaña «Delegations». Si ves direcciones desconocidas en la lista de delegaciones, ¡tienes una bomba de relojería.
✅ Paso 2: Cancela cualquier delegación desconocida de inmediato.
Como herramienta principal para cancelar, usa OpenZeppelin Defender o el revocador comunitario EIP-7702. El costo en gas para cancelar una delegación on-chain suele estar entre 1 y 5 dólares estadounidenses; la operación es similar a una transferencia normal.
⚠️ Advertencia: si tu wallet ya fue tomada por una delegación maliciosa, la cancelación podría fallar. En ese caso, la opción más segura actualmente es generar la firma de la transacción de cancelación de forma offline con una hardware wallet (Ledger o Trezor), y luego difundirla desde otro equipo limpio.
✅ Paso 3: Ajusta temporalmente tus hábitos de uso de la wallet.
Si usas Trust Wallet o Exodus, evita por ahora firmar directamente transacciones de tipo 4. Una combinación más segura es hardware wallet Ledger + extensión para navegador Rabby: los dispositivos de firma física no ejecutan automáticamente delegaciones anidadas, al menos no firman «en silencio» por ti.
✅ Paso 4: No pulses el botón «Delegate» en DApp desconocidos.
Cualquier DApp que te pida firmar una delegación bajo pretextos como «descuentos en tarifas de gas», «sin comisiones» o «rendimientos automatizados» merece una pausa. Busca en X o Telegram el nombre del DApp junto con las palabras «hack» o «scam». Pasar tres minutos investigando su historial vale mucho más que ahorrarte unos dólares en gas.
✅ Paso 5: Nota especial para usuarios de exchanges.
Si usas principalmente exchanges centralizados como Binance u OKX, estos gestionan de forma centralizada las delegaciones de sus hot wallets. A nivel de tu cuenta personal no necesitas realizar ninguna acción adicional, pero sí recomendamos usar preferentemente la app oficial del exchange y evitar usar wallets de terceros para firmar transacciones de tipo 4 directamente en las direcciones de depósito del exchange.
Cinco. Lista de verificación práctica para desarrolladores
Como desarrollador de DApp o DeFi, tu responsabilidad es aún mayor. A continuación presentamos cinco medidas que constituyen actualmente la «línea base mínima de seguridad» aceptada por la industria:
1. Las autorizaciones de delegación deben incluir una marca de tiempo de expiración razonable (expiry).
Aunque hoy no todas las wallets validan el parámetro expiry en la capa de firma, tu lógica de contrato de delegación debe incluir explícitamente esta verificación. Una delegación que «expira automáticamente tras 30 días» y otra que «permanece vigente de forma indefinida» tienen niveles de seguridad radicalmente distintos.
2. La interfaz de usuario (UI) frontal debe advertir al usuario con una ventana emergente roja grande cada vez que se trate de una transacción de tipo 4.
La práctica estándar es: al pulsar el botón «Delegate», la UI debe mostrar un cuadro modal rojo independiente, con texto en negrita y tamaño grande que diga claramente «⚠️ Estás a punto de firmar una transacción de delegación EIP-7702: esto otorgará al destino indicado autoridad para ejecutar código en tu wallet», y exigir que el usuario escriba manualmente «Entiendo los riesgos» para continuar.
3. Nunca aceptes como entrada del usuario la dirección del destinatario de la delegación.
La dirección del contrato destinatario debe estar codificada de forma fija en el código frontal y verificada contra la dirección real desplegada en la cadena. Permitir que el usuario ingrese libremente esa dirección equivale a entregarle la «dirección postal» del permiso de delegación.
4. Actualízate a la variante «delegateWithPermissions» de EIP-7715.
EIP-7715 añade, sobre la base de EIP-7702, controles de permisos (permissions) que permiten especificar qué funciones puede invocar el destinatario de la delegación y cuáles no. En teoría debería ser el estándar obligatorio, aunque su soporte aún es limitado. Migra lo antes posible.
5. Ejecuta forzosamente el script de auditoría OpenZeppelin para EIP-7702 en entornos de prueba.
OpenZeppelin ya integró la auditoría de seguridad EIP-7702 en su lista de comprobaciones de Defender. Ejecuta este script automatizado en cada despliegue de contrato para escanear riesgos relacionados con delegaciones: el costo prácticamente es nulo.
Seis. Conclusión
EIP-7702 no es un protocolo «con errores»: su objetivo central —dotar a las cuentas externas (EOA) comunes de capacidades de contrato— es correcto. El problema radica en su supuesto subyacente de «vigencia permanente», que choca con el eslabón más débil del ecosistema Ethereum: los hábitos de seguridad humanos.
El incidente de Binance quizá sea la lección de seguridad más costosa desde la adopción generalizada de EIP-7702. Pero, visto desde otra perspectiva, este evento despertó de golpe al ecosistema entero del «sueño» de las delegaciones inconscientes. Hoy etherscan ya dispone de una pestaña dedicada a delegaciones, los equipos de wallets están implementando ventanas emergentes de seguridad y OpenZeppelin actualizó sus scripts de auditoría: cada incidente hace que este mecanismo sea más seguro.
Para ti, como persona, solo hay dos acciones realmente valiosas ahora mismo: ir a etherscan y comprobar si tienes delegaciones desconocidas, y contarle esto a tus amigos que usan DeFi. Con eso basta.