AGENTWALLETS · INDEPENDENT PERSPECTIVES
ERC-4337: Following an Agent Payment from UserOperation to Receipt
Understand the account, bundler, EntryPoint and paymaster roles behind ERC-4337, including gas sponsorship and failed-operation handling.
Quick answer
ERC-4337 is an account-abstraction standard that routes UserOperations through bundlers and an EntryPoint contract. The account supplies authorization logic, and an optional paymaster covers gas under its own conditions. It does not itself define an agent spending policy or prove that a merchant delivered an order.
A purchasing agent has a valid instruction to pay an invoice. Its account has the payment token, but no native gas token. The product team wants to sponsor the network fee and let the account enforce who may submit the payment. ERC-4337 provides a transaction path for this design, with several separate points where the operation can fail.
Research boundary: official documentation reviewed November 1, 2026. ERC-4337 is Final. This is an architectural walkthrough, not a wallet benchmark or a report of a transaction we executed.
Four roles behind one payment button
Under ERC-4337, an application prepares a UserOperation for an account. A bundler packages eligible operations into a transaction sent to an EntryPoint contract. The account’s validation logic decides whether an operation is authorized. A paymaster may agree to cover gas.
The roles should remain visible in an integration design. The account holds the payment authority; the bundler provides inclusion infrastructure; the EntryPoint coordinates validation and execution; the paymaster decides whether to fund the network fee. A successful response from one role is not confirmation from all the others.
Conceptual ERC-4337 path, not a test result. The authorization node represents preparing account-valid authorization; onchain validation still occurs through EntryPoint.
Keep spending rules in the account design
The standard leaves signature interpretation to the account implementation. That flexibility enables different authorization models, but an integration cannot infer “agent-safe” permissions from an ERC-4337 label. An unrestricted signer and a narrowly constrained session signer may use the same submission infrastructure.
For the invoice buyer, write an authorization specification before choosing an SDK: which payment contract may be called, which token is allowed, who may sign, and how authority ends. Then identify the account code or policy component enforcing each requirement. A prompt telling the agent to obey a budget is useful task context, but it is not the enforcing component.
The component documentation explains the account’s relationship with a particular EntryPoint. Record the chain, EntryPoint address/version, account implementation and bundler support together. A working example for another version is not a compatibility test for this combination.
Sponsoring gas creates a second budget
The paymaster documentation describes sponsorship eligibility checks and gas funding. Those conditions are separate from the account’s permission to buy the invoice. The account may authorize a payment that the sponsor refuses; a sponsor’s willingness to pay gas does not authorize the purchase.
A practical product therefore needs two accounting views: value paid to merchants and execution costs paid by the sponsor or user. Decide what happens when sponsorship is unavailable. Falling back to a user-funded operation can change the cost presented at approval, so it should be an explicit product rule rather than an invisible retry.
| Observed stage | What the application should establish |
|---|---|
| Operation accepted by an RPC endpoint | It was received, not necessarily included |
| Simulation rejected | Which account, paymaster or deployment condition failed |
| Bundle transaction included | The individual operation’s result, not just the outer transaction |
| Payment execution confirmed | The merchant’s order and delivery state |
This is a proposed diagnostic model, not observed output from a specific provider.
Treat simulation as a checkpoint
Bundler simulation guidance covers checking account, deployment and paymaster behavior before submission. For an agent service, preserve the diagnostic result alongside the intended action. If a retry changes the nonce, sponsor terms or payload, it is no longer sufficient to reuse the previous “looks valid” decision.
Do not make a new invoice purchase just because receipt polling timed out. Keep a business-operation identifier separate from the UserOperation and transaction identifiers, then reconcile the outstanding attempt. This lets support distinguish “not yet observed” from “known to have failed” without asking the model to guess.
Where ERC-4337 fits
ERC-4337 is useful when programmable account validation and an adaptable gas-payment path are important to the application. Its operational cost is a larger integration surface: account code, bundler, EntryPoint and any sponsor all need explicit versioning and failure handling.
For an agent payment product, the acceptance test should finish at an invoice-linked result, not at the first returned hash. Read the ERC-4337 directory reference, then compare the permission-request layer in ERC-7715 and the retry model in payment idempotency.
FOLLOW THE SOURCES