Session Keys and Smart Wallets: How Ethereum Is Making Crypto Payments Feel Like Apple Pay

Every crypto payment today begins with a popup. Connect your wallet. Approve the token. Confirm the transaction. Wait for confirmation. Pay gas. For a user who has tapped their phone at a coffee shop and watched Apple Pay settle in two seconds, this is not a minor inconvenience: it is a dealbreaker. Session keys are Ethereum's answer to this problem. By letting users grant scoped, temporary permissions to applications, session keys eliminate per-transaction approvals and bring crypto payments closer to the "authenticate once, spend within limits" model that consumers already expect.

The infrastructure enabling this shift is account abstraction, specifically ERC-4337 and the newer EIP-7702. Together, they transform Ethereum wallets from simple key-pair signers into programmable accounts with modular permissions, gas sponsorship, and batch execution. This article breaks down how session keys work, who is building with them, and what the security model actually looks like.

What Are Session Keys?

A session key is a secondary cryptographic key with limited, scoped authority delegated from a user's primary smart wallet. Instead of signing every transaction with the master private key, the user signs once to authorize a session key with constrained permissions. The session key then signs subsequent transactions on the user's behalf within those constraints, with no further prompts required.

Think of it like a hotel key card. The master key opens every door in the building. A session key opens one specific room, only during your stay, and stops working at checkout. If someone steals the card, they get access to one room for a limited time: not the entire hotel.

What Scopes Can Be Defined?

Session key permissions are composable. A wallet or dApp can combine multiple constraints to define exactly what a session key is allowed to do:

• Target contract addresses: the key can only interact with specified contracts
• Function selectors: restrict calls to specific functions (e.g., only swap() on a DEX, only transfer() on a token)
• Spending caps: maximum amounts per transaction or per session (e.g., $500 per transaction, $5,000 per session)
• Time limits: automatic expiry after 24 hours, one week, or a custom duration
• Token type restrictions: limit which tokens the key can move
• Chain restrictions: confine the key to a specific L2 or mainnet

Key insight: Session keys invert the approval model. Traditional wallets ask "do you approve this specific transaction?" before every action. Session keys ask "do you approve this category of transactions for this time period?" once upfront. The security boundary shifts from individual transaction signing to scope definition.

The ERC-4337 Infrastructure Stack

Session keys do not work with traditional Ethereum externally owned accounts (EOAs). They require account abstraction: the ability to define custom validation logic for transactions. ERC-4337, deployed with its first EntryPoint contract in March 2023, provides this infrastructure without requiring changes to the Ethereum protocol itself.

Core Components

The ERC-4337 stack has four moving parts, each playing a specific role in making session keys possible:

• UserOperations: pseudo-transaction objects that describe what a user wants to do. Unlike regular transactions, UserOps can be signed by any key the smart account's validation logic recognizes: including session keys
• EntryPoint: a singleton smart contract that validates and executes bundles of UserOperations. The EntryPoint v0.7.0 (deployed mid-2024) reduced calldata costs by consolidating gas and paymaster fields
• Bundlers: nodes that collect UserOperations from a dedicated mempool, validate them, and package them into standard Ethereum transactions for on-chain submission
• Paymasters: smart contracts that pay gas fees on behalf of users, enabling gasless transactions or payment in ERC-20 tokens instead of ETH

By April 2026, approximately 62 million smart accounts had been deployed across EVM chains, with over 2.4 billion UserOperations processed. Base, Polygon, and Optimism lead in adoption. In 2024, 87% of all UserOperations were gas-sponsored by paymasters: users paid nothing for gas in the overwhelming majority of smart wallet transactions.

Why Paymasters Matter for Payments

Gas sponsorship is the silent enabler of consumer crypto payments. No mainstream payment system asks users to pay a separate infrastructure fee on top of their purchase. When you tap Apple Pay at a terminal, you pay the price of your coffee: not the coffee plus a variable network fee denominated in a different currency.

Paymasters eliminate this friction. A merchant or application deposits ETH into a paymaster contract, which then covers gas for its users' transactions. On L2s where most consumer apps deploy in 2026, sponsoring a user's first ten operations typically costs the application under $1 total. Infrastructure providers like Pimlico, Alchemy, and Biconomy have collectively relayed hundreds of millions of sponsored transactions.

How Session Keys Work Under the Hood

When a user creates a session key, the smart wallet stores a mapping between the session key's public key and its permission scope. The flow works like this:

1. The dApp requests a session with specific permissions (target contracts, spending caps, duration)
2. The user reviews the scope and signs once with their primary key (via biometric, passkey, or password) to authorize the session
3. The wallet generates or registers the session key and stores its permission constraints on-chain or in a validation module
4. For subsequent transactions within scope: the dApp constructs a UserOperation and signs it with the session key. No user interaction required
5. The smart account's validation logic checks: is this session key valid? Does this operation fall within its permitted scope? If yes, execution proceeds
6. When the session expires or the spending cap is reached, the key automatically becomes invalid

