Account Abstraction: ERC-4337 y el Futuro de la UX Crypto

Crypto tiene un problema de experiencia de usuario. Después de más de una década de desarrollo, interactuar con una blockchain todavía requiere administrar una seed phrase de 12 palabras que nunca puede recuperarse si se pierde, mantener un balance de token nativo solo para pagar fees de gas en cada transacción, y firmar mensajes crípticos en hexadecimal sin contexto claro. Estos no son edge cases -- son la experiencia por defecto para cada usuario nuevo. Y representan la barrera más grande para la adopción masiva de blockchain.

Account abstraction es la mejora de UX más significativa en la historia de Ethereum. Reemplaza el modelo de cuentas rígido y dependiente de claves con wallets de smart contracts programables que pueden implementar cualquier lógica de autenticación, patrocinar gas para los usuarios, recuperar acceso a través de contactos de confianza y agrupar múltiples operaciones en un solo clic. Esta guía proporciona un recorrido técnico integral de cómo funciona account abstraction, los estándares que lo hacen posible y cómo los equipos de desarrollo pueden construir con él hoy.

El Problema de UX con las Externally Owned Accounts

Ethereum tiene dos tipos de cuentas: externally owned accounts (EOAs) y contract accounts. Desde que la red se lanzó en 2015, cada interacción de usuario ha sido iniciada por una EOA -- una cuenta controlada por una sola clave privada derivada de una seed phrase. Este diseño tenía sentido como punto de partida, pero ha creado un conjunto de restricciones de UX que son fundamentalmente incompatibles con la adopción masiva.

El primer problema es la gestión de claves. Una seed phrase es un punto único de falla sin mecanismo de recuperación. Si la perdés, tus fondos se fueron permanentemente. Si alguien más la obtiene, tus fondos se fueron permanentemente. No hay reset de contraseña, no hay soporte al cliente y no hay recuperación de cuenta. Todo el modelo de seguridad descansa en la suposición de que cada usuario puede almacenar de forma segura y nunca perder una secuencia de 12 palabras aleatorias -- una suposición que falla regularmente, incluso entre usuarios técnicos.

El segundo problema es el gas. Cada transacción en Ethereum requiere que el remitente pague gas en ETH. Esto significa que incluso si un usuario recibe USDC, un NFT o cualquier otro token, no puede hacer nada con él hasta que también adquiera ETH. Para usuarios nuevos, esto crea un problema de huevo y gallina: necesitan ETH para usar la aplicación, pero adquirir ETH es en sí un proceso de múltiples pasos que involucra exchanges, KYC y bridging. Las aplicaciones pierden usuarios en cada uno de estos puntos de fricción.

El tercer problema es la rigidez transaccional. Una EOA solo puede ejecutar una operación por transacción, debe firmar cada operación individualmente y no puede aplicar lógica de validación personalizada. No podés establecer límites de gasto, requerir aprobación multipartita, automatizar pagos recurrentes o delegar permisos temporales -- todas funcionalidades que el software financiero tradicional provee por defecto. Cada transacción requiere la clave privada completa para firmar, cada vez, sin excepciones.

Qué Significa Realmente Account Abstraction

Account abstraction es el concepto de convertir cada cuenta en Ethereum en un smart contract. En lugar de que las cuentas sean controladas por una sola clave privada con verificación ECDSA hardcodeada, las cuentas se vuelven programables -- pueden definir su propia lógica de validación, ejecutar código arbitrario durante las transacciones e implementar cualquier esquema de autenticación que el desarrollador elija.

La palabra abstraction acá se usa en el sentido de ciencias de la computación: separar la interfaz de la implementación. Actualmente, el protocolo de Ethereum hardcodea cómo funcionan las cuentas -- firmas ECDSA, control de clave única, pago de gas por el remitente. Account abstraction elimina estas suposiciones hardcodeadas y permite que cada cuenta defina sus propias reglas. Al protocolo solo le importa que la cuenta diga que la transacción es válida, no cómo determina la validez.

