Bundlers y UserOperations: cómo funcionan las transacciones ERC-4337

Una UserOperation es el objeto de intención firmado que define ERC-4337: declara qué quiere hacer una cuenta de smart contract y cómo debe validarse y pagarse esa acción. A diferencia de una transacción ordinaria de Ethereum, no es un objeto a nivel de protocolo firmado por una cuenta de propiedad externa: su firma la comprueba el propio contrato de la cuenta, y no tiene por qué pagar su propio gas nativo. Un bundler es el actor off-chain que recopila UserOperations de una mempool alternativa dedicada, simula cada una, empaqueta las válidas en una única transacción ordinaria de Ethereum y llama al contrato canónico EntryPoint — que valida todas las operaciones del lote antes de ejecutar ninguna de ellas. El bundler adelanta el gas real desde su propia EOA y recibe el reembolso on-chain de la cuenta remitente o del paymaster de esa cuenta. Un contrato paymaster opcional puede aceptar cubrir una operación durante ese paso de validación, y ahí es donde las comisiones pasan a estar patrocinadas o a poder pagarse en un token ERC-20 en lugar del token de gas nativo de la cadena.

Un repaso rápido de ERC-4337

ERC-4337 es el estándar de Ethereum para la abstracción de cuentas — una forma de dar a las cuentas de smart contract la misma capacidad de primera clase para iniciar y pagar acciones que las cuentas de propiedad externa (EOA) siempre han tenido, sin ningún cambio en el protocolo base. En lugar de modificar la capa de consenso, ERC-4337 introduce un sistema paralelo de objetos de alto nivel e infraestructura off-chain que finalmente se liquida mediante transacciones ordinarias de Ethereum. Si prefieres primero la versión desde cero, nuestra explicación sobre qué es la abstracción de cuentas cubre la motivación, qué es ERC-4337 traza el estándar completo y cuentas inteligentes frente a EOA compara directamente los dos tipos de cuenta. Este artículo hace zoom en la mecánica: los objetos que se mueven por el sistema y los actores que los procesan. Ten en cuenta que ERC-4337 es un estándar de EVM — aplica a Ethereum y cadenas compatibles con EVM, no a cadenas no EVM como Solana o TON.

Qué es realmente una UserOperation

El objeto central en ERC-4337 es la UserOperation. Superficialmente parece una transacción, pero se entiende mejor como una declaración de intención firmada: "esto es lo que mi cuenta quiere que se haga, y estos son los parámetros para validarlo y pagarlo." Es un struct que se pasa como calldata a un contrato, no un objeto nativo del protocolo — la capa base nunca ha oído hablar de él.

Una UserOperation lleva, en esencia:

• sender — la cuenta de smart contract en cuyo nombre actúa la operación.
• nonce — protección contra repetición, que el EntryPoint registra como un valor de dos partes (una clave más una secuencia), de modo que una cuenta puede mantener varios carriles de nonce independientes en vez de una única cola estricta.
• callData — lo que la cuenta debe ejecutar, con frecuencia un lote de varias llamadas en una sola operación.
• datos de despliegue de la cuenta — opcional; despliega el contrato de la cuenta en su primerísima operación, que es cómo una cuenta inteligente puede recibir fondos en una dirección conocida y derivada de forma determinista antes de existir on-chain.
• límites de gas — presupuestos separados para la validación y la ejecución, más una cifra de preVerificationGas que compensa al bundler por el calldata y la sobrecarga que el EntryPoint no puede medir por sí mismo.
• parámetros de comisión — una comisión máxima y una comisión de prioridad máxima, reflejando EIP-1559.
• datos del paymaster — opcional; qué contrato patrocinará la operación y cualquier contexto que necesite.
• firma — comprobada por la propia función de validación de la cuenta, no por el protocolo.

La codificación exacta ha cambiado entre versiones del EntryPoint — la v0.7 divide los blobs de despliegue y de paymaster en campos explícitos y empaqueta juntos varios valores de gas, mientras que la v0.6 usaba cadenas de bytes únicas initCode y paymasterAndData — pero el contenido conceptual es el mismo. Si estás integrando, comprueba a qué versión del EntryPoint apunta tu bundler.

La diferencia clave con una transacción normal es quién y qué la firma. Una transacción convencional de Ethereum debe ser firmada por la clave privada de una EOA usando un esquema ECDSA fijo, y esa misma cuenta paga el gas. Una UserOperation es validada por la propia lógica de la cuenta de smart contract del remitente — que puede implementar cualquier esquema de firma, regla multiclave, clave de sesión o política de autorización que la cuenta defina — y no tiene por qué pagarse a sí misma en gas nativo en absoluto. Esa flexibilidad es justo el objetivo: la cuenta, no el protocolo, decide qué aspecto tiene una acción válida.

