Session Key

A session key is a temporary, limited-permission key that lets apps sign transactions on a user's behalf without repeated approvals.

Key Takeaways

A session key is a temporary cryptographic key with scoped permissions that lets applications sign transactions on behalf of a user's smart wallet without requiring approval for every action.
Session keys work through account abstraction (ERC-4337): the smart account's onchain validation logic enforces constraints like spending limits, contract allowlists, function restrictions, and time-based expiry.
If a session key is compromised, the damage is bounded by its permission scope: unlike a leaked private key, an attacker cannot access funds or functions beyond the session's defined boundaries.

What Is a Session Key?

A session key is a temporary, limited-authority cryptographic key pair that an application uses to sign blockchain transactions on behalf of a user. Instead of the user confirming every transaction through their wallet, they approve a set of permissions once, and the session key handles subsequent signing autonomously within those boundaries.

The concept addresses a fundamental UX problem in crypto: every onchain action traditionally requires a wallet popup, transaction review, and manual confirmation. For applications that involve frequent transactions (blockchain games, trading interfaces, subscription services, or AI agent workflows), this creates an unusable experience. A game requiring 50 moves per session means 50 wallet popups.

Session keys solve this by separating the user's primary key (which retains full authority) from a disposable key that can only perform specific, pre-approved actions. The user's primary key never leaves their control. The session key is a separate key pair whose authority is enforced by the smart account's validation logic onchain: not by a backend, not by the application, but by contract code that cannot be bypassed.

How It Works

Session keys require a smart account rather than a standard externally owned account (EOA). This is because permission enforcement demands programmable validation logic in the account contract itself, which is the core innovation of account abstraction.

The lifecycle of a session key follows these steps:

The application generates a new key pair or the user creates one and shares the public key with the application
The user signs a permission grant (offchain, zero gas cost) that defines what the session key is allowed to do
The application stores the session key locally (browser, server, or agent) and uses it to sign UserOperations under ERC-4337
When a bundler submits the UserOperation, the smart account's session key validator checks the transaction against the stored permission constraints
If all checks pass, the transaction executes. If any constraint is violated, the transaction reverts onchain

The permission grant is signed offchain by the account owner, so creating a session key costs no gas. Revoking one does require an onchain transaction, though in most cases the key simply expires at its predefined time boundary.

Permission Parameters

Session keys enforce granular constraints that define exactly what the key is authorized to do. The specific parameters vary by implementation, but the common set includes:

Parameter	Description
Time bounds	Start and end timestamps controlling when the session key is active. Keys automatically become invalid after expiry.
Contract allowlist	Restricts which contract addresses the session key can interact with. A key scoped to a DEX router cannot call a lending protocol.
Function selectors	Limits which specific functions the key can invoke on allowed contracts. A key might be restricted to only `swap()` on a DEX, not `approve()` or `transfer()`.
Spending limits	Maximum ETH or ERC-20 token amounts the session can transfer. Can be cumulative or reset on a daily, weekly, or monthly basis.
Operation count	Maximum number of transactions the session key can execute before becoming invalid.
Argument constraints	Rules applied to function arguments using operators like EQUAL, GREATER_THAN, or LESS_THAN, enabling fine-grained control over call parameters.

The onchain validation flow typically checks these in order: time bounds, operation count, spending limit, contract allowlist, function selector, and then argument constraints.

Permission Standards

Two draft ERC standards aim to create a common interface for session key permissions across wallets and SDKs:

ERC-7715 defines a JSON-RPC method (wallet_grantPermissions) that lets a dApp request scoped, time-bounded permissions from a wallet. It standardizes the request and grant flow between applications and wallets.
ERC-7710 defines the onchain execution layer: how smart contracts delegate capabilities to other contracts or key pairs through a DelegationManager. When a session key holder submits a transaction, the DelegationManager verifies the delegation chain.

Both standards remain in draft status as of mid-2026. Multiple production implementations exist (MetaMask, Biconomy, Rhinestone, Alchemy), but interoperability across different SDKs is still limited.

Code Example

A simplified example showing how an application might create and use a session key with a smart account SDK:

// Define session key permissions
const sessionKeyPermissions = {
  validAfter: Math.floor(Date.now() / 1000),
  validUntil: Math.floor(Date.now() / 1000) + 3600, // 1 hour
  permissions: [
    {
      target: "0xDEX_ROUTER_ADDRESS",
      functionSelector: "0x38ed1739", // swapExactTokensForTokens
      valueLimit: 0n,
      rules: [
        {
          param: 0,                    // amountIn
          operator: "LESS_THAN",
          value: parseEther("100"),    // max 100 tokens per swap
        },
      ],
    },
  ],
};

// Owner signs the permission grant (offchain, no gas)
const sessionKey = await account.createSessionKey(sessionKeyPermissions);

// Application uses the session key to sign transactions
const userOp = await sessionKey.sendTransaction({
  to: "0xDEX_ROUTER_ADDRESS",
  data: encodeFunctionData({
    abi: routerAbi,
    functionName: "swapExactTokensForTokens",
    args: [amountIn, amountOutMin, path, recipient, deadline],
  }),
});

