¿Qué es EIP-7702?

EIP-7702 es una propuesta central del protocolo que cambia las capacidades de las cuentas de Ethereum. EIP significa Ethereum Improvement Proposal, es decir, propuesta de mejora de Ethereum, y 7702 es el número de la propuesta. Permite que una cuenta externa delegue la ejecución de código a código de contrato inteligente ya desplegado, sin perder su dirección, saldo ni control mediante clave privada.

Una cuenta externa (Externally Owned Account, EOA) es una cuenta de Ethereum controlada por una clave privada y utilizada habitualmente por una billetera individual. Una EOA tradicional puede firmar e iniciar transacciones, pero no puede programar en la propia cuenta operaciones agrupadas, reglas de permisos o lógica de recuperación como una cuenta de contrato inteligente. EIP-7702 conecta ambos modelos: una EOA puede ejecutar código de contrato designado en el contexto de su propia cuenta sin trasladar activos a una dirección nueva.

La propuesta alcanzó el estado Final y se activó en la red principal de Ethereum el 7 de mayo de 2025 como parte de la actualización de red Pectra. Define un mecanismo de delegación subyacente, no un producto de billetera completo. La disponibilidad de funciones como operaciones agrupadas, patrocinio de gas, permisos de sesión o recuperación de cuenta depende del contrato delegado que elija la billetera y de su implementación.

¿Qué problema resuelve?

Una EOA tradicional es sencilla: quien pueda utilizar la clave privada correspondiente puede firmar y controlar la cuenta. Sin embargo, la cuenta no tiene lógica programable. Si una persona quiere aprobar un token, intercambiar un activo y depositar el resultado en otro protocolo, por lo general debe confirmar varias transacciones por separado. Las comisiones de gas también suelen pagarse con ETH, el activo nativo de Ethereum, que mantiene la cuenta.

Una cuenta de contrato inteligente puede añadir reglas de validación y ejecución más complejas. Sin embargo, crear una cuenta de contrato nueva puede implicar usar una dirección nueva y gestionar la migración de activos, la compatibilidad con aplicaciones y la continuidad del historial o la identidad de la cuenta.

EIP-7702 permite que una EOA existente apunte a código de contrato. Así, una billetera puede añadir capacidades definidas por código sin cambiar la dirección de la cuenta. La propuesta no elimina el control existente mediante clave privada ni actualiza automáticamente todas las EOA. La delegación solo se escribe en el estado de Ethereum después de que la cuenta firme y envíe una autorización válida.

¿Cómo entra en vigor una autorización?

EIP-7702 introduce el tipo de transacción 0x04. Esta transacción puede incluir una o más autorizaciones, cada una de las cuales indica que una EOA acepta delegar la ejecución de código a una dirección de destino.

Desde la perspectiva de la persona usuaria, el proceso tiene cinco pasos:

1. La billetera selecciona el código del contrato delegado que pretende usar y presenta la autorización.
2. La EOA firma la autorización y confirma la red de destino, la dirección delegada y el número de secuencia actual de la cuenta, llamado nonce.
3. Una transacción de tipo 4 envía la autorización a la red. El remitente puede ser la EOA u otra cuenta que pague la comisión de gas en su nombre.
4. Después de validar la firma y el nonce, los nodos de la red escriben en la EOA un marcador de delegación que apunta al código de destino.
5. Cuando otra cuenta o contrato llama posteriormente a la EOA, el código del contrato de destino procesa la llamada utilizando la dirección, el saldo y el contexto de almacenamiento de la propia EOA.

Varios campos de la autorización limitan riesgos diferentes:

La delegación no transfiere activos a la dirección de destino. El código de destino se ejecuta en el contexto de la EOA que lo autorizó, por lo que lee y modifica el almacenamiento de esa EOA y utiliza su dirección y saldo. Por eso el código delegado puede tener un alcance de control amplio sobre la cuenta.

¿Qué cambia después de la autorización?

La cuenta conserva la misma dirección después de la delegación, su saldo existente no se transfiere automáticamente y su clave privada todavía puede firmar transacciones. El cambio consiste en que el campo de código de la cuenta almacena un marcador especial que apunta al código del contrato de destino. Las llamadas a la cuenta se procesan conforme al código indicado por ese marcador.

La delegación es persistente. No desaparece automáticamente después de una transacción. Permanece activa hasta que la cuenta usa otra autorización válida para apuntar a código diferente o elimina la delegación. No debe suponerse que una autorización terminó solo porque una operación agrupada concreta ya se completó.

