Una sola firma puede reescribir tu billetera: la paradoja del EIP-7702 en Ethereum

1. La actualización que enseñó nuevos trucos a las viejas billeteras

El 7 de mayo de 2025, a las 10:05:11 UTC y en el epoch 364032, Pectra se activó en la red principal de Ethereum e incorporó el EIP-7702. Vitalik Buterin, Sam Wilson, Ansgar Dietrichs y lightclient habían creado esta propuesta Core el 7 de mayo de 2024. Su objetivo era directo: añadir una transacción que establece permanentemente código para una EOA. Así, una cuenta controlada por clave podía adquirir funciones de contrato sin cambiar de dirección.^[1][2][6]

La transacción de código usa el tipo 0x04 y una lista de tuplas [chain_id, address, nonce, y_parity, r, s]. Por cada tupla válida, se escribe en la cuenta un indicador formado por 0xef0100 y la dirección de destino. Las operaciones posteriores ejecutan el código de esa dirección en el contexto de la EOA. La clave privada sigue bajo control del propietario, pero durante la ejecución la cuenta se comporta como el contrato delegado.^[1]

La arquitectura habilita lotes atómicos, patrocinio de gas, autenticación alternativa, límites de gasto y recuperación sin cambiar de dirección. La Fundación Ethereum también describió salvaguardas: las autorizaciones son específicas de cadena por defecto, se vinculan al nonce y el propietario puede reemplazarlas o revocarlas. Reducen el riesgo de repetición y bloqueo, aunque no vuelven seguro un delegado malicioso.^[2]

2. Persistente por diseño, no por accidente

La lista de autorizaciones se procesa antes de la ejecución, después de incrementar el nonce del emisor. Si la ejecución posterior falla o se revierte, los indicadores ya procesados no se deshacen. La delegación permanece hasta que el propietario la reemplaza o la elimina con la dirección cero. Es software persistente de cuenta, no una autorización de sesión que caduca al terminar una interacción.^[1][3]

La especificación advierte que el código autorizado obtiene acceso sin restricciones a la cuenta y debe ser auditado por la billetera. Pocos usuarios pueden verificar razonablemente el bytecode delegado. La clave privada permite volver a una EOA común, pero revocar no deshace operaciones ejecutadas mientras estuvo activo un contrato malicioso.^[1][3]

Un delegado mal implementado puede permitir que un actor malicioso tome un control casi completo sobre la EOA del firmante.^[1]

— Especificación EIP-7702, Consideraciones de seguridad

3. La superficie de phishing por autorización

Security Alliance identifica la amenaza principal en su guía sobre autorizaciones EIP-7702: sitios de phishing y estafas que inducen al usuario a firmar una delegación SetCode hacia un contrato malicioso bajo la apariencia de una actualización de la billetera. Si la víctima firma una autorización que apunta su cuenta a código controlado por el atacante, la guía advierte que este puede obtener el control y vaciar activos. El arma no tiene que ser una frase semilla robada; puede ser una firma de consentimiento válida obtenida mediante una interfaz engañosa.^[5]

Esta dinámica cambia la forma del phishing de autorizaciones. Muchas estafas tradicionales de aprobaciones o transacciones se centran en conseguir que la víctima firme una acción dañina. Con el EIP-7702, una tupla de autorización válida, una vez procesada en una transacción de tipo 0x04, instala un puntero de código persistente que sobrevive al fallo de la fase de ejecución. El preprint de diciembre de 2025 caracteriza ese cambio permanente como una clase cualitativamente nueva de phishing; la persistencia está fijada por la especificación, mientras que la clasificación del ataque sigue siendo una afirmación de los autores del preprint.^[1][4]

El alcance puede superar una cadena. Las autorizaciones se vinculan normalmente a una red, pero chain_id=0 las hace válidas en todas las redes EVM. Security Alliance advierte que un atacante podría reutilizar la firma donde haya desplegado código malicioso en la misma dirección. Por eso la guía oficial pide mostrar con claridad el contrato de destino antes de firmar.^[3][5]

4. Un preprint, no un veredicto definitivo

El 13 de diciembre de 2025, Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu y Shiping Chen publicaron en arXiv el preprint EIP-7702 Phishing Attack, identificado como 2512.12174v1 [cs.CR]. Sus afiliaciones eran la Universidad de la Ciudad de Macao, CSIRO Data61 y la Universidad de Wollongong. El resumen condensó su tesis en una frase.^[4]

Mostramos que este diseño habilita una clase cualitativamente nueva de ataques de phishing^[4]

— Minfeng Qi et al., EIP-7702 Phishing Attack (preprint de arXiv 2512.12174v1)

Los experimentos y mediciones del artículo siguen siendo afirmaciones de autores en un preprint sin revisión por pares. Esta crónica no presenta sus cifras de adopción o pérdidas como hechos establecidos. La advertencia central ya existía: en mayo de 2024, los autores del EIP habían indicado que la firma directa de autorizaciones no debía ser una función abierta de las dApps.^[1][4]

5. La frontera de defensa

La defensa del ecosistema se basa en una división de funciones. La guía de ethereum.org parte de que las billeteras incluirán contratos de delegación específicos en listas blancas y señala que las dApps no deben solicitar autorizaciones EIP-7702 directamente, sino usar interfaces estandarizadas como ERC-5792 (wallet_sendCalls). Para las billeteras de hardware también recomienda no exponer delegaciones arbitrarias y describe una lista de delegadores de confianza como el consenso emergente. Son restricciones y recomendaciones de interfaz, no garantías impuestas por el protocolo.^[3]

Security Alliance recomienda usar el flujo nativo de la billetera y contratos integrados por su proveedor. La cuenta puede volver a ser una EOA delegando a la dirección cero (0x0000000000000000000000000000000000000000). La seguridad no puede depender de que el usuario lea bytecode. La especificación lo resume así: "No hay forma segura de proporcionar esta interfaz".^[1][5]

Ese reparto define el legado del EIP-7702. La actualización llevó lotes, patrocinio de gas, autenticación alternativa y recuperación a las cuentas existentes. Pero una sola firma también puede instalar código persistente. La seguridad pasa entonces de revisar cada transacción a controlar qué interfaces pueden pedir la autorización. Los autores del EIP escribieron esa obligación más de un año antes del preprint.^[1][2][4]

Las aplicaciones no deben esperar poder sugerir al usuario que firme una autorización y, por lo tanto, es deber de la billetera no proporcionar una interfaz para hacerlo.^[1]

— Especificación EIP-7702, Interacción con aplicaciones y billeteras