Quién paga el gas de tu agente: auditoría on-chain de Circle Paymaster

Un agente que solo tiene stablecoins igual necesita gas para moverse. Hay dos formas de resolverlo, y cada una entrega la decisión del fee a una parte muy distinta. Medimos una de ellas durante veinticuatro horas en siete cadenas.

El camino de x402 es el que más hemos cubierto: el pagador firma una autorización EIP-3009, el facilitator envía la transacción y absorbe el gas. El agente nunca tiene token nativo. Explicamos ese primitivo en settlement gasless con stablecoins.

El otro camino es el que un agente necesita apenas quiere hacer algo que no sea un pago x402: aprobar un router, recargar un canal, desplegar su propia cuenta, mover fondos entre sus direcciones. Para eso alguien tiene que pagar gas en el token nativo de la cadena, y un agente fondeado en USDC no lo tiene.

Circle Paymaster es la respuesta permissionless: un contrato paymaster ERC-4337 que paga el fee de red desde su propio deposit y le cobra a la smart account en USDC. Sin API key, sin cuenta de Circle, sin dependencia off-chain. Para una wallet de agente, esa es exactamente la forma que uno quiere.

También mete la decisión del fee dentro del payload que el agente firma. Así que lo auditamos: cada deployment de mainnet, y después un día completo de tráfico real.

Qué es el contrato

Circle publica dos deployments. Paymaster v0.7 (0x6C973eBe80dCD8660841D4356bf15c32460271C9) sirve al EntryPoint v0.7 en Arbitrum y Base. Paymaster v0.8 (0x0578cFB241215b77442a541325d6A4E6dFE700Ec) sirve al EntryPoint v0.8 en Arbitrum, Avalanche, Base, Ethereum, Optimism, Polygon y Unichain. Las direcciones y el esquema de eventos están en la página de addresses and events.

Verificamos los deployments en vez de confiar en la tabla. En las siete mainnets la dirección v0.8 tiene el mismo runtime de proxy de 141 bytes, byte por byte: un proxy ERC-1967 mínimo que lee el slot estándar de implementación. Cada cadena apunta a su propia implementación de 16.671 bytes; el largo del código es idéntico en todas y solo cambian los immutables, que es lo esperable de un mismo contrato compilado y desplegado con constantes por cadena. El proxy v0.7 tiene 144 bytes sobre una implementación de 16.886.

Llamando a través del proxy, entryPoint() devuelve 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108 y token() devuelve el USDC canónico de la cadena. En Base, getDepositInfo reporta al paymaster con stake de 0,25 ETH y unstake delay de 86.400 segundos: el stake de reputación de ERC-4337, no el presupuesto de gas. El presupuesto de gas es el deposit, y ahí es donde esta auditoría se pone interesante.

El modelo de cobro es permit más prefund más refund. Según el quickstart, la cuenta firma un permit EIP-2612 que le da allowance al paymaster y lo empaqueta en paymasterData:

// Quickstart de Circle Paymaster, getPaymasterData()
const permitAmount = 10000000n;  // 10 USDC

const paymasterData = encodePacked(
  ["uint8", "address", "uint256", "bytes"],
  [0, usdcAddress, permitAmount, permitSignature],
);

El deadline del permit es MAX_UINT256, y el quickstart explica por qué: "The paymaster cannot access block.timestamp due to 4337 opcode restrictions, so the deadline must be MAX_UINT256." El allowance que firma un agente acá no expira. Su único límite es el value.

En validación el paymaster cobra un prefund de la cuenta. Después de ejecutar, _postOp devuelve el excedente y emite UserOperationSponsored con token, sender, hash de la user op, nativeTokenPrice (unidades de token por 1e18 wei), actualTokenNeeded y feeTokenAmount. Verificamos la identidad sobre una operación viva: el sender 0xf68da023… transfirió 0,065317 USDC, recibió de vuelta 0,046015 USDC, y el evento reportó actualTokenNeeded = 0,019302 USDC. Prefund menos refund es exactamente el cobro.

Método