Establecer la autorización y ejecutar la llamada posterior también son etapas separadas. Según las reglas de procesamiento de EIP-7702, una delegación ya procesada no se revierte automáticamente si falla la ejecución posterior de la transacción de tipo 4. La billetera debe mostrar y verificar por separado que «la delegación se escribió» y que «la acción prevista tuvo éxito».

¿Qué funciones de cuenta puede admitir?

EIP-7702 proporciona una herramienta subyacente a las billeteras. Algunos diseños pueden usar el código delegado para ofrecer:

• un solo flujo de firma para varias operaciones, como aprobar, intercambiar y depositar;
• envío y pago del gas por parte de otra cuenta o servicio;
• permisos específicos, como claves de sesión, límites por uso o destinos restringidos;
• métodos de autenticación distintos de la firma de una sola clave privada;
• recuperación, pausa o controles de gasto;
• compatibilidad con infraestructura de cuentas inteligentes basada en el estándar de abstracción de cuentas ERC-4337.

EIP-7702 no garantiza ninguna de estas funciones. Especifica cómo autorizar, registrar una delegación y ejecutar el código referenciado. El contrato delegado y la interfaz de la billetera determinan qué funciones existen, cómo validan una acción y cómo se recupera la cuenta si ocurre un problema.

El patrocinio de gas no significa que Ethereum deje de cobrar gas. Una transacción de tipo 4 permite que otra cuenta actúe como remitente de la transacción externa, incluya la autorización de la EOA y pague la comisión de gas. La decisión de un servicio de patrocinar la comisión, la forma de liquidar el costo y quién paga llamadas posteriores dependen del producto de billetera o servicio.

¿En qué se diferencia de una cuenta inteligente?

«Cuenta inteligente» es un término amplio para una experiencia de cuenta en la que código programable define las reglas de validación y ejecución. EIP-7702 es un mecanismo a nivel del protocolo que permite esa experiencia, pero no equivale a todos los diseños de cuentas inteligentes.

ERC-4337 es otro estándar de abstracción de cuentas. Organiza acciones mediante un objeto de datos UserOperation que describe la intención de la persona, empaquetadores que agrupan operaciones y un contrato EntryPoint que las valida y ejecuta. No exige que la capa de consenso de Ethereum añada una regla de transacción para cada diseño de cuenta. EIP-7702, en cambio, permite que una EOA establezca una delegación de código directamente en el estado del protocolo. Ambos mecanismos pueden combinarse: ERC-4337 define cómo incluir una autorización EIP-7702 en su flujo de operaciones de usuario.

EIP-7702 tampoco convierte automáticamente una EOA común en una cuenta controlada exclusivamente por una política multifirma real. Aunque el código delegado exija varias aprobaciones, la clave privada original puede sustituir o eliminar la delegación y eludir una política de largo plazo aplicada únicamente por el delegado actual. Si una aplicación necesita un modelo de control que una sola clave privada original no pueda anular, no puede concluir que ese modelo existe solo porque se estableció una delegación EIP-7702.

¿Cómo se sustituye o revoca la delegación?

La cuenta puede firmar una autorización nueva que apunte a otra dirección de destino. Para eliminar la delegación, puede usar la dirección cero como destino de la autorización. La autorización nueva todavía debe superar las comprobaciones de red, firma y nonce, y escribirse en la cadena mediante una transacción de tipo 4.

Eliminar la delegación quita el puntero al código, pero no borra automáticamente los datos que el código delegado anterior escribió en el almacenamiento de la cuenta. Si la cuenta utiliza código diferente más adelante, el código nuevo puede leer los datos anteriores o interpretar de otra forma la misma ubicación de almacenamiento. El diseño del contrato delegado debe tener en cuenta la inicialización, las actualizaciones y la compatibilidad del almacenamiento. Antes de cambiar de implementación, la persona también debe comprobar si la billetera ofrece un flujo adecuado de migración y recuperación.

Revocar la delegación no sustituye la protección de la clave privada. Si la clave queda expuesta, un atacante todavía puede firmar una autorización nueva, sustituir el delegado o controlar directamente la cuenta. El código delegado puede añadir reglas operativas, pero la clave original sigue siendo una credencial de control crítica.

Principales riesgos y puntos de verificación

Código delegado malicioso o defectuoso