The owner's primary key never touches the swap transactions. The session key signs them autonomously, and the smart account's onchain validator enforces every constraint.

Session Keys vs. Token Approvals

Session keys are sometimes compared to token approvals (ERC-20 approve()), but they differ fundamentally in scope, safety, and expiry:

Aspect	Token Approval	Session Key
Scope	Grants a specific contract permission to spend one token	Grants a key permission to call defined functions on defined contracts with value caps
Expiry	No built-in expiration (infinite by default)	Time-bounded by design with hard expiry timestamps
Granularity	Token, spender, and amount only	Contract allowlists, function selectors, argument constraints, spending limits, operation counts
Revocation	Requires an onchain transaction setting approval to zero	Can be revoked onchain or allowed to expire automatically
Attack surface	A compromised approved contract can drain all approved tokens	A compromised session key is bounded by its permission constraints

An infinite ERC-20 approval is a permanent onchain attack surface with no ceiling and no expiry. A session key grant is bounded by spending caps and hard time limits, and it disappears automatically when the grant expires.

Use Cases

Blockchain Gaming

Games require dozens or hundreds of transactions per session: moving characters, attacking, trading items, crafting. Without session keys, each action triggers a wallet popup. With a session key scoped to the game contract's specific functions (with spending limits on in-game token transfers), gameplay becomes seamless. The key expires when the session ends.

DeFi Automation

Yield strategies, rebalancing, and limit orders often require transactions at unpredictable times. A session key can authorize a vault contract or keeper bot to execute specific DeFi operations (harvesting rewards, rebalancing positions) within defined value thresholds. This eliminates the need for the user to be online and actively confirming every operation.

AI Agent Wallets

As AI agents gain the ability to transact onchain, session keys provide the constraint layer that prevents an agent from exceeding its mandate. An agent authorized to make purchases up to $50 per transaction on specific contracts cannot suddenly drain the wallet or interact with unapproved protocols.

Subscription Payments

Session keys can authorize recurring payments to a specific address for a defined amount on a set schedule. Unlike traditional token approvals that grant open-ended spending authority, a session key can enforce per-period caps (such as 10 USDC per month to a subscription contract) with automatic expiry at the end of the subscription term.

Implementations

Several smart account SDKs and wallet infrastructure providers offer session key implementations:

ZeroDev provides session keys through their Kernel smart account, supporting offchain permission signing, serializable keys, argument-level constraints, and paymaster restrictions
Biconomy and Rhinestone co-developed the SmartSessions module for ERC-7579 compatible accounts, supporting action-specific policies and ERC-7715 integration
Alchemy offers session keys through Modular Account V2, with session creation via their wallet API
MetaMask's Delegation Toolkit implements ERC-7715 and ERC-7710 for requesting and redeeming delegations
Safe supports permission logic through Safe Modules, including spending limit enforcement and contract allowlists

With EIP-7702 (shipped in Ethereum's Pectra upgrade in 2025), existing EOAs can temporarily delegate to a smart contract implementation, gaining session key capability without migrating funds or changing addresses. This removed a major adoption barrier.

Risks and Considerations

Existing Approval Abuse

If a user previously granted a token approval to a contract, a session key with access to that contract could abuse the existing approval. For example, a session key authorized to call a DEX router could exploit a prior infinite approve() to drain tokens. This limitation led some teams (notably Base) to explore alternative architectures like sub-accounts with isolated approval scopes.

Paymaster Drain

Without proper paymaster restrictions in the session key permissions, a malicious key holder could spam transactions with inflated gas fees, draining the account's native token balance or paymaster deposit. Best practice is to always configure paymaster requirements unless the operator is fully trusted.

Fragmentation

Each account abstraction SDK implements session keys differently. There is no cross-SDK standard for permission format, storage, or revocation. A session key created with one provider cannot be used with another. ERC-7715 and ERC-7710 aim to solve this, but both remain drafts.

Key Storage Risks

Session keys must be stored somewhere accessible to the application: browser local storage, a server, or an agent's memory. Each storage location has its own threat model. Browser storage is vulnerable to XSS attacks. Server storage introduces a centralized point of compromise. Proper key management practices remain essential even for temporary keys.

Permission Scope Misjudgment

Granting overly broad permissions defeats the purpose of session keys. A key with unlimited spending, no time expiry, and access to all contracts is functionally equivalent to a full private key. Applications must design permission scopes carefully, and users should review permission grants with the same scrutiny they apply to token approvals.

Why It Matters

Session keys represent a shift from all-or-nothing authorization to granular, time-bounded permissions in crypto wallets. Traditional EOAs offer two states: full control or no control. Session keys introduce a middle ground where applications can act within precisely defined boundaries, bringing crypto wallet UX closer to the seamless experience users expect from traditional web applications.

For ecosystems focused on self-custody and programmable payments, session keys are a building block for making onchain interactions invisible to end users. When a user can authorize a payment app to handle transactions within safe limits, the underlying blockchain mechanics fade into the background: exactly the kind of experience that drives mainstream adoption. Read more about how embedded wallet UX patterns are evolving to reduce friction for end users.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.