La mempool alternativa donde viven

Las UserOperations no entran en la mempool normal de transacciones de Ethereum, porque todavía no son transacciones. En su lugar se difunden a una mempool alternativa separada (a menudo llamada alt-mempool) — una red peer-to-peer dedicada a los objetos de ERC-4337. En la práctica, una wallet o una dApp envía una llamando a eth_sendUserOperation en el endpoint RPC de un bundler; ese bundler puede propagarla a la alt-mempool compartida o guardarla en un pool privado propio. En cualquier caso, la infraestructura que consume estos objetos escucha aquí en lugar de en la mempool de la capa base. Esta separación mantiene el tráfico de abstracción de cuentas fuera de la ruta crítica para el consenso hasta el momento en que se empaqueta en una transacción real.

El papel del bundler

Un bundler es el actor off-chain que convierte las intenciones en realidad on-chain. Su trabajo tiene cuatro partes. Primera, recopila UserOperations de la mempool alternativa. Segunda, simula y valida cada una — ejecutando la lógica de validación de la cuenta en un contexto simulado para confirmar que la firma es válida, que el nonce es correcto y que la cuenta o su paymaster pueden cubrir el coste. Tercera, empaqueta una o más UserOperations válidas en una única transacción ordinaria de Ethereum. Cuarta, envía esa transacción a la red desde su propia EOA, pagando por adelantado el gas de la capa base y esperando ser reembolsado on-chain.

La simulación por sí sola no es protección suficiente, porque el estado puede cambiar entre la simulación y la inclusión. Por eso ERC-4337 también limita lo que el código de validación puede hacer: durante la fase de validación, una cuenta o un paymaster no pueden leer marcas de tiempo de bloque ni otros valores del entorno que les permitirían comportarse de forma distinta on-chain y en simulación, y su acceso a almacenamiento se restringe en gran medida a los slots asociados a su propia cuenta. De los contratos que actúan en nombre de muchos usuarios — sobre todo las factories y los paymasters — se espera que depositen un stake, de modo que un único contrato que se porte mal no pueda invalidar barato una porción grande de la mempool de golpe. Estas reglas existen por una razón: hacer que la simulación de un bundler sea una predicción fiable de lo que ocurrirá on-chain.

Como el bundler adelanta el gas y gana comisiones por la inclusión, se comporta muy parecido a un constructor de bloques especializado para el tráfico de abstracción de cuentas. Su paso de simulación y validación es lo que lo protege: no empaquetará una operación que no lograra reembolsarlo.

El contrato EntryPoint

Todo converge en un único y canónico smart contract llamado EntryPoint. Es un singleton, desplegado por versión en la misma dirección en todas las cadenas EVM, y custodia los depósitos que pagan las operaciones. La transacción del bundler es una llamada al EntryPoint con un array de UserOperations, y el EntryPoint entonces ejecuta un estricto bucle de dos fases.

En la fase de validación, para cada operación llama a la función de validación de la cuenta remitente (y a la del paymaster, si se especifica uno) para volver a comprobar on-chain la firma, el nonce y el acuerdo de pago, y reserva el coste máximo posible a quien vaya a pagar. Solo después de que todas las operaciones del lote hayan sido validadas pasa a la fase de ejecución, donde despacha el calldata de cada operación a su cuenta para realizar efectivamente la transferencia, el swap u otra acción, y luego liquida el coste real y devuelve la reserva no utilizada.

Esta división importa: la validación y la ejecución se separan para que las garantías de pago de un lote se establezcan antes de que corra cualquier trabajo que cambie el estado, y para que el EntryPoint pueda contabilizar el gas con precisión a través de muchas operaciones a la vez. También significa que el fallo de una operación durante la ejecución no puede contaminar a las demás del lote.

Dónde encaja el paymaster

Un paymaster es un contrato opcional que acepta pagar por una UserOperation en nombre de la cuenta. Cuando una UserOperation incluye datos de paymaster, el EntryPoint pregunta a ese paymaster, durante la fase de validación, si patrocinará la operación y bajo qué términos; el paymaster devuelve una decisión más un blob de contexto. Tras la ejecución, el EntryPoint vuelve a llamar al paymaster en un paso posterior a la operación con el gas realmente consumido, y ahí es donde un paymaster que cobra en token liquida la cantidad exacta. El paymaster puede aceptar incondicionalmente (patrocinio verdaderamente sin gas, en el que una app absorbe el coste), o puede aceptar a cambio de valor — lo más útil, cobrando al usuario en un token ERC-20 en lugar de gas nativo. Para una mirada más profunda a este componente, consulta qué es un paymaster. El paymaster es el enganche del flujo que desacopla "con qué paga el usuario" de "con qué se paga a la red."