Standards in progress: Two complementary draft EIPs define the session key architecture. ERC-7715 defines the request layer: how a dApp asks a wallet for permissions using JSON-RPC methods like wallet_requestExecutionPermissions. ERC-7710 defines the execution layer: the on-chain delegation manager that validates and enforces those permissions. Both are in Draft status as of September 2026, but already have production implementations.

The Security Model: Limiting the Blast Radius

The fundamental security question with session keys is: what happens if one is compromised? The answer is the defining advantage of the model: the blast radius is contained by design.

Session Key vs. EOA Compromise

If an attacker compromises a traditional EOA's private key, they gain total, permanent control over all assets. Every token, every NFT, every approval: everything is exposed. The user's only recourse is to move assets to a new address (if they notice in time).

A compromised session key, by contrast, gives the attacker access to only the narrowly scoped permissions that were granted:

• Can only spend up to the remaining cap (not the full wallet balance)
• Can only call whitelisted contracts and functions
• Cannot access tokens or contracts outside the defined scope
• Cannot change account ownership, recovery settings, or guardians
• Automatically expires at the preset time
• Can be revoked by the account owner at any time

The Approval Drain Problem

Coinbase's engineering team discovered an important nuance while building session key support for their Smart Wallet. If a smart account has existing token approvals (e.g., unlimited allowances granted to a DEX), a session key could potentially exploit those approvals to drain tokens: even without explicit permission to interact with those tokens.

This led Coinbase to pivot away from traditional session keys toward Sub Accounts: hierarchical, app-specific accounts where each application gets its own isolated address. Combined with Spend Permissions (launched December 2024), Sub Accounts prevent cross-contamination between approval scopes. A compromised app account cannot access approvals belonging to another.

UX Comparison: Apple Pay vs. Session Key Payments

Apple Pay's payment flow is the gold standard for consumer payments. Understanding how it works reveals both what session keys replicate and where they diverge.

Apple Pay's Flow

When a user taps their phone at a payment terminal, the following happens in roughly two to three seconds:

1. The NFC antenna detects the terminal
2. The device prompts for biometric authentication (Face ID or Touch ID)
3. The Secure Element generates a one-time dynamic security code
4. A tokenized card number (Device Account Number, stored only in tamper-resistant hardware) and the dynamic code are transmitted to the terminal
5. The real card number is never shared with the merchant

The key insight: Apple Pay requires biometric authentication for every transaction, but the authentication is so fast and integrated into the physical gesture of tapping that it feels frictionless.

Session Key Payment Flow

A session-key-enabled crypto payment works differently:

1. The user authenticates once (biometric, passkey, or password) to create a session key with defined spending limits
2. For subsequent transactions within scope: the application submits UserOperations signed by the session key with zero user interaction
3. A paymaster sponsors gas, so no ETH balance is needed
4. The session expires after its time limit or when the spending cap is exhausted

For single in-store purchases, Apple Pay's biometric-per-transaction model is hard to beat. But for use cases involving repeated, small-value transactions (in-game purchases, streaming payments, subscription renewals, micropayments), session keys offer a fundamentally smoother experience: authenticate once, then transact freely within limits.

Who Is Building Smart Wallet Session Keys

The session key ecosystem spans wallet infrastructure providers, smart account frameworks, and consumer-facing wallets. Approaches differ significantly in architecture.

Biconomy: Modular Smart Sessions

Biconomy's Smart Sessions module provides a validation layer for their Modular Smart Account. The Session Key Manager verifies whether each UserOperation adheres to the permissions defined within the session. Their implementation is multichain-first: a single signature can install sessions across multiple chains, enabling cross-chain session keys that work on Ethereum mainnet, Arbitrum, and Base simultaneously.

ZeroDev: Composable Permissions

ZeroDev's Kernel wallet (v3, built for EntryPoint v0.7) decomposes session keys into three composable primitives. Signers define who can sign (ECDSA key, WebAuthn passkey). Policies define when the key can be used (time bounds, rate limits). Actions define what execution functions the key can invoke. Developers combine these primitives to build fine-grained permission schemes without writing custom validation logic.

Safe: ERC-7579 Module System

Safe{Wallet} added session key support through the Safe7579 Adapter, developed with Rhinestone. This adapter makes Safe accounts compliant with the ERC-7579 modular account standard, enabling session key validators, passkey signers, spending limit executors, and cross-chain execution hooks. As of early 2026, the Rhinestone module registry lists 14 audited modules including social recovery and dead man switches.

Coinbase: The Sub Account Approach

