Sponsored fees still need a source of execution funding, and wallet recovery needs a working design. This guide follows an ERC-4337 request from authorization to execution, explains who can pay the gas, and shows which conditions a recovery feature must satisfy.
Follow one request from the wallet to the chain
ERC-4337 introduces a UserOperation and supporting infrastructure without requiring consensus-layer changes for that mechanism. The account can use programmable validation rules, while the request passes through three main stages:
- The wallet prepares a UserOperation. It describes the requested calls and supplies the authorization data required by the account. The account's implementation determines how that authorization is checked.
- A bundler submits operations to an EntryPoint contract. The bundler packages the requests into an on-chain transaction. A bundler is not automatically a network validator.
- EntryPoint coordinates validation, execution and fee accounting. The account and any paymaster must satisfy the relevant checks. Actual fields, encodings and compatible contracts depend on the deployed version.
A real integration needs encoded calldata, valid addresses, signatures and the complete required structure. Multiple EntryPoint deployments or versions may exist, so a description of the flow is not transaction data ready to submit.
Who pays when the wallet offers sponsored fees?
The underlying gas is funded in the chain's native asset. A paymaster can support sponsorship under its own conditions. An arrangement may instead collect another token from the user while funding gas in the native asset. A paymaster can impose limits, pricing or refusal conditions.
When comparing a fee offer, check which calls it covers, what the user is charged, and what happens when sponsorship ends. The ERC-4337 label alone does not answer those questions; the wallet and service terms do.
Recovery: a two-of-three example
Suppose a hypothetical wallet requires two of three guardians and a two-day delay to replace a signer. Recovery works only if the mechanism was deployed and configured, enough guardians remain available, and the replacement follows the actual contract rules.
| In this hypothetical design | What the rule implies |
|---|---|
| Two guardians are available | The threshold can be met, subject to the configured recovery process and two-day delay. |
| Only one guardian is available | That guardian alone cannot meet the stated threshold. |
| Two guardians collude | The same threshold may let them attempt an unwanted signer replacement under the contract's rules. |
The example makes the trade-off visible: the people who can help restore access may also have enough authority to threaten it. A recovery feature must be assessed through its actual thresholds, delays and control rules.
Check the other promised features
- Scheduled payments: a rule can authorize a payment, but a transaction still needs an external trigger and execution funding. A contract does not wake up by itself on the first of the month.
- Spending limits: check which tokens, calls and time window a limit covers, and who can change it.
- Account control: read the installed implementation, upgrade authority, recovery policy, session permissions and fees. Features depend on the deployed wallet and its configuration; account abstraction does not automatically install recovery or make funds immune to loss.
Continue with permissions and delegation
EIP-7702 lets an existing externally owned account delegate code. It is distinct from ERC-4337, and compatible implementations can use the two together.
Next guide: To distinguish token allowances, session keys and persistent code delegation, read EIP-7702 and ERC-4337: Persistent Delegation and Wallet Permissions. That guide focuses on who has authority, how long it lasts and how its end condition is checked.
This explanation is educational; it does not certify a particular wallet as safe.
Revision history
19 October 2026: Corrected absolute EOA and gas-sponsorship claims; distinguished optional wallet features from ERC-4337 guarantees and added EIP-7702 context. The earlier phrases “buy NFT” and “use USDC for gas” described a conceptual sketch, not valid transaction data.
Editorial update — 20 October 2026: Reorganized the guide around execution, fee funding and recovery conditions. Expanded the existing hypothetical recovery example into a conditional comparison and moved detailed correction notes here. The original publication date and URL are retained.