Esto no es una mejora menor. Es un cambio arquitectónico que transforma lo que una cuenta blockchain puede ser. Una smart contract account puede verificar firmas de cualquier esquema -- ECDSA, Ed25519, BLS, passkeys o multisig. Puede implementar social recovery a través de direcciones de guardianes. Puede agrupar múltiples operaciones en una sola transacción atómica. Puede delegar permisos con session keys que expiran. Y puede tener su gas pagado por un tercero, para que los usuarios nunca necesiten tener ETH.

El Camino hacia ERC-4337: Breve Historia

Account abstraction no es una idea nueva. La comunidad de Ethereum ha trabajado hacia ella desde los primeros días de la red, pero el camino ha sido largo y complejo porque las implementaciones obvias requerían cambios al protocolo core de Ethereum -- cambios que son difíciles de coordinar y riesgosos de deployar.

EIP-86, propuesto por Vitalik Buterin en 2017, fue una de las primeras propuestas formales. Sugería permitir que las transacciones se originaran desde cualquier dirección (no solo EOAs) y dejar que los contratos pagaran su propio gas. Sin embargo, requería cambios profundos al formato de transacciones y al pipeline de validación, haciéndolo demasiado riesgoso para un hard fork. EIP-2938, propuesto en 2020, refinó el enfoque introduciendo un nuevo tipo de transacción específicamente para account abstraction, pero aún requería cambios en la capa de consenso y enfrentaba los mismos desafíos de deployment.

ERC-4337, escrito por Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh y Shahaf Nacson, tomó un enfoque fundamentalmente diferente. Publicado en 2021 y deployado en Ethereum mainnet en marzo de 2023, logra account abstraction completamente en la capa de aplicación -- sin cambios al protocolo. Lo hace introduciendo un sistema de transacciones de nivel superior que corre sobre la infraestructura existente de Ethereum, usando un mempool separado, actores especializados llamados bundlers y un smart contract singleton llamado EntryPoint.

Arquitectura de ERC-4337: Análisis en Profundidad

Entender ERC-4337 requiere comprender sus cinco componentes core: UserOperations, el alt mempool, Bundlers, el contrato EntryPoint y Paymasters. Cada uno juega un rol distinto en el sistema, y juntos replican la funcionalidad del pipeline nativo de transacciones de Ethereum -- pero con cuentas programables en lugar de EOAs.

UserOperations

Una UserOperation (o UserOp) es el equivalente en ERC-4337 de una transacción. Es una estructura de datos que describe lo que una smart contract account quiere hacer. A diferencia de una transacción tradicional, que es firmada por una clave privada y enviada directamente al mempool de Ethereum, una UserOp se envía a un mempool alternativo donde los bundlers la recogen para procesamiento.

Una UserOp contiene campos análogos a una transacción regular -- sender, nonce, calldata, gas limits -- más campos adicionales específicos de account abstraction: initCode (para deployar la cuenta en el primer uso), paymasterAndData (para patrocinio de gas) y signature (que puede ser cualquier formato que el contrato de la cuenta espere, no necesariamente ECDSA). El campo sender es la dirección de la smart contract account, no de un poseedor de clave privada.

Bundlers

Los Bundlers son actores off-chain que monitorean el mempool de UserOperations, recolectan UserOps válidas y las agrupan en una sola transacción regular de Ethereum. El bundler llama a la función handleOps del contrato EntryPoint, pasando un array de UserOps. Desde la perspectiva del protocolo de Ethereum, esta es una transacción estándar enviada por la EOA del bundler -- el protocolo no tiene conocimiento de account abstraction.

Los Bundlers cumplen un rol análogo a los block builders en el pipeline de transacciones existente de Ethereum. Validan UserOps, simulan ejecución, ordenan operaciones y envían el bundle on-chain. Son compensados a través de reembolsos de gas y propinas opcionales. Cualquiera puede correr un bundler, y existen múltiples servicios de bundler -- desde el Rundler de Alchemy hasta Stackup, Pimlico y Biconomy.

El Contrato EntryPoint

El EntryPoint es un smart contract singleton deployado en una dirección canónica en cada cadena EVM. Es el coordinador central de todo el sistema ERC-4337. Cuando un bundler envía un batch de UserOps, el EntryPoint procesa cada una a través de un modelo de ejecución de dos fases.