Recolectamos todos los eventos UserOperationSponsored de ambos paymasters en una ventana de 24 horas, del 2026-08-29 09:06:47Z al 2026-08-30 09:06:47Z (bloques 50602530 a 50645730 de Base; las demás cadenas alineadas con minutos de diferencia). Para los mismos rangos recolectamos el UserOperationEvent del propio EntryPoint filtrando por el paymaster —el tercer topic indexado—, que da actualGasCost y actualGasUsed por operación. Después bajamos el receipt de cada transacción de bundle para saber cuánto costó realmente incluirla, fee de datos de L1 incluido.

Nueve superficies, 4.853 operaciones patrocinadas, cero fallas. RPCs públicos en todo; precios contrastados contra spot de Coinbase y Kraken al momento de medir.

cadena / entrypoint   ops    USDC cobrado   nativo facturado   cobrado/facturado
base       v0.8       643      35.765,92    16,910122 ETH          0,861
base       v0.7       528      24.544,60    11,445303 ETH          0,873
arbitrum   v0.8       672      34.238,55    16,207886 ETH          0,860
arbitrum   v0.7       520      16.931,46     8,342903 ETH          0,826
ethereum   v0.8       597      33.540,57    15,876323 ETH          0,860
optimism   v0.8       623      34.080,19    16,096663 ETH          0,862
polygon    v0.8       709      12.420,68   138.220,93 POL          0,867
avalanche  v0.8       440       7.788,70     1.249,11 AVAX         0,855
unichain   v0.8       121       2.996,24     1,415386 ETH          0,862
                    -----   ------------                          ------
total               4.853     202.306,90                           0,859

El precio cotizado es honesto. En Base el nativeTokenPrice promedio del paymaster en la ventana fue 2.456,46 USDC por ETH contra un spot de Coinbase de 2.456,93 y un último de Kraken de 2.456,78: dos centésimas de punto porcentual de diferencia. AVAX cotizó 7,2948 contra 7,3425 spot, POL 0,10368 contra 0,10343. Sea lo que sea que pasa acá, nadie está marcando el oráculo.

Hallazgo 1: el precio del gas lo fija la user operation

Divide actualGasCost por actualGasUsed y obtienes el precio de gas que pagó cada operación. En Base ese promedio es 224,6 gwei. La mediana del base fee de Base en la misma ventana fue 0,005 gwei.

El patrón se repite en todas: 253,0 gwei en Ethereum contra un base fee de 0,0448 gwei, 237,9 gwei en Arbitrum contra 0,0200, 1.915.500 gwei en Polygon contra 248,8, 27.551 gwei en Avalanche contra 0,0513.

La forma más limpia de decirlo es a nivel transacción, porque no necesita supuestos sobre el costo de datos de L1. Para cada bundle de la ventana sumamos lo que el EntryPoint le facturó al paymaster y lo que costó incluir la transacción:

cadena / entrypoint  bundles  facturado       costo real tx     múltiplo
base       v0.8          51   16,910122 ETH   0,00923899 ETH     1.830x
base       v0.7          45   11,445303 ETH   0,00807076 ETH     1.418x
arbitrum   v0.8          41   16,207886 ETH   0,00403213 ETH     4.020x
arbitrum   v0.7          19    8,342903 ETH   0,00192193 ETH     4.341x
ethereum   v0.8          30   15,876323 ETH   0,05830830 ETH       272x
optimism   v0.8          28   16,096663 ETH   0,00927545 ETH     1.735x
polygon    v0.8          16  138.220,93 POL      750,56 POL         184x
avalanche  v0.8          16    1.249,11 AVAX      7,65 AVAX         163x
unichain   v0.8           7    1,415386 ETH   0,00065332 ETH     2.166x

En las nueve superficies: 202.307 USDC cobrados a smart accounts contra 358,43 dólares de fees reales de cadena. Un factor de 564.

