Binance 29-oct: 50 tuplas de EIP-7702 y una sola delegación

En el ataque a Binance del 29 de octubre de 2026, las 50 autorizaciones de EIP-7702 que viajaban en la transacción de las 20:20:59 UTC en Ethereum apuntaban las 50 al mismo contrato y a la misma cadena, con nonces consecutivos del 18.914.775 al 18.914.824. El nonce real de la cuenta firmante en ese bloque era el 18.914.810: la posición 36 de las 50. Leído campo por campo, el lote es una misma delegación escrita cincuenta veces, una por cada número de secuencia que la cuenta podía tener al procesarse. Por encima del real quedaban 14 firmas, y al ritmo de esa cuenta en las 24 horas anteriores —9,12 nonces por minuto— esas 14 son 1,54 minutos de cobertura. La segunda medición es el congelamiento del emisor, evento a evento: la lista negra del contrato de USDT comprueba quién firma una transferencia y no quién la cobra, así que la dirección que recibió el barrido sumó 204.315.411,59 USDT después de entrar en la lista, y a 3 de noviembre de 2026 seguía sumando. El contrato de USDC sí comprueba al receptor, y el saldo en USDC de esa misma dirección no se movió. Las dos mediciones se contrastan con el censo de EIP-7702 del 21 de octubre de 2026, ocho días anterior al ataque.

¿Qué es una tupla de autorización de EIP-7702?

Una tupla de autorización es la unidad de contenido nueva que lleva una transacción de tipo 4, el tipo que la EIP-7702 introdujo en Ethereum con la bifurcación Pectra, activa desde mayo de 2025. La tupla tiene cuatro campos con significado: chainId, la cadena en la que vale; address, el contrato cuyo código ejecutará la cuenta; nonce, el número de secuencia que la cuenta debe tener al procesarla; y la firma, de la que el nodo recupera quién la firmó.

La especificación llama «autoridad» a quien firma la tupla, que es la cuenta que queda delegada, y quien envía la transacción que la transporta puede ser cualquier otro. En el lote del 29 de octubre esa separación está medida: lo envió una dirección cuyo propio nonce era 10, y las tuplas las había firmado una cuenta que iba por el nonce dieciocho millones novecientos catorce mil ochocientos diez.

El nonce de la tupla funciona como el número de secuencia de un pago domiciliado: el banco lo ejecuta si el número coincide con el que toca en tu libro, y si no coincide lo rechaza. El mapeo es directo —el banco es el nodo, el libro es el estado de la cuenta, el número es el nonce— y el límite también: una tupla no mueve fondos. Al procesarse con éxito escribe en el código de la cuenta un puntero de 23 bytes que empieza por 0xef0100 y sigue con la dirección delegada, de modo que desde ese bloque cualquier llamada a la cuenta ejecuta el código de ese contrato con su saldo y su almacenamiento. El puntero y el recuento de cuántas cuentas lo llevan están en nuestro censo de EIP-7702 del 22 de octubre.

¿Por qué las 50 tuplas del lote de Binance eran una sola delegación de EIP-7702?

Porque las tres cosas que distinguen una delegación de otra coinciden en las 50: la cadena (chainId 0x1), el contrato delegado (0x63e842b054bd624a465454d533c33f573e9c6fae) y la cuenta firmante. Lo único que cambia entre tupla y tupla es el cuarto campo, el nonce, y los 50 valores forman una serie sin huecos.

El protocolo solo puede aceptar una de las 50: las 35 por debajo del nonce real ya habían caducado y el nodo las descarta cobrando el gas de verificarlas, las 14 de arriba pedían un número que la cuenta no había alcanzado, y la trigésima sexta escribió el puntero.

El tamaño del lote mide, por tanto, otra cosa. Una serie de 50 nonces consecutivos cubre un dato que no se conoce al firmar: cuántas transacciones más habrá enviado esa cuenta cuando el bloque llegue. Si el primer nonce del rango era el que la cuenta tenía en el momento de firmar, entre la firma y la inclusión gastó 35 nonces; la medición da el nonce en la inclusión y no el de la firma, así que esa lectura es del diseño del lote y no un dato medido. El gas de la transacción —1.258.562 para escribir un puntero de 23 bytes— es el precio de verificar 49 firmas que el nodo descarta.