En la fase de verificación, el EntryPoint llama a la función validateUserOp en la smart contract account del remitente. La cuenta puede implementar cualquier lógica de validación -- verificar una firma ECDSA, validar un umbral de multi-sig, verificar una assertion de passkey, o cualquier esquema personalizado. Si la validación tiene éxito, el EntryPoint procede a la fase de ejecución, donde llama al contrato de la cuenta para ejecutar la operación real descrita en el calldata de la UserOp. Este modelo de dos fases asegura que la validación esté separada de la ejecución, previniendo que cuentas maliciosas manipulen al bundler.

Paymasters

Los Paymasters son el componente que habilita transacciones sin gas -- la mejora de UX individual más impactante en account abstraction. Un Paymaster es un smart contract que acepta pagar los costos de gas de una UserOperation en nombre del usuario. Cuando una UserOp incluye un campo paymasterAndData, el EntryPoint llama a la función validatePaymasterUserOp del Paymaster para confirmar que patrocinará el gas.

Los modelos de negocio para Paymasters son diversos. Una aplicación puede patrocinar gas para todos los usuarios para eliminar fricción (como las web apps no le cobran a los usuarios por los HTTP requests). Un Paymaster puede aceptar tokens ERC-20 como pago, para que los usuarios paguen gas en USDC o DAI en lugar de ETH. Un Paymaster puede implementar modelos de suscripción, tiers gratuitos o patrocinio condicional basado en el comportamiento del usuario. El insight clave es que el pago de gas se desacopla del usuario completamente -- alguien más puede pagar, y la experiencia del usuario se vuelve indistinguible de una aplicación web tradicional.

Aggregators

Los Aggregators son un componente opcional pero poderoso para escalar. Permiten que múltiples UserOperations que usan el mismo esquema de firmas tengan sus firmas agregadas en una sola prueba compacta. Para firmas BLS, por ejemplo, cientos de firmas individuales pueden combinarse en una, reduciendo dramáticamente los datos on-chain y el costo de gas por UserOp. Aunque no están ampliamente adoptados todavía, los aggregators se vuelven cada vez más importantes a medida que account abstraction escala a millones de usuarios.

Capacidades Clave Desbloqueadas por Account Abstraction

La arquitectura descrita arriba no es solo una refactorización técnica -- habilita experiencias de usuario completamente nuevas que eran previamente imposibles con EOAs.

• Transacciones sin gas: Los Paymasters permiten que las aplicaciones patrocinen gas, dejando que los usuarios interactúen con dApps sin nunca adquirir ETH. Este único cambio elimina la barrera de onboarding más común en crypto.
• Social recovery: En lugar de depender de una seed phrase, los usuarios pueden designar direcciones de guardianes -- amigos, familia o custodios institucionales -- que pueden autorizar colectivamente una rotación de claves si el usuario pierde acceso. Ningún guardián puede actuar solo, y el usuario retiene control total en operación normal.
• Session keys: Las smart accounts pueden emitir claves temporales con permisos limitados que permiten a una aplicación enviar transacciones en nombre del usuario sin requerir una firma para cada una. Una aplicación de gaming puede solicitar una session key válida por 30 minutos con un límite de gasto, habilitando gameplay fluido sin popups constantes de wallet.
• Transacciones en batch: Múltiples operaciones pueden agruparse en una sola transacción atómica. Un usuario de DeFi puede aprobar un token, hacer swap e stakear el resultado en un clic en lugar de tres transacciones separadas, cada una requiriendo confirmación y pago de gas.
• Multi-signature con mejor UX: Las smart accounts pueden requerir que múltiples partes aprueben una transacción mientras presentan una interfaz simple. Las tesorerías corporativas pueden aplicar políticas de aprobación dos de tres, límites de gasto y direcciones whitelisted -- todo impuesto por el contrato de la cuenta mismo.
• Lógica de validación personalizada: Las cuentas pueden usar cualquier método de autenticación -- WebAuthn passkeys (autenticación biométrica via huella digital o Face ID), módulos de seguridad de hardware, aprobaciones con time-lock, restricciones geográficas o cualquier combinación. La cuenta define su propia política de seguridad.

Implementaciones del Mundo Real

Account abstraction no es teórico -- está deployado en mainnet y usado por millones de cuentas en el ecosistema EVM. Han surgido varias implementaciones principales, cada una con un enfoque y público objetivo diferente.