Cómo se gestionan el gas y los fallos

El gas en ERC-4337 está en capas. El bundler paga ETH real por la transacción externa; el EntryPoint mide el gas de validación y ejecución de cada UserOperation contra los límites que declaró; y quienquiera que sea el responsable — la cuenta o su paymaster — debe haber depositado en el EntryPoint lo suficiente para cubrir la factura, que se liquida al final del lote. Una consecuencia que conviene conocer: una operación ERC-4337 cuesta algo más de gas que la transacción simple equivalente, porque estás pagando la validación a nivel de contrato y la contabilidad del EntryPoint además de la acción en sí.

Los fallos se contienen gracias al diseño de validación primero. Si una operación falla durante la validación on-chain, todo el lote revertiría, así que el bundler la descarta y reconstruye el lote en lugar de dejar que eso ocurra — que es exactamente para lo que sirve su simulación off-chain. Si una operación pasa la validación pero su ejecución revierte, los efectos de la ejecución se deshacen mientras el gas ya gastado sigue contabilizándose y pagándose, así que el bundler no queda sin compensar por un trabajo honesto. Esta asimetría es la razón por la que los bundlers simulan con tanto cuidado: su protección contra el griefing es negarse a incluir cualquier cosa que no fuera a reembolsarles.

El ciclo de vida, en orden

1. Tu wallet construye una UserOperation: sender, nonce, calldata, límites de gas, parámetros de comisión, datos opcionales de paymaster.
2. Un paymaster, si se usa, da el visto bueno a las condiciones de patrocinio antes de difundir la operación.
3. La lógica de firma de tu cuenta la firma — y no tiene por qué ser una única clave ECDSA.
4. La wallet la envía al RPC de un bundler, y entra en la mempool alternativa.
5. El bundler la simula y la valida bajo las reglas de opcodes restringidos y almacenamiento del estándar.
6. El bundler la empaqueta con otras operaciones en una transacción de Ethereum que llama a handleOps en el EntryPoint, y paga el gas de la capa base.
7. El EntryPoint valida todas las operaciones, ejecuta el calldata de cada una, liquida los costes contra los depósitos, devuelve el excedente y reembolsa al bundler.

Qué gana con esto quien usa una wallet

La maquinaria es elaborada, pero su objetivo es prosaico y útil: agrupar varias acciones en una sola confirmación (aprobar y hacer swap a la vez, por ejemplo), comisiones patrocinadas o pagadas en token, esquemas de firma distintos de una única clave secp256k1, políticas de gasto y claves de sesión, y recuperación social o basada en dispositivo. Vale la pena señalar que EIP-7702 permite que una EOA ordinaria ejecute temporalmente con código de cuenta inteligente, lo que acorta la distancia en algunas de estas funciones sin sustituir la infraestructura ERC-4337 descrita arriba.

Cómo usa WATS esto

En cadenas EVM, WATS depende de exactamente una pieza de este flujo: la ranura del paymaster. Cuando haces una transferencia, un swap o staking en la Hot Wallet de WATS, la UserOperation que construye tu wallet nombra un paymaster, y ese paymaster es lo que permite que la comisión se cobre en ATS en lugar del token de gas nativo de la cadena — así nunca necesitas mantener un saldo residual de ETH, BNB o POL en cada red solo para poder moverte. No se te pide ejecutar un bundler, elegir una versión del EntryPoint ni tener una clave RPC de bundler; eso es infraestructura, y el trabajo de la wallet es construir una UserOperation válida y enviarla.

Dos aclaraciones mantienen esto honesto. Primera, pagar en ATS no es un descuento — la red sigue cobrando su comisión normal y el paymaster la liquida, así que lo que cambia es qué token sale de tu saldo, no el coste subyacente. Segunda, ERC-4337 es exclusivo de EVM, así que en Solana y TON un acuerdo equivalente de pagador de comisiones desempeña el papel del paymaster en lugar del flujo del EntryPoint descrito aquí. ATS es un OFT de LayerZero, que es lo que permite que un único saldo de ATS cubra las comisiones en Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana y TON, y el ATS cobrado se quema, llevando el suministro de 100.000.000 hacia un piso de 30.000.000. WATS es totalmente no custodial de principio a fin: tú tienes tus claves, y WATS nunca tiene ninguna.

Si quieres ver este flujo como un sistema en funcionamiento y no como una especificación, el paso concreto es probar una transferencia en la Hot Wallet de WATS en una cadena donde no tengas nada del token de gas nativo: la UserOperation, el bundler y el EntryPoint hacen su trabajo fuera de la vista, y la comisión sale de tu saldo de ATS. Cómo funciona el modelo de comisiones ATS cubre la mecánica de principio a fin.