EIP-7702 no es la causa principal del robo de 6 300 millones de dólares de Binance; lo es cómo se obtuvo la firma.

Hora de Pekín, 30 de octubre de 2026, 04:24.

Los registros en cadena muestran que los fondos salieron de 0x28C6…1d60. Esta dirección se llama Binance 14, una de las billeteras calientes de Ethereum más grandes de Binance, que realiza miles de retiros diarios. Esta transacción movió 167 464 ETH, 1 615 millones de USDT y más de 60 tipos de tokens, por un valor aproximado de 2 500 millones de dólares en ese momento. La billetera quedó con 1 ETH.

La tarifa de gas fue de 0,0004 ETH, menos de 1 dólar.

Tres minutos antes, a las 04:21, alguien envió una transacción de tipo EIP-7702 a dicha dirección, cargada con 50 autorizaciones, con nonces entre 18 914 775 y 18 914 824. 49 eran inválidas; 1 tuvo éxito. Un «éxito» significa que, a partir de ese segundo, cualquier llamada a Binance 14 ejecuta el contrato desplegado por el atacante a las 23:59 de la noche anterior: un «limpiador» no verificado con una única función de barrido.

Así, Binance 14 dejó de ser una billetera. Se convirtió en una cáscara que contiene un programa ajeno.

A las 08:06, la delegación seguía activa. Pasaron 3 horas y 45 minutos sin que nadie la revocara.

Además, «revocar» esta delegación solo requiere firmar una vez más con la misma clave. A las 06:55 de esa mañana, Binance aún usaba dicha clave para transferir de vuelta a su propia billetera los tokens dispersos que no habían sido barridos.

¿Es EIP-7702 la causa principal del ataque?

La lógica de EIP-7702 es la siguiente: permite que una dirección ordinaria (EOA) alquile el código de un contrato inteligente, manteniendo inalteradas la dirección, el saldo y la clave privada. El mecanismo de alquiler consiste en escribir 23 bytes en el campo «code» de dicha dirección: 0xef0100 seguido de la dirección del contrato. Estos 23 bytes no son código ejecutable, sino un puntero. A partir de entonces, cualquier llamada a esta dirección hará que la EVM cargue y ejecute el código apuntado por dicho puntero en el contexto propio de la dirección: address(this) sigue siendo ella misma y su saldo también.

No tiene errores. Derek Chiang, fundador de ZeroDev y participante en EIP-7702, afirmó claramente el día del incidente: EIP-7702 en sí no presenta vulnerabilidades, y los usuarios de billeteras que lo soportan no deben alarmarse. Añadió además: para que un atacante use EIP-7702, debe controlar la clave privada o engañar a Binance para que firme una autorización 7702.

Tampoco es la primera vez que se usa como herramienta de ataque. Tras la actualización Pectra de Ethereum, Wintermute descubrió en cuestión de semanas que más del 97 % de las delegaciones 7702 en mainnet apuntaban casi todas al mismo contrato «limpiador»; investigaciones registraron unas 3,66 millones de transacciones de autorización, de las cuales aproximadamente el 63 % estaban vinculadas a contratos maliciosos, con pérdidas confirmadas de 2,3 millones de dólares; Blockaid verificó cuatro incidentes 7702 en el primer semestre de 2026, por un total de unos 1,08 millones de dólares, y predijo que el primer caso de siete cifras ocurriría antes de finalizar el año.

El resultado alcanzó diez cifras, tres órdenes de magnitud por encima de su estimación.

Esto ha llevado a muchos a atribuir el robo de 5 600 millones de dólares a Binance —el mayor de la historia— a EIP-7702. ¿Pero realmente se trata de un problema de 7702?

Cómo se obtuvieron las firmas

Antes de continuar, debe aclararse algo: 50 autorizaciones equivalen a 50 firmas; ¿cómo se generaron exactamente esas 50 firmas?

Si el atacante hubiera obtenido las claves privadas completas, ¿por qué necesitaría intentar ciegamente 50 nonces? Si las claves siempre estuvieron bajo control de Binance, ¿por qué 11 billeteras fueron comprometidas simultáneamente en 12 minutos? Todavía no hay explicación.

Veinticuatro segundos después del barrido principal, Binance 16 transfirió 28 005,6 ETH, 55,7 millones de USDT, 25,9 millones de RLUSD y 84,5 WBTC, todos a la misma dirección receptora.

En 12 minutos, otros 10 monederos calientes de Binance hicieron lo mismo en cuatro cadenas: Binance 55 en Optimism transfirió 44,2 millones de OP; cuatro monederos en Arbitrum transfirieron 74,6 millones de ARB y 8 426 ETH; cuatro monederos en Avalanche transfirieron 1,81 millones de AVAX y 8,41 millones de USDT.

Ninguno de estos monederos contenía código. Cada transacción fue una transferencia ordinaria, firmada con la clave privada del monedero, intercalada entre retiros habituales.

Quien posee las claves privadas no necesita usar nonces ciegas. Consultar eth_getTransactionCount tarda un segundo.

La persona que necesita crear 50 autorizaciones para 50 nonces consecutivos de una vez es distinta: alguien que puede obtener firmas pero no acceder al estado en tiempo real del monedero; o alguien que solo puede enviar un lote de autorizaciones prearmadas de golpe y dejar que el sistema las pruebe.

Más notablemente, estas 50 autorizaciones se aprobaron todas a la vez en una única transacción.

Blockaid, firma de seguridad, considera que «la clave se usó indebidamente», no que se extrajera directamente la clave privada. El VP de Blockchain de Yuga Labs, Quit, también apunta en esa dirección: el atacante obtuvo «firmas autorizadas», no la clave privada, y usar un relayer para enviarlas pudo buscarse precisamente para ocultar el origen de dichas firmas.

Shenyu mencionó un detalle en su resumen matutino: hasta las 06:55, Binance seguía usando la misma clave privada para firmar, transfiriendo fragmentos de tokens no barridos de vuelta a su propio monedero.

Esto indica que la clave aún estaba bajo control de Binance esa mañana.

Hace unos momentos, a las 10:26, Binance dio su informe preliminar: posiblemente un portátil de un ingeniero DevOps fue comprometido, lo que permitió al atacante acceder a contenedores de servicios y enviar transacciones no autorizadas de retiro; actualmente no hay evidencia de fuga de claves privadas del monedero.

La pérdida no ocurrió en la cadena.

Así, el problema central no es EIP-7702, sino la etapa previa a la firma.

Un monedero caliente firma miles de transacciones al día, por lo que debe automatizarse; debe ser seguro, por lo que requiere HSM, MPC, multisig y flujos de aprobación. Así, todo el modelo de seguridad se reduce a una frase: ¿puede este proceso determinar, antes de firmar, que «esta transacción no debe firmarse»?

El problema es que la mayoría de los criterios de evaluación solo tienen dos columnas: monto y dirección.

La autorización 7702 no tiene ninguna de las dos. No tiene monto. Lo que cambia no es «cuánto transferir», sino «qué es esta dirección».

No es que Binance no hubiera implementado defensas.

Tres días antes del incidente, el 27 de octubre, divulgó proactivamente algo relevante: durante la semana anterior, su equipo de seguridad había interceptado varios ataques vinculados a Corea del Norte. El método se llama Entrevista Contagiosa: el atacante se hace pasar por reclutador, usa entrevistas, pruebas de programación y frases como «instala primero una herramienta para desarrolladores» para engañar a personas y ejecutar programas maliciosos; una vez ejecutado, el programa abre vías para robar claves, acceder a redes internas y mover fondos.

Pero no logró evitar la pregunta «¿debe firmarse esta transacción?»