¿Cuántos minutos de validez le quedaban al lote de 50 autorizaciones de Binance?

La cobertura de un lote así se agota sola, y el ritmo de la cuenta la cuantifica. Leyendo eth_getTransactionCount por bloque en nodo de archivo, la cuenta firmante gastó 9,12 nonces por minuto en las 24 horas anteriores, de las 20:14:23 UTC del 28 de octubre a las 20:20:59 del 29. A ese ritmo la serie entera de 50 nonces vale 5,49 minutos. Lo que quedaba al incluirse la transacción son las 14 tuplas por encima del nonce real: 14 dividido por 9,12 da 1,54 minutos. La cuenta que importa es la de las tuplas aún no alcanzadas.

Dicho al revés: si el lote hubiera tardado unos 92 segundos más en entrar en un bloque, las 50 firmas habrían estado caducadas y la transacción no habría escrito nada a cambio de 1,2 millones de gas.

¿Qué pasó en la cuenta de Binance desde las 20:20 UTC del 29 de octubre de 2026?

Con el puntero escrito, cualquier llamada a la dirección de la cuenta ejecuta el contrato delegado con sus saldos y sus permisos. La medición del 30 de octubre de 2026 cubre tres llamadas y los primeros eventos de lista negra.

El USDT de ese lote son 1.615.409.498,97324 unidades, leídas del log con los seis decimales del contrato. El mecanismo genérico de un drenaje —cómo se consigue que una cuenta firme algo que no quería firmar— está en nuestra pieza sobre drenadores de wallets, y es justo la parte que no está en la cadena.

Tras el barrido el ritmo de la cuenta decae a 3,60 por minuto, después a 2,60 y después a 1,60; llega a cero entre las 20:35:59 y las 20:40:59, se queda ahí unas dos horas y veinte minutos, y vuelve entre las 00:21:59 y las 00:32:23 del 30 de octubre con un pico de 31,35 por minuto, 3,4 veces su línea base. De aquí no se deduce ninguna decisión corporativa ni se fecha ningún anuncio: el nonce mide si una dirección firmó, y a qué horas.

¿Qué impide la lista negra de USDT a una dirección bloqueada?

En la ventana que va del bloque 26.300.693 al 26.302.100 hay 13 eventos de lista negra: nueve AddedBlackList del contrato de USDT en Ethereum y cuatro Blacklisted del de USDC. Ninguna destrucción de fondos (DestroyedBlackFunds) en esa ventana.

Tres lecturas de la tabla. La primera: cinco de las nueve direcciones de USDT tenían saldo cero en el bloque anterior a su evento, así que contar direcciones y contar montones de dinero son dos cosas distintas. El segundo: la primera dirección listada es exactamente el destino de los 63 transfers, y el primer evento llegó 37,2 minutos después del barrido.

La tercera es el mecanismo, y depende del contrato. En el de USDT en Ethereum la comprobación de lista negra recae sobre quien firma la transferencia, de modo que una dirección bloqueada deja de poder enviar y sigue pudiendo cobrar. Medido en la dirección del barrido: 971.149.299,48324 USDT en el bloque anterior a su evento, 1.175.464.711,075362 al cierre de la ventana —204.315.411,59 unidades más ya bloqueada— y 1.175.464.712,876362 en una relectura con balanceOf del 3 de noviembre de 2026: 1,801 USDT más que al cierre de la ventana, cinco días después. En Tron no está verificado.

El de USDC hace lo contrario, y la tabla lo deja ver: el saldo en USDC de esa misma dirección es idéntico en los dos momentos. Su implementación comprueba también al receptor, así que una transferencia hacia una dirección bloqueada revierte con «Blacklistable: account is blacklisted» (simulación propia de transfer desde una dirección no listada, 3-nov-2026). Los dos mayores emisores de stablecoins aplican la misma herramienta con alcances distintos, y la diferencia está en el código. El matiz obligó a corregir la guía de la wallet de autocustodia de Tether de CleanSky.

Lo que esta tabla no cuadra: el barrido movió 1.615.409.498,97324 unidades de USDT y el destino aparece con 971.149.299,48 antes de su evento. La medición no lee su saldo previo al barrido ni lo que salió después, así que la diferencia no se atribuye a ningún movimiento concreto.

