En su cuenta de X, Hoskinson instó a la comunidad a actuar con cautela respecto a lo que calificó como herramientas de código críticas que circulan en el ecosistema. En su publicación citó directamente una reconstrucción de bytecode realizada por un analista técnico conocido como CyberSatoshi.

El informe afirma que el atacante desplegó un contrato automatizado de barrido diseñado específicamente para atacar la infraestructura del exchange. Sin embargo, Hoskinson no señaló vulnerabilidades técnicas directas en el protocolo Ethereum ni detalló qué aspectos exactos del informe respaldaba.

El debate técnico se centró en 2 elementos distintos. Por un lado, los investigadores están examinando cómo obtuvieron los atacantes la autorización para firmar transacciones en nombre de la billetera afectada; por otro, evalúan el alcance operativo que permitió el estándar de delegación de Ethereum una vez obtenidas las credenciales.

Según la reconstrucción técnica presentada por CyberSatoshi, el código malicioso mantuvo un saldo de exactamente 1 ETH en la billetera durante todo el proceso de drenaje de activos. La evaluación del analista sugiere que esta condición tenía como objetivo evitar que los sistemas de monitoreo automatizados de Binance notificaran fallos por saldo insuficiente para pagar las comisiones de gas.

El análisis también señala que el contrato ejecutó un bucle con llamadas de bajo nivel para comprobar los saldos de tokens en la dirección Binance 14. Esta estructura permitió que la secuencia de transacciones siguiera procesando otros activos aunque un contrato individual fallara o estuviera en la lista negra.

Además, el documento técnico indicó que una función de ejecución personalizada interactuó con una bóveda externa que contenía 823 millones de dólares en USDC. Según los datos proporcionados por CyberSatoshi, ese contrato reconocía la dirección Binance 14 como administrador legítimo, lo que facilitaba la emisión de instrucciones sobre fondos ajenos a su saldo inmediato en cadena.

Mecánica técnica de la delegación y reglas de consenso

La propuesta EIP-7702 define un tipo de transacción que permite que una cuenta de propiedad externa (EOA) delegue temporalmente su ejecución a la lógica de un contrato inteligente.

En la arquitectura tradicional de Ethereum, una cuenta externa opera exclusivamente mediante firmas generadas con su clave privada. Con la implementación de este estándar, la cuenta puede ejecutar lógica avanzada de contratos dentro de su propio contexto operativo, lo que facilita el procesamiento de transacciones por lotes.

La especificación técnica del protocolo establece que cada autorización debe incluir el ID de la cadena, la dirección del delegado y el nonce de la cuenta, junto con una firma criptográfica. Durante la validación, los nodos de la red verifican que la firma corresponda antes de aplicar la delegación solicitada.

En su informe, CyberSatoshi reconoció esta regla fundamental de seguridad de la red. El analista determinó que el ataque requería estrictamente acceso a la clave privada original o permisos de firma sin restricciones dentro de los sistemas internos del exchange.

La documentación de Ethereum no especifica cómo se vieron comprometidas las credenciales de acceso de Binance. No obstante, los requisitos criptográficos confirman que la red no permite asignar delegaciones a cuentas de terceros sin una autorización debidamente firmada.

En cuanto al procesamiento por lotes, el informe afirma que el atacante envió 50 autorizaciones consecutivas con nonces progresivos para adelantarse a los cambios en la secuencia de transacciones de la cuenta Binance 14. Las especificaciones de Ethereum procesan estas entradas en orden secuencial, incrementando el nonce y ejecutando la delegación válida más reciente recibida.

La documentación oficial redactada por los autores del estándar advierte explícitamente que los contratos delegados obtienen acceso irrestricto a los activos de la cuenta. En consecuencia, el marco técnico establece que el software de las billeteras debe auditar exhaustivamente cualquier código autorizado para prevenir transferencias ilícitas.

Los desarrolladores de la propuesta señalan además que la delegación permanece activa en la cuenta hasta que el propietario difunde una autorización que apunta explícitamente a la dirección cero. Las auditorías técnicas y las investigaciones forenses siguen en curso para determinar el vector de compromiso de las credenciales institucionales.