Safe (anteriormente Gnosis Safe) es la wallet de smart contracts más probada en batalla, asegurando más de USD 100 mil millones en activos. Originalmente diseñada para wallets multi-signature, Safe adoptó compatibilidad con ERC-4337, permitiendo que su arquitectura modular se integre con bundlers y paymasters. El sistema de módulos de Safe permite a los desarrolladores extender la funcionalidad de la wallet agregando módulos para social recovery, políticas de gasto, estrategias automatizadas de DeFi y más -- todo sin modificar el contrato core de la wallet.

ZeroDev provee un SDK orientado a desarrolladores construido sobre la Kernel smart account, una cuenta ERC-4337 liviana y modular. La arquitectura kernel de ZeroDev usa validators (para verificación de firmas personalizada), executors (para lógica de transacciones extendida) y hooks (para checks pre/post ejecución). Su SDK abstrae la complejidad de UserOps, bundlers y paymasters en llamadas API simples, haciendo directo para los desarrolladores integrar account abstraction en aplicaciones existentes.

Biconomy ofrece una plataforma de account abstraction full-stack con su Nexus smart account, infraestructura de bundler y servicio de Paymaster. Su SDK soporta session keys, transacciones en batch y operaciones cross-chain out of the box. Biconomy se ha enfocado fuertemente en la experiencia del desarrollador, proporcionando React hooks drop-in y un dashboard para administrar políticas de patrocinio de gas.

El Account Kit de Alchemy provee una capa de infraestructura end-to-end que combina una implementación de smart account (Modular Account), un bundler de alto rendimiento (Rundler, escrito en Rust) y APIs de gas manager. Su solución de embedded wallet integra login por email y redes sociales con smart accounts, creando una experiencia de onboarding donde los usuarios crean una cuenta blockchain usando sus credenciales de Google sin nunca ver una seed phrase o un fee de gas.

ERC-7702 y el Upgrade Pectra: Account Abstraction Nativo

Mientras ERC-4337 logra account abstraction en la capa de aplicación, ERC-7702 -- incluido en el upgrade Pectra de Ethereum -- trae account abstraction nativo al nivel del protocolo. Propuesto por Vitalik Buterin y Sam Wilson, ERC-7702 introduce un nuevo tipo de transacción que permite a una EOA delegar temporalmente su lógica de ejecución a un smart contract por la duración de una transacción.

El mecanismo es elegantemente simple. Un nuevo tipo de transacción incluye una authorization list -- un conjunto de pares (dirección de contrato, firma). Cuando la transacción se procesa, el campo de código de la EOA se setea temporalmente a un delegation designator apuntando al contrato especificado. Para esa transacción, la EOA se comporta como si fuera un smart contract, ganando acceso a ejecución en batch, gas patrocinado y lógica de validación personalizada. Después de que la transacción se completa, la delegación persiste hasta ser explícitamente revocada.

Esto es significativo porque resuelve el problema de migración. Con ERC-4337, los usuarios deben deployar una nueva smart contract account y migrar sus activos desde su EOA existente -- un punto de fricción que ha frenado la adopción. ERC-7702 permite que las EOAs existentes ganen capacidades de smart account in place, sin mover fondos ni cambiar direcciones. Los miles de millones de dólares en EOAs a través de Ethereum pueden ser upgradeados sin una sola transferencia.

ERC-7702 y ERC-4337 son complementarios, no competidores. ERC-7702 maneja el upgrade de cuenta a nivel de protocolo, mientras que la infraestructura de ERC-4337 -- bundlers, paymasters y el mempool de UserOperations -- continúa proporcionando la capa de coordinación off-chain. Juntos, crean un stack completo de account abstraction que funciona tanto para smart accounts nuevas como para EOAs upgradeadas.

Impacto a Través de Sectores

El impacto de account abstraction se extiende mucho más allá de una mejor UX de wallet. Cambia fundamentalmente lo que es posible en cada sector que toca blockchain.

DeFi: Composabilidad en Un Clic