El código delegado se ejecuta en el contexto de la EOA y puede llamar a otros contratos, transferir activos o modificar almacenamiento. El código malicioso o vulnerable puede obtener un control operativo casi completo sobre la cuenta. Una billetera debe verificar el código de destino y sus permisos de actualización, y no debe pedir que se firme para una dirección delegada desconocida.

Phishing de autorizaciones

Una autorización EIP-7702 puede afectar muchas transacciones futuras y, por lo tanto, tiene un alcance mayor que la firma de una sola transferencia. Si una interfaz solo muestra «iniciar sesión» o «activar una función» sin indicar claramente la red de destino, el código delegado y la persistencia, la persona puede subestimar la autorización. La guía oficial de Ethereum recomienda que las billeteras administren las interacciones de delegación y examinen el código de destino, en lugar de permitir que una página web común solicite autorizaciones arbitrarias.

Repetición entre cadenas y diferencias de dirección

El campo chain_id limita la autorización a una red. El valor 0 puede permitir que la misma autorización se use en varias cadenas, mientras que la misma dirección puede no contener el mismo código en todas las redes. Aunque el texto de una dirección sea idéntico, el código y el estado de la cuenta pueden diferir. La billetera debe comprobar de forma conjunta la red, la dirección de destino y el código realmente desplegado en esa red.

Inicialización y conflictos de almacenamiento

El código delegado nuevo puede necesitar almacenar primero un propietario, permisos u otros datos iniciales. Si otra parte puede ejecutar la inicialización antes, la cuenta podría configurarse incorrectamente. Cuando cambia la delegación, las implementaciones que reutilizan las mismas posiciones de almacenamiento también pueden crear conflictos de permisos o datos.

Las suposiciones antiguas de las aplicaciones dejan de ser válidas

Algunas aplicaciones han tratado «la cuenta no tiene código actualmente» como prueba de que es una cuenta de usuario común, o han utilizado tx.origin para inferir el origen de una llamada. EIP-7702 permite que una EOA ejecute código delegado, por lo que esas suposiciones dejan de ser confiables y también pueden crear riesgos de reentrada. Las aplicaciones deben validar permisos mediante el modelo real de llamadas y autorizaciones, y no basarse en las características anteriores del tipo de cuenta.

Preguntas frecuentes

¿Establecer una delegación cambia la dirección de la billetera?

No. La EOA conserva su dirección después de la delegación, y su saldo e historial permanecen en esa dirección. El elemento nuevo es un marcador de delegación de código.

¿La delegación dura solo una transacción?

No. Una vez escrita, persiste hasta que una autorización nueva la sustituye o elimina. El fallo de una acción prevista no revoca necesariamente una delegación ya procesada.

¿La clave privada sigue siendo válida después de la delegación?

Sí. La clave privada original todavía puede firmar transacciones, sustituir la delegación o eliminarla. El código delegado no elimina la necesidad de proteger la clave.

¿Proporciona automáticamente operaciones agrupadas y patrocinio de gas?

No. Proporciona el mecanismo de delegación subyacente necesario para implementar esas funciones. El código delegado implementa las operaciones agrupadas, mientras que el patrocinio de gas también requiere un remitente o servicio externo dispuesto a enviar la transacción y pagar su comisión.

¿Una cuenta puede delegar en cualquier contrato?

El protocolo permite que una autorización apunte a una dirección con código, pero la posibilidad técnica no significa que el código sea adecuado. Como el código de destino se ejecuta en el contexto de la cuenta, la persona debe usar una billetera confiable para verificar la finalidad del código, la información de auditoría, los permisos de actualización y el método de revocación. No debe firmar una autorización que no pueda identificar.

Conceptos relacionados

Continúa con Ethereum, los contratos inteligentes y la máquina virtual de Ethereum, o vuelve al glosario de criptomonedas. Esta entrada no se enlazará desde el glosario A–Z hasta que las siete versiones lingüísticas estén publicadas.

Fuentes

• EIP-7702: Set Code for EOAs — tipo de transacción, campos de autorización, ejecución delegada, revocación y consideraciones de seguridad.
• Ethereum.org: guía de EIP-7702 — integración con billeteras, control de cuenta, autorización entre cadenas, riesgos de delegación y recomendaciones de interacción.
• Ethereum Foundation: anuncio de Pectra en la red principal — fecha de activación en la red principal y contexto de las funciones para personas usuarias de EIP-7702.
• ERC-4337: abstracción de cuentas mediante un mempool alternativo — compatibilidad de ERC-4337 con autorizaciones EIP-7702.