Esto no es un bug del paymaster. Es ERC-4337 funcionando como está diseñado. El precio de gas que paga una operación es min(maxFeePerGas, maxPriorityFeePerGas + baseFee), y esos campos viven dentro de la user operation. Quien arma la operación fija el precio; la diferencia entre ese precio y el del bloque la cobra el bundler como beneficiary de handleOps. Cuando el fee está denominado en el USDC de la cuenta, esa diferencia también.

Hallazgo 2: a la cuenta le cobran 0,86 de lo que factura el EntryPoint

La razón entre lo que la cuenta paga en USDC y el valor de lo que factura el EntryPoint, al propio precio cotizado por el paymaster, cae en una banda estrecha: 0,826 a 0,873 en nueve superficies, 0,859 agregado. Es notablemente estable, lo que indica que es mecánica y no de mercado.

El mecanismo se ve en el EntryPoint de referencia. En EntryPoint.sol, UNUSED_GAS_PENALTY_PERCENT = 10 y PENALTY_GAS_THRESHOLD = 40000: una operación que reserva mucho más gas de ejecución o de postOp del que usa paga un diez por ciento del sobrante. El _postOp del paymaster se invoca con el costo calculado antes de sumar el gas de postOp y su penalidad, mientras que el actualGasCost del evento emitido se recalcula después. A la cuenta le cobran el número anterior. El deposit del paymaster paga el posterior.

De ahí salen dos consecuencias. Primero, quien escribe límites de gas gordos en una operación mueve valor real del paymaster al bundler, y el paymaster lo absorbe. Segundo, el surcharge documentado no es observable desde afuera: el overview de Circle dice que hay "a 10% surcharge on gas fees… only applies to Arbitrum and Base (and their testnets)", pero Base está en 0,861 y Arbitrum en 0,860, dentro de la misma banda que Ethereum en 0,860 y Optimism en 0,862, mientras que los dos extremos de la banda son Base v0.7 (0,873) y Arbitrum v0.7 (0,826), ambas cadenas con surcharge. El campo feeTokenAmount, documentado como el spread que cubre el slippage de cambiar USDC por ETH, fue cero en los 4.853 eventos. El surcharge puede estar calculado contra un costo interno; en la razón entre cobro y factura no se ve.

Hallazgo 3: el deposit corre en cero

Los docs de Circle prometen que "ensures that there is always a sufficient amount of native gas token for each supported chain, managing swaps and balances behind-the-scenes". Vimos funcionar esa máquina.

En Base, el deposit del paymaster en el EntryPoint recibió 24 recargas en la ventana, una cada 450 bloques: quince minutos, como reloj. Todas las dispara la misma dirección, 0x6ef7627da1e59fbf48025c52f94084f49a429ff8, llamando al paymaster con value cero: el contrato cambia el USDC cobrado por WETH on-chain y lo deposita. En la ventana esas recargas gastaron 35.367,38 USDC y compraron 14,385970 WETH, una tasa realizada de 2.458,46 USDC por ETH. Spot, otra vez.

El EntryPoint facturó 16,910122 ETH en la misma ventana. La diferencia salió del colchón, y la aritmética cierra exacta:

facturado por el EntryPoint    16,910122 ETH
comprado con el USDC cobrado   14,385970 ETH
                               -------------
drawdown                        2,524152 ETH

deposit al inicio de la ventana 2,524535 ETH
deposit al final de la ventana  0,000382 ETH

Toda superficie de la que pudimos leer estado histórico terminó la ventana con un deposit que redondea a cero: Ethereum 2,478335 a 0,000393 ETH, Optimism 2,432414 a 0,000336, Base v0.7 1,449443 a 0,000168, Unichain 0,386124 a 0,001103, Avalanche 204,160183 a 0,000353 AVAX. Los RPCs públicos de Arbitrum y Polygon no sirvieron estado de archivo, así que esas dos quedan como no medidas en vez de estimadas.

Después de cerrar la ventana siguieron entrando operaciones —23 más en Base en los dieciséis minutos siguientes, con una recarga—, así que esto es un diente de sierra, no una caída. Pero el colchón de trabajo es de unos 0,6 ETH en Base, recargado cada quince minutos por un swap. Esa es una dependencia de liveness que el operador de agentes hereda: si el camino de recarga se traba o el swap slippea, el patrocinio se corta para cuentas que no tienen token nativo, y la falla aparece como error de validación, no como error de pago.