En DeFi, account abstraction habilita swaps en un clic que combinan la aprobación de tokens y la ejecución en una sola transacción. Estrategias de yield farming que requieren múltiples operaciones secuenciales -- depositar, stakear, reclamar rewards, reinvertir -- pueden agruparse en un clic. El rebalanceo automatizado de portfolio puede delegarse a una session key con límites de gasto estrictos, eliminando la necesidad de que el usuario apruebe manualmente cada rebalanceo. Y los Paymasters pueden aceptar el token que se está tradeando como pago de gas, para que un usuario haciendo swap de USDC a WBTC pague el fee de gas en USDC en lugar de necesitar ETH.

Gaming: Blockchain Invisible

Para gaming en blockchain, account abstraction hace que la blockchain sea invisible para el jugador. Las session keys permiten que un juego envíe transacciones -- mover personajes, craftear ítems, completar quests -- sin un popup de wallet en cada acción. El juego solicita una session key al login con un límite de tiempo y tope de gasto, y el jugador interactúa como lo haría con cualquier juego tradicional. El gas es patrocinado por el desarrollador del juego a través de un Paymaster, así que el jugador nunca piensa en ETH. La blockchain se convierte en infraestructura, no en interfaz.

Enterprise: Wallets con Políticas Enforceadas

La adopción empresarial de blockchain se ha visto obstaculizada por la falta de controles de acceso y funcionalidades de compliance en las EOAs. Account abstraction resuelve esto directamente. Una tesorería corporativa puede implementar una smart account con control de acceso basado en roles -- personal junior puede iniciar transferencias hasta un límite, personal senior puede aprobar montos mayores y el CFO puede autorizar cualquier cosa. Direcciones de destino whitelisted previenen transferencias no autorizadas. Operaciones con time-lock agregan un período de revisión antes de que se ejecuten transacciones grandes. Estos no son controles a nivel de aplicación que pueden bypassearse -- están impuestos por el contrato de la cuenta mismo, on-chain e inmutable.

Consideraciones de Seguridad

Las wallets de smart contracts introducen un modelo de seguridad diferente al de las EOAs, y los equipos que construyen con account abstraction deben entender los tradeoffs.

El riesgo del smart contract es la preocupación más fundamental. La seguridad de una EOA depende solo de la clave privada -- el algoritmo ECDSA es bien entendido y no tiene vulnerabilidades conocidas. La seguridad de una smart contract account depende de la corrección de su código. Un bug en el contrato de la wallet, sus módulos o su mecanismo de upgrade podría comprometer cada cuenta que use esa implementación. Es por esto que se prefieren fuertemente implementaciones probadas en batalla como Safe, que ha asegurado más de USD 100 mil millones sin un exploit a nivel de contrato, sobre implementaciones personalizadas.

Los mecanismos de upgrade requieren diseño cuidadoso. La mayoría de las implementaciones de smart accounts soportan upgrades para que se puedan agregar nuevas funcionalidades y corregir bugs. Sin embargo, un path de upgrade sin restricciones significa que quien controle la autoridad de upgrade puede reemplazar la lógica de la wallet completamente. Las mejores prácticas incluyen upgrades con time-lock (dando a los usuarios tiempo para salir antes de que los cambios tomen efecto), upgrades controlados por governance y la opción para que los usuarios opten por no upgradearse congelando la implementación de su cuenta.

La gestión de guardianes para social recovery debe pensarse cuidadosamente. Los guardianes deben ser diversos -- no todos de la misma plataforma o región geográfica. El umbral para recovery debe ser lo suficientemente alto para prevenir colusión pero lo suficientemente bajo para seguir siendo práctico. La rotación de guardianes debe ser directa, y debe haber un time delay en las acciones de recovery para dar al propietario legítimo tiempo de intervenir si un atacante compromete un subconjunto de guardianes.

• Usá implementaciones de smart accounts establecidas y auditadas en lugar de construir contratos de wallet personalizados
• Implementá upgrades con time-lock con un período mínimo de delay que les dé a los usuarios la capacidad de revisar y salir
• Diseñá conjuntos de guardianes con diversidad en mente -- diferentes dispositivos, plataformas, ubicaciones geográficas y relaciones de confianza
• Seteá los permisos de session keys al alcance mínimo requerido y la duración práctica más corta
• Monitoreá patrones inusuales en el comportamiento del bundler y el consumo de gas del paymaster
• Realizá auditorías de seguridad regulares de cualquier módulo personalizado o lógica de validación agregada a la cuenta base

