Qué es un paymaster y cómo funciona el patrocinio de gas (ERC-4337 y EIP-7702)
Qué es un paymaster, cómo ERC-4337 y EIP-7702 resuelven el gas de formas distintas, y por qué el segundo evita que tus usuarios cambien de cartera.
Qué es un paymaster
Un paymaster es el componente que paga la comisión de red en lugar de quien firma la transacción. El término viene del trabajo de account abstraction de Ethereum, pero resuelve un problema que conoce cualquier producto Web3: para hacer algo on-chain, el usuario necesita tener la moneda nativa de la red — ETH en Ethereum, BNB en BNB Chain, POL en Polygon. Quien recién llega no la tiene, y a menudo no entiende por qué la necesitaría.
Un paymaster invierte esa relación. El usuario firma la intención; otro cubre el costo. Conviene ser preciso: el gas no desaparece. La red sigue cobrándolo y alguien sigue pagándolo — el patrocinador. Lo que cambia es quién paga, y cuándo.
El problema, en el orden correcto
Aquí se confunden dos cosas.
La primera es el costo. En una red como BNB Chain o Polygon, una transferencia de token cuesta centavos. Para la mayoría de los productos, el costo del gas nunca fue el obstáculo real.
La segunda es la adquisición. Para pagar esos centavos, el usuario tiene que comprar la moneda nativa en algún exchange, pasar verificación de identidad, retirar a una cartera y elegir la red correcta. Son cinco pasos antes del primer paso. Ahí muere la conversión — no en el precio, sino en el recorrido.
El paymaster resuelve el segundo problema, no el primero. Quien patrocina absorbe un costo que ya era pequeño y elimina un recorrido que era caro en abandono.
ERC-4337: el diseño original
ERC-4337 introdujo account abstraction sin cambiar el protocolo de Ethereum. En lugar de transacciones comunes, el usuario emite una UserOperation, una estructura que describe qué quiere hacer y quién paga por ello.
Intervienen cuatro roles:
- Smart Account — la cuenta del usuario deja de ser una clave y pasa a ser un contrato capaz de definir sus propias reglas de validación.
- Bundler — agrupa UserOperations y las envía como una transacción normal.
- EntryPoint — el contrato singleton que valida y ejecuta cada operación del lote.
- Paymaster — el contrato que se compromete a pagar. Implementa `validatePaymasterUserOp`, donde decide si banca esa operación, y `postOp`, llamado tras la ejecución para ajustar cuentas.
Para operar, un paymaster debe mantener depósito y stake en el EntryPoint — la garantía económica de que no aceptará operaciones dejando la cuenta al bundler. La implementación de referencia está en el repositorio account-abstraction de eth-infinitism.
El diseño es potente y habilita cosas que una cuenta común no hace: recuperación social, límites de gasto, múltiples firmantes, sesiones. Tiene, eso sí, una exigencia ineludible: el usuario necesita una smart account. Quien ya tiene cartera debe crear otra cuenta, con otra dirección, y mover los fondos allí. Para un producto que busca reducir fricción, esa migración es fricción nueva.
EIP-7702: la cuenta común gana superpoderes
EIP-7702 resuelve justamente eso. Define un tipo nuevo de transacción que lleva una lista de autorizaciones: con ella, una cuenta común (EOA) apunta a un contrato y empieza a comportarse como él, conservando la misma dirección y la misma clave.
En la práctica el código de la cuenta pasa a ser un pequeño indicador de delegación que apunta al contrato elegido. Toda llamada a esa cuenta ejecuta la lógica del contrato delegado. La autorización la firma el propio titular, y puede revocarse.
La consecuencia de producto es directa: el usuario no cambia de cartera. La dirección que ya compartió sigue valiendo, su historial sigue en su lugar, la cartera que ya usa sigue funcionando — y aun así gana la capacidad de transaccionar sin tener la moneda nativa.
Comparando ambos
| ERC-4337 | EIP-7702 | |
|---|---|---|
| Cuenta del usuario | una smart account nueva | la misma EOA que ya tiene |
| Dirección | cambia | se preserva |
| Migración | obligatoria | ninguna |
| Infraestructura | bundler + EntryPoint + paymaster | contrato delegado + patrocinador |
| Fortaleza | reglas de cuenta muy ricas | adopción sin fricción |
No son excluyentes: una cuenta delegada por 7702 puede participar del flujo de 4337. La elección es de ingeniería de producto y depende de dónde está tu fricción. Si el valor central es recuperación social y política de firma, 4337 entrega más. Si el valor central es no pedirle nada al usuario, 7702 entrega más.
Por eso VKX Gas usa el modelo EIP-7702: el servicio existe para quitar el paso del gas, y sería contradictorio quitarlo cobrando a cambio una migración de cartera.
Cómo funciona el patrocinio en la práctica
El modelo es prepago. Mantienes un depósito en moneda nativa, y un único depósito cubre las redes EVM atendidas — hoy BSC, Polygon, Base, Arbitrum y Ethereum. Cuando tu usuario va a actuar, tu backend pide el patrocinio, VKX devuelve los datos firmados, el usuario firma su propia operación y la transacción sigue. Se te cobra de tu saldo por el gas real consumido, y parte vuelve como crédito de cashback aplicado a transacciones posteriores.
npm install @vkx/gas
La integración vive en tu servidor, porque ahí corresponde tu clave. El panel de gas muestra saldo, consumo por red e historial.
Ventajas y limitaciones
Lo que entrega el patrocinio de gas:
- Elimina el prerrequisito de moneda nativa, la mayor causa de abandono en flujos on-chain para público no técnico.
- Preserva la autocustodia: el usuario sigue firmando. Patrocinar gas no es custodiar fondos.
- Vuelve el costo predecible para ti — el gas pasa a ser una línea de costo de adquisición, no un obstáculo de producto.
Lo que no entrega, y conviene decirlo con claridad:
- No es gratis. El costo existe y es tuyo. En redes de bajo costo es trivial; en Ethereum con congestión no lo es — conviene medir antes de patrocinar todo.
- No previene el abuso por sí solo. Si cualquiera puede disparar operaciones patrocinadas, alguien lo hará. Los límites por usuario, por operación y por ventana de tiempo son parte del diseño, no un extra opcional.
- No reemplaza la moneda nativa en todos los casos. Las operaciones que dependen de valor nativo (enviar ETH, por ejemplo) siguen requiriendo saldo.
Cuándo tiene sentido
Tiene sentido cuando "necesitas gas" es la frase que hace abandonar a tu usuario. Aparece en mints de NFT e ítems de juego, en el canje de recompensas de fidelidad, en pagos con stablecoin y en cualquier onboarding cuya primera acción del usuario sea on-chain.
No tiene sentido cuando tu audiencia ya opera on-chain con soltura y ya mantiene saldo nativo. Ahí el patrocinio resuelve un problema que no tienen.
Preguntas frecuentes
¿Un paymaster es lo mismo que una cartera custodial? No. Custodia significa que alguien más guarda la clave del usuario. En el patrocinio de gas la clave queda exclusivamente con el usuario — el patrocinador paga la comisión, no firma en su nombre.
¿El usuario nota el patrocinio? Nota que la transacción se completó sin pedirle saldo nativo. Nada más cambia.
¿Necesito un depósito por red? No. Un único depósito en moneda nativa cubre las redes EVM atendidas.
¿EIP-7702 funciona en cualquier red? Funciona en las redes que adoptaron la especificación. La lista vigente de redes atendidas está en la página del producto.
¿Cómo es el precio? Pagas el gas real consumido, sin recargo, y parte vuelve como crédito. En redes como BNB Chain eso significa centavos por transacción.
Siguiente paso
Si el gas es lo que separa a tu usuario de su primera acción, mira cómo implementar el patrocinio o habla con la ingeniería desde la página de VKX Gas.
Aviso: este contenido tiene carácter informativo y educativo y no constituye recomendación de inversión.