De ahí se sigue cómo leer cualquier cifra de «lo congelado» en USDT: marca una hora y no un total, porque el saldo de una dirección bloqueada sube mientras le sigan llegando transferencias. Las cifras de pérdidas que han circulado difieren entre medios, con distintas cadenas y distintas horas detrás de cada una; Decrypt titula con 6,4 mil millones de dólares y otras publicaciones manejan importes menores. Aquí no se adopta ninguna: esta medición cubre 13 eventos de dos contratos en una sola cadena. Conviene además no confundir pérdida con congelamiento: los «roughly $2.8B» que cita Fireblocks son lo que los emisores bloquearon, no lo que salió.

La tabla recoge además un efecto del puntero: la cuenta vaciada aparece en las dos listas negras, en USDT a las 22:06:23 por 1.351.530,01 unidades y en USDC a las 23:53:35 por 52.363,12. El puntero de delegación seguía escrito en su código, así que cualquier USDT o USDC que llegara a ella seguía siendo alcanzable por el contrato delegado. El otro congelamiento de emisor medido en CleanSky, el del hackeo de Bitget, tiene otro eje: allí se midieron el alcance —qué activos tienen botón de congelación— y el reloj del emisor; aquí, los saldos a cero y el montón que crece después de bloquearlo.

¿Era raro en Ethereum un lote de 50 tuplas como el del ataque a Binance?

La pregunta que decide si una alarma habría sonado exige una foto de la red anterior al ataque, y el censo de EIP-7702 del 21 de octubre de 2026 la da, con dos muestras —una ventana densa de 2.000 bloques consecutivos y otra sistemática de uno de cada mil bloques desde Pectra—.

Por tamaño, el lote del 29 de octubre no destacaba. Entre un tercio y la mitad de las autorizaciones de la línea base viajaban en lotes de 20 o más, con un máximo de 650 tuplas en una sola transacción. Las dos muestras comparten cuatro transacciones, así que suman 14.230 transacciones de tipo 4 distintas; entre las de 50 o más tuplas no se solapa ninguna, de modo que las 81 son 81 transacciones diferentes. Una alarma que se dispare por «lote grande» habría sonado todos los días de octubre.

Por forma, en cambio, el lote es casi único en esa foto, y eso se puede contar. Revisando las 81 transacciones de 50 o más tuplas de la línea base del 21 de octubre (cálculo propio del 3 de noviembre de 2026 sobre sus ficheros de autorizaciones): las 81 apuntan a un único contrato delegado, igual que el lote del incidente, así que ese rasgo no distingue nada. Lo que distingue es el nonce. En 80 de las 81 hay nonces repetidos dentro del mismo lote —hasta 222 firmas con el mismo número, y 19 transacciones donde todas llevan el mismo valor—, lo esperable cuando un lote mueve muchas cuentas distintas, cada una con su contador. Solo una de las 81 no repite ningún nonce: la de 650 tuplas del bloque 26.172.584, con 650 nonces estrictamente consecutivos del 123.500 al 124.149 y la dirección cero como destino: un lote de revocación. Esa es la misma forma del lote del 29 de octubre. Recuperar la cuenta firmante exigiría un ecrecover por tupla, que esa medición no hace, así que lo comparable es la forma.

La consecuencia es concreta para quien diseñe vigilancia: el rasgo que habría señalado esta transacción es la combinación de nonces consecutivos sin repetición y un solo contrato de destino, y no su número de tuplas. Con ese filtro, entre las 81 de 50 o más tuplas de la línea base hay un precedente; con el del tamaño, 81. Por debajo de 50 tuplas la forma no se ha revisado, así que el recuento vale para ese tramo y no para toda la muestra.

¿Por qué el censo de EIP-7702 de CleanSky da 51 lotes grandes y esta medición da 81?

Porque no son la misma cifra. Las dos series tienen unidad, umbral y ancla distintos, y puestas una al lado de la otra sin su denominador parecerían contradecirse.

Con la misma unidad y el mismo umbral, las dos series casi coinciden: 24,99 % de las instrucciones en el censo del 14 de octubre frente al 20,01 % en la línea base del 21. El 0,101 % que aparece antes en esta pieza es otra fracción, transacciones con exactamente 50 tuplas sobre la ventana densa, y por eso queda tan lejos: cambian la unidad y el umbral a la vez.