Construyendo con Account Abstraction Hoy

Para equipos de desarrollo listos para integrar account abstraction, el ecosistema ofrece tooling e infraestructura maduros. La elección de SDK y proveedor de infraestructura depende de las necesidades específicas de tu aplicación -- ya sea que priorices modularidad, experiencia del desarrollador o control de infraestructura.

Empezá eligiendo una implementación de smart account. La arquitectura modular de Safe es ideal para aplicaciones que necesitan multi-sig, permisos complejos o módulos componibles. La Kernel account de ZeroDev es liviana y altamente personalizable, haciéndola una opción fuerte para aplicaciones con requisitos específicos de lógica de validación. La Nexus de Biconomy y la Modular Account de Alchemy proveen soluciones opinionadas y full-stack que minimizan la complejidad de integración.

Después, seleccioná tu infraestructura de bundler. Podés correr tu propio bundler para máximo control, o usar servicios hosteados de Alchemy, Pimlico, Stackup o Biconomy. Para desarrollo y testing, los bundlers locales como los provistos por la implementación de referencia de Infinitism te permiten desarrollar y testear flujos de UserOp sin depender de servicios externos.

Configurá tu estrategia de Paymaster basada en tu modelo de negocio. Patrocinar todo el gas durante la beta o para usuarios nuevos reduce la fricción de onboarding dramáticamente. Aceptar tokens ERC-20 como pago de gas permite que los power users paguen en su token preferido. Patrocinio condicional -- patrocinar gas para acciones específicas pero no para otras -- te da control granular sobre tu presupuesto de subsidio.

• Usá permissionless.js o los módulos de account abstraction de viem para desarrollo TypeScript-first con control granular sobre la construcción de UserOps
• Aprovechá el aa-sdk de Alchemy o el SDK de Biconomy para abstracciones de nivel superior que manejan la comunicación con bundlers y la integración con paymasters automáticamente
• Testeá en Sepolia u otras testnets donde el EntryPoint está deployado y los servicios de bundler están disponibles
• Implementá ERC-4337 incrementalmente -- empezá con transacciones sin gas via Paymasters, luego agregá session keys y batching a medida que las necesidades de tus usuarios evolucionen
• Monitoreá el rollout de ERC-7702 y planificá tu estrategia de migración para que los usuarios EOA existentes puedan upgradear in place una vez que Pectra se active
• Usá herramientas como userop.js, el Bundler test suite y los métodos de simulación del EntryPoint para validar UserOps localmente antes de enviarlas a un bundler en vivo

El Camino Hacia Adelante

Account abstraction representa un cambio fundamental en cómo los usuarios interactúan con blockchain. La combinación de la infraestructura de capa de aplicación de ERC-4337 y los upgrades de EOA a nivel de protocolo de ERC-7702 crea un camino claro hacia un futuro donde las cuentas blockchain son tan flexibles y amigables como las cuentas en cualquier sistema de software tradicional -- pero con la auto-custodia y la resistencia a la censura que hacen valiosa a blockchain en primer lugar.

La tecnología está lista para producción hoy. Wallets principales, proveedores de infraestructura y aplicaciones han adoptado ERC-4337. Redes L2 como Base, Arbitrum y Optimism ven millones de transacciones de smart accounts mensualmente. El tooling es maduro, los estándares son estables y el track record de seguridad está creciendo. Para equipos de desarrollo construyendo aplicaciones blockchain, ya no hay razón para forzar a los usuarios a pasar por la experiencia EOA. Account abstraction es cómo crypto se vuelve usable para todos.

En Xcapit, nuestro equipo de desarrollo blockchain tiene profunda experiencia construyendo smart contract wallets, protocolos DeFi e infraestructura Web3. Ya sea que estés integrando ERC-4337 en una aplicación existente, diseñando un nuevo producto con account abstraction desde el día uno, o planificando tu estrategia de migración a ERC-7702, podemos ayudarte a navegar las decisiones de arquitectura y entregar una implementación lista para producción. Conocé más sobre nuestros servicios de desarrollo blockchain.