Hallazgo 4: esto no es tráfico retail

La población es chica y concentrada. 34 senders distintos produjeron las 643 operaciones de Base, 30 en Ethereum, 28 en Optimism, 16 en Polygon, 7 en Unichain. Cincuenta y una transacciones de bundle cubrieron todo el día de Base, y en una muestra de 25 de ellas, diez eran transacciones de creación de contrato en vez de llamadas directas a handleOps: patrón de bundler, no de wallet.

La distribución de cobros dice lo mismo. En Base v0.8 el cobro por operación fue de 0,006766 USDC en el mínimo a 1.465,31 USDC en el máximo, con mediana de 8,53. Ese máximo fue una sola user operation, en el bloque 50634962, del sender 0x1979967a…; en ese mismo bundle a la cuenta le retiraron 24.029,41 USDC de prefund y le devolvieron 18.633,61.

No vamos a atribuir intención a direcciones que no podemos identificar. La medición se sostiene sola: en esta ventana, el uso dominante del rail de gas en USDC fueron un puñado de cuentas automatizadas moviendo sumas de seis cifras de USDC por un canal de fees cuyo costo de cadena subyacente fueron trescientos dólares. El cobro mínimo, 0,0068 USDC, es lo que parece una transferencia común. Ese es el número contra el que debería presupuestar un operador de agentes, y la razón por la que importa la brecha entre los dos es que nada en el diseño mantiene las operaciones de un agente en el extremo bajo.

El único cap que tiene tu agente es el permit

Junta las piezas desde la perspectiva de una wallet autónoma.

El USDC que puede salir por el canal de gas en una sola operación está acotado por un número: el value del permit EIP-2612 que la cuenta firmó para esa operación. El quickstart usa 10 USDC y re-firma por operación, que es el default correcto. Firma maxUint256 una vez —el atajo que toda integración tiene a mano, y el valor que el helper de permit importa por defecto— y habrás otorgado un allowance de USDC ilimitado y sin vencimiento a un contrato cuyo cobro es función de un precio de gas que no elegiste.

Nada más en el stack lo cubre. Los spend controls de cliente de x402 capean el monto de un pago; auditamos ese cap por defecto de un dólar y sus escapes cuando salió, y nunca ve una user operation. El SpendPermissionManager de Coinbase acumula un presupuesto por período para un spender, que medimos on-chain; el paymaster no es ese spender. Las Agent Wallets de la propia Circle documentan límites de gasto para transferencias salientes y pagos x402, que es otra superficie más. El canal de gas es la costura entre todas.

Qué hace distinto x402

El contraste no es "más barato". Es "quién tiene la lapicera sobre el fee".

El scheme exact de x402 en EVM abre con el diseño en una línea: "the Facilitator (server) pays the gas, but the Client (user) controls the exact flow of funds via cryptographic signatures." El pagador firma una autorización EIP-3009 por un monto exacto a un destinatario exacto. No hay campo de fee en lo que el pagador firma, así que no hay campo de fee que un adversario pueda inflar. La exposición del facilitator es su propio gas, y la spec le dice que lo acote: el scheme de Starknet enuncia la propiedad de forma explícita —"the facilitator/paymaster alone sets the outer INVOKE fee — so a client cannot directly inflate the sponsored gas"— e instruye a capear el fee de settlement patrocinado y aplicar rate limits por pagador.

Los dos rails no se conocen. En el HEAD del monorepo e398a9e5 (2026-08-28), la palabra "paymaster" aparece en trece archivos de x402-foundation/x402, doce de ellos bundles generados del paywall de navegador y el treceavo esa spec de Starknet. Donde x402 necesita patrocinar algo más allá de la transferencia, lo hace con sus propias extensiones —erc20ApprovalGasSponsoring y eip2612GasSponsoring— dentro del facilitator, no vía un paymaster.