Lo que este caso añade es una capa que un recuento de instrucciones no separa por sí solo: la repetición por nonce dentro de una misma cuenta. Con nonces consecutivos, el número de instrucciones y el de cuentas afectadas divergen por construcción, porque de esa serie solo una instrucción puede surtir efecto: 50 instrucciones y, como mucho, una delegación efectiva. En la línea base esa forma aparece en una transacción de 81.

¿Qué se había publicado sobre las 50 autorizaciones de EIP-7702 de Binance?

De las tres piezas de cobertura leídas para esta medición —techreport.com, Fireblocks y Decrypt—, la que más lejos llega es techreport.com, que escribe que una transacción «carried fifty EIP-7702 authorizations signed by the Binance 14 hot wallet for consecutive nonces», lo atribuye a «an analysis shared in the security community» sin nombrar al autor y avisa de que descansa en la lectura de un solo investigador y de que Binance no ha confirmado el detalle. La lectura de los nonces consecutivos estaba publicada, entonces. Lo que no aparece en ese texto es el rango, la posición del nonce real, el contrato delegado ni el ritmo de la cuenta. La nota de Fireblocks se queda un paso antes: «One transaction carried 50 authorizations, so at least one would be valid when processed», sin el rango, la posición, la dirección del contrato delegado, el ritmo ni línea base de red, y con una sola mención de los congelamientos —«roughly $2.8B was frozen by stablecoin issuers and others»— que no entra en el mecanismo.

En esas tres piezas no aparecen el rango de nonces, la posición 36 de 50, los 1,54 minutos de cobertura restante, los 13 eventos de lista negra con sus saldos ni la forma de los lotes en una foto de la red anterior al ataque. La explicación general de Decrypt sí da la cifra de pérdidas más alta de las que circulan y atribuye el ataque a un Estado citando a analistas; esa atribución queda fuera de esta pieza por falta de fuente forense pública y fechada que podamos verificar.

¿Qué se comprueba el 6 de noviembre de 2026 sobre el lote de Binance?

Cuatro umbrales, fijados después de tomar los datos. (a) Si el contrato 0x63e842b0…6fae recibe autorizaciones de otras cuentas después del 30 de octubre, deja de ser una pieza de un solo uso. (b) Si en una ventana densa nueva los lotes de 50 o más pasan del 1 % de las transacciones de tipo 4 —hoy 0,45 % en la densa y 0,65 % en la sistemática—, el patrón se ha vuelto común y «no destacaba por tamaño» cambia de sentido. (c) Si el saldo de las direcciones listadas baja más del 1 % entre el cierre de la ventana y el control, el congelamiento no era completo; a 3 de noviembre el de la principal ha subido 1,801 unidades. (d) Si el nonce de la cuenta vaciada no recupera su ritmo previo de 9,12 por minuto antes del 6 de noviembre, el silencio de esa dirección sigue abierto.

Cuatro límites. La medición es solo de Ethereum, y según la cobertura citada el ataque tocó también Tron y Bitcoin: eso es compatible con que los importes publicados superen a los medidos aquí. El estado histórico sale de un único nodo de archivo, aunque la relectura del 3 de noviembre es independiente en el tiempo. La forma de los lotes por debajo de 50 tuplas no se ha revisado. Y cómo se obtuvo la firma de la cuenta no está en la cadena.

El 6 de noviembre de 2026 las cuatro filas se vuelven a leer con el mismo guion y la misma altura de bloque. La que más puede moverse es la (b): los lotes de 50 o más ya están en el 0,65 % de las transacciones de tipo 4 de la muestra sistemática, a un tercio del 1 % que haría común el patrón.

Fuentes y enlaces: EIP-7702, especificación (estructura de la tupla de autorización) · Contrato de USDT en Ethereum (función de lista negra) · techreport.com: las cincuenta autorizaciones y los nonces consecutivos · Fireblocks: nota técnica sobre el incidente · Decrypt: explicación general de EIP-7702 · Extracciones propias congeladas del 30-oct-2026 y del 21-oct-2026, y relectura de saldos del 3-nov-2026 con balanceOf.