Coinbase initially built session key support for their Smart Wallet, then pivoted to Sub Accounts after identifying the approval drain risk. Their model uses hierarchical account ownership: a user's universal wallet owns app-specific sub-accounts, each isolated at the address level. Combined with Spend Permissions, this provides session-key-like UX with stronger isolation guarantees. Sub Accounts went live on Base mainnet in Q2 2025.

Privy: Embedded Wallet Infrastructure

Privy provides embedded wallet infrastructure where users sign up via email, phone, social login, or passkeys. Under the hood, Privy creates non-custodial embedded wallets using Shamir Secret Sharing with TEE infrastructure. Their smart wallet layer acts as an aggregator: applications choose which ERC-4337 account implementation powers their users' wallets (Kernel, Safe, Biconomy, or others), inheriting that implementation's session key capabilities. After Stripe's acquisition of Privy in June 2025, this infrastructure now sits inside the payment platform powering millions of merchants.

EIP-7702: Smart Wallet Features for Every Account

The Ethereum Pectra upgrade (May 7, 2025) introduced EIP-7702, which fundamentally changes the smart wallet landscape. EIP-7702 allows any existing EOA to temporarily delegate its execution logic to a smart contract. A new transaction type (0x04) writes a delegation indicator to the EOA's code field, instructing the EVM to execute smart contract code at a specified address.

The practical impact: the billions of existing Ethereum EOAs can now gain smart wallet features (session keys, gas sponsorship, batch execution) without migrating to a new address. Since the Pectra launch, approximately 14 million EOAs have signed at least one EIP-7702 authorization.

ERC-4337 and EIP-7702 are complementary. ERC-4337 is for new smart contract accounts built from scratch. EIP-7702 is for upgrading existing EOAs. Both can plug into the same bundler and paymaster infrastructure. MetaMask's Delegation Toolkit already implements ERC-7710 delegation for 7702-enabled EOAs, giving MetaMask users access to session keys without switching wallets.

What This Means for Crypto Payments

Session keys unlock payment patterns that were previously impossible or impractical in crypto:

• Subscription billing: a user grants a session key that allows a merchant to pull a fixed amount of stablecoins monthly, mimicking card-on-file recurring charges
• In-game economies: players authorize a session key scoped to a game contract, enabling in-game purchases and trades without wallet popups interrupting gameplay
• Agentic payments: AI agents operating with session keys can execute transactions within defined budgets, a use case Coinbase is pursuing with their Agentic Wallets launched in February 2026
• Point-of-sale: a mobile wallet creates a short-lived session key when entering a store, enabling tap-and-go payments at checkout without per-transaction signing
• DeFi automation: users authorize session keys for specific DeFi protocols, enabling automated rebalancing or yield harvesting without granting unlimited token approvals

Tradeoffs and Open Questions

Complexity for Developers

The session key ecosystem is fragmented. Biconomy, ZeroDev, Safe, and Coinbase each implement permissions differently. ERC-7715 and ERC-7710 aim to standardize the request and execution layers, but both remain in Draft status. Developers building payment applications today must choose a stack and accept the risk that standards may shift.

Privacy Limitations

Every session-key-signed transaction lands on a public blockchain. Apple Pay shares only a tokenized card number with merchants: the real card number never leaves the device. Crypto payments expose transaction amounts, counterparties, and wallet balances to anyone watching the chain. L2s and privacy-preserving techniques can mitigate this, but the gap remains significant for consumer adoption.

Trust in Paymaster Infrastructure

Gasless transactions depend on paymaster availability and solvency. If a paymaster runs out of deposited ETH or goes offline, user transactions fail. This introduces a centralized dependency that does not exist in traditional EOA transactions where users pay their own gas.

A Different Approach: Protocol-Level Simplicity

Ethereum's session key infrastructure is impressive engineering, but it is also a multi-layer solution to a problem that stems from Ethereum's base-layer design. EOAs were never built for payments. Smart contract wallets, bundlers, paymasters, and session key modules are all patches applied on top of that original architecture.

Spark takes a different approach. Built on Bitcoin as a Layer 2, Spark achieves frictionless payment UX through protocol-level design rather than smart contract middleware. There are no gas fees, no approval popups, no token allowances to manage. Transfers settle instantly at the protocol layer. The user experience is simple by default, not simple because layers of infrastructure abstract away underlying complexity.

For developers building payment applications, the Spark SDK provides direct access to instant Bitcoin and stablecoin transfers without needing to integrate bundlers, paymasters, or session key modules. Wallets like General Bread demonstrate what this looks like in practice: a consumer-facing wallet where payments feel native, not bolted on.

Both approaches are converging on the same user expectation: crypto payments should feel as natural as tapping a phone at a terminal. Ethereum is getting there through programmable wallets and delegated permissions. Spark is getting there through protocol simplicity. For a deeper comparison of how different blockchains handle payment finality, see our payment finality comparison.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.