Es una división coherente, y es la razón por la que un stack de agentes termina con las dos. x402 para la llamada paga. Un paymaster para todo lo demás que la cuenta tiene que hacer on-chain. El error es asumir que los caps configurados para la primera aplican a la segunda.

Qué significa para LLM4Agents

Nuestro gateway está del lado x402 de esta línea. Un agente paga por inferencia con una autorización firmada por un monto exacto; nunca fija un precio de gas, nunca tiene token nativo y nunca firma un allowance que sobreviva al request. El modo de falla que medimos acá —una cuenta a la que le cobran 1.465 USDC por una operación porque la operación declaró un precio de gas cuatro órdenes de magnitud arriba del de la cadena— no puede alcanzar a un pago por ese camino.

Sí puede alcanzar al agente, y esa es la parte que conviene decir con precisión. Los agentes que nos usan para inferencia también hacen otras cosas on-chain: se fondean, rebalancean, despliegan cuentas, interactúan con contratos que no son endpoints x402. En el momento en que la smart account de un agente firma un permit de paymaster, su balance de USDC —el mismo que financia sus llamadas a nosotros— queda expuesto por un canal que nuestros spend controls no observan. Un allowance de gas drenado se ve, de nuestro lado, como un agente que deja de pagar.

Hay un efecto de segundo orden sobre nuestra propia economía. Una infraestructura de fees en stablecoin que corre un loop de swap cada quince minutos con un colchón de menos de un ETH es una dependencia con ciclo de trabajo. Cualquier componente nuestro que asuma que un agente con smart account siempre puede incluir una transacción —helpers de settlement, flujos de recarga, cualquier cosa que espere una confirmación on-chain— tiene que tratar "el paymaster compartido está vacío" como estado esperado, no como incidente.

Cómo mantenerse en la frontera

1. Tratar el gas como categoría de gasto, no como plomería. Donde ayudemos a un agente a construir una user operation, el value del permit es el cap y hay que fijarlo por operación desde una estimación, nunca maxUint256. Es un cambio de cinco líneas con el mismo peso que un cap de pago, y es el único punto de enforcement que existe.

2. Acotar el precio de gas declarado, no solo el monto. Una operación cuyo maxFeePerGas está órdenes de magnitud arriba del base fee de la cadena es la firma del patrón que medimos. Rechazar operaciones por encima de un múltiplo del base fee actual —la misma disciplina que la spec de Starknet de x402 le prescribe a los facilitators— es barato de implementar y atrapa tanto bundlers hostiles como estimadores con bugs.

3. Instrumentar el canal de gas junto al de pagos. Ya emitimos atributos GenAI de OpenTelemetry para el costo de inferencia, que auditamos en agosto. Los cobros de UserOperationSponsored pertenecen al mismo libro, por agente, en la misma unidad. Un operador que ve "este agente gastó 4 USDC en inferencia y 40 en gas" lo arregla en un día; el que solo ve lo primero, no.

4. No convertir un paymaster compartido en dependencia dura. Donde un agente necesite una transacción con token nativo, preferir primero el camino facilitator-paga, caer al paymaster y fallar ruidosamente en vez de reintentar en silencio contra un deposit vacío. Publicar el chequeo: el balance del deposit y el tiempo desde la última recarga se leen con dos llamadas RPC.

5. Empujar el cap aguas arriba. La brecha que expone esta auditoría es estructural, no específica de Circle: ERC-4337 no tiene un techo de fee por operación que la cuenta pueda expresar, así que la única palanca es un allowance ERC-20 sin deadline. Un modo de paymaster que acepte un máximo firmado de cobro en token —el análogo del monto exacto de x402— lo cerraría. Eso es una propuesta que vale escribir más que un workaround que valga desplegar.

La lección general repite una que ya pegamos en esta serie. Los stacks de agentes acumulan canales que mueven dinero sin pasar por la capa de pagos: approvals, delegaciones, patrocinios, gas. Cada uno se firma una vez, se acota flojo y no lo audita nadie. El rail de pagos es la parte que todos miran. No es la parte con el número más grande adentro.