If you have used an onchain game or a fast moving trading app, you may have noticed something odd: after one initial approval, actions just happen. No signature popup for every move, no confirmation for every trade. That convenience usually comes from a session key, a limited permission your smart wallet hands out so an app can act on your behalf within strict boundaries, without ever touching your main key.
Our ERC-4337 explainer covered how smart wallets replace a single private key with a contract that can verify transactions in flexible ways. Session keys are one of the most common things that flexibility gets used for, so it is worth understanding them on their own.
The problem session keys solve
A traditional wallet has one key that can do everything: send any token, approve any contract, sign any message. That is fine when you make a handful of transactions a day. It becomes friction when an app wants to execute dozens of small actions quickly, a game moving a character, a trading bot placing orders, a music app streaming micropayments per second.
Asking for a full signature every time would make those apps unusable. The alternative used to be worse: hand the app your actual private key or a broad, unlimited approval and hope it behaves. Session keys give a third option, a separate key that is powerful enough to do the specific job and nothing else.
What a session key actually is
A session key is a second keypair that your smart contract wallet authorizes to act on its behalf, subject to rules the wallet enforces onchain. When you grant one, you are not exporting your main key or copying your recovery phrase. You are telling your smart account "let this other key sign transactions, but only if they match these conditions."
Typical conditions include:
- Which contracts it can call. A session key for a game is usually scoped to that game's contract address and nothing else.
- A spending limit. For example, a cap of a small, fixed amount of ETH or a specific token, so even a compromised session key cannot drain the wallet.
- An expiry time. Session keys are commonly valid for a few hours or a single sitting, not indefinitely.
- Allowed function calls. Some implementations restrict the key to specific functions on a contract, like "place an order" but not "withdraw funds."
The wallet contract checks these rules for every transaction the session key tries to sign. If a transaction falls outside the scope, the wallet rejects it, even if the session key's signature is technically valid.
Why this is different from a token approval
It is easy to confuse session keys with token approvals, but they solve different problems. A token approval lets a specific contract move a specific token up to a set amount, and it is enforced by the token contract itself. A session key is a signing credential enforced by your own wallet contract, and it can cover many kinds of actions, not just token transfers.
In practice, an app might use both: a token approval so a contract can pull funds when needed, and a session key so the app does not have to ask you to sign each individual transaction that triggers that pull.
What to check before granting one
Session keys are a real capability handed to a third party, so the same caution that applies to wallet signature requests and dapp connections applies here.
Before approving a session key request, it is worth looking for:
- A visible spending limit. If the interface does not show a cap, or the cap looks unusually high for what the app does, that is worth pausing on.
- A visible expiry. A session that never expires is a standing permission, not a temporary one.
- Scope to a single app. A session key scoped narrowly to one contract limits the damage if that app or your device is ever compromised.
- A way to revoke it. Reputable smart wallet interfaces let you view and cancel active sessions. If you cannot find that screen, look for it before relying on the app regularly.
None of this means session keys are risky in general. Enforced correctly by the wallet contract, a well scoped session key is arguably safer than a broad, permanent token approval, since it typically expires on its own and covers a narrower set of actions. The risk shows up when limits are set too loosely, or when an app requests a scope wider than the task actually needs.
Where you will run into them on Base
Session keys are more common in categories where transaction frequency matters: onchain games, some perpetuals and trading interfaces, and automated strategies that need to act without a person clicking approve each time. If you are using a standard passkey based smart wallet for everyday swaps and transfers, you may never encounter one directly, since a normal swap only needs a single signature anyway.
As more apps on Base adopt account abstraction, expect session key prompts to show up more often, usually worded as something like "allow this app to transact for you" with a duration and a spending cap attached. Reading that fine print is the same habit as checking any other approval: a minute spent confirming the scope is a lot cheaper than finding out later that it was wider than you thought.
Standardization across wallets is still catching up. The idea behind ERC-4337 session keys is consistent, but exactly how a given wallet displays limits, expiry, and revocation can vary between implementations, so it is worth getting familiar with your specific wallet's permissions screen rather than assuming every app presents the same controls.