Un smart wallet es una cuenta de Ethereum con autorización programable, implementada mediante una cuenta de contrato o, con EIP-7702, mediante código delegado en una EOA. La hoja de ruta de account abstraction de Ethereum explica por qué esto importa: las cuentas programables pueden incorporar recuperación, batching, gas patrocinado, pago de fees con otros tokens y políticas de autorización más flexibles. Estos monederos trasladan una parte mayor de la autorización a código. Las claves y el riesgo siguen existiendo, y aparecen nuevos componentes que deben ser confiables.
Actualmente hay dos caminos técnicos especialmente importantes. ERC-4337 introduce un flujo paralelo basado en UserOperation, bundlers, un contrato EntryPoint y paymasters opcionales. EIP-7702 permite que una externally owned account autorice una dirección de implementación que el protocolo registra mediante un indicador de delegación. Resuelven problemas de UX parecidos, pero no son la misma arquitectura.
Puntos clave
- Una EOA tradicional sin delegación está controlada por una clave privada y utiliza un nonce para evitar repeticiones y ordenar transacciones.
- Un monedero smart contract puede imponer multisig, recuperación, límites de gasto, permisos temporales, batching o validación personalizada.
- ERC-4337 añade un flujo alternativo donde las
UserOperationpasan por un EntryPoint; no sustituye el tipo de transacción base de Ethereum. - EIP-7702 permite que una EOA autorice una dirección de implementación; el protocolo registra un indicador de delegación en el código de la EOA mientras la cuenta conserva su dirección.
- Gas sponsorship no significa que el gas deje de costar: un paymaster o la aplicación asume o recupera ese coste bajo sus propias reglas.
- Los smart wallets pueden reducir el riesgo de pérdida de claves, pero añaden riesgos de código, módulos, upgrades, permisos y dependencias.
- “Smart account” describe capacidades, no garantiza que una wallet concreta sea más segura que una EOA bien gestionada.
EOA frente a monedero smart contract
Ethereum distingue externally owned accounts de contract accounts. Una EOA está controlada por una clave privada. Una cuenta de contrato está controlada por código que se ejecuta cuando recibe una llamada. Un smart wallet utiliza lógica programable para decidir si una acción está autorizada.
Eso cambia el significado práctico de “control”. En una EOA simple, poseer la clave normalmente basta para autorizar cualquier acción disponible. Un smart wallet puede exigir dos de tres firmantes, aceptar una recuperación con guardians después de un retraso, permitir una session key con un límite pequeño o rechazar operaciones que incumplan una política.
| Capacidad | EOA tradicional | Monedero smart contract |
|---|---|---|
| Autorización | Firma de clave privada | Lógica de validación programable |
| Recuperación | Sin recuperación nativa a nivel de cuenta; el acceso depende de la clave privada o de la copia de la seed | Guardians, claves alternativas, delays o módulos |
| Multisig | Contrato o capa adicional | Puede formar parte de la lógica principal |
| Batching | Varias transacciones | Puede agrupar varias llamadas |
| Pago de gas | El emisor suele necesitar el token nativo | Puede utilizar paymasters u otros flujos |
| Políticas de gasto | Sin límites de gasto programables a nivel de cuenta | Pueden aplicarse onchain |
| Permisos de sesión | No forman parte de una EOA básica | Se pueden añadir claves limitadas y temporales |
| Riesgo de upgrade | Sin código de cuenta que actualizar | Implementación y módulos pueden ser actualizables |
La comparación útil enfrenta la autoridad simple basada en una clave con la autoridad programable.
Cómo cambia el flujo con ERC-4337
La especificación ERC-4337 define un objeto UserOperation que describe lo que una smart account quiere ejecutar. No se envía a Ethereum exactamente como una transacción EOA normal.
Un flujo simplificado es:
- La aplicación del monedero construye una
UserOperation, y el mecanismo de autorización de la cuenta aporta los datos de validación que exige su implementación. - Un bundler reúne una o varias operaciones.
- El bundler envía una transacción al contrato EntryPoint.
- EntryPoint pide a cada smart account que valide su operación.
- Si la validación y el funding de gas son correctos, se ejecuta.
- Un paymaster opcional puede patrocinar gas o aplicar otra lógica de pago.
La especificación exige que la cuenta valide que la llamada procede del EntryPoint esperado y que compruebe la autorización de la operación. Por eso la seguridad depende en parte del código de validación del monedero.
El paymaster puede mejorar onboarding porque el usuario no necesita necesariamente tener ETH antes de su primera acción. No elimina el coste del gas: alguien lo paga y el paymaster puede aplicar límites, condiciones, cobro en otro token o reglas de elegibilidad.
Qué añade EIP-7702
EIP-7702 adopta otro enfoque. Su especificación final permite que una EOA autorice una dirección de implementación. Después, el protocolo escribe en el código de la EOA un indicador de delegación que apunta a esa dirección. La EOA conserva su dirección y la delegación persiste hasta que una autorización posterior la sustituye o la elimina autorizando la dirección cero.
El código delegado puede implementar batching, sponsorship, permisos o recuperación sin obligar al usuario a trasladar fondos a otra dirección de cuenta. Las funciones disponibles y su seguridad dependen de la implementación delegada.
El código delegado puede obtener una autoridad muy amplia sobre la EOA. EIP-7702 advierte que un delegate mal implementado puede permitir que un actor malicioso tome un control casi total de la EOA del firmante. También describe riesgos de front-running durante la inicialización de la delegación y riesgos al sustituir un delegate por otro. Por eso la interfaz del monedero debe identificar el código delegado y mostrar claramente cuándo se sustituye una delegación existente.
Las arquitecturas difieren en el flujo de transacciones y el tipo de cuenta:
- ERC-4337: la smart account participa en un pipeline alternativo de account abstraction.
- EIP-7702: una EOA autoriza una dirección de implementación y ejecuta su código delegado mientras conserva la dirección de la EOA.
Los dos sistemas también pueden combinarse. ERC-4337 contempla expresamente cuentas delegadas mediante EIP-7702.
Por qué importa ERC-1271
Muchas aplicaciones históricamente suponían que un usuario demostraba control produciendo una firma ECDSA de una EOA. Una contract account no firma con una clave privada propia de esa misma forma porque la cuenta es código.
ERC-1271 define un método estándar para que un contrato indique si una firma es válida para un hash determinado. La lógica de validación depende de la implementación, lo que permite que las aplicaciones admitan autorización mediante contract wallets sin suponer que cada usuario es una EOA.
Esto permite que dApps trabajen con multisig, cuentas institucionales, recuperación programable y cualquier modelo donde autorización signifique algo más complejo que “una clave firmó este hash”.
Ejemplo práctico: onboarding DeFi en una acción
Imaginemos un usuario nuevo que quiere depositar una stablecoin en un protocolo de lending.
Con una EOA básica puede necesitar:
- conseguir el token nativo para gas;
- aprobar el contrato de la stablecoin;
- enviar la transacción de depósito;
- conservar suficiente gas para operaciones posteriores.
Un smart account podría agrupar approval y depósito mientras la aplicación patrocina la primera operación mediante un paymaster. El usuario puede firmar una intención en lugar de enviar manualmente varias transacciones.
La experiencia mejora, pero el mapa de riesgo cambia. El usuario debe confiar ahora en:
- implementación del wallet;
- bundle de llamadas;
- reglas del paymaster;
- módulos o session keys;
- autoridad de upgrade;
- frontend que explica lo que se autoriza.
Reducir el número de transacciones no elimina el riesgo transaccional.
La seguridad de un smart wallet es seguridad de políticas
En una EOA, la pregunta central suele ser “¿quién controla la clave?”. En un smart wallet aparece otra: “¿qué acepta el código como autorización válida?”.
La documentación de Safe Smart Account muestra esta lógica. Una cuenta Safe puede usar varios owners y un threshold de firmas, mientras que los modules opcionales pueden iniciar transacciones sin reunir las aprobaciones multisig normales y los guards pueden ejecutar comprobaciones antes y después de la ejecución.
Estas extensiones pueden cambiar la autorización. Un módulo defectuoso o malicioso puede debilitar la cuenta aunque las hardware wallets de los owners sigan intactas.
En una tesorería conviene inventariar no solo firmantes, sino también:
- módulos activos;
- guards;
- fallback handlers;
- autoridad de upgrade;
- permisos de gasto;
- lógica de recuperación;
- paymasters y relayers;
- session keys y expiración.
Matriz de decisión: EOA o smart account
| Caso de uso | Una EOA puede bastar si… | Una smart account gana valor si… |
|---|---|---|
| Ahorro personal | un firmante, pocas operaciones y un plan de recuperación sencillo | hacen falta guardians, recuperación diferida, varias claves o límites de política |
| DeFi activo | el usuario entiende gas, approvals y gestión de nonce | batching, gas patrocinado o permisos limitados reducen pasos manuales repetidos |
| Tesorería | el control de una sola clave no es aceptable | hacen falta varios firmantes, thresholds y controles de política |
| App de consumo | el usuario puede gestionar seed phrases y gas nativo | la app necesita passkeys, recuperación, gas patrocinado o batching invisible |
| Automatización | la firma es poco frecuente y se revisa manualmente | las session keys necesitan permisos limitados, restricciones y expiración automática |
La tabla no significa que toda smart account sea más segura. Una wallet poco auditada con módulos de amplio alcance puede ser más arriesgada que una EOA simple protegida por hardware.
Recuperación: más flexible no significa sin secretos
Los smart wallets suelen promocionarse por recuperación. Es útil, pero la recuperación redistribuye confianza en lugar de eliminarla.
Un sistema con guardians puede rotar la clave de owner tras perder un dispositivo. Un delay puede dar tiempo para cancelar una recuperación maliciosa. Un esquema multidispositivo puede exigir dos dispositivos en lugar de una única seed.
Cada diseño tiene edge cases:
- guardians pueden coludirse o ser comprometidos;
- delays pueden bloquear una recuperación urgente legítima;
- varias copias pueden perderse juntas;
- administradores de upgrade pueden convertirse en punto único de fallo;
- contactos de social recovery pueden sufrir ingeniería social.
Una revisión de recuperación debe identificar qué evento inicia el proceso, quién puede aprobarlo, cuánto tarda y cómo se detiene una toma de control fraudulenta.
Session keys y permisos de gasto
Una smart account puede autorizar claves con poderes más estrechos que el owner principal. Un juego, bot o pago recurrente puede recibir una clave temporal capaz de llamar solo contratos concretos o gastar por debajo de un límite.
Esto puede reducir el impacto de exponer una session key, pero únicamente si las restricciones se aplican en el código. Una limitación descrita en el frontend pero no aplicada onchain no equivale a una política real.
La documentación de smart accounts de Coinbase ilustra este tipo de capacidades con batching, gas sponsorship y spend permissions.
Un smart wallet no elimina phishing
Una cuenta programable puede mejorar validación y recuperación, pero un usuario todavía puede autorizar una acción dañina.
Un sitio de phishing puede solicitar una llamada peligrosa, pedir una delegación EIP-7702 maliciosa, engañar al usuario para que habilite un módulo o explotar un batch mal explicado. El problema puede pasar de “firmaste una transferencia” a “cambiaste lo que tu cuenta puede hacer”.
La cobertura de BTC-Pulse sobre phishing en Ethereum y dominios maliciosos recuerda que la seguridad de cuenta y la confianza en el frontend son capas distintas.
Para usuarios de Layer 2 existe otra dependencia. El comportamiento de una smart account puede depender de infraestructura de red, bundlers, paymasters, sequencers y despliegues específicos de cada chain. Nuestra guía sobre fiabilidad de Ethereum Layer 2 explica por qué una cuenta puede estar bien protegida a nivel de clave y depender todavía de infraestructura operativa adicional.
Errores frecuentes
“Smart contract wallet significa que ya no hay claves privadas”
No necesariamente. Muchas smart accounts siguen teniendo owner keys. La diferencia es que el código puede combinar, sustituir o limitar esas claves.
“ERC-4337 es un nuevo tipo de transacción de consenso”
No. ERC-4337 implementa account abstraction sin cambiar el consenso mediante UserOperations, bundlers y EntryPoint.
“EIP-7702 convierte una EOA en una contract account desplegada de forma normal”
No. Tras la autorización, el protocolo escribe un indicador de delegación en el código de la EOA. La cuenta conserva su dirección e identidad de EOA mientras las llamadas ejecutan la implementación delegada.
“Gas sponsorship significa transacciones gratis”
No. El gas sigue teniendo coste; cambia quién lo paga o cómo se recupera.
“Multisig y smart wallet son lo mismo”
Una multisig puede ser un smart wallet, pero una cuenta programable también puede tener un solo owner, recovery, session keys, límites y batching.
Casos límite
Cuentas contrafactuales
ERC-4337 admite direcciones contrafactuales cuyos datos de despliegue pueden incluirse con la primera UserOperation. Es posible enviar activos a la dirección predeterminada antes del despliegue, pero el acceso depende de que la factory y la inicialización previstas funcionen correctamente.
La misma dirección en varias chains
Una dirección puede coincidir entre redes con despliegues deterministas, pero el código, el estado de los módulos, los balances, los despliegues de EntryPoint y el soporte de paymasters pueden diferir. No se debe inferir funcionalidad solo por la dirección.
Código actualizable
El upgrade permite corregir fallos y añadir funciones, pero quien controla upgrades tiene mucho poder. Hay que saber si el control pertenece a owners, DAO, proveedor, timelock o código inmutable.
Owner EOA comprometido
Si una smart account tiene un único owner EOA comprometido y ninguna política adicional, la protección puede ser limitada.
Checklist antes de usar una smart account
- Identifica el modelo: una cuenta de contrato que use ERC-4337 u otro flujo, una EOA delegada mediante EIP-7702 u otra arquitectura.
- Lista todos los owners y thresholds.
- Lista cada module, guard, plugin, session key y método de recuperación activo.
- Comprueba quién puede actualizar la implementación.
- Entiende si un paymaster puede negar servicio o cobrar otro activo.
- Revisa límites y expiración de permisos delegados.
- Prueba la recuperación con documentación y cuentas de poco valor antes de depender de ella en una tesorería.
- Comprueba qué muestra la wallet al firmar batches o delegaciones.
- Mantén reservas de alto valor separadas de permisos experimentales cuando sea razonable.
- Repite la revisión después de instalar módulos o modificar recuperación.
Preguntas frecuentes
¿Qué es un monedero smart contract?
Es una cuenta de Ethereum cuya lógica de autorización reside en un smart contract o en código delegado. Puede incluir multisig, recovery, batching, límites de gasto o gas sponsorship.
¿ERC-4337 y EIP-7702 son lo mismo?
No. ERC-4337 introduce el flujo UserOperation/EntryPoint. EIP-7702 permite que una EOA autorice una dirección de implementación y registra un indicador de delegación en el código de la EOA. Pueden complementarse, pero operan de forma distinta.
¿Son más seguros que una EOA?
Pueden reducir riesgo de una sola clave y mejorar recuperación, pero añaden riesgo de código, módulos, upgrades y dependencias. La seguridad depende de la implementación y de su configuración.
¿Necesitan ETH para pagar gas?
No siempre desde la perspectiva del usuario. Un paymaster o aplicación puede patrocinar gas o cobrar otro activo, aunque la ejecución de red continúa teniendo coste.
¿Puede una hardware wallet ser owner de una smart account?
Sí. Una EOA protegida por hardware puede ser uno de los owners de una smart account o multisig. El hardware protege esa clave; la smart account aplica la política general.
BTC-Pulse Take
Los smart wallets implementan autorización programable. Pueden facilitar recuperación, mejorar la seguridad de equipos y simplificar apps de consumo, pero cada función nueva se convierte en parte del modelo de riesgo.
ERC-4337 y EIP-7702 facilitan mucho el despliegue de esa programabilidad. Trasladan políticas desde hábitos informales hacia reglas que el propio account puede hacer cumplir, sin eliminar la responsabilidad de entenderlas.
Para una persona puede significar recuperación o gas sponsorship. Para una empresa puede significar thresholds, límites y permisos auditables. En ambos casos, la revisión fundamental es la misma: identificar quién y qué puede autorizar movimiento de valor y limitar ese poder a lo estrictamente necesario.
Este artículo es educativo y no constituye asesoramiento financiero ni de seguridad. Los estándares y las implementaciones evolucionan; comprueba siempre la documentación y auditorías actuales de la wallet concreta.
Fuentes
- Ethereum.org — Account abstraction
- Ethereum Improvement Proposals — ERC-4337
- Ethereum Improvement Proposals — EIP-7702
- Ethereum Improvement Proposals — ERC-1271
- Safe Documentation — Smart Account Overview
- Coinbase Developer Platform — Managing Accounts / Smart Accounts
