For a closer look at the topic, consider erc 4337 session keys recurring payments alongside the options and criteria discussed below.
Managing recurring payments on-chain has always been a friction point for both users and developers. Traditional accounts require a signature for every single transaction, which means ongoing gas interactions, private key exposure, and a poor experience for subscription-based services. ERC-4337 changed that equation by introducing account abstraction at the bundler level, and when combined with session keys, it enables truly seamless recurring payment flows. This guide covers how these pieces fit together to power modern smart account subscriptions.
Why On-Chain Subscriptions Were Broken Before Account Abstraction
Ethereum’s original account model ties every transaction to an Externally Owned Account (EOA) signing each action individually. For one-off payments this works fine. For subscriptions it creates real problems. A SaaS platform charging monthly needs to execute a payment every cycle, but the user must sign every time or delegate full control to another address. Delegation is risky. Manual signing defeats the purpose of automation.
ERC-4337 introduced EntryPoint contracts that validate and execute transactions through a new lifecycle. UserOperations replace traditional transactions, allowing smart wallets to define their own authentication logic. The bundler network packages these operations and includes them in regular block transactions. This separation means the wallet contract itself decides what signatures are valid, opening the door for flexible authentication schemes like session keys.
How ERC-4337 Enables Session Keys
Session keys are restricted authorization tokens that let a spender or service interact with a smart wallet under predefined conditions. Instead of giving another address full access to funds, you grant limited permissions — a specific contract, a maximum spend amount, a time window. The smart account validates these restrictions before executing any UserOperation.
With ERC-4337, the validation happens inside the validateUserOp function of the smart wallet. This means session key logic can be encoded directly into the wallet contract. A typical setup looks like this:
| Component | Role |
|---|---|
| Smart Wallet | Holds funds, defines session key rules, executes UserOperations |
| Session Key Contract | Authorized spender with limited permissions set by the wallet owner |
| EntryPoint | Validates and bundles UserOperations from the session key contract |
| Bundler Network | Collects operations and submits them on-chain |
| Paymaster (optional) | Covers gas fees so the end user doesn’t need native token balance |
The wallet owner creates the session key through a single transaction, setting parameters like target contract address, allowed token amounts, expiration date, and cumulative spend limits. After that, the authorized contract can submit UserOperations on behalf of the wallet without requiring additional signatures from the owner.
Recurring Payment Architecture
A recurring payment system built on top of ERC-4337 consists of several coordinated components working together. The subscription provider deploys a smart contract that accepts payments. The user’s smart wallet authorizes this contract via a session key with appropriate spending caps. A scheduler triggers the payment cycle, and the provider submits a UserOperation through the bundler network.
Here is the flow step by step:
- User deploys or imports a smart wallet compatible with ERC-4337
- User creates a session key granting the subscription contract permission to withdraw up to a set amount per period
- The subscription contract schedules its next payment execution using on-chain timers or off-chain relayers
- When the payment cycle arrives, the subscription contract calls
eth_sendUserOperationthrough the bundler - EntryPoint validates the UserOperation against the smart wallet’s
validateUserOpfunction - The smart wallet checks that the caller is an authorized session key, the spend limit hasn’t been exceeded, and the request falls within the permitted timeframe
- If all checks pass, the transfer executes and the subscription renews
This architecture removes the need for continuous user interaction. Once the initial session key is created, recurring payments happen automatically. The user retains full control because the session key can be revoked at any time, and spending limits prevent overcharges.
On-Chain vs Off-Chain Scheduling
Scheduling recurring payments presents two approaches. On-chain schedulers use timelock contracts or chainlink keepers to trigger payments directly on Ethereum. This approach is fully decentralized and censorship-resistant but incurs gas costs for every scheduled check, even when no payment is needed.
Off-chain schedulers use relayers or bots that monitor subscription expiry times and submit UserOperations when needed. This is cheaper since only actual payments consume gas, but it introduces a small trust assumption around the relayer infrastructure. Most production systems combine both — on-chain timers for critical high-value subscriptions and off-chain relayers for routine low-value charges.
Paymasters and Gas Sponsorship for Subscriptions
One of the biggest barriers to subscription adoption is the requirement for users to hold native tokens for gas. ERC-4337 paymasters solve this by sponsoring gas fees in exchange for tokens or by absorbing costs as part of a business model. A paymaster contract attaches its signature to a UserOperation, telling EntryPoint that it will cover the gas.
For subscription services, paymasters enable a frictionless onboarding experience. New users can start a subscription without first acquiring ETH. The subscription provider can sponsor initial setup gas or implement a hybrid model where the paymaster covers routine payment gas while the user pays for wallet deployment and session key creation.
Paymasters also support context data passed alongside UserOperations. This allows conditional sponsorship logic — for example, sponsoring gas only for verified subscription payments above a certain threshold or during promotional periods.
Security Considerations
Session keys introduce attack surfaces that must be managed carefully. The primary risk is session key compromise. If the authorized contract gets exploited, attackers can drain funds up to the session key’s spending limit. Mitigation strategies include:
| Risk | Mitigation |
|---|---|
| Compromised session key contract | Set conservative per-transaction and cumulative spend limits |
| Unlimited duration keys | Always set expiration timestamps on session keys |
| Overly broad contract allowances | Restrict session keys to specific target contract addresses only |
| No withdrawal mechanism | Implement a cancel-or-revoke endpoint in the wallet contract |
| Reuse across multiple services | Create separate session keys for each subscription provider |
Smart wallet implementations should also include execution guards that monitor outgoing transfers and flag anomalous behavior. Some wallets integrate with insurance protocols that compensate users if funds are stolen due to smart contract vulnerabilities in the session key approval chain.
Implementation Patterns
Several well-established patterns exist for building ERC-4337-powered subscription systems. The most common involves a dedicated subscription manager contract that tracks user subscriptions, manages proration for mid-cycle cancellations, and coordinates with the ERC-4337 bundler network.
Another pattern uses batched UserOperations. Instead of submitting individual payment operations for each subscriber, a subscription platform can aggregate multiple payments into a single batched UserOperation. This reduces total gas costs significantly when processing hundreds or thousands of recurring charges simultaneously.
Wallet integrations matter too. Popular ERC-4337-compatible wallets like Safe{Wallet}, Account Abstraction SDK implementations, and custom-built smart wallets each handle session key creation differently. Some use multi-signature layouts for session key authorization, adding an extra layer of security for high-value subscriptions. Others rely on social recovery mechanisms that let users restore wallet control if their session key management infrastructure goes offline.
Getting Started
Building an ERC-4337 subscription system requires understanding the interaction between smart wallets, the EntryPoint contract, bundlers, and optional paymasters. The core stack typically includes a wallet SDK for creating and managing smart accounts, a session key authorization module, a subscription management contract, and integration with a bundler provider for UserOperation submission.
Testing should cover edge cases: expired session keys, exceeded spend limits, revoked keys still attempting to submit operations, and concurrent UserOperations from the same session key. The EntryPoint contract rejects invalid operations, but catching failures early in development saves significant debugging time.
The combination of ERC-4337 account abstraction, session key authorization, and paymaster gas sponsorship creates a foundation for subscription models that were previously impractical on blockchain networks. Users get automatic payments without constant signing. Providers get reliable recurring revenue without manual collection. The infrastructure is mature